Blender 2.8 Crashing on Alembic export of fluid animation past 80 frames #58686

New Issue

Peter Gotlib · 2018-12-04T06:28:43+01:00

Peter Gotlib commented

2018-12-04 06:28:43 +01:00

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).
Blender-2.8-Fluid-test.7z

**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). [Blender-2.8-Fluid-test.7z](https://archive.blender.org/developer/F5807375/Blender-2.8-Fluid-test.7z)

Peter Gotlib commented

2018-12-04 06:28:43 +01:00

Added subscriber: @pegot

Sebastian Parborg commented

2019-01-04 16:11:32 +01:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-01-04 16:11:32 +01:00

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?

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 commented

2019-01-15 13:03:13 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-01-15 13:03:13 +01:00

should be investigated though

Sebastian Parborg commented

2019-01-23 12:52:48 +01:00

@lichtwerk so can you reproduce this?

Peter Gotlib commented

2019-01-23 18:10:19 +01:00

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 e5e885d0ec) and January 23’rd 00:32 (hash dc3b5024be).

The 12/23 version crashed at about 16%. The 1/23 version crashed almost immediately, never getting past 1 or 2%.

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

sebastien commented

2019-01-29 17:24:02 +01:00

Added subscriber: @sebastientricoire

sebastien commented

2019-01-29 17:24:02 +01:00

I have the same issue with the 2019-01-27 2.8 beta.
Pegot's scene crash around 28%
Mine at start (1%)

I have the same issue with the 2019-01-27 2.8 beta. Pegot's scene crash around 28% Mine at start (1%)

Sebastian Parborg commented

2019-02-01 14:18:48 +01:00

Added subscriber: @LazyDodo

Sebastian Parborg commented

2019-02-01 14:18:48 +01:00

@LazyDodo can you reproduce this?

Demeter Dzadik commented

2019-02-06 16:52:52 +01:00

Added subscriber: @Mets

Demeter Dzadik commented

2019-02-06 16:52:52 +01:00

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

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 ```

Sybren A. Stüvel was assigned by Sebastian Parborg

2019-02-06 18:00:39 +01:00

Sebastian Parborg commented

2019-02-06 18:00:39 +01:00

While I can't reproduce this on my end, it seems like most windows users can. So I'll mark this as Normal

While I can't reproduce this on my end, it seems like most windows users can. So I'll mark this as `Normal`

Ray molenkamp commented

2019-02-06 20:20:09 +01:00

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]

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] ```

Ray molenkamp commented

2019-02-06 21:20:19 +01:00

it's a use after free bug ASAN will catch it if you can't repro

https://developer.blender.org/diffusion/B/browse/master/source/blender/alembic/intern/abc_mesh.cc$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 @dr.sybren judge if this is a proper fix or not.

it's a use after free bug ASAN will catch it if you can't repro https://developer.blender.org/diffusion/B/browse/master/source/blender/alembic/intern/abc_mesh.cc$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 @dr.sybren judge if this is a proper fix or not.

Artur Tavares commented

2019-02-10 02:39:49 +01:00

Added subscriber: @artutava