Page MenuHome

Crash when starting modal operator from asset engine
Closed, InvalidPublic

Description

Blender crashes when starting a modal operator from an asset engine. This requires a Blender build from the asset-engine branch, and was tested on revision rBbe5c2a52665a.

To demonstrate this issue:

  1. Open and run the Python code shown in the text editor.
  2. Click the "Open" button at the bottom of the image viewer.
  3. At the top left, where it says "None", select "Crash me".
  4. Crash.

For completeness, this is the code:

#!/usr/bin/env python
import bpy


class AsyncLoopModalOperator(bpy.types.Operator):
    bl_idname = 'asyncio.loop'
    bl_label = 'Runs the asyncio main loop'

    timer = None

    def execute(self, context):
        return self.invoke(context, None)

    def invoke(self, context, event):
        context.window_manager.modal_handler_add(self)

        wm = context.window_manager
        self.timer = wm.event_timer_add(1, context.window)

        return {'RUNNING_MODAL'}

    def modal(self, context, event):
        return {'PASS_THROUGH'}


class CrashingAssetEngine(bpy.types.AssetEngine):
    bl_label = "Crash me"
    bl_version = 1

    def list_dir(self, job_id, asset_list):
        bpy.ops.asyncio.loop()


if __name__ == '__main__':
    bpy.utils.register_class(AsyncLoopModalOperator)
    bpy.utils.register_class(CrashingAssetEngine)

This results in the following stack trace:

# Blender 2.77 (sub 0), Commit date: 2016-03-17 13:54, Hash be5c2a5
bpy.context.area.type = 'IMAGE_EDITOR'  # Property
bpy.ops.text.run_script()  # Operator
bpy.context.space_data.asset_engine_type = 'CrashingAssetEngine'  # Property

# backtrace
blender-debug(BLI_system_backtrace+0x26) [0x29684b7]
blender-debug() [0x18f9665]
blender-debug() [0x18f9866]
/lib/x86_64-linux-gnu/libc.so.6(+0x36d40) [0x7f5741308d40]
blender-debug(BLI_addhead+0x21) [0x2917e51]
blender-debug(WM_event_add_modal_handler+0xed) [0x1907883]
blender-debug() [0x28604a2]
blender-debug(WindowManager_modal_handler_add_call+0x4e) [0x2866015]
blender-debug(RNA_function_call+0x43) [0x26b932f]
blender-debug() [0x2009a31]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyObject_Call+0x6a) [0x7f57464002ca]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x378b) [0x7f57463eb62b]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x736d) [0x7f57463ef20d]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(+0x1f3542) [0x7f5746438542]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x48) [0x7f5746438658]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(+0x1f3c06) [0x7f5746438c06]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyObject_Call+0x6a) [0x7f57464002ca]
blender-debug() [0x200c746]
blender-debug() [0x285f2cb]
blender-debug() [0x1903de7]
blender-debug() [0x19044ef]
blender-debug(WM_operator_call_py+0x8b) [0x1904681]
blender-debug() [0x2018e7f]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyCFunction_Call+0xc9) [0x7f5746307299]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x758e) [0x7f57463ef42e]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(+0x1f3542) [0x7f5746438542]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x48) [0x7f5746438658]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(+0x1f3c06) [0x7f5746438c06]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyObject_Call+0x6a) [0x7f57464002ca]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(+0x15a5ad) [0x7f574639f5ad]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyObject_Call+0x6a) [0x7f57464002ca]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(+0x1319f0) [0x7f57463769f0]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyObject_Call+0x6a) [0x7f57464002ca]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x378b) [0x7f57463eb62b]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(+0x1f3542) [0x7f5746438542]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x48) [0x7f5746438658]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(+0x1f3c06) [0x7f5746438c06]
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0(PyObject_Call+0x6a) [0x7f57464002ca]
blender-debug() [0x200c746]
blender-debug() [0x26dd2ef]
blender-debug() [0x194e0b2]
blender-debug(wm_jobs_timer+0xb6) [0x190f2ef]
blender-debug() [0x1927324]
blender-debug(wm_window_process_events+0x97) [0x19274d1]
blender-debug(WM_main+0x18) [0x18fa7c5]
blender-debug(main+0x4f9) [0x18f5f78]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f57412f3ec5]
blender-debug() [0x18f5967]

Details

Type
Bug

Event Timeline

Sybren A. Stüvel (sybren) created this task.
Sybren A. Stüvel (sybren) raised the priority of this task from to Needs Triage by Developer.

A little investigation shows that in wm_event_system.c:2645 (function WM_event_add_modal_handler) CTX_wm_window(C) returns NULL.

Bastien Montagne (mont29) claimed this task.

Well, then you have your answer - you need to call your operator with a context containing a Window…

Anyway, you should totally avoid calling anything bpy-related in list_dir callback, even though it’s called from update part of the filebrowser listing job (i.e. from main thread), you should not assume nor depend on Blender here, asset engines are supposed to be able to list their entries on their own. And since that callback is called every 10ms until it reports listing as finished, you do not need any other looper anyway imho.