System Information
Operating system: Win 10
Graphics card: 2 GTX 1080 Ti, 1 GTX 780
Blender Version
2.8 Beta
Short description of error
Simple fluid sim with resolution of 235 and length of 280 frames is crashing blender on export to Alembic.
I am only able to get the export working if kept under 80 frames.
Exact steps for others to reproduce the error
Based on the default startup or an attached .blend file (as simple as possible).
If I try export with a debug build I get the following assert:
BLI_assert failed: blender/source/blender/blenkernel/intern/DerivedMesh.c:2192, mesh_get_eval_final(), at 'ob->id.tag & LIB_TAG_COPIED_ON_WRITE'
However, that is not a fatal error. So with a release build, I seem to be able to export to alembic without any crashes (with a build from today).
Could you try a recent build and see if this is still an issue for you?
Unfortunately export to Alembic is still crashing for me on Blender Beta 2.8.
I tried 2 Beta versions, 2.8 dated December 23’rd 21:42 (hash e5e885d0ecb9) and January 23’rd 00:32 (hash dc3b5024be1a).
The 12/23 version crashed at about 16%. The 1/23 version crashed almost immediately, never getting past 1 or 2%.
I have the same issue with the 2019-01-27 2.8 beta.
Pegot's scene crash around 28%
Mine at start (1%)
Win10 x64 (v1607) console output:
find_node component: Could not find ID OBIcosphere add_node_handle_relation(Fluidsim Object) - Could not find op_from (ComponentKey(OBIcosphere, TRANSFORM))
Then it waits a few seconds, then it crashes with this:
Error : EXCEPTION_ACCESS_VIOLATION Address : 0x00007FF779532410 Module : E:\3D\Blender\blender-2.80.0-git.8996e26116f0-windows64\blender.exe
While I can't reproduce this on my end, it seems like most windows users can. So I'll mark this as Normal
I can repro this with both the builds from the buildbot and local builds.
after disabling the problematic asserts i end up with this stack trace after a while
blender.exe!Alembic::Util::v10::MurmurHash3_x64_128(void const *,unsigned __int64,unsigned __int64,void *) C++ blender.exe!Alembic::AbcCoreAbstract::v10::ArraySample::getKey(void) C++ blender.exe!Alembic::AbcCoreOgawa::v10::ApwImpl::setSample(class Alembic::AbcCoreAbstract::v10::ArraySample const &) C++ blender.exe!Alembic::Abc::v10::OArrayProperty::set(class Alembic::AbcCoreAbstract::v10::ArraySample const &) C++ blender.exe!Alembic::AbcGeom::v10::SetPropUsePrevIfNull<class Alembic::Abc::v10::OTypedArrayProperty<struct Alembic::Abc::v10::V3fTPTraits>,class Alembic::Abc::v10::TypedArraySample<struct Alembic::Abc::v10::V3fTPTraits> >(class Alembic::Abc::v10::OTypedArrayProperty<struct Alembic::Abc::v10::V3fTPTraits>,class Alembic::Abc::v10::TypedArraySample<struct Alembic::Abc::v10::V3fTPTraits>) C++ blender.exe!Alembic::AbcGeom::v10::OPolyMeshSchema::set(class Alembic::AbcGeom::v10::OPolyMeshSchema::Sample const &) C++ > blender.exe!AbcGenericMeshWriter::writeMesh(Mesh * mesh=0x000000000ae465e8) Line 457 C++ blender.exe!AbcGenericMeshWriter::do_write() Line 386 C++ blender.exe!AbcObjectWriter::write() Line 107 C++ blender.exe!AbcExporter::operator()(float & progress=0.353571415, bool & was_canceled=false) Line 333 C++ blender.exe!export_startjob(void * customdata=0x000000000a0bc038, short * stop=0x000000000a233cac, short * do_update=0x000000000a233caa, float * progress=0x000000000a233cb0) Line 271 C++ blender.exe!do_job_thread(void * job_v=0x000000000a233c38) Line 330 C blender.exe!tslot_thread_start(void * tslot_p=0x0000000005e90cb8) Line 251 C [External Code]
it's a use after free bug ASAN will catch it if you can't repro
over here the velocities variable goes out of scope, but m_mesh_sample retains a dangling pointer to it which later gets de-referenced which never leads to good things
moving the declaration of velocities of above the if (m_is_liquid) line fixes the issue for me.
but i'll let @Sybren A. Stüvel (sybren) judge if this is a proper fix or not.
@LazyDodo (LazyDodo) looks like a good fix to me, I'll commit that soon.
Seems like a duplicate of T52814.