bpy.ops.script.reload() seg fault #80694

New Issue

Tomasz Dysinski · 2020-09-11T12:14:34+02:00

Tomasz Dysinski commented

2020-09-11 12:14:34 +02:00

System Information
Operating system: Darwin-19.5.0-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 5500M OpenGL Engine ATI Technologies Inc. 4.1 ATI-3.9.15

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-08-11 20:18, hash: ec5f392087
Worked: (newest version of Blender that worked as expected)

Short description of error
Simply running bpy.ops.script.reload() causes a seg fault. Not always, but usually the second or third time I run it. I have tested with no unofficial addons installed.
Running F3 > Reload Scripts works fine.

terminal output:
Writing: /var/folders/9j/s986zj3575d_p6ns3hqf3sn00000gn/T/blender.crash.txt

58385 segmentation fault ./Blender

blender.crash.txt

Exact steps for others to reproduce the error
open blender
run bpy.ops.script.reload() in the console

**System Information** Operating system: Darwin-19.5.0-x86_64-i386-64bit 64 Bits Graphics card: AMD Radeon Pro 5500M OpenGL Engine ATI Technologies Inc. 4.1 ATI-3.9.15 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-08-11 20:18, hash: `ec5f392087` Worked: (newest version of Blender that worked as expected) **Short description of error** Simply running `bpy.ops.script.reload()` causes a seg fault. Not always, but usually the second or third time I run it. I have tested with no unofficial addons installed. Running F3 > Reload Scripts works fine. terminal output: Writing: /var/folders/9j/s986zj3575d_p6ns3hqf3sn00000gn/T/blender.crash.txt - [x] 58385 segmentation fault ./Blender [blender.crash.txt](https://archive.blender.org/developer/F8864886/blender.crash.txt) **Exact steps for others to reproduce the error** open blender run bpy.ops.script.reload() in the console

Tomasz Dysinski commented

2020-09-11 12:14:34 +02:00

Added subscriber: @bunnybones

Robert Guetzkow commented

2020-09-11 12:38:19 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Robert Guetzkow commented

2020-09-11 12:59:53 +02:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-09-11 12:59:53 +02:00

The execution of CONSOLE_OT_execute results in a mangled data structure of the operator op after wm_operator_invoke calls rna_operator_execute_cb through retval = op->type->exec(C, op);. Subsequent access to the operator's data structure result in the crash.

The execution of `CONSOLE_OT_execute` results in a mangled data structure of the operator `op` after `wm_operator_invoke` calls `rna_operator_execute_cb` through `retval = op->type->exec(C, op);`. Subsequent access to the operator's data structure result in the crash.

Dalai Felinto commented

2020-09-11 16:21:28 +02:00

Added subscriber: @dfelinto

Dalai Felinto commented

2020-09-11 16:21:28 +02:00

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

Dalai Felinto commented

2020-09-11 16:21:28 +02:00

I cannot reproduce it in Linux with 2.83, 2.90 or master (2.91 to be).

Can either @bunnybones or @rjg check what was the latest working version of Blender where this doesn't crash? Lowering the priority to normal until we figure this out. Specially since this only happens when running this via the console (not via the UI).

And @rjg if you manage to crash in a debug build can you share the complete backtrace?

I cannot reproduce it in Linux with 2.83, 2.90 or master (2.91 to be). Can either @bunnybones or @rjg check what was the latest working version of Blender where this doesn't crash? Lowering the priority to normal until we figure this out. Specially since this only happens when running this via the console (not via the UI). And @rjg if you manage to crash in a debug build can you share the complete backtrace?

Robert Guetzkow commented

2020-09-11 16:24:15 +02:00

@dfelinto I will try to bisect this, probably on Sunday. Can't promise that I will have time to identify this though, in case it reaches far back. The stack trace is identical to the one in the supplied crash log, but I can add it as well.

Robert Guetzkow commented

2020-09-11 16:28:23 +02:00

Stack trace for build based on commit c01f8bb672 current master is equally affected:

WM_operator_py_idname(unsigned char * to, const unsigned char * from) Line 125	C
WM_operator_pystring_ex(bContext * C, wmOperator * op, const bool all_args, const bool macro_args, wmOperatorType * ot, PointerRNA * opptr) Line 246	C
WM_operator_pystring(bContext * C, wmOperator * op, const bool all_args, const bool macro_args) Line 308	C
wm_operator_reports(bContext * C, wmOperator * op, int retval, bool caller_owns_reports) Line 896	C
wm_operator_invoke(bContext * C, wmOperatorType * ot, wmEvent * event, PointerRNA * properties, ReportList * reports, const bool poll_only, bool use_last_properties) Line 1332	C
wm_handler_operator_call(bContext * C, ListBase * handlers, wmEventHandler * handler_base, wmEvent * event, PointerRNA * properties, const unsigned char * kmi_idname) Line 2132	C
wm_handlers_do_keymap_with_keymap_handler(bContext * C, wmEvent * event, ListBase * handlers, wmEventHandler_Keymap * handler, wmKeyMap * keymap, const bool do_debug_handler) Line 2442	C
wm_handlers_do_intern(bContext * C, wmEvent * event, ListBase * handlers) Line 2739	C
wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) Line 2866	C
wm_event_do_handlers(bContext * C) Line 3364	C
WM_main(bContext * C) Line 485	C
main(int argc, const unsigned char * * UNUSED_argv_c) Line 531	C

Stack trace for build based on commit c01f8bb672 current master is equally affected: ``` WM_operator_py_idname(unsigned char * to, const unsigned char * from) Line 125 C WM_operator_pystring_ex(bContext * C, wmOperator * op, const bool all_args, const bool macro_args, wmOperatorType * ot, PointerRNA * opptr) Line 246 C WM_operator_pystring(bContext * C, wmOperator * op, const bool all_args, const bool macro_args) Line 308 C wm_operator_reports(bContext * C, wmOperator * op, int retval, bool caller_owns_reports) Line 896 C wm_operator_invoke(bContext * C, wmOperatorType * ot, wmEvent * event, PointerRNA * properties, ReportList * reports, const bool poll_only, bool use_last_properties) Line 1332 C wm_handler_operator_call(bContext * C, ListBase * handlers, wmEventHandler * handler_base, wmEvent * event, PointerRNA * properties, const unsigned char * kmi_idname) Line 2132 C wm_handlers_do_keymap_with_keymap_handler(bContext * C, wmEvent * event, ListBase * handlers, wmEventHandler_Keymap * handler, wmKeyMap * keymap, const bool do_debug_handler) Line 2442 C wm_handlers_do_intern(bContext * C, wmEvent * event, ListBase * handlers) Line 2739 C wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) Line 2866 C wm_event_do_handlers(bContext * C) Line 3364 C WM_main(bContext * C) Line 485 C main(int argc, const unsigned char * * UNUSED_argv_c) Line 531 C ```

Ankit Meel commented

2020-09-11 19:45:58 +02:00

Added subscriber: @ankitm

Ankit Meel commented

2020-09-11 19:45:58 +02:00

2.82a, 2.81a, and 2.80rc3 also crash.

Robert Guetzkow commented

2020-09-11 20:25:11 +02:00

In #80694#1014051, @ankitm wrote:
2.82a, 2.81a, and 2.80rc3 also crash.

It's possible to crash 2.79 as well. I think we can skip bisecting then.

> In #80694#1014051, @ankitm wrote: > 2.82a, 2.81a, and 2.80rc3 also crash. It's possible to crash 2.79 as well. I think we can skip bisecting then.

Tomasz Dysinski commented

2020-09-12 01:50:38 +02:00

This inspired a decent workaround, where I just run a script like this:

import bpy
bpy.ops.script.reload()

That way the reload function doesn't return anything to the console directly.
Thanks for the insight.

This inspired a decent workaround, where I just run a script like this: ``` import bpy bpy.ops.script.reload() ``` That way the reload function doesn't return anything to the console directly. Thanks for the insight.

Chris Kohl commented

2020-09-13 01:46:36 +02:00

Added subscriber: @ckohl_art

Campbell Barton commented

2020-09-14 08:36:08 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2020-09-14 08:36:08 +02:00

While there are multiple ways to fix this, many would mean making changes with bigger implications - just to support this one case, which I'm not so keen on.

Support operators being re-registered as part of operator execution complicates operator execution for a corner-case, will also cause hard to reason about bugs when an operators properties don't match those which they were activated in.
A quick fix for this case would be to move the console execution into a C operator, however it seems weak to change the implementation just to support reloading.

I think these are more reasonable alternatives...

Change bpy.ops.script.reload to postpone reloading so the operator that activates it can finish without being freed (this could use a timer for example).
Change bpy.ops.script.reload to inspect it's own call-stack. Skip reloading modules which are part of the call stack.

At the moment I'm more in favor of postponing reloading as it's not as involved as skipping modules in the call-stack, which might fail if there are any issues filtering out call-stack-modules could be tricky to do in a cross-platform way.

It's also possible the developer expects these modules to be reloaded, and needs to investigate why they don't.

While there are multiple ways to fix this, many would mean making changes with bigger implications - just to support this one case, which I'm not so keen on. - Support operators being re-registered as part of operator execution complicates operator execution for a corner-case, will also cause hard to reason about bugs when an operators properties don't match those which they were activated in. - A quick fix for this case would be to move the console execution into a C operator, however it seems weak to change the implementation just to support reloading. ---- I think these are more reasonable alternatives... - Change `bpy.ops.script.reload` to postpone reloading so the operator that activates it can finish without being freed (this could use a timer for example). - Change `bpy.ops.script.reload` to inspect it's own call-stack. Skip reloading modules which are part of the call stack. At the moment I'm more in favor of postponing reloading as it's not as involved as skipping modules in the call-stack, which might fail if there are any issues filtering out call-stack-modules could be tricky to do in a cross-platform way. It's also possible the developer expects these modules to be reloaded, and needs to investigate why they don't.

Dalai Felinto commented

2020-09-14 09:37:53 +02:00

@ideasman42 - another option: change the poll on script.reload to return False when executing from the console editor.

@ideasman42 - another option: change the poll on `script.reload` to return False when executing from the console editor.

blender-admin commented

2020-09-14 09:50:01 +02:00

This issue was referenced by 27ea086242

This issue was referenced by 27ea0862426d910badc6f81ce13d29a6ef3cc5f0

blender-admin commented

2020-09-14 09:50:01 +02:00

This issue was referenced by 14b0f20374

This issue was referenced by 14b0f203744027451533f563c5d7373b73e070e0

Campbell Barton commented

2020-09-14 10:00:42 +02:00

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

Campbell Barton closed this issue

2020-09-14 10:00:42 +02:00

Campbell Barton self-assigned this 2020-09-14 10:00:42 +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

bpy.ops.script.reload() seg fault #80694