Crash when baking particles using python #78624

New Issue

Gary Oberbrunner · 2020-07-05T01:51:40+02:00

Gary Oberbrunner commented

2020-07-05 01:51:40 +02:00

System Information
Operating system: Linux Ubuntu 18.04 in WSL1
Graphics card: GTX970

Blender Version
Broken: 2.90.0 Alpha (hash cad98923d0 built 2020-07-03 23:12:15)
Worked: unknown

Short description of error
I have a complex Python script that takes some external data and creates a blend file, using blender python. It's non-interactive, run from the command line.
It's been working fine, until today when I added this line to my python script:

bpy.ops.ptcache.bake_all(True)

to bake the simulation, and now it crashes right after baking the last frame (240 total frames, one particle node).

I rebuilt from today's master branch as a debug build, same result.

Crash log looks like this. All I can note is the ED_undo_push call in the stack.

# Blender 2.90.0, Commit date: 2020-07-04 15:31, Hash 464aaf27016f

# backtrace
/c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender(BLI_system_backtrace+0x35) [0xd69d3b3]
/c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x3061dfb]
/c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x306201f]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fc7c624ef20]
/c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender(ED_undo_push+0xbf) [0x41e1a16]
/c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender(ED_undo_push_op+0x2a) [0x41e23e3]
/c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x34fcd98]
/c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x34fdffb]
/c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x34fe62b]
/c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender(WM_operator_call_py+0x95) [0x34fe909]

I did try disabling undo earlier in the script with bpy.context.preferences.edit.undo_steps=0 but that didn't change anything.

Exact steps for others to reproduce the error
There's a bunch of external data required to repro this; I know that's not ideal. I can package it all up for you, there's nothing proprietary.
But I'm also willing to debug it on my side, which might be faster. I'm not a core blender developer but my C/C++ and debugging skills are decent.

Is there any way to get more detail from the above stack trace? Since it's a debug build ("make debug" on linux) I was expecting file/line info.

I tried running under gdb but it didn't work; I'm invoking blender as "...blender -b --python foo.py -- arg1 arg2" but when I do that with gdb I get "No module named 'keyframe'" so I'm guessing it's not getting the right $PYTHONPATH.

**System Information** Operating system: Linux Ubuntu 18.04 in WSL1 Graphics card: GTX970 **Blender Version** Broken: 2.90.0 Alpha (hash cad98923d006 built 2020-07-03 23:12:15) Worked: unknown **Short description of error** I have a complex Python script that takes some external data and creates a blend file, using blender python. It's non-interactive, run from the command line. It's been working fine, until today when I added this line to my python script: ```python ``` bpy.ops.ptcache.bake_all(True) ``` ``` to bake the simulation, and now it crashes right after baking the last frame (240 total frames, one particle node). I rebuilt from today's master branch as a debug build, same result. Crash log looks like this. All I can note is the `ED_undo_push` call in the stack. ``` # Blender 2.90.0, Commit date: 2020-07-04 15:31, Hash 464aaf27016f # backtrace /c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender(BLI_system_backtrace+0x35) [0xd69d3b3] /c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x3061dfb] /c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x306201f] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fc7c624ef20] /c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender(ED_undo_push+0xbf) [0x41e1a16] /c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender(ED_undo_push_op+0x2a) [0x41e23e3] /c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x34fcd98] /c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x34fdffb] /c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender() [0x34fe62b] /c/dss/Product/Horizon/ext-sources/blender/blender-official/build_linux_debug/bin/blender(WM_operator_call_py+0x95) [0x34fe909] ``` I did try disabling undo earlier in the script with `bpy.context.preferences.edit.undo_steps=0` but that didn't change anything. **Exact steps for others to reproduce the error** There's a bunch of external data required to repro this; I know that's not ideal. I can package it all up for you, there's nothing proprietary. But I'm also willing to debug it on my side, which might be faster. I'm not a core blender developer but my C/C++ and debugging skills are decent. Is there any way to get more detail from the above stack trace? Since it's a debug build ("make debug" on linux) I was expecting file/line info. I tried running under gdb but it didn't work; I'm invoking blender as "...blender -b --python foo.py -- arg1 arg2" but when I do that with gdb I get "No module named 'keyframe'" so I'm guessing it's not getting the right $PYTHONPATH.

Gary Oberbrunner commented

2020-07-05 01:51:40 +02:00

Added subscriber: @garyo

Gary Oberbrunner commented

2020-07-05 02:13:55 +02:00

OK, I got it running under gdb. Here's the backtrace:

Thread 1 "blender" received signal SIGSEGV, Segmentation fault.
0x00000000041e1a16 in ED_undo_push (C=0x7ffffc072e88, str=0xe87fc5c "Bake All Physics")
    at /c/dss/Product/Horizon/ext-sources/blender/blender-official/blender/source/blender/editors/undo/ed_undo.c:95
95        if ((steps <= 0) && wm->undo_stack->step_init != NULL) {
(gdb) where
#0  0x00000000041e1a16 in ED_undo_push (C=0x7ffffc072e88, str=0xe87fc5c "Bake All Physics")
    at blender/source/blender/editors/undo/ed_undo.c:95
#1  0x00000000041e23e3 in ED_undo_push_op (C=0x7ffffc072e88, op=0x7fffe9717108)
    at blender/source/blender/editors/undo/ed_undo.c:301
#2  0x00000000034fcd98 in wm_operator_finished (C=0x7ffffc072e88, op=0x7fffe9717108, repeat=false, store=true)
    at blender/source/blender/windowmanager/intern/wm_event_system.c:925
#3  0x00000000034fdffb in wm_operator_invoke (C=0x7ffffc072e88, ot=0x7fffea17d648, event=0x0, properties=0x7ffffffebe40,
    reports=0x7fffcdf70008, poll_only=false, use_last_properties=true)
    at blender/source/blender/windowmanager/intern/wm_event_system.c:1320
#4  0x00000000034fe62b in wm_operator_call_internal (C=0x7ffffc072e88, ot=0x7fffea17d648, properties=0x7ffffffebe40, reports=0x7fffcdf70008,
    context=6, poll_only=false, event=0x0)
    at blender/source/blender/windowmanager/intern/wm_event_system.c:1532
#5  0x00000000034fe909 in WM_operator_call_py (C=0x7ffffc072e88, ot=0x7fffea17d648, context=6, properties=0x7ffffffebe40,
    reports=0x7fffcdf70008, is_undo=true)

At this point steps is 0, and wm->undo_stack is 0x0, so it's dereferencing a null pointer there.

Note that this is in a CLI app, no GUI is running, in case that makes a difference.

The code around this line is this:

101
102       /* Only apply limit if this is the last undo step. */
103       if (wm->undo_stack->step_active && (wm->undo_stack->step_active->next == NULL)) {
104         BKE_undosys_stack_limit_steps_and_memory(wm->undo_stack, steps - 1, 0);
105       }
106

If I disable undo it crashes in a slightly different place, line 95:

90         * Note that some modes (paint, sculpt) initialize an undo step before an action runs,
91         * then accumulate changes there, or restore data from it in the case of 2D painting.
92         *
93         * For this reason we need to handle the undo step even when undo steps is set to zero.
94         */
95        if ((steps <= 0) && wm->undo_stack->step_init != NULL) {
96          steps = 1;
97        }

OK, I got it running under gdb. Here's the backtrace: ``` Thread 1 "blender" received signal SIGSEGV, Segmentation fault. 0x00000000041e1a16 in ED_undo_push (C=0x7ffffc072e88, str=0xe87fc5c "Bake All Physics") at /c/dss/Product/Horizon/ext-sources/blender/blender-official/blender/source/blender/editors/undo/ed_undo.c:95 95 if ((steps <= 0) && wm->undo_stack->step_init != NULL) { (gdb) where #0 0x00000000041e1a16 in ED_undo_push (C=0x7ffffc072e88, str=0xe87fc5c "Bake All Physics") at blender/source/blender/editors/undo/ed_undo.c:95 #1 0x00000000041e23e3 in ED_undo_push_op (C=0x7ffffc072e88, op=0x7fffe9717108) at blender/source/blender/editors/undo/ed_undo.c:301 #2 0x00000000034fcd98 in wm_operator_finished (C=0x7ffffc072e88, op=0x7fffe9717108, repeat=false, store=true) at blender/source/blender/windowmanager/intern/wm_event_system.c:925 #3 0x00000000034fdffb in wm_operator_invoke (C=0x7ffffc072e88, ot=0x7fffea17d648, event=0x0, properties=0x7ffffffebe40, reports=0x7fffcdf70008, poll_only=false, use_last_properties=true) at blender/source/blender/windowmanager/intern/wm_event_system.c:1320 #4 0x00000000034fe62b in wm_operator_call_internal (C=0x7ffffc072e88, ot=0x7fffea17d648, properties=0x7ffffffebe40, reports=0x7fffcdf70008, context=6, poll_only=false, event=0x0) at blender/source/blender/windowmanager/intern/wm_event_system.c:1532 #5 0x00000000034fe909 in WM_operator_call_py (C=0x7ffffc072e88, ot=0x7fffea17d648, context=6, properties=0x7ffffffebe40, reports=0x7fffcdf70008, is_undo=true) ``` At this point `steps` is 0, and `wm->undo_stack` is 0x0, so it's dereferencing a null pointer there. Note that this is in a CLI app, no GUI is running, in case that makes a difference. The code around this line is this: ``` 101 102 /* Only apply limit if this is the last undo step. */ 103 if (wm->undo_stack->step_active && (wm->undo_stack->step_active->next == NULL)) { 104 BKE_undosys_stack_limit_steps_and_memory(wm->undo_stack, steps - 1, 0); 105 } 106 ``` If I disable undo it crashes in a slightly different place, line 95: ``` 90 * Note that some modes (paint, sculpt) initialize an undo step before an action runs, 91 * then accumulate changes there, or restore data from it in the case of 2D painting. 92 * 93 * For this reason we need to handle the undo step even when undo steps is set to zero. 94 */ 95 if ((steps <= 0) && wm->undo_stack->step_init != NULL) { 96 steps = 1; 97 } ```

Gary Oberbrunner commented

2020-07-05 02:27:47 +02:00

Headless build also fails.

Gary Oberbrunner commented

2020-07-05 15:16:02 +02:00

This fixes it for me, but I don't know if it has any other impact. I see a few other source files where this same condition is checked (e.g. ed_util.c, sculpt.c, wm.c) so I'm guessing it's safe.

@@ -84,6 +84,10 @@ void ED_undo_push(bContext *C, const char *str)
   wmWindowManager *wm = CTX_wm_manager(C);
   int steps = U.undosteps;
 
+  if (wm->undo_stack == NULL) {
+    return;
+  }
+
   /* Ensure steps that have been initialized are always pushed,
    * even when undo steps are zero.
    *

This fixes it for me, but I don't know if it has any other impact. I see a few other source files where this same condition is checked (e.g. ed_util.c, sculpt.c, wm.c) so I'm guessing it's safe. ``` @@ -84,6 +84,10 @@ void ED_undo_push(bContext *C, const char *str) wmWindowManager *wm = CTX_wm_manager(C); int steps = U.undosteps; + if (wm->undo_stack == NULL) { + return; + } + /* Ensure steps that have been initialized are always pushed, * even when undo steps are zero. * ```

Philipp Oeser commented

2020-07-06 12:31:58 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-07-06 12:31:58 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Philipp Oeser commented

2020-07-06 12:31:58 +02:00

Thx for investigating!
Could you share a minimal example script that leads to the crash?
(this will make it much easier for devs looking into this to reproduce. thx in advance!)

Thx for investigating! Could you share a minimal example script that leads to the crash? (this will make it much easier for devs looking into this to reproduce. thx in advance!)

Gary Oberbrunner commented

2020-07-09 03:53:51 +02:00

It's super easy to repro:

blender -b --python-expr 'import bpy; bpy.ops.ptcache.bake_all(True)'

Without above fix:

Blender 2.90.0 Alpha (hash 464aaf27016f built 2020-07-08 21:15:13)
found bundled python: ...ext-sources/blender/blender-official/build_linux_headless-NOFIX/bin/2.90/python
Writing: /tmp/blender.crash.txt
[1]    6628 segmentation fault (core dumped)  ...build_linux_headless-NOFIX/bin/blender -b --python-expr

With above fix:

% ~3/build_linux_headless-FIX/bin/blender -b --python-expr 'import bpy; bpy.ops.ptcache.bake_all(True)'
Blender 2.90.0 Alpha (hash 464aaf27016f built 2020-07-08 00:47:33)
found bundled python: .../ext-sources/blender/blender-official/build_linux_headless-FIX/bin/2.90/python

Blender quit

It's super easy to repro: `blender -b --python-expr 'import bpy; bpy.ops.ptcache.bake_all(True)'` Without above fix: ``` Blender 2.90.0 Alpha (hash 464aaf27016f built 2020-07-08 21:15:13) found bundled python: ...ext-sources/blender/blender-official/build_linux_headless-NOFIX/bin/2.90/python Writing: /tmp/blender.crash.txt [1] 6628 segmentation fault (core dumped) ...build_linux_headless-NOFIX/bin/blender -b --python-expr ``` With above fix: ``` % ~3/build_linux_headless-FIX/bin/blender -b --python-expr 'import bpy; bpy.ops.ptcache.bake_all(True)' Blender 2.90.0 Alpha (hash 464aaf27016f built 2020-07-08 00:47:33) found bundled python: .../ext-sources/blender/blender-official/build_linux_headless-FIX/bin/2.90/python Blender quit ```

blender-admin commented

2020-07-19 10:59:14 +02:00

This issue was referenced by ccd2af43b3

This issue was referenced by ccd2af43b3ab83dc873010faade1b2916553291a

Campbell Barton commented

2020-07-19 11:01:40 +02:00

Changed status from 'Needs User Info' to: 'Resolved'

Campbell Barton closed this issue

2020-07-19 11:01:40 +02:00

Campbell Barton self-assigned this 2020-07-19 11:01:40 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crash when baking particles using python #78624