IndexOutOfRangeException on iOS 64bit

tim.hoeregott

Hello Team!

At wonderkind, we are currently developing our newest app with Unity and 2dToolkit. When we learned from Apple that 64bit support is required, we built the app for iOS 64bit and encountered a strange error.

Two of our SkeletonData files could not be read and they don't show up in the app on the device. They throw an IndexOutOfRangeException (though inside the editor and on 32bit devices, they work perfectly well). There are other animations inside the project that are almost the same as the broken ones, but which do work.

Could you please have a look at the JSON files and tell me if anything is wrong with them? Should you need further information, I can provide you with the respective SPINE files (but I would rather refrain from uploading them openly in the forums).

Are there any known issues related to 64bit-only exceptions?

Thank you very much in advance for your help!

Best regards,
Tim.

tim.hoeregott

Pharan

Do you have a stack trace for where specifically it raises the exception? That'll help tell what can and can't be fixed on the Spine side.
I think this is on the side of the runtime (as it's compiled for iOS 64bit) and not just your data.

Seems like iOS 64 bit support for Unity is brand new and the first time they're trying out IL2CPP.

tim.hoeregott

Thank you for your quick reply! The stack trace our developer provided me with is as follows:

Error reading skeleton JSON file for SkeletonData asset: door_SkeletonData
Array index is out of range.
  at Spine.SkeletonJson.ReadSkeletonData (System.IO.TextReader reader) [0x00000] in <filename unknown>:0 
  at SkeletonDataAsset.GetSkeletonData (Boolean quiet) [0x00000] in <filename unknown>:0 
  at SkeletonRenderer.Reset () [0x00000] in <filename unknown>:0 
  at SkeletonAnimation.Reset () [0x00000] in <filename unknown>:0 
  at SkeletonRenderer.Awake () [0x00000] in <filename unknown>:0 
UnityEngine.Debug:Internal_Log(Int32, String, Object)
UnityEngine.Debug:LogError(Object, Object)
SkeletonDataAsset:GetSkeletonData(Boolean)
SkeletonRenderer:Reset()
SkeletonAnimation:Reset()
SkeletonRenderer:Awake()

Pharan

Wow, this is cryptic. It sucks that it doesn't/can't spit out line numbers. At least we know which class it is, I guess.

Coincidentally, the Unity blog just posted something about iOS and ARM64 and IL2CPP stuff.
http://blogs.unity3d.com/2015/01/29/uni ... t-support/

That blog post also points to this page in the Unity manual: http://docs.unity3d.com/Manual/iphone-64bit.html

tim.hoeregott

Thank you very much Pharan. We still haven't found out what causes the problem though (and why the problem occurs only with these two animations, not with the 90-some others that we have). Redoing one of the animations still hasn't helped much, the problem still occurs.

Maybe one of the Esoteric developers knows an answer?

Mitch

I don't have a working iOS dev pipeline here at the moment, but if you could, just put a crap ton of Debug.Log's into the ReadSkeletonData function of SkeletonJson and try to find where it fails - that'll give something to go on.

Pharan

This poster's stacktrace seems to be a bit different: viewtopic.php?f=9&t=4025
But it did seem to reach the ReadAnimation method. Maybe that's a good place to focus the crapton of Debug.Logs

tim.hoeregott

We now fixed the problem. We cannot really say what it was, only that it had something to do with the Draw Order keyframes. When I removed the draw order keyframes and added them again manually (basically recreating the same thing that has been there before), all worked fine. Maybe there were some broken legacy information stored in them?

I don't know (and even less do I know why this only happened in 64 bit), but the problem is solved now and we will be able to hold our deadline.

Thank you for your support!

P.S.: The method we narrowed down the problem with was exporting several different JSONs, where I procedurally stripped the file from one animation at a time, then the skins, then the slots with multiple attachments, and so on, put them into Unity and see which of them works and which throws the exception. That way we were able to narrow the problem down to the animated draw order in one of the animations.

joboldo

we have the same problem. Its crashing when we load our animations with IL2CPP export.

When we delete all draw-order-keyframes its working.

We tried tim.hoergott suggestion to remove the draw order keyframes and to add them again manually but it doesn't work.

Can somebody please help out? Thanks

tim.hoeregott

For our new problem, the problem is back, and for us, manually readding the keyframes does not work this time, as described by joboldo.

Please note that an update to the upcoming version 3 would not be an option for solving the issue for us, as we would have to rework all of our animations (which are a lot) to substitute the many flips with negative scalings.

beayfergm

I have also had the same problem and I have been able to fix it 🙂

The bug was exactly at this line:

drawOrder[originalIndex + (int)(float)offsetMap["offset"]] = originalIndex++;

Since IL2CPP generates C++ files out of the C# IL-Code, there is some magic happening in the process. The outcome of that was that the originalIndex variable was being incremented before accessing to the array element.

This is the generated c++ for that piece of code:

NullCheck(V_59);
Object_t * L_142 = (Object_t *)VirtFuncInvoker1< Object_t *, String_t* >::Invoke(Dictionary_2_get_Item_m20848_MethodInfo_var, V_59, (String_t*) &_stringLiteral4643);
int32_t L_143 = V_57;
V_57 = ((int32_t)((int32_t)L_143+(int32_t)1));
NullCheck(V_53);
IL2CPP_ARRAY_BOUNDS_CHECK(V_53, ((int32_t)((int32_t)V_57+(int32_t)(((int32_t)(([i](float[/i])((float*)UnBox (L_142, InitializedTypeInfo(&Single_t80_il2cpp_TypeInfo))))))))));
[i]((int32_t[/i])(int32_t*)SZArrayLdElema(V_53, ((int32_t)((int32_t)V_57+(int32_t)(((int32_t)(([i](float[/i])((float*)UnBox (L_142, InitializedTypeInfo(&Single_t80_il2cpp_TypeInfo))))))))))) = (int32_t)L_143;

That code uses an "off by 1" index when accessing the array.

I changed that line to:

drawOrder[originalIndex + (int)(float)offsetMap["offset"]] = originalIndex+1;
originalIndex++;

which, in IL2CPP code is:

NullCheck(V_59);
Object_t * L_142 = (Object_t *)VirtFuncInvoker1< Object_t *, String_t* >::Invoke(Dictionary_2_get_Item_m20848_MethodInfo_var, V_59, (String_t*) &_stringLiteral4643);
NullCheck(V_53);
IL2CPP_ARRAY_BOUNDS_CHECK(V_53, ((int32_t)((int32_t)V_57+(int32_t)(((int32_t)(([i](float[/i])((float*)UnBox (L_142, InitializedTypeInfo(&Single_t80_il2cpp_TypeInfo))))))))));
[i]((int32_t[/i])(int32_t*)SZArrayLdElema(V_53, ((int32_t)((int32_t)V_57+(int32_t)(((int32_t)(([i](float[/i])((float*)UnBox (L_142, InitializedTypeInfo(&Single_t80_il2cpp_TypeInfo))))))))))) = (int32_t)((int32_t)((int32_t)V_57+(int32_t)1));
V_57 = ((int32_t)((int32_t)V_57+(int32_t)1));

And now it's all good :rofl:

Mitch

Problems like these really piss me off.

Pharan

This was the same bug as the last one, right? Where there was an = ++something ? Or is this the exact same one and the repo wasn't updated?
We already knew this was the problem with IL2CPP.

I certainly think it's weird that it would generate this bug when compiling from IL. C# maybe, sure.

beayfergm

Small correction:

drawOrder[originalIndex + (int)(float)offsetMap["offset"]] = originalIndex+1;
originalIndex++;

should be

drawOrder[originalIndex + (int)(float)offsetMap["offset"]] = originalIndex;
originalIndex++;

The originalIndex+1 should be originalIndex

:think: