My add-on crashes when undoing a UI_List

Coding Python Support
1

Hey Guys,
My brother and I are currently developing an Addon, and run into a problem with the undo function.
When Undoing specific parts, blender just crashes.
I’ve already put the question on Blender Stack Exchange, but unfortunately to addon is too big for me to just post the lines of code there.
https://blender.stackexchange.com/questions/293101/addon-development-blender-crashes-when-undoing-how-to-find-the-problem?noredirect=1#comment504720_293101

So I was suggested to put the code here, if people want to help me figure out what exactly is causing the issue. Be advised, the code is still WIP, so a lot of the names etc. are still very messy.
You can download the code from this Google Drive link. Unzip the folder and there is a text file explaining how to reproduce the error, and what the overall idea behind the addon is.

This is probably not an “easy look at the code, and you know where the error is” kind of deal. Or maybe it is, that would be nice.
I’m not a coder myself, but my brother is. He unfortunately is currently unavailable for a few days. So not sure if I can answer all the questions.

https://drive.google.com/drive/folders/1Lgu2lvShDgb9zY5dCS9RROq5hSxyGtj7?usp=sharing

Thank You!

2

The crash happens inside the draw method of a panel:

blender.exe         :0x00007FF787A35C40  BLI_findstring    <---- Last call
blender.exe         :0x00007FF7821F5AD0  IDP_AddToGroup
blender.exe         :0x00007FF7827B0C10  RNA_property_pointer_add
blender.exe         :0x00007FF7827B0D20  RNA_property_pointer_get
blender.exe         :0x00007FF7828E7430  pyrna_prop_to_py
blender.exe         :0x00007FF7828E2140  pyrna_struct_getattro
python310.dll       :0x00007FFAF14F4E30  PyObject_GetAttr
python310.dll       :0x00007FFAF15BA3A0  PyEval_EvalFrameDefault
python310.dll       :0x00007FFAF15BA3A0  PyEval_EvalFrameDefault
python310.dll       :0x00007FFAF14ABED0  PyFunction_Vectorcall
blender.exe         :0x00007FF7828E37E0  bpy_class_call
blender.exe         :0x00007FF782884B10  panel_draw
blender.exe         :0x00007FF7829086B0  ed_panel_draw
blender.exe         :0x00007FF782906A60  ED_region_panels_layout_ex
blender.exe         :0x00007FF7831F0610  view3d_buttons_region_layout
blender.exe         :0x00007FF782905840  ED_region_do_layout
blender.exe         :0x00007FF7824FDE70  wm_draw_window_offscreen
blender.exe         :0x00007FF7824FDCD0  wm_draw_window
blender.exe         :0x00007FF7824FD720  wm_draw_update
blender.exe         :0x00007FF7824D6090  WM_main
blender.exe         :0x00007FF781FC9D80  main
blender.exe         :0x00007FF787BB82D4  __scrt_common_main_seh
KERNEL32.DLL        :0x00007FFB3AF07600  BaseThreadInitThunk
ntdll.dll           :0x00007FFB3BF22680  RtlUserThreadStart

Python:

# Python backtrace
  File "Z:\__vs\_blendfiles\deleteme.blend\Easy PLANETS_13.py", line 78 in draw

Which points to:

class CUSTOMPLANET_PT_main(Panel):          
    bl_label = ADDON_NAME
    bl_idname = "PT_CustomPlanet"
    bl_space_type = "VIEW_3D"
    bl_region_type = "UI"
    bl_category = ADDON_NAME
    
    def draw(self, context):
        scene = context.scene
        
        item = bpy.app.driver_namespace["current_item"]
        
        if item:
            print(f"planet = {item.planet}")  # Ln 78    <----------------------------------

The driver namespace is not managed so you’re potentially passing a dangling reference back to Blender.

You should instead use the concept of an active_item which is a PointerProperty to the selected list item and let Blender remap it on undo.

1 Like
3

Wow, I did not expect an answer that quickly.
Like I said, I’m not much of a coder myself, so I can probably first test it out, once my brother is back in a few Days.
But thank you very very much! I will let you know if that fixes the Problem. Thank You!!!

1 Like
4

Btw, how did you get all these information? Is this basic blender, or are you using an addon or program?

5

This is obtained by the crash log Blender dumps before it exits. If you run Blender from a terminal, something like this gets printed on a normal segfault:

Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF787A35C60
Module  : blender.exe
Thread  : 00003fdc
Writing: C:\Users\ict-pc\AppData\Local\Temp\deleteme.crash.txt

I always run Blender with --debug-memory, but I don’t think it’s a requirement for the above to show.

3 Likes
6

It is possible to get an error that does not leave the crash.txt.

Error   : EXCEPTION_STACK_OVERFLOW
Address : 0x00007FFA29877D44
Module  : C:\blender\blender-3.1.2-windows-x64\tbbmalloc.dll

The Gotchas have a suggestion about using faulthandler.

If the crash happens in the C/C++ part the traceback can be meaningless or not complete. You might need a Blender debug build.