Page MenuHome

Blender 2.8 Crashing on Alembic export of fluid animation past 80 frames
Closed, ResolvedPublic


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).

Event Timeline

Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.

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?

Philipp Oeser (lichtwerk) raised the priority of this task from Needs Information from User to Needs Triage by Developer.

should be investigated though

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:

Address : 0x00007FF779532410
Module  : E:\3D\Blender\blender-2.80.0-git.8996e26116f0-windows64\blender.exe
Sebastian Parborg (zeddb) triaged this task as Normal priority.

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$447

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.

Crashing here too while exporting fluid simulation to alembic.

@LazyDodo (LazyDodo) looks like a good fix to me, I'll commit that soon.

Seems like a duplicate of T52814.