Exception Types in iOS crash logs

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.

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.

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