Crash using operator panel with quick smoke #55048

New Issue

Tim Roberts · 2018-05-13T09:32:41+02:00

Tim Roberts commented

2018-05-13 09:32:41 +02:00

System Information
system-info.txt

Blender Version
Broken: 2.79.4 c84b8d4801
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
blender.crash.txt
terminal_session.txt

**System Information** [system-info.txt](https://archive.blender.org/developer/F3355456/system-info.txt) **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 [blender.crash.txt](https://archive.blender.org/developer/F3355514/blender.crash.txt) [terminal_session.txt](https://archive.blender.org/developer/F3355519/terminal_session.txt)

Tim Roberts commented

2018-05-13 09:32:41 +02:00

Added subscriber: @Timaroberts

Lukas Ziechmann commented

2018-05-13 10:03:41 +02:00

Added subscriber: @LukasZiechmann

Lukas Ziechmann commented

2018-05-13 10:03:41 +02:00

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.

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.

Philipp Oeser commented

2018-05-13 12:16:55 +02:00

Added subscribers: @ideasman42, @lichtwerk

Campbell Barton was assigned by Philipp Oeser

2018-05-13 12:16:55 +02:00

Philipp Oeser commented

2018-05-13 12:16:55 +02:00

@LukasZiechmann: 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 @ideasman42

@LukasZiechmann: 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)

@LukasZiechmann: 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 @ideasman42 @LukasZiechmann: 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)

Lukas Ziechmann commented

2018-05-13 20:11:13 +02:00

@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!