Skip to content

Instantly share code, notes, and snippets.

@SheldonWangRJT
Last active August 4, 2018 21:35
Show Gist options
  • Save SheldonWangRJT/88ee611f146562b8851f67107a349055 to your computer and use it in GitHub Desktop.
Save SheldonWangRJT/88ee611f146562b8851f67107a349055 to your computer and use it in GitHub Desktop.
Dealing with the Crash Log Files (.crash), dSYM, EXC_BAD_ACCESS, EXC_CRASH and so on.

Something About iOS Crashes

#iOSBySheldon Apps are crashing all the time. No matter how good you write your app, it will crash in some cases.

When apps crashed, iOS will automatically generate a crash log file, the file has the extension as .crash. A crash file contains a lot of info like which version, which build, which device your app is crashing on. And the most important part of a crash file a the stack trace that indicates which function of your code in which file is crashing.

However, to find out which function of your code is crashing is not that straight forward from the crash log files. Because when we build our app, Xcode compiles our code files into binaries that changes the looking of our code. Therefore, to find out which line of code is crashing, we need a file to kinda to the translation for us, in iOS, this "translation" needs to be handled by debug-symbols files, which is also called dSYM files. (.dSYM)

Please see [1] as the image that indicates the whole process of creating the build by Apple and see [2] as the Apple document for symbolicating crashes. (Symbolicating iOS Crash Reports With Xcode + Symbolicating Crash Reports With atos) 1

Apart from symbolication, another pretty important thing in the crash file is the crash type. Apple has listed all the types that we need to care about in iOS, (crash types are C related types that we only care few of them), most important ones are [2]:

  1. Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]
    The process attempted to access invalid memory, or it attempted to access memory in a manner not allowed by the memory's protection level (e.g. writing to read-only memory).
  2. Abnormal Exit [EXC_CRASH // SIGABRT]
    The process exited abnormally. The most common causes of crashes with this exception type are uncaught Objective-C/C++ exceptions and calls to abort().
  3. Trace Trap [EXC_BREAKPOINT // SIGTRAP]
    Similar to an Abnormal Exit, this exception is intended to give an attached debugger the chance to interrupt the process at a specific point in its execution.
  4. Illegal Instruction [EXC_BAD_INSTRUCTION // SIGILL]
    The process attempted to execute an illegal or undefined instruction. The process may have attempted to jump to an invalid address via a misconfigured function pointer.
  5. Quit [SIGQUIT]
    The process was terminated at the request of another process with privileges to manage its lifetime. SIGQUIT does not mean that the process crashed, but it did likely misbehave in a detectable manner.
  6. Killed [SIGKILL]
    The process was terminated at the request of the system. Look at the Termination Reason field to better understand the cause of the termination.

References:
[1] https://developer.apple.com/library/content/technotes/tn2151/Art/tn2151_crash_flow.png
[2] https://developer.apple.com/library/content/technotes/tn2151/_index.html

@SheldonWangRJT
Copy link
Author

Reformatted into md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment