library_foreach_ID_link crash after creating joined mesh (script attached)

Coding Python Support
1

I’m running across a very consistent crash with a script I’m working on. I’m trying to create a function that solves a long-requested feature among addon developers- take some visual geometry and merge it together (non-destructively) and have it look exactly the way it looks in the viewport (curves, instanced collections, nested instances, autosmooth normals, weighted normals, etc).

The good news is that it works perfectly*.

*The bad news is that it crashes blender if you try to delete any of the original objects the script interacted with- and it’s very consistent. I’ve combed through this a few times looking for any slip-ups with access violation gotchas but I’m not seeing anything that should cause this crash. If I were caching off objects and then accessing them it might make more sense- but this is some kind of ‘delayed reaction’ because the crash doesn’t happen until well after the script has run. You can move one of the original objects around, go into edit mode, move some verts- but the object itself is a ticking timebomb. If you delete it, Blender crashes.

The callstack is always the same:

Stack trace:
blender.exe         :0x00007FF665CA5DE0  library_foreach_ID_link
blender.exe         :0x00007FF665CA5590  BKE_library_foreach_ID_link
blender.exe         :0x00007FF665FA3A30  blender::deg::DepsgraphNodeBuilder::end_build
blender.exe         :0x00007FF665F93BE0  blender::deg::AbstractBuilderPipeline::build
blender.exe         :0x00007FF665F7E480  DEG_graph_relations_update
blender.exe         :0x00007FF665C8C5E0  scene_graph_update_tagged
blender.exe         :0x00007FF665EA5D10  wm_event_do_notifiers
blender.exe         :0x00007FF665E8F050  WM_main
blender.exe         :0x00007FF665AEF260  main
blender.exe         :0x00007FF66B0833C8  __scrt_common_main_seh
KERNEL32.DLL        :0x00007FFA27357020  BaseThreadInitThunk
ntdll.dll           :0x00007FFA29282630  RtlUserThreadStart

see the code here on pastebin (didn’t want a huge wall of code here in the post):

Apologies for the state of the code, it’s still in a ‘mock up’ phase though I’ve tried to clean it up a bit for readability. It’s recursive by necessity, since the whole point is to be able to handle instances (and thus, nested instances, etc), but I hope it’s clear what’s happening.

To trigger the crash, select a mesh in object mode and run the script. After the script is finished the new object will be selected and active. Delete it if you like, it won’t cause a crash. Select the original object and hit delete. Crash!

Any help figuring this out would be appreciated!

1 Like
2

actually I figured it out- I noticed that the final (merged) mesh’s materials were all showing up as linked data for some reason, so it would stand to reason that if the original object were removed the linked data would no longer resolve correctly- and thus cause an access violation crash.

turned out to be a one line fix, rather than appending the material directly:
final_mesh.materials.append(m)

append the material from bpy.data
final_mesh.materials.append(None if m is None else bpy.data.materials[m.name])

thanks for joining me on this public rubber ducking session :slight_smile:

5 Likes