iOS Crash without Error or Stack Trace

Question

Having a hard time tracking down a crash in an iPad application. The difficulty really stems from the fact that there is no errors or stack trace present when the application fails. It simply goes away like Keiser Soze, "And like that, poof. He's gone.".

I've replicated the crash on both the simulator and the device. There are zero device logs, nothing in the console, etc.

I know that during the crash some CoreGraphics operations are occurring in a background thread. Typically, three or so NSOperations are kicking of some image blends.

The blending consists of CGContext* calls (DrawImage, SetBlendMode, SetAlpha, etc). The NSOperation calls back to a delegate in the main thread to handle the image and set it to UIImage, so it shouldn't be a UI main thread conflict, but I'm not discounting anything at this point.

Are there some Xcode tricks I'm missing to track down exactly what is happening? Or at least get a better hint of where the problem lies?

EDIT I have run the app in Instruments tracking memory usage and see that it is pretty rock steady around 2MB. So, don't think it's a memory issue. But after consideration, this rock steady 2MB seems abnormally low. Is there a chance Instruments is not picking up the CoreGraphics allocations?

Solution 1

For lack of a better solution, and if it isn't obvious, pepper your app with NSLogs to circle where this occurs, then drill deeper from there via breakpoints and/or additional logs.

Solution 2

Try reading the registers.

Whenever my app crashes without error, in most cases I have found the exception in the registers.

First go to Exceptions tab and 'Add Exception Breakpoint' using the + at the bottom left corner.

Then when the app crashes click on "0 objc_exception_throw" under Thread 1

Finally in the console enter:

• register read (you should get a list of registers)

• po $rax (normally the exception is in 'rax')

  (you should see the exception output on the console)

Hope this helps.

Solution 3

Super late answer, but I've found that using try/catch helps give information when I can't get a stack trace and my application pulls a Keiser Soze.

@try
{
  // suspected code causing crash/errors
}
@catch (NSException *exception)
{
  NSLog(@"Exception: %@", exception);
}

Solution 4

In my case, it was because of bad outlet connection in the storyboard. Check using breakpoint if viewDidLoad method of UIViewController to be loaded gets called. If not, check your outlet connections in the storyboard.

Incorrect connection crashes the app without any error or stack trace.

I am wondering what happened to the this class is not key value coding-compliant for the key error that used to show in older versions of XCode.

Solution 5

In my case, it was because I had "Zombie Objects" enabled in the scheme to help find the problem, which was eventually causing it to run out of memory and crash.

View more solutions

Comments

[Nerrolken]

You said "normally the exception is in 'rax'". Any suggestions for where else to try?

[shrishaster]

@Nerrolken you could try out other registers from the list like 'rab', etc

[Duck]

for some reason I never saw this stuff work. Every time I have tried to used it the app crash the same way. No exception was ever caught for me.

[dragonflyesque]

Did you check out @Paul-Slocum answer below? Also, enabling zombie objects does not throw Objective C exceptions. Good answer here: stackoverflow.com/a/8738527/2907798.

[Duck]

YES. When I enable that, the app goes fine until the memory is exhausted and it crashes without messages or without providing a way to debug. Instruments shows no leak on my code but it is memory intensive. Because zombies keep elements allocated it will use all the memory and crash.

[Albert Bori]

This is a recurring issue for me. Dozens of outlets and one is bad. Without a proper error message, it's like trying to find a needle in a haystack. :(

[Cerlin]

I was not able to get any stack trace, now using this method i got the info. Adding a breakpoint did everything. Thanks a ton.