iOS crash only when NOT running via XCode. Concidence?

Question

My app was crashing only when not running using XCode debugger. It was hard to track because I can't debug but I finally figured it out. It was because of calling release on some object not owned by me. Before I corrected it I searched and found 2 related questions here (links below)

iOS App Crashes when running by itself on device, does not crash when running through Xcode using debugger, or in simulator

iPhone crash only when device not connected to xcode, how to understand the crash log?

None of the above question has answered why no crash when running via debugger.So my question is why it happens ? I know reasons for debug/release specific crashes but this is crazy. Is it just by chance although it happened more than 10 times.

Answer 1

I had this same issue while working on a project modularised with Xcode Frameworks. Even after removing all the logic in AppDelegate and only returning true inside application:didFinishLaunchingWithOptions, I was still getting the crash. Then I switched to my project settings, in the Frameworks, Libraries, and Embedded Content section and changed the embed option for the frameworks I added to Embed & Sign. This was what fixed the issue for me. I hope someone finds this helpful.

Answer 2

I had this issue when accessing SQLite databases from outside the [[NSBundle mainBundle] resourcePath] directory, which caused iCloud errors.

I discovered the error only by installing a Console app onto my iPhone which logged the errors.

Once I accessed the databases from the correct directory, the errors disappeared and the application booted correctly.

Answer 3

Reiterating @jyoung's answer since I didn't see it the first time I glanced through:

Try running with Zombie Objects turned off.

In debug mode if you have it turned on it is handling memory allocation differently. Try running it without.

Go to Edit Scheme... > Run > Diagnostics. Then make sure zombie objects is turned off:

Then run through your code path again.

Answer 4

I was having this problem as well and was fortunate to figure out the cause quickly, hopefully by posting here I can save someone else some wasted time. To clarify, my app would run with no issues when launched directly from XCode, but would crash immediately when launched manually on the iPad.

The app in question is written in Obj-C but relies on some 3rd party code written in Swift. The Swift code is included in the app as an embedded framework. I had to set "Embedded Content Contains Swift Code" to Yes in the Build Settings for the app (under Build Options), then the problem went away.

Answer 5

I experienced this symptom when I made a NSString, sent a UTF8String from it to another object, and assigned it to a char pointer. Well, it turns out that I forgot to retain the original NSString, which wouldn't have mattered anyway, since I also failed to realize that the UTF8String method (which is presumably an object that gives access to the pointer itself) operates in the autorelease pool. That is, retaining the NSString itself did not fix the problem.

I suppose this appeared to work just fine when attached under the debugger only because I had zombies enabled, so the pointer I had was still valid. I should see if this is the reason it worked; if so, this is a good reason to test with and without NSZombie enabled.

At any rate, this was probably poor design to begin with, and a pretty obvious newbie memory management mistake once I found it. Luckily the console in the Organizer window gave me some hints on where to start looking, and debugging ultimately showed me where my pointer's value was changing. Hope this helps anyone who finds the way here.

Answer 6

What you describe is not atypical of obscure memory-related bugs. You might also want to use debug-malloc at such times. Although that is not guaranteed to find everything. The reason (and it's been happening probably as long as there've been source-level debuggers) is that memory is laid out at least somewhat differently in debuggable code, and when running under the debugger. So the error results in a different piece of memory being (harmlessly) corrupted when under the debugger. When not under the debugger the location corrupted is actually something that your code cares about, and it crashes.

The same could happen in reverse, but you'd never know - if it crashes when run debuggable, you'd find it before switching to running outside the debugging environment.