Exception Types in iOS crash logs

Question

I've seen a few different types of crash logs since I begin learning iOS development.

I know that: Exception Type: EXC_BAD_ACCESS (SIGSEGV) mean we are accessing a released object.

but don't know about:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Type: EXC_CRASH (SIGABRT)
Exception Type: EXC_BREAKPOINT (SIGTRAP)

Do you know how many Exception Types in iOS crash logs and what do they mean?

Solution 1

I know that: Exception Type: EXC_BAD_ACCESS (SIGSEGV) mean we are accessing a released object.

No.

A SIGSEGV is a segmentation fault, meaning you are trying to access an invalid memory address.

Those exceptions (in fact, they are signals) are not related to Objective-C, but C. So you can get such an exception without Objective-C objects.

Note that a signal is not an exception, meaning you can't catch them with @try and @catch blocks.

You may set a signal handler with the signal and sigaction functions. Keep in mind some signals, like SIGABRT cannot be blocked.

You can check the Wikipedia page about signals, if you want more informations.

That said, to resume:

SIGSEGV (Segmentation fault)

Access to an invalid memory address. The address exist, but your program does not have access to it.

SIGBUS (Bus error)

Access to an invalid memory address. The address does not exist, or the alignment is invalid.

SIGFPE (Floating point exception)

Invalid arithmetic operation. Can be related to integer operations, despite the name.

SIGPIPE

Broken pipe.

SIGILL

Illegal processor instruction.

SIGTRAP

Debugger related

SIGABRT

Program crash, not related to one of the preceding signal.

Solution 2

SIGSEGV literally means you're accessing an address you don't own. So it's not necessarily that you're accessing a released object; you could be accessing an object that never existed, as in:

UIView *view; // uninitialised, could point to anything
[view setFrame:someFrame];

Or even just making an error in C-level non-object stuff, such as:

int array[100];
array[1000] = 23; // out-of-bounds access

SIGBUS is very similar to SIGSEGV, the difference being at the hardware level (usually the difference between trying to access an address that does exist but which you don't own and trying to access an address that doesn't have anything behind it, but that's not a strict definition), but is usually associated with the same sort of errors, though a SIGBUS is much more likely to be to do with an uninitialised variable than a SIGSEGV.

If you're trying to map to errors you probably made in Objective-C, you probably just want to read SIGSEGV and SIGBUS together as meaning "a memory access I didn't have the right to make".

SIGABRT is a program attempting to abort itself, so it usually means that some sort of internal consistency check has failed. For example, SIGABRT is raised if you try to free the same memory twice, or — at the Cocoa level — if you raise an NSException that isn't caught. If you get a SIGABRT, you've done something wrong that is detected by the system software (in contrast to SEGV and BUS, which arise in hardware).

SIGTRAP is a call out from the program to a debugger. Anecdotally, Apple seem to use these when you do something wrong that can be detected in software but relates to the environment rather than your specific code. So, for example, you call a C function that exists in the SDK you built with but not on the device you are running on (such as when you build against the latest SDK with a lower deployment target), or do a similar thing with an object.

Solution 3

These messages are from gdb, and they are not exclusive for objective-C. To get info about the signals all you have to do is enter info signals at the debugger console, this is an example output. Sorry for no posting it here, but the format of the console output is awful.

Source and more info about signals

Solution 4

I've recently studied this topic area and here is my summary:

EXC_BAD_ACCESS (SIGSEGV) or EXC_BAD_ACCESS (SIGBUS)

Our program most likely tried to access a bad memory location or the address was good but we did not have the privilege to access it. The memory might have been deallocated due to memory pressure.

EXC_BREAKPOINT (SIGTRAP)

This is due to an NSException being raised (possibly by a library on our behalf) or _NSLockError or objc_exception_throw being called. For example, this can be the Swift environment detecting an anomaly such as force unwrapping a nil optional.

EXC_BAD_INSTRUCTION (SIGILL)

This is when the program code itself is faulty, not the memory it might be accessing. This should be rare on iOS devices; perhaps a compiler or optimizer bug, or faulty hand written assembly code. On Simulator, it is a different story as using an undefined opcode is a technique used by the Swift runtime to stop on access to zombie objects (deallocated objects).

EXC_GUARD

This is when the program closed a file descriptor that was guarded. An example is the SQLite database used by the system.

View more solutions

Comments

[sage444]

provided samples doesn't throw exceptions in xcode6.1

[Tommy]

With ARC the first sample is now explicitly legal; view is implicitly initialised to nil and messaging that is always safe. Try setting it to a random address. I'm on an iPad right now; will edit when I'm at a real keyboard.

[n13]

SIGTRAP is not debugger related. According to the specs, this happens when there's an exception and that would trigger a debugger breakpoint if the app were running in a debugger. If it's not running in a debugger, it just terminates. In Swift, It's either trying to unwrap an optional that is nil, or an invalid force conversion.