Page MenuHome

Crash using operator panel with quick smoke
Closed, ResolvedPublic


System Information

Blender Version
Broken: 2.79.4 c84b8d48019
Worked: (optional)

Short description of error
Blender is crashing when using operator panel or F6 to change quick smoke from smoke to fire or smoke+fire
Exact steps for others to reproduce the error

  • With default scene, add quick smoke to cube.
  • F6/operator panel to change smoke style to fire or smoke+fire (choosing smoke causes crash as well)
  • Crash



Event Timeline

Lukas Ziechmann (bl_cat) triaged this task as Confirmed, Medium priority.

It doesn't crash for me - but if I switch to smoke+fire the scene freezes for a fraction of a second and in the console the following is printed:

loadTile: No noise tile '/tmp/blender_oVxHhr/noise.wavelets' found.
Generating new 3d noise tile size=128^3
saveTile: Noise tile file '/tmp/blender_oVxHhr/noise.wavelets' saved.
Generating new 3d noise done

So I guess there goes something wrong while opening/saving this noise.wavelets file - maybe your system runs out of memory, but definitely something a developer should have a look at.

@Lukas Ziechmann (bl_cat): What you are seeing is actually nothing to worry about afaik. Did you test this in master? Or 2.79 official release?

Because in master there is indeed a real crash, relating to the UNDO refactor:

1  mesh_undosys_step_decode           editmesh_undo.c      768   0x1c6b0ac 
2  undosys_step_decode                undo_system.c        174   0x276d121 
3  BKE_undosys_step_undo_with_data_ex undo_system.c        529   0x276e628 
4  BKE_undosys_step_undo_with_data    undo_system.c        544   0x276e75c 
5  ed_undo_step                       ed_undo.c            126   0x186d711 
6  ED_undo_pop_op                     ed_undo.c            189   0x186d8ee 
7  ED_undo_operator_repeat            ed_undo.c            344   0x186de08

In BKE_undosys_step_undo_with_data() the UndoStep is still "Quick Smoke"
but gets changed in BKE_undosys_step_undo_with_data_ex() to "Enter Editmode"
Then in mesh_undosys_step_decode() the MeshUndoStepObject->obedit_ref.ptr is NULL

We have a couple of reports relating to the UNDO refactor (I should really familiarize with the system more), but for now assigning to @Campbell Barton (campbellbarton)

@Lukas Ziechmann (bl_cat): btw: I sometimes forget this myself, but note that it's always best to have someone to assign the report to when you triage as "confirmed" (otherwise chances are higher the report gets skipped in searches)

@Philipp Oeser (lichtwerk) : Sorry - Yes, I just tested it with the 2.79b-official release where it works fine. And I didn't know I was allowed to just assign confirmed bugs to someone - I guess always to the relevant module owner, right? Thanks for pointing all this out!