Thank you for the detailed report with the callstacks! This appears to be a threading issue related to the internal_spine_objects_invalidated signal in spine-godot.
The internal_spine_objects_invalidated signal is emitted whenever the underlying data of a SpineSprite changes - specifically when its skeleton data reference changes. It's also emitted if a SpineSkeletonDataResource is modified.
Based on your callstacks, it looks like there's a race condition where:
- The main thread is emitting
internal_spine_objects_invalidated and trying to clean up signal connections
- The GC thread is simultaneously trying to delete a
SpineTrackEntry object and remove its connections to the SpineSprite
- Both threads are competing for the same connection/lock, causing the crash
Questions to help diagnose this:
Are you programmatically changing the skeleton data reference of a SpineSprite, or the skeleton and atlas asset references of a SpineSkeletonDataResource during gameplay?
Does this happen when switching scenes or destroying SpineSprite nodes?
Can you create a minimal reproduction case that reliably triggers this crash? Even if it takes some time to occur, having a reproducible scenario would help identify the root cause.
This looks like it could be a genuine threading issue in spine-godot's signal handling when skeleton data is invalidated. The interaction between Godot's GC thread and the main thread's signal emission seems to be causing the problem.
In the meantime, you might want to avoid changing skeleton data references at runtime if possible, as this triggers the problematic signal emission.
