Crash on device using ad-hoc distribution
Asked Answered
F

1

8

Suddenly my ad-hoc distributions through Testflight and iTunes-sync no longer work. The application distributed using the ad-hoc build config never start fully on device. It crashes immediately with a segmentation fault 11.

The weird thing with this problem is that a debug build, on all the devices mentioned below, work flawlessly. This is causing me to believe that there is something messed up in my project.pbxproj. But when I look in the git-log I see nothing out of order, the only thing changed in there are the Architectures (ARCHS) and Valid Architectures (VALID_ARCHS).

Am I correct to assume that messing up the architectures should not cause an actual error on startup but during the build process?

Some Background:
Also worth mentioning is that I had both Xcode 4.4.1 and 4.5 GM installed, when I upgraded the GM to the one from App Store it removed my backup of Xcode 4.4.1 as well. After that hiccup I removed all version of Xcode, rebooted and installed version 4.4.1 again (this is so I can build for armv6).

Any helpful tips in how to proceed with this debugging is extremely valuable to me.
Thanks for your time. <3

Console print and crash log from device:
- https://gist.github.com/3781018
I can add more logs if needed.

Current Environment:
- Xcode Version 4.4.1 (4F1003)
- Mac OS Version 10.8.2

Project Setup (pbxproj):
- https://gist.github.com/3780985

Devices tested:
- iPhone 3GS iOS 6
- iPhone 3G iOS 4.2.1
- iPad 2nd Gen iOS 5.1.1
- iPhone 4S iOS 5.1.1
- iPhone 4 iOS 6.0
- iPhone 4S iOS 6.0

Update
To proceed with the debugging this is what I tried:
1. Skip Testflight and use the old-school way of releasing an ad-hoc with iTunes. FAIL 2. Reinstalling the provisioning profiles FAIL
2. Create a new user on my machine an reinstall Xcode. FAIL
3. Build from another machine. FAIL
4. Set optimization level to: -O0 FAIL

Even though I was certain that none of the code had been changed, I saw no other reasonable explanation for this. So I started reverting the project in git, staring with the day I successfully made an ad-hoc release. To my horror I noticed that the same segmentation fault was following me through the fabric of time!
Considering this fact there was only one action left to take; a very powerful way of debugging I dubbed spray-and-pray. =) In other words I started to comment out sections of the code and see if that made any difference and to my complete surprise it actually did. After a few hours of disabling and enabling parts of my application I found the culprit: a static NSArray was never retained. What's really blowing my mind here is that the actual initialization of the array has been looking the same since 2010. So why on earth did this suddenly result in a memory error now? And why did the static analyzer not warn we about this?

I am too exhausted at the moment to answer those questions right now, I will try to update the question with more details and hopefully an answer as well tomorrow.
Once again, a big thank you for anyone who helped out so far! <3

Feathers answered 25/9, 2012 at 10:8 Comment(5)
Compiler optimizations are sometimes weird and a typical debug build gets rid of optimizations. Tried running a release buid built with -O0?Overcritical
Thank you for the tip, but that did nothing. Same crash as before. :/Feathers
Probably not your issue, but I had the exact same symptoms when I had a signing issue. I had to muck around with my certs and provisioning profiles. Also make sure you are not signing for the app store by mistake.Underscore
Thank you for the tip Ryan but I have checked, double checked and triple checked. It has nothing to do with the signing process, since I can load a dummy view instead of my whole view hierarchy and create a functioning build.Feathers
May i ask out of curiosity what is the line CompanyXTabBarController.m:62 ?Jourdan
C
0

It looks like the cause of the problem is the concurrency issue:

Crashed Thread:  1

In such a case it may be hard to find and resolve the root of the problem (http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug).

May be you are doing something with one object from multiple threads without proper synchronization; or may be you dealloc'ed object in one thread (ex. thread 0) and trying to access it from another (thread 1).

Cruse answered 27/9, 2012 at 15:14 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.