Is this only occurring with TestFlight or does it happen if you just export from Unity directly to a 32-bit device?

Hi dm3d, its happening on both testflight and AppStore. If I build directly from Xcode it works.

The weird thing is that, if I download the app from Testflight or AppStore and tap directly on the app, it crashes, BUT If I open Xcode and run without building it works.

The problem is that we had an app (quite important as its the Official Jurassic World AR App) with this issue but thanks to Apple that granted us an expeditet review we fixed it using an older version of Unity.

The new Unity 4.6.5 p4 contains a fix for the multiplayer and we absolutely need to update the app, we are blocked for this crash on 32 bits devices.

Ale.

Summarizing details from your first post:

Unity 4.6.5p2 (working okay)
Unity 4.6.5p3/p4:
-- not working with TestFlight or HockeyApp
-- working if built directly from Xcode
-- p4 contains non-related fix required by app
-- disabling AR allows app to work okay

• If you compile IPA from Xcode and manually load to 32-bit device does it work?
• If you load same IPA to TestFlight does it work okay?
• Could you provide via PM a stack trace of the app crashing on a 32-bit device?

Hi, yeah all the points are good.

If I compile the IPA from Xcode it works fine

if I load the same IPA from Testlflight or Hockeyapp it crashes (Only on 32 bit devices)

I just sent you the stack trace.

Thanks!

Ale.

Thanks for the stack trace. Looks like it is an ARM-specific error:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Subtype: EXC_ARM_DA_ALIGN at 0x06a19f66

Searching Google for that error showed a lot of articles. Here's one:

http://www.splinter.com.au/what-do-do-with-excarmdaalign-on-an-iphone-ap/

You might want to check things like Debug/Release and if Xcode is using Debug when compiling to a device and if TestFlight is using different settings. Try using Release in Xcode and try using IL2CPP, with Architecture set to ARMv7 (32-bit only) settings (note: use ARMv7 just to test; Universal needed for 32+64-bit). The release notes for p3 have 6 fixes related to iOS/IL2CPP which may be a factor. It seems that issue might not be specific to Vuforia, but potentially affect other native Unity plugins supporting ARM platform. If you have other native Unity plugins which support 32/64-bit on ARM, you might want to try them in a project to see if the crash persists.

Hi, thanks for this, I will check immediately. :)

We use only prime31's etcetera (other than Vuforia) in our app and I've already tested it with a test app with just etcetera and it works.

I tried basically everything, definitely looks like the crash occurs when the ARCamera its instantiating the videoTexture. If the camera access is denied the app doesn't crash ans I can see all the GUI.

Thanks!

Ale.

EDIT: Exported the app IL2CPP 32 bit only and if downloaded as ad hoc it crashes on all my devices, 32 bit and 64 bit. So, definitely its the 32 bit part the problem

HI, I did a test on a brand new app with just a simple scene with the ARCamera. No other plug ins of any kind. The app crashes on 32 bit devices.

My settings are:

- Unity 4.6.5p4

- Xcode 6.3.2

Build settings are:

IL2CPP, Universal, Force OpenGL 2.0,

Ale.

Hi RedFrogDigital,

you mentioned in your previous post:

Exported the app IL2CPP 32 bit only and if downloaded as ad hoc it crashes on all my devices, 32 bit and 64 bit. So, definitely its the 32 bit part the problem

could you make the same "32-bit only" export test using "Mono 2.x" as Backend, instead of IL2CPP ?

Hi AlessandroB, I already did export 32 bit using Mono armV7 and it works, the problem only occurs if I use IL2CPP Universal and only on 32 bit devices.

Unfortunately Apple wants the App to be Both 32 and 64 bit.

Ale.

Ok, thanks for confirming that the "Mono compile test" produces working (non-crashing) binaries;

this is a useful hint;

in fact, if the crash was also occurring with the binaries compiled by the Mono backend, then this would have been an indication of a potential problem in the Vuforia codebase with 32 bit mode; however this is ruled out by the result of the "Mono" 32bit test

Secondly, the IL2CPP compiler was also working fine up in version 4.6.5 patch p2, i.e. prior to the introduction of patch p3 / p4.

Also, on 64bit things work OK too.

So, the elements above (MONO OK and IL2CPP also OK prior to patch p3),

are a fair indication that possibly (and probably) the Unity 4.6.5 patches p3 and/or p4 might have introduced some kind of "regression" in the IL2CPP compiler backend.

One hypothesis is that such regression might have been introduced as an unfortunate "side effect" of  other IL2CPP-related fixes (there have been quite a few IL2CPP fixes as mentioned in the Release Notes of Unity 4.6.5 patch p3 and p4).

No doubt that this issue is "revealed" or triggered when some Vuforia component goes to execution,  but this does not mean that the bug itself is in the Vuforia codebase; simply, it means that there is some code that Vuforia is using which is unfortunately able to trigger and manifest this specific issue on that specific version of the IL2CPP backend (at least when used in combination with Test Flight, as you mention).

Have you raised this with Unity ? 

I'll raise this issue internally with our engineering team, but if it is confirmed that the bug is caused by Unity (in that specific patch), then this should be filed to Unity as a bug.

Another option might be to wait for the next patch and see if it resolves this, or to upgrade to Unity 5.0.2 and se if the problem persists on that version.

Hi AlessandroB, thanks for the explanaition. I was pretty sure that was something on Unity side, I wrote them a few weeks ago but no response.

I think I will send them the project and submit a bug report, last time I did it for another issue and they solved it with the p4 patch (but then created this new problem).

Unfortunately I can't update the project to Unity 5 as its using a series a plug ins and codes that are not compatible with it, I tried many times but no luck.

Ale.

Ok, a litle suggestion:

when you submit the bug report to Unity, make sure to mention that the 32-bit binaries compiled with Mono do not exhibit the issue (so to make it clear that the issue is with the IL2CPP), and that things were working fine also with IL2CPP on versions up to 4.6.5 p2 included, so that they have a baseline working version for reference.

I will also come back to you on this, in case I have additional details after double checking with the team here.

In the meantime, Unity releaesed Unity 4.6.6 and 4.6.6 patch p1:

https://unity3d.com/unity/qa/patch-releases

you may want to try that one.

Hi AlessandroB, unfortunately I've already tried both versions and the crash its still there. Hopefully next version they will do something about it, at the moment I cannot send any new app to the AppStore.

Ale.

Hi RedFrog,

I was having the same problem.  Confirmed 4.6.6 doesnt fix it.   Changing the optimiztion level of Release Builds to None in Xcode worked for me.  It's located in Build Settings -> Apple LLVM 6.1 - Code Generation.  

From building native apps in the past, I've found in general that if a Debug Build works and a Release Build doesnt, go through all the settings to see what the compiler is doing different for each.  Another setting other than None might work as well, I just wanted to be safe.  Your filesize might grow slightly.

I've attached an image of the setting.  I hope it works for you.

Thaks dpizzle for sharing this tip.

RedFrogDitigal, can you confirm this also works for you ?

Hi, AlessandroB and dpizzle. I've just tried with the 4.6.6p1 patch and definitely solved the problem. The app is now 8 MB bigger which makes it too big but as a temporary fix its ok.

Thank you dpizzle for this great tip!

Ale.

Glad to hear it works.  Make sure you try the other optimization levels (i only tried none) to see if you can get some reduced filesize and have it still work.

This link also provides some tips about how to reduce build (App) size:

https://developer.apple.com/library/ios/qa/qa1795/_index.html

In particular this part:

Setting the Optimization Level build setting to Fastest, Smallest [-Os]; and the Strip Debug Symbols During Copy build setting to Yes (COPY_PHASE_STRIP = YES) can dramatically lower the size of your compiled binary. These settings are the default for the "Release" configuration in Xcode projects.

Does anyone have the unity bug number for this? I was having the same issue with unity 5.0.3 and vuforia 4.2.3 and I would like to be able to turn optimizations on.

Hi charlesfishermen, i've reported it to Unity and the Case Number is (702408).

Ale.

Do you have a link for that so I can give my votes to it or is the issue private for you?

I have just tried with Unity 4.6.6p1 patch + Vuforia 4.2.3, but it does not work.

RedFrogDigital, did you do any special setting in Unity and/or Xcode?

DigitalSolutions wrote:

I have just tried with Unity 4.6.6p1 patch + Vuforia 4.2.3, but it does not work.

RedFrogDigital, did you do any special setting in Unity and/or Xcode?

HI, currently i'm using unity 4.6.6p3 and the trick by dpizzle and it works fine. Instead on NONE i use FAST, I've just published the app on the AppStore and it works fine on all ioS devices.

Ale.

RedFrogDigital, I forgot the setting of dpizzle. After I setting Xcode as dpizzle's suggestion, it works now.

Thank you.

Thank you everyone - I also had this problem with Unity 5.0.3 and setting optimization levels to FAST fixed it.