Bad Instruction with iOS framework upon deployment to IPA

[grgcombs]

Is anyone else having issues with Bad Instruction: 4 crashes when deploying an app based on these iOS frameworks to the device via an IPA?

The crash only happens when you archive the app, sign it, and install it on the device. It does not occur when compiling for Release, or otherwise when it's convenient for the debugger to catch the problem. I'm spending hours on hours archiving, signing, installing the IPA, and symbolicating the resulting crash logs with hundreds of NSLogs for any debugging info. I'm drowning.

From what I can gather from several stack overflow posts, it would seem that it has to do with running any static C functions in sub-libraries.

So my application workspace and frameworks (via dependency) look like this:

Application Target:

• An "app plugin" as a framework
• Common/Core utility framework
• Custom UI element framework
• Custom UI Shell/Environment framework
• Security and Authentication framework

• Network and Data framework

  -- RestKit as a framework (inside the network and data framework, in order to keep it unexposed)

All the frameworks have the same build settings. All of the frameworks are executing code successfully before the crash. Some of the RestKit framework methods work fine too, but it's a few seconds into the startup that it dies while mapping some JSON to Core Data (not all JSON to Core Data is problematic though, it's already mapped some successfully before the crash).

Jul 31 04:13:48 unknown ReportCrash[11834] <Notice>: Formulating crash report for process Fusion Tap[11830]
Jul 31 04:13:48 unknown com.apple.launchd[1] <Warning>: (UIKitApplication:com.oraclecorp.internal.Fusion-Tap[0x704a]) Job appears to have crashed: Illegal instruction: 4
Jul 31 04:13:48 unknown SpringBoard[23] <Warning>: Application 'Fusion Tap' exited abnormally with signal 4: Illegal instruction: 4
Jul 31 04:13:48 unknown ReportCrash[11834] <Notice>: Saved crashreport to /var/mobile/Library/Logs/CrashReporter/Fusion Tap_2012-07-31-041347_Spooky-Mulder.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0

[grgcombs]

OK, a little more info on the issue. As for the root cause of the crash, it's still unclear to me, but after iterating through the project history I've identified some factors that help introduce the problem.

The crash occurs after making the following changes to each of the "framework" and "sub-framework" library build settings:

    DEAD_CODE_STRIPPING = NO;
    STRIP_STYLE = "non-global";
    COPY_PHASE_STRIP = NO;

However, even with these settings in place the crash is effectively eliminated if I convert RestKit's RKObjectIsValueEqualToValue() function into a class method.

So at this point, should I invoke the power of @blakewatters too? I'm baffled at how electing to not strip dead/debugging library code and would introduce such a crash. I would expect that these mysterious illegal instruction problems would be more prevalent if someone did strip such things when they shouldn't... Alas, my years at Metrowerks/CodeWarrior didn't prepare me enough for funky llvm compiler/linking craziness.

[mvoong]

We're having the exact same problem! We found out the hard way - waiting for 8 days and Apple telling us about it. In our case we hid the Urban Airship static library inside the dependent project to hide it.

We found two workarounds:

1. Move the Urban Airship static library into the main project. We didn't have to do this when creating an IPA file without using the archive tool. Would be great if someone could explain why?! What does archiving do differently to a normal build?
2. Compiling the framework using the aggregate "Framework" target and importing this into the main project rather than using the dependent project approach. Again, does anyone know why this would make a difference?

[mvoong]

I found this, which describes a bug in Xcode 4.3+.

"When performing an Archive action, Xcode uses the project-level build setting for STRIP_INSTALLED_PRODUCT rather than the target-level setting."

http://www.cocoabuilder.com/archive/xcode/313893-bug-xcode-wrongly-applies-project-settings-during-target-archive.html