I’m running into what appear to be deadlocks during animation compression. A very similar issue was previously reported and fixed here, but this seems to be triggered by a slightly different use case.
I did manage to attach a debugger when the deadlock occurred (see the attached image for the call stack), and from what I can tell it looks like it deadlocks while destroying an AnimSequence that is still being compressed.
Unfortunately, I don’t have clear repro steps at the moment, presumably because some results are cached and thus won’t need building causing the issue.
Any insight or suggestions on how to approach or fix this would be greatly appreciated.
Hey there, talking with the team, we’ll need some more info. A full call stack, any sample code you can provide, and the approach you’re taking. I’ve logged an issue here: https://issues.unrealengine.com/issue/UE-364179 that you can follow, but most likely we won’t be able to provide a better fix or workaround with more concrete details.
Yes, I’ve reviewed that other case. My situation does seem similar; however, the solution discussed there was implemented in UE 5.7, and despite that fix, I am still encountering a deadlock in UE 5.7.
I believe my case is slightly different. From what I can tell, the deadlock occurs when attempting to cancel compression during animation sequence destruction. The compression thread ends up deadlocking with the game thread, which is the one requesting the cancellation.
Regarding custom code: we do have some project-specific code in the stack, but we haven’t modified the core compression or sequencer pipeline. We have an animation generator that automatically creates multiple animations. The issue occurs when attempting to overwrite an existing animation. Specifically, we load the package containing the animation, and shortly after it is loaded (while compression is still in progress), we attempt to overwrite it with a new one. As a result, the animation is destroyed, compression cancellation is requested, and the deadlock occurs.
I did find a workaround by modifying the code so that, instead of canceling compression during destruction, we wait for the compression to complete. However, this is not ideal, and I wouldn’t commit this fix as it risks slowing down all animation sequence destruction.
Thanks for logging the issue and for following up with the team — I appreciate it.
I haven’t had the time yet to put together a proper repro case with a sample code. As soon as I get some time, I’ll work on isolating the problem and providing more concrete details.
My plan is to try reproducing the deadlock in a minimal setup. Conceptually, it may just require a loop that continuously unloads and reloads an animation while forcing the cached data to be cleared, so that it recompresses each time. I’m also considering using one of the animations that ships with the engine (if any) to keep the repro as simple and self-contained as possible.
I’ll follow up on the issue tracker as soon as I have something reliable to share.