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 (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.

Stack trace for build based on commit rBc01f8bb672f3 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

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

In T80694#1014051, @Ankit Meel (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.

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.

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.

@Campbell Barton (campbellbarton) - another option: change the poll on script.reload to return False when executing from the console editor.