Page MenuHome

Crash rendering particle animation with particle caches [disk cache works though]
Closed, ResolvedPublicBUG

Description

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71

Blender Version
Broken: version: 2.91.0 Beta, branch: master, commit date: 2020-11-14 03:36, hash: rB9b54c8141480
Worked: 2.90.1
Worked: 2.83.9
Caused by rB263148dbacc4: Depsgraph: refactor tagging after time changes

Short description of error
Rendering an animation with two particle systems using Cycles or Eevee results in a crash

Stack trace:
blender.exe         :0x00007FF7C378C910  ptcache_particle_read
blender.exe         :0x00007FF7C378D0A0  ptcache_read
blender.exe         :0x00007FF7C3789BC0  BKE_ptcache_read
blender.exe         :0x00007FF7C3783780  system_step
blender.exe         :0x00007FF7C377D870  particle_system_update
blender.exe         :0x00007FF7C39FED20  deformVerts
blender.exe         :0x00007FF7C37B1F70  mesh_calc_modifiers
blender.exe         :0x00007FF7C37B1CB0  mesh_build_data
blender.exe         :0x00007FF7C37B1AF0  makeDerivedMesh
blender.exe         :0x00007FF7C37DB030  BKE_object_handle_data_update
blender.exe         :0x00007FF7C37DAD60  BKE_object_eval_uber_data
blender.exe         :0x00007FF7C740BE30  std::_Func_impl_no_alloc<std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph * __ptr64,Main * __p
blender.exe         :0x00007FF7C740A210  blender::deg::`anonymous namespace'::evaluate_node
blender.exe         :0x00007FF7C740A1C0  blender::deg::`anonymous namespace'::deg_task_run_func
tbb.dll             :0x00007FFEDBA351D0  tbb::interface7::internal::isolate_within_arena
blender.exe         :0x00007FF7C748E410  tbb::internal::function_task<Task>::execute
tbb.dll             :0x00007FFEDBA437A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll             :0x00007FFEDBA437A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
blender.exe         :0x00007FF7C3A565E0  tbb::internal::task_group_base::wait
blender.exe         :0x00007FF7C7409D50  blender::deg::deg_evaluate_on_refresh
blender.exe         :0x00007FF7C36DAFF0  scene_graph_update_tagged
blender.exe         :0x00007FF7C3862730  wm_event_do_notifiers
blender.exe         :0x00007FF7C384D2F0  WM_main
blender.exe         :0x00007FF7C35596E0  main
blender.exe         :0x00007FF7C79B3888  __scrt_common_main_seh
KERNEL32.DLL        :0x00007FFEEB787020  BaseThreadInitThunk
ntdll.dll           :0x00007FFEED51CEA0  RtlUserThreadSta

Exact steps for others to reproduce the error

  1. Open the project file attached below
  2. Render the animation

Workaround

  • enable Render > Lock Interface or
  • bake to disk cache

Event Timeline

Robert Guetzkow (rjg) changed the task status from Needs Triage to Needs Information from User.Tue, Nov 17, 10:00 AM

According to the crash log it happens when accessing the particle cache. The CUDA/OptiX denoiser problem seems like a separate issue. Please try to create a minimal version of the project that still results in a crash and upload it here.

The hint with the particles helped a lot to reduce the scene to a minimum and get a closer idea of what is causing the trouble. It only crashes if disk cache is unchecked, but if I bake to disk cache it does not crash anymore. Anyway, here's the file:

Robert Guetzkow (rjg) changed the task status from Needs Information from User to Needs Triage.Wed, Nov 18, 4:51 PM

I can reproduce the crash regardless of the denoiser in 2.91+, 2.83.9 works fine. This seems to be an issue with the particle system cache or how it's processed. Using Delete All Bakes and then Bake All Dynamics on both particle systems doesn't make a difference. However, Delete All Bakes, enabling Disk Cache and then Bake All Dynamics appears to avoid the crash.

ptcache_particle_read(int index, void * psys_v, void * * data, float cfra, const float * old_data) Lines 345	C
ptcache_read(PTCacheID * pid, int cfra) Lines 2183	C
BKE_ptcache_read(PTCacheID * pid, float cfra, bool no_extrapolate_old) Lines 2313	C
system_step(ParticleSimulationData * sim, float cfra, const bool use_render_params) Lines 4516	C
particle_system_update(Depsgraph * depsgraph, Scene * scene, Object * ob, ParticleSystem * psys, const bool use_render_params) Lines 4934	C
deformVerts(ModifierData * md, const ModifierEvalContext * ctx, Mesh * mesh, float[3] * vertexCos, int numVerts) Lines 229	C
mesh_calc_modifiers(Depsgraph * depsgraph, Scene * scene, Object * ob, int useDeform, const bool need_mapping, const CustomData_MeshMasks * dataMask, const int index, const bool use_cache, const bool allow_shared_mesh, Mesh * * r_deform, Mesh * * r_final) Lines 991	C
mesh_build_data(Depsgraph * depsgraph, Scene * scene, Object * ob, const CustomData_MeshMasks * dataMask, const bool need_mapping) Lines 1806	C
makeDerivedMesh(Depsgraph * depsgraph, Scene * scene, Object * ob, BMEditMesh * em, const CustomData_MeshMasks * dataMask) Lines 1927	C
BKE_object_handle_data_update(Depsgraph * depsgraph, Scene * scene, Object * ob) Lines 194	C
BKE_object_eval_uber_data(Depsgraph * depsgraph, Scene * scene, Object * ob) Lines 385	C
 	[External Code]	
blender::deg::`anonymous namespace'::deg_task_run_func(TaskPool * pool, void * taskdata) Lines 127	C++
 	[External Code]	
tbb::interface7::internal::isolate_impl<void,void <Lambdafunktion>(void) const>(const Task::()::__l2::void <Lambdafunktion>(void) & f) Lines 160	C++
Task::operator()() Lines 122	C++
tbb::internal::function_task<Task>::execute() Lines 1049	C++
 	[External Code]	
tbb::internal::task_group_base::wait() Lines 168	C++
blender::deg::deg_evaluate_on_refresh(blender::deg::Depsgraph * graph) Lines 398	C++
scene_graph_update_tagged(Depsgraph * depsgraph, Main * bmain, bool only_if_tagged) Lines 2592	C
wm_event_do_depsgraph(bContext * C, bool is_after_open_file) Lines 356	C
wm_event_do_refresh_wm_and_depsgraph(bContext * C) Lines 384	C
wm_event_do_notifiers(bContext * C) Lines 562	C
WM_main(bContext * C) Lines 641	C
main(int argc, const unsigned char * * UNUSED_argv_c) Lines 527	C
 	[External Code]

@Bernhard Engstler (B_Engstler) Do you know how you managed to create the file where the particle cache seemingly breaks 2.91 and 2.92?

Robert Guetzkow (rjg) updated the task description. (Show Details)
Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Thu, Nov 19, 11:56 AM
Philipp Oeser (lichtwerk) changed the subtype of this task from "Report" to "Bug".

Will check

Robert Guetzkow (rjg) renamed this task from Crash rendering animation in Cycles - EXCEPTION_ACCESS_VIOLATION; Adress 0x00007FF7C378C987 to Crash rendering particle animation in Cycles.Thu, Nov 19, 11:59 AM
Robert Guetzkow (rjg) updated the task description. (Show Details)

Forgot that I need to fix my CUDA installation, thus cannot fully bisect, but it broke between rB940b239ad473 (good) an rBe4932d1167f4 (bad)

I just recreated a very basic scene with only one emitter (default cube) and another subdivided and displaced cube as particle object. To me it seems that somehow it is related to change the emitter object on a mesh level and baking again, e.g. deleting a face, bake again, safe file, render. But I'm not 100% sure, this seems very erratic.


This basic scene crashes immediately upon opening and rendering (Ctrl F12).

For me, ani_SH_180_v004_bE_debug seems to survive if I have Render > Lock Interface checked.

@Bernhard Engstler (B_Engstler) : can you confirm?

For me, ani_SH_180_v004_bE_debug seems to survive if I have Render > Lock Interface checked.

@Bernhard Engstler (B_Engstler) : can you confirm?

Yes! It rendered a couple of times now without crashing and locked interface, unchecking it crashes during first render attempt. It also crashes with CPU rendering for me.

It also crashes with CPU rendering for me.

For me, too [that means I can do the bisect though :)]

Philipp Oeser (lichtwerk) renamed this task from Crash rendering particle animation in Cycles to Crash rendering particle animation with particle caches [disk cache works though].Thu, Nov 19, 2:20 PM
Philipp Oeser (lichtwerk) triaged this task as High priority.
Philipp Oeser (lichtwerk) updated the task description. (Show Details)
Philipp Oeser (lichtwerk) updated the task description. (Show Details)

CC @Jacques Lucke (JacquesLucke) (feel free to set back to lower prio, just letting you know this is bisected and a regression in 2.91 from 2.90.1)

Not sure how rB263148dbacc4 caused this regression, but D9606 seems to fix the threading issue.

This comment was removed by Robert Guetzkow (rjg).

I can confirm this fixes the problem. In my previous comment I didn't notice that this was not yet merged into master.