4.6 iOS 64-bit beta

Bug thread! We're having a crash that occurs only in 64-bit il2cpp iOS builds (but the armv7 version works fine), seems to be related to il2cpp not correctly instantiating a static class before accessing it.

Specifically, we have an addon (UnitySerializer) in the plugins that contains a static class with a static boolean we're accessing in our scripts. However, when it is accessed, the il2cpp code bails with EXC_BAD_ACCESS.

Pretty sure it's the same one that @cojo71 reported earlier (http://fogbugz.unity3d.com/default.asp?691588_rnd8rcnuqstk2beh), see GetCustomAttributes in the callstack. We're hitting this in 4.6.5. Any chances that fix is also getting ported to 4.6.x?

Code (CSharp):

1. * thread #1: tid = 0x3e84c, 0x02b50060 EonAltarProd`il2cpp::icalls::mscorlib::System::MonoType::get_DeclaringType(monoType=<unavailable>) + 88 at MonoType.cpp:296, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
2.   * frame #0: 0x02b50060 EonAltarProd`il2cpp::icalls::mscorlib::System::MonoType::get_DeclaringType(monoType=<unavailable>) + 88 at MonoType.cpp:296
3.     frame #1: 0x01b2ef60 EonAltarProd`MonoType_get_DeclaringType_m46686(__this=0x0d05d060, method=0x03581ae4) + 116 at Bulk_mscorlib_2.cpp:9501
4.     frame #2: 0x011098f8 EonAltarProd`VirtFuncInvoker0<Type_t*>::Invoke(method=0x03581ae4, obj=0x0d05d060) + 72 at GeneratedVirtualInvokers.h:20
5.     frame #3: 0x01b2ed10 EonAltarProd`MonoType_get_MemberType_m46682(__this=0x0d05d060, method=0x03581a04) + 56 at Bulk_mscorlib_2.cpp:9442
6.     frame #4: 0x01b678b0 EonAltarProd`VirtFuncInvoker0<int>::Invoke(method=0x03549898, obj=0x0d05d060) + 72 at GeneratedVirtualInvokers.h:20
7.     frame #5: 0x019e8820 EonAltarProd`Attribute_GetCustomAttributes_m12901(__this=0x00000000, ___element=0x0d05d060, ___type=0x0d05d540, ___inherit=false, method=0x0352b128) + 192 at Bulk_mscorlib_0.cpp:570
8.     frame #6: 0x0038923c EonAltarProd`UnitySerializer_ScanAllTypesForAttribute_m8565(__this=0x00000000, ___function=0x0cfac620, ___assembly=0x0cfac658, ___attribute=0x0d05d540, method=0x0308f600) + 716 at Bulk_Assembly-CSharp-firstpass_15.cpp:11225
9.     frame #7: 0x00381514 EonAltarProd`UnitySerializer_RegisterSerializationAssembly_m8563(__this=0x00000000, ___assembly=0x0cfac658, method=0x0308f52c) + 1288 at Bulk_Assembly-CSharp-firstpass_15.cpp:11095
10.     frame #8: 0x00381004 EonAltarProd`UnitySerializer_RegisterSerializationAssembly_m8562(__this=0x00000000, method=0x0308f4e0) + 144 at Bulk_Assembly-CSharp-firstpass_15.cpp:11031
11.     frame #9: 0x0037f44c EonAltarProd`UnitySerializer__cctor_m8534(__this=0x00000000, method=0x0308ea08) + 8884 at Bulk_Assembly-CSharp-firstpass_15.cpp:8707
12.     frame #10: 0x01dccfb8 EonAltarProd`RuntimeInvoker_Void_t134(method=0x0308ea08, obj=0x00000000, args=0x00000000) + 60 at GeneratedInvokers.cpp:12
13.     frame #11: 0x02b98dfc EonAltarProd`il2cpp::vm::Runtime::ClassInit(TypeInfo*) + 756
14.     frame #12: 0x00320728 EonAltarProd`LevelSerializer__cctor_m7936(__this=0x0cfa6708, method=0x03994250) + 6272 at Bulk_Assembly-CSharp-firstpass_14.cpp:10531
15.     frame #13: 0x01dccfb8 EonAltarProd`RuntimeInvoker_Void_t134(method=0x030779a0, obj=0x00000000, args=0x00000000) + 60 at GeneratedInvokers.cpp:12
16.     frame #14: 0x02b98dfc EonAltarProd`il2cpp::vm::Runtime::ClassInit(TypeInfo*) + 756
17.     frame #15: 0x00c7e334 EonAltarProd`EonBehaviour_Awake_m18511(__this=0x0cf97a20, method=0x03278534) + 108 at Bulk_Assembly-CSharp_7.cpp:19411
18.     frame #16: 0x01dccfb8 EonAltarProd`RuntimeInvoker_Void_t134(method=0x03278534, obj=0x0cf97a20, args=0x0804a30c) + 60 at GeneratedInvokers.cpp:12
19.     frame #17: 0x02b97628 EonAltarProd`il2cpp::vm::Runtime::Invoke(MethodInfo*, void*, void**, Il2CppObject**) + 172
20.     frame #18: 0x02544d8c EonAltarProd`ScriptingInvocation::Invoke(this=0x0804a29c, exception=0x0804a28c, convertArguments=<unavailable>) + 92 at ScriptingInvocation.cpp:128
21.     frame #19: 0x02545378 EonAltarProd`ScriptingInvocationNoArgs::InvokeChecked() [inlined] ScriptingInvocationNoArgs::Invoke(this=<unavailable>) + 76 at ScriptingInvocationNoArgs.cpp:83
22.     frame #20: 0x02545364 EonAltarProd`ScriptingInvocationNoArgs::InvokeChecked(this=<unavailable>) + 56 at ScriptingInvocationNoArgs.cpp:124
23.     frame #21: 0x02538714 EonAltarProd`MonoBehaviour::CallMethodInactive(this=0x00000000, method=<unavailable>) + 68 at MonoBehaviour.cpp:370
24.     frame #22: 0x0253b7ec EonAltarProd`MonoBehaviour::CallAwake(this=0x19b08530) + 48 at MonoBehaviour.cpp:1422
25.     frame #23: 0x0253ba54 EonAltarProd`MonoBehaviour::AddToManager(this=0x19b08530) + 164 at MonoBehaviour.cpp:1516
26.     frame #24: 0x0253b7b0 EonAltarProd`MonoBehaviour::AwakeFromLoad(this=<unavailable>, awakeMode=<unavailable>) + 576 at MonoBehaviour.cpp:1411
27.     frame #25: 0x02591d2c EonAltarProd`AwakeFromLoadQueue::InvokePersistentManagerAwake(objects=<unavailable>, size=96, awakeMode=3, safeBinaryCallback=<unavailable>)(Object&, TypeTree const&)) + 220 at AwakeFromLoadQueue.cpp:322
28.     frame #26: 0x02591b18 EonAltarProd`AwakeFromLoadQueue::PersistentManagerAwakeFromLoad(this=0x18342390, mode=3, safeBinaryCallback=0x00000000)(Object&, TypeTree const&)) + 48 at AwakeFromLoadQueue.cpp:158
29.     frame #27: 0x024f0a30 EonAltarProd`CompletePreloadMainData(awakeQueue=<unavailable>) + 180 at SaveAndLoadHelper.cpp:700
30.     frame #28: 0x024dd43c EonAltarProd`PreloadLevelOperation::IntegrateMainThread(this=0x18342390) + 432 at PreloadManager.cpp:801
31.     frame #29: 0x024db610 EonAltarProd`PreloadManager::UpdatePreloadingSingleStep(this=0x16ad5340, stopPreloading=<unavailable>) + 488 at PreloadManager.cpp:488
32.     frame #30: 0x024dc644 EonAltarProd`PreloadManager::WaitForAllAsyncOperationsToComplete(this=0x1fe70214) + 164 at PreloadManager.cpp:555
33.     frame #31: 0x024d5fc8 EonAltarProd`PlayerStartFirstLevel() + 292 at Player.cpp:1081
34.     frame #32: 0x024d6240 EonAltarProd`PlayerLoadFirstLevel() + 192 at Player.cpp:1116
35.     frame #33: 0x021efbac EonAltarProd`UnityLoadApplication + 12 at LibEntryPoint.mm:241
36.     frame #34: 0x00058534 EonAltarProd`-[UnityAppController startUnity:](self=0x16917cf0, _cmd=0x02d52b92, application=0x1691e700) + 628 at UnityAppController.mm:99
37.     frame #35: 0x2c6e5f38 Foundation`__NSFireDelayedPerform + 468
38.     frame #36: 0x2b9a6c86 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
39.     frame #37: 0x2b9a6802 CoreFoundation`__CFRunLoopDoTimer + 650
40.     frame #38: 0x2b9a4a52 CoreFoundation`__CFRunLoopRun + 1418
41.     frame #39: 0x2b8f23c0 CoreFoundation`CFRunLoopRunSpecific + 476
42.     frame #40: 0x2b8f21d2 CoreFoundation`CFRunLoopRunInMode + 106
43.     frame #41: 0x32cf00a8 GraphicsServices`GSEventRunModal + 136
44.     frame #42: 0x2ef007b0 UIKit`UIApplicationMain + 1440
45.     frame #43: 0x00036064 EonAltarProd`main(argc=1, argv=0x0804ca58) + 308 at main.mm:45

 

Was this deadlock issue resolved? I also see this in Unity 5.1 beta 5.

 

We are seeing this as well for an empty scene. Seem to me that generics are the major problem as we make heavy use of generics. A cursory inspection of the generated class seems to indicated that a lot of shared functions were generated with different different names although they have the same signature and same method body. That's all I have currently.

 

@JoshPeterson

I want to know if IL2CPP support weak reference well?

 

It does not happen with the Mono scripting backend. I'm building with 4.6.5. Unfortunately, I cannot send you the project for legal reasons and I'm not having very much luck producing a ersatz project to demonstrate the issue. I will note that the stack traces I'm getting seem kind of wonky in that they could not possibly be real. I remember reading somewhere that IL2CPP stack traces were bad, but I figured that was fixed by now. Any idea when that bug will be fixed? And is there any way around it?

 

Great. That sounds good, here's hoping that they come close to the aot build within the next patch or so. In the meantime, we'll look at other ways of trimming the fat from the application itself.

On the other hand, does anyone know if copious use of linq will also increase code size?

 

@JoshPeterson

Yes, we store a Texture2D object within WeakReference, but when we convert Target in WeakReference to Texture2D, it is null, but convert to Object is not null and Target's type sure is Texture2D.

 

Quick check-in, is 5.0.1p4 on track to release today per the usual weekly schedule? We're awaiting some fixes there pretty eagerly, but if it's not going to hit today we may go ahead and move forward on some releases without it.

Thanks!

 

That also seems to give quirky stack traces. For example:

Code (csharp):

1.  
2. System.Diagnostics.StackTrace:init_frames(Int32, Boolean)
3. System.Diagnostics.StackTrace:.ctor(Int32, Boolean)
4. UnityEngine.StackTraceUtility:ExtractStackTrace()
5. System.Collections.Generic.Transform`1:EndInvoke(IAsyncResult)
6. System.Array:swap(Color[], Int32, Int32)
7. System.Array:swap(Color[], Int32, Int32)
8. System.Array:swap(Color[], Int32, Int32)
9. System.Array:swap(Color[], Int32, Int32)
10. UnityEngine.Debug:Internal_Log(Int32, String, Object)
11. UnityEngine.Debug:Log(Object)
12. foo.<loadWithCoroutine>c__Iterator1:MoveNext()
13. System.Collections.Generic.Transform`1:EndInvoke(IAsyncResult)
14. System.Array:swap(Color[], Int32, Int32)
15. System.Array:swap(Color[], Int32, Int32)
16. System.Array:swap(Color[], Int32, Int32)
17. System.Array:swap(Color[], Int32, Int32)
18. System.Array:swap(Color[], Int32, Int32)
19. System.Array:swap(Color[], Int32, Int32)
20. System.Array:swap(Color[], Int32, Int32)
21. System.Array:swap(Color[], Int32, Int32)

Is there any way to just turn off the managed stack trace and show the native C++ stack trace?

 

Yeah. Part of the problem with the stack traces is that I'm having a hard time finding where to break in the C++ code.

 

Finally found the exact place where the code was throwing. I found something very peculiar. The exception we are getting is "System.IO.IOException: EndRead failure ---> System.Net.Sockets.SocketException: Operation on non-blocking socket would block". In the catch block where that exception is thrown, I added the following code:

Code (csharp):

1.  
2.        TcpClient_t5153 * L_0 = (__this->___client_3);
3.  
4.         Socket_t3957 * L_1 = TcpClient_get_Client_m22697(L_0, /*hidden argument*/&TcpClient_get_Client_m22697_MethodInfo);
5.  
6.         std::cout << "IsBlocking: " << Socket_get_Blocking_m55628(L_1, &Socket_get_Blocking_m55628_MethodInfo) << std::endl;

It prints out "IsBlocking: 1". Any idea why a Socket which reports itself as blocking would throw an exception that says an operation on a non-blocking socket would block? I tried searching for "Operation on non-blocking socket would block" to try to figure out why it would be throwing and it only appears in libiPhone.a, which means it's some place I can't look at. Any ideas?

 

@JoshPeterson
@Charles Max
@Hacky

This is in reference to:
http://forum.unity3d.com/threads/4-6-ios-64-bit-beta.290551/page-34#post-2083092

We're having the same issue. Essentially when the lock button is pressed, and Metal is enabled it triggers an applicationWillResignActive and SetupMetalFBO crash. This causes the app to not background, and the next time the app boots it'll reload.

I also found this related thread:

http://forum.unity3d.com/threads/ne...-sigabrt-crash-on-entering-background.321225/

It seems the fix is potentially related to commenting out the UnityForcedRepaint() line.

Any ideas on this issue or a potential fix?

 

You told yesterday that you would release 5.0.1p4 today too, is it still true?

 

http://forum.unity3d.com/threads/unity-patch-releases.246198/page-2

 

Thx both ( subscribed the announcement thread pointed by @MrEsquire not to miss the patches anymore )

 

we use prime31 ios social networking.
if call TwitterBinding.showLoginDialog that app is crashed.
unity version : 4.6.5p1
scripting backend : il2cpp
architecture : Universal
emptyproject , only one button , and call TwitterBinding.showLoginDialog
ipad works fine.
but iphone6 , iphone6+ is crashed.
please help us~

 

Hi, i'm using Unity 4.6.5 and trying to compile a rather small game as universal build. How long is it supposed to take on first run? Mono-compiled game weights no more than 150mb.

I've been trying to run it directly on device (xcode set to "Release" scheme), other times just archive, but it always hangs at some point ("Compiling x of y" source files is the status message shown by XCode) - i mean it stays responsive, but just seem to proccess some file indefinitely. I see no errors, just a bunch of warnings. I was waiting as long as 4 or 5 hours, but it seems to be stuck every time (at different file though).

I've also tried to run it through cloud build, which restarted twice before ending with "failed" status, but no meaningful message was given in logs ("Status: UNKNOWN" is the last line logged).

Is there any way to somehow debug such behavior more deeply?

 

Building a simple project works ok, i guess i'll just add scenes one by one and try to narrow down the scope where anything might break the proccess. Thanks for the clues.

 

I have same Unityserializer crash issue on my app.. When does 4.6.5p2 come out?
Thank you..

 

It seems that System.Globalization.CultureInfo.CreateSpecificCulture just throws a NotSupportedException using IL2CPP. Is there are workaround for this? Also, is there a list of non-supported standard library functions?

NotSupportedException: /Users/builduser/buildslave/unity/build/Tools/il2cpp/il2cpp/libil2cpp/icalls/mscorlib/System.Globalization/CultureInfo.cpp(299) : Unsupported internal call for IL2CPP:CultureInfo::construct_internal_locale_from_specific_name - "This icall is not supported by il2cpp."
at System.Globalization.CultureInfo.construct_internal_locale_from_specific_name (System.Globalization.CultureInfo ci, System.String name) [0x00000] in <filename unknown>:0
at System.Globalization.CultureInfo.ConstructInternalLocaleFromSpecificName (System.Globalization.CultureInfo ci, System.String name) [0x00000] in <filename unknown>:0
at System.Globalization.CultureInfo.CreateSpecificCulture (System.String name) [0x00000] in <filename unknown>:0

 

I've setup a system to report stack traces when exception occurs. I'm getting correct stack traces from android beta testers, but the iOS il2cpp builds send weird (incomplete?) stack traces. Is it a known issue?

 

Did you guys benchmark it?
If I remember correctly since last I used arm opcodes( it has been almost 10 years, back at the Symbian times) thumb instruction set itself is slower and also run a separate state, and switching between the normal set and thumb also come at a cost.
You could have a 10-20% performance loss with that enabled depending on how the compiler do its job.
If it was without any downside it would have been always on in the compiler.

 

Thanks for that, I understand that il2cpp converts IL code. Was just wondering about the amount of IL code that linq can potentially generate. We'll take a look at that avenue also.

 

Using Unity 4.6.5, my game is done and I just built it with IL2CPP and I'm happy to say it runs on my device -- have to test it on various other devices. The file size is about the same as building with mono.

But it builds with 368 error messages. Most are of the type attached. Any suggestions? Thanks.

They don't interfere with building and archiving but hoping there's a way to avoid them. 368 is a lot of error messages. All yellow.

 

I encountered a pInvoke marshelling bug for IL2CPP iOS 64-bit using Unity Pro 4.6.5:

The following is an API of a native iOS plugin. It worked fine with 32-bit IL2CPP converted C# and 32-bit plugin. It broke with 64-bit IL2CPP converted C# and 64-bit native plugin. The problem with 64-bit is that the last few parameters are zeroed out even though some of them have non-zero values passed in from the C# side. The same pInvoke works fine with Mono backend or IL2CPP 32bit backend. So it looks like a IL2CPP 64-bit specific marshelling bug. I know the parameter list is a bit too long. But I'd like to understand if there is a hard limit as to the maximum number of parameters supported by IL2CPP 64-bit P-Invoke ?

[DllImport ("libArticulatedCharacter")] public static extern
IntPtr acCreateBipedController(
IntPtr world, IntPtr character,
int lFoot, int rFoot,
int lAnkle, int rAnkle,
int lKnee, int rKnee,
int lHip, int rHip,
int lowerBack, int torso, int head,
float stanceHipDamping,
float stanceHipMaxVelocity,
float rootPredictiveTorqueScale,
float maxGyro,
int staringState,
int startingStance,
bool isVFOn,
bool isIPOn,
bool isGCOn,
bool isRDOn,
bool useExplicitPD,
bool useImplicitPos,
bool useMOIAboutJoint,
float stepWidth
);

Thanks!
A.P.

 

There shouldn't be any performance penalty for using Thumb since ARMv7 (there was in ARMv6). Apple recommends to always leave it enabled now and it is also enabled by default, but previous versions of Unity added a flag to turn it off.

 

Funny how all this mess started because of 64bit, and now we are looking into 16bit code to patch up some issues
This goes to show the usefulness of Apple new policy.