Deleting object with transform drivers crashes

Hi there,

I am having problems with an add-on operator that creates an object, parent it to a camera, and then sets drivers on that object transforms, driven by some camera settings.

The issue is that after running that operator, if I delete the camera or the object, Blender crashes.

However, if I save the scene, close and reopen it, then it works fine. It crashes only after running the operator, so it’s hard for me to create a bug report because I can’t provide a scene to reproduce it.
It’s really the drivers that are the cause of the crash, everything is stable if I comment out the drivers code. I tried to not parent the object, or use an intermediary empty or constraints instead of parenting, but it’s still crashes.

I can’t share the entire add-on because it’s not free, so I recreated that operator inside Blender Scripting, for devs to be able to reproduce the crash. And of course, it doesn’t crash… I wonder if it registers differently from an external add-on.
I attached that blend file here, so you can see the script.

I’d like to know if someone knows of a workaround, or can decrypt the crash report and give me some clues about what could be the cause.

blender.crash.txt (46.6 KB)

ExceptionCode         : EXCEPTION_ACCESS_VIOLATION
Exception Address     : 0x00007FF7ABD40534
Exception Module      : blender.exe
Exception Flags       : 0x00000000
Exception Parameters  : 0x2
	Parameters[0] : 0x0000000000000000
	Parameters[1] : 0x0000000000000060


Stack trace:
blender.exe         :0x00007FF7ABD402B0  library_foreach_ID_link
blender.exe         :0x00007FF7ABD3FBE0  BKE_library_foreach_ID_link
blender.exe         :0x00007FF7ABD27D20  BKE_id_copy_ex
blender.exe         :0x00007FF7AC6447E0  blender::deg::deg_expand_copy_on_write_datablock
blender.exe         :0x00007FF7AC644CE0  blender::deg::deg_update_copy_on_write_datablock
blender.exe         :0x00007FF7AC644780  blender::deg::deg_evaluate_copy_on_write
blender.exe         :0x00007FF7AC6602B0  blender::deg::`anonymous namespace'::evaluate_node
blender.exe         :0x00007FF7AC660260  blender::deg::`anonymous namespace'::deg_task_run_func
tbb.dll             :0x00007FF9231A51D0  tbb::interface7::internal::isolate_within_arena
blender.exe         :0x00007FF7AFA80550  tbb::internal::function_task<Task>::execute
tbb.dll             :0x00007FF9231B37A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll             :0x00007FF9231B37A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll             :0x00007FF9231A51D0  tbb::interface7::internal::isolate_within_arena
tbb.dll             :0x00007FF9231AA490  tbb::task_scheduler_init::terminate
tbb.dll             :0x00007FF9231B19C0  tbb::thread_bound_filter::try_process_item
tbb.dll             :0x00007FF9231B19C0  tbb::thread_bound_filter::try_process_item
ucrtbase.dll        :0x00007FF9D7890F70  beginthreadex
KERNEL32.DLL        :0x00007FF9D9BF7C10  BaseThreadInitThunk
ntdll.dll           :0x00007FF9D9D4D4B0  RtlUserThreadStart


Threads:
Thread : 000024f8
ntdll.dll           :0x00007FF9D9D7CFA0  ZwYieldExecution
KERNELBASE.dll      :0x00007FF9D6E6CF70  SwitchToThread
tbb.dll             :0x00007FF9231B37A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll             :0x00007FF9231B37A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
blender.exe         :0x00007FF7AC90D010  tbb::internal::task_group_base::wait
blender.exe         :0x00007FF7AC65FDF0  blender::deg::deg_evaluate_on_refresh
blender.exe         :0x00007FF7AC63AE60  DEG_evaluate_on_refresh
blender.exe         :0x00007FF7ABD2FBA0  scene_graph_update_tagged
blender.exe         :0x00007FF7AC0E8C80  rna_ViewLayer_update_tagged
blender.exe         :0x00007FF7AC0D4210  RNA_function_call
blender.exe         :0x00007FF7AC1D08E0  pyrna_func_call
python37.dll        :0x00007FF9229462F0  PyObject_FastCallKeywords
python37.dll        :0x00007FF922A13FA0  PyEval_GetFuncDesc
python37.dll        :0x00007FF922A0E490  PyEval_EvalFrameDefault
python37.dll        :0x00007FF9229464E0  PyObject_Call
python37.dll        :0x00007FF9229469C0  PyFunction_FastCallKeywords
python37.dll        :0x00007FF922A13FA0  PyEval_GetFuncDesc
python37.dll        :0x00007FF922A0E490  PyEval_EvalFrameDefault
python37.dll        :0x00007FF922A12550  PyEval_EvalCodeWithName
python37.dll        :0x00007FF922946740  PyFunction_FastCallDict
python37.dll        :0x00007FF922947730  PyObject_Call_Prepend
python37.dll        :0x00007FF9229A6D00  PyType_Ready
python37.dll        :0x00007FF9229462F0  PyObject_FastCallKeywords
python37.dll        :0x00007FF922A13FA0  PyEval_GetFuncDesc
python37.dll        :0x00007FF922A0E490  PyEval_EvalFrameDefault
python37.dll        :0x00007FF9229464E0  PyObject_Call
python37.dll        :0x00007FF9229469C0  PyFunction_FastCallKeywords
python37.dll        :0x00007FF922A13FA0  PyEval_GetFuncDesc
python37.dll        :0x00007FF922A0E490  PyEval_EvalFrameDefault
python37.dll        :0x00007FF9229464E0  PyObject_Call
blender.exe         :0x00007FF7AC1D3CF0  bpy_class_call
blender.exe         :0x00007FF7AC0EECD0  rna_operator_modal_cb
blender.exe         :0x00007FF7ABED8A20  wm_handler_operator_call
blender.exe         :0x00007FF7ABED99B0  wm_handlers_do_intern
blender.exe         :0x00007FF7ABED9000  wm_handlers_do
blender.exe         :0x00007FF7ABED6520  wm_event_do_handlers
blender.exe         :0x00007FF7ABEC1FF0  WM_main
blender.exe         :0x00007FF7ABC41AE0  main
blender.exe         :0x00007FF7AFF91398  __scrt_common_main_seh
KERNEL32.DLL        :0x00007FF9D9BF7C10  BaseThreadInitThunk
ntdll.dll           :0x00007FF9D9D4D4B0  RtlUserThreadStart

I haven’t looked at your blend file yet (not at a computer at the moment) but without actual context where the code is actually failing it will be hard to diagnose.

Access violations, while nebulous, are pretty straightforward if you’ve already narrowed it down. Essentially, your script is trying to access memory that is no longer mapped the way you expect due to an object being deleted/added/moved. My guess is that you think you have isolated the suspicious behavior in the .blend you attached but since the repro isn’t there the culprit is likely elsewhere in your add-on. Are you caching object references directly by chance?

Thank you for taking the time to answer! I’d be more than happy to share the add-on for debugging purposes, just not publicly on a forum :slight_smile: Let me know if you would have time to give it a try.

I would understand that if it was my script that was trying to delete it, but in that case it’s Blender’s delete (shortcut assigned to object.delete). I can delete my objects using a button in my add-on fine (using bpy.ops.object.delete or bpy.data.objects.remove). In fact, if I delete my objects with that button, then undo, then Blender won’t crash anymore.
There is something that only gets registered properly after a scene save and reload, or recreating the objects with an undo. I have literally tried everything I could think of, but no luck.

I do save the object ID as a PointerProperty, but again, I can reference this PointerProperty in the add-on without any crash.

Another example is that Blender also crashes if I use the “Show in Viewports” checkbox in the Object Visibility panel of the camera or the driven plane. Funnily enough, the Eye button in the Outliner controls the same object property (hide_viewport) but doesn’t crash.

Sure, PM me a link and I’ll take a look- make sure you give me the repro steps as well.

testure was right about the PointerProperty reference and suggested to save a boolean as object data instead of storing the object as a PointerProperty, like this:

obj["is_plane"] = True

This way the object can be found again:

for o in bpy.data.objects:
            if o.get("is_plane", False):