The errors you're encountering in UE5 with the Spine plugin suggest that certain properties in the SpineSkeletonAnimationComponent are not being initialized correctly. This could be due to a mismatch between the Spine runtime version and the assets or an issue with the plugin itself. To resolve this, ensure that you are using the latest version of the Spine runtime and that your assets are compatible with this version. Additionally, check if there are any updates or patches available for the Spine plugin that might address this initialization issue. If the problem persists, you might need to manually inspect the code in SpineSkeletonAnimationComponent.h to ensure that all properties are properly initialized.

bbt636 Could you please tell us what operations you are performing before the crash occurs? Perhaps from your description, the installation of the spine-ue runtime and the import of the skeleton data is going well, but the crash occurs while you are doing something with the skeleton. Am I right? To what extent can operations be successfully performed, e.g. can a skeleton be successfully instantiated in a level?

bbt636 I understand your situation. Unfortunately, the steps to reproduce the issue are currently unclear, making it difficult to investigate further without a reproduction project. Could you prepare a minimal Unreal Engine project where the problem can be reliably reproduced and email it to us?: contact@esotericsoftware.com
Please include the URL of this forum thread in the email so we know the context. Then we can take a look at what's wrong.

I went through the log, and while it does mention the incorrectly initializede FSpineEvent structs, it doesn't give me a stack trace for the crash which would allow me to understand what is happening.

Is there any way you could share your project either here or privately via email (contact@esotericsoftware.com) with steps to reproduce the issue?

This is extremely hard to figure out I'm afraid. I've been banging my head against it for a few days, without much progress. UE's garbage collector is ... peculiar.

I've pushed a supposed fix, please give it a try.

The issue: spine-ue exposes TrackEntry instances. These are wrapped inside a USpineTrackEntry, so users of blueprints can easily access and modify them, e.g. set mix durations etc. These are UObjects and thus eligible for UE garbage collection. Normally, the garbage collection happens after the underlying TrackEntry is disposed. Disposal of a TrackEntry triggers a callback in the USpineWidget or USpineSkeletonAnimatinComponent, which will then set the USpineTrackEntry::entry field to nullptr. However, sometimes, under specific circumstances, that callback has no chance to be executed before the USpineTrackEntry::BeginDestroy() method, which is triggered by the UE garbage collector, is invoked. This can lead to a situation, where the USpineTrackEntry::entry points to a freed memory region, while USpineTrackEntry::BeginDestroy() is trying to access the ::entry field. That results in a crash.

The solution: do not access ::entry in the BeginDestroy() method. While this sounds trivial, I had to trace through everything to make sure this doesn't mess with other state, which is part of why resolving this took so long.