SDK 4.2 build must use stripping level or crash at splash screen

Unity Engine
,
1

OS X Lion, SDK 4.2, Unity 3.4.1 pro, target arm7, optimization slow safe:

When I build our game, I must use a stripping level of either Strip Assemblies or Strip Bytecode or the game will crash at the splash screen. (Crashes if I select Disabled or Use micro mscorlib.) Xcode reports “thread 1: program received signal: EXC_BAD_ACCESS” apparently in file mscorlib.dll.s. This happened after upgrading to SDK 4.2.

Building smaller projects works fine without stripping. Our project builds upwards of a 200 MB app.

Any ideas or suggestions? It worked with the previous SDK, but breaks with 4.2.

2
  1. is the first scene an empty one?
  2. Did you ensure you don’t load more stuff into memory than you have? that means < 70mb of RAM + VRAM usage at maximum (100-120mb is possible if the device wasn’t in longer term usage)
3
  1. The first scene is a very small one that loads the large scene. It crashes before this first scene loads.
  2. The game normally loads and plays from 3GS class devices on up. We use Resources.Load() to keep memory use optimized. If nothing else, the first scene is tiny, so that should load without a problem. This makes me think it’s not memory related.
4

if its not RAM related then you should start it from xcode in debug mode and build it from unity with slow and save. Cause then its really a null pointer that happens under the SDK you use or with the device and its iOS version.

by starting it in debug mode from xcode you will get a callstack. its not able to say you which line messed it, but the top most entry in the stack will be a class - function name combination for the monobehaviour in your code thats responsible for it. Potentially you even got to see the error in the editor at times but it didn’t break anything there, where as applications getting null reference exceptions on the device will be killed by iOS instantly (on the desktop the rest of the code is just not executed leading to missbehaviors)

as it happens upon startup, using the mono debugger which you can hookup even to device running code could be tricky unless changing the initial scene to ‘not continue until you touch’ helps in which case you get the required time to hook up the debugger and hopefully get the explicit line that fails that way then

5

FYI: This problem was fixed by updating to the latest Unity version 3.4.2f2. Thanks for the suggestions, dreamora. Luckily the fix came out before we had to try to track this one down.