Crash on .blend unload if it contains Python nodes #37698

New Issue

Tom Edwards · 2013-12-04T14:20:23+01:00

Tom Edwards commented

2013-12-04 14:20:23 +01:00

System Information
Win7 x64, GTX 560

Blender Version
Broken: git latest (45fc8015)
Worked: Blender 2.69 r60995

If there are any Python nodes in a blend file, Blender will crash at blender\blenkernel\intern\context.c:316 whenever unloading it.

Exact steps for others to reproduce the error

Execute the "Custom Nodes" template script.
Create one of the script's Python nodes.

Exit Blender or open a different blend file.

If you are opening the attached blend, remember to hit "Run Script".

**System Information** Win7 x64, GTX 560 **Blender Version** Broken: git latest (45fc8015) Worked: Blender 2.69 r60995 If there are any Python nodes in a blend file, Blender will crash at `blender\blenkernel\intern\context.c:316` whenever unloading it. **Exact steps for others to reproduce the error** - Execute the "Custom Nodes" template script. - Create one of the script's Python nodes. # Exit Blender or open a different blend file. If you are opening the attached blend, remember to hit "Run Script".

Tom Edwards commented

2013-12-04 14:20:23 +01:00

Changed status to: 'Open'

Tom Edwards commented

2013-12-04 14:20:23 +01:00

Added subscriber: @artfunkel

Sergey Sharybin commented

2013-12-05 14:08:16 +01:00

Added subscribers: @LukasTonne, @ThomasDinges, @Sergey

Sergey Sharybin commented

2013-12-05 14:08:16 +01:00

Can not reproduce the issue.

@ThomasDinges, @LukasTonne did you try to crash blender here?

Can not reproduce the issue. @ThomasDinges, @LukasTonne did you try to crash blender here?

Lukas Tönne commented

2013-12-05 14:29:04 +01:00

I don't get a crash, but valgrind warns about invalid memory read:

==7519== Invalid read of size 8
==7519==    at 0x1CADCCA: ctx_data_get (context.c:313)
==7519==    by 0x1CADDF3: ctx_data_pointer_verify (context.c:348)
==7519==    by 0x1CAF0C7: CTX_data_main (context.c:862)
==7519==    by 0x19C7DA5: BPY_context_update (bpy_interface.c:110)
==7519==    by 0x19C7E03: bpy_context_set (bpy_interface.c:122)
==7519==    by 0x19D66E0: bpy_class_call (bpy_rna.c:7107)
==7519==    by 0x20EB408: rna_Node_free (rna_nodetree.c:1242)
==7519==    by 0x1D80FCA: nodeFreeNode (node.c:1602)
==7519==    by 0x1D814C1: ntreeFreeTree_ex (node.c:1739)
==7519==    by 0x1D81606: ntreeFreeTree (node.c:1770)
==7519==    by 0x1D3ABD6: BKE_libblock_free (library.c:953)
==7519==    by 0x1D3ADE0: free_main (library.c:1021)
==7519==  Address 0x1a81fb08 is 248 bytes inside a block of size 256 free'd
==7519==    at 0x5A9C8AC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7519==    by 0x1F768CE: MEM_lockfree_freeN (mallocn_lockfree_impl.c:132)
==7519==    by 0x1D3ACA5: BKE_libblock_free (library.c:987)
==7519==    by 0x1D3ADE0: free_main (library.c:1021)
==7519==    by 0x1C7570D: free_blender (blender.c:116)
==7519==    by 0x141AFFE: WM_exit_ext (wm_init_exit.c:455)
==7519==    by 0x141B0E1: WM_exit (wm_init_exit.c:535)
==7519==    by 0x142D8AC: wm_window_close (wm_window.c:290)
==7519==    by 0x142EA8F: ghost_event_proc (wm_window.c:804)
==7519==    by 0x1F4FD13: GHOST_CallbackEventConsumer::processEvent(GHOST_IEvent*) (GHOST_CallbackEventConsumer.cpp:53)
==7519==    by 0x1F653FB: GHOST_EventManager::dispatchEvent(GHOST_IEvent*) (GHOST_EventManager.cpp:113)
==7519==    by 0x1F654A3: GHOST_EventManager::dispatchEvent() (GHOST_EventManager.cpp:130)

So it looks like calling py functions like this during Blender exit is not safe. Conceptually it should not be necessary either: the bNodeTree ID data is only freed when closing the file or exiting Blender, which means that nothing the python callback could do would/should have a lasting effect anyway. When removing individual nodes that might be useful, but not when freeing the bNodeTree data block.

I don't get a crash, but valgrind warns about invalid memory read: ``` ==7519== Invalid read of size 8 ==7519== at 0x1CADCCA: ctx_data_get (context.c:313) ==7519== by 0x1CADDF3: ctx_data_pointer_verify (context.c:348) ==7519== by 0x1CAF0C7: CTX_data_main (context.c:862) ==7519== by 0x19C7DA5: BPY_context_update (bpy_interface.c:110) ==7519== by 0x19C7E03: bpy_context_set (bpy_interface.c:122) ==7519== by 0x19D66E0: bpy_class_call (bpy_rna.c:7107) ==7519== by 0x20EB408: rna_Node_free (rna_nodetree.c:1242) ==7519== by 0x1D80FCA: nodeFreeNode (node.c:1602) ==7519== by 0x1D814C1: ntreeFreeTree_ex (node.c:1739) ==7519== by 0x1D81606: ntreeFreeTree (node.c:1770) ==7519== by 0x1D3ABD6: BKE_libblock_free (library.c:953) ==7519== by 0x1D3ADE0: free_main (library.c:1021) ==7519== Address 0x1a81fb08 is 248 bytes inside a block of size 256 free'd ==7519== at 0x5A9C8AC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7519== by 0x1F768CE: MEM_lockfree_freeN (mallocn_lockfree_impl.c:132) ==7519== by 0x1D3ACA5: BKE_libblock_free (library.c:987) ==7519== by 0x1D3ADE0: free_main (library.c:1021) ==7519== by 0x1C7570D: free_blender (blender.c:116) ==7519== by 0x141AFFE: WM_exit_ext (wm_init_exit.c:455) ==7519== by 0x141B0E1: WM_exit (wm_init_exit.c:535) ==7519== by 0x142D8AC: wm_window_close (wm_window.c:290) ==7519== by 0x142EA8F: ghost_event_proc (wm_window.c:804) ==7519== by 0x1F4FD13: GHOST_CallbackEventConsumer::processEvent(GHOST_IEvent*) (GHOST_CallbackEventConsumer.cpp:53) ==7519== by 0x1F653FB: GHOST_EventManager::dispatchEvent(GHOST_IEvent*) (GHOST_EventManager.cpp:113) ==7519== by 0x1F654A3: GHOST_EventManager::dispatchEvent() (GHOST_EventManager.cpp:130) ``` So it looks like calling py functions like this during Blender exit is not safe. Conceptually it should not be necessary either: the bNodeTree ID data is only freed when closing the file or exiting Blender, which means that nothing the python callback could do would/should have a lasting effect anyway. When removing individual nodes that might be useful, but not when freeing the bNodeTree data block.

Lukas Tönne self-assigned this 2013-12-05 14:29:33 +01:00

Tom Edwards commented

2013-12-05 14:55:02 +01:00

I just tried with a release build and couldn't repro, but it happens 100% with a MSVC debug build.