Tim Reiter

Hi there!
we just released our 1.36.3 update for Idle Miner Tycoon, where we introduce Spine Animations. On iOS we see several EXC_BAD_ACCESS KERN_PROTECTION_FAILURE crashes on many devices in Crashlytics. Crashes happen in AnimationState_ApplyRotateTimeline, Animation_BinarySearch, TrackEntry_get_AnimationTime, and others.
Unity Version 5.4.5 and Spine 3.6.
Example:
http://crashes.to/s/54a86b16d53

It looks like a bug in the unity spine package?
I tried to write a workaround by directly working on the spine Timelines, but could not find an example how to do this.
Any help is greatly appreciated!
Thanks and best regards,
Tim
Tim Reiter
Posts: 3

Pharan

Damn, it's really hard to debug with IL2CPP like that.

Though have you tried building on a newer version of Unity?
We could try to find a workaround, but it's quite a measure more likely that this is a Unity/IL2CPP thing than something inherent in spine-csharp's code. You're the first to report this.

Just checking those methods now, nothing seems to stand out as something that would confuse the IL2CPP.
User avatar
Pharan

Pharan
Posts: 4502

Tim Reiter

So the error is a StackOverflow in AnimationState ApplyMixingFrom. Its happening because there is a recursive method call in ApplyMixingFrom.
Tried to workaround by setting the Default Mix Duration in the SkeletonData.asset to 0 - this maybe makes the error appear less often, but it still happens.
I dont think it's an il2cpp thing, we are also able to get this error in the Unity Editor.

What could cause this StackOverflow? At the moment i dont fully understand the AnimationState code.
Attachments
spineSO.jpg
Tim Reiter
Posts: 3

Pharan

This, we can work with.

This can happen with certain arrangements of event handling.
For example, if you call SetAnimation in an End handler, SetAnimation actually causes End to fire, which can infinitely recurse. That can stack overflow.

This doesn't seem to be that case, but it's also likely that at some point, there was an absurd number of SetAnimation/AddAnimation calls all the same, or many of them had trackEntry.TimeScale = 0 which may have prevented them from ever ending.

Would you know if any of your code does this or something similar to this?
User avatar
Pharan

Pharan
Posts: 4502


Return to Unity