[Translated] understood that the type of exception iOS

Original link: Understanding iOS Exception Types . (PS unknown reasons has expired, upon inspection, the article referenced in the links are still valid :)

Translation: CoderWangx

When your iOS application crashes, we need to analyze the exception log to locate the root cause. Collapse may be "low memory corruption Low Memory Crash " or "normal abnormal collapse." When it comes to "abnormal", the better understanding "of different types of exception" can really help us quickly locate the problem.

In this article, we will examine iOS application may encounter different types of "abnormal", for example EXC_CRASH , EXC_BAD_ACCESS , EXC_RESOURCE , 00000020 and so on.

Crash log in "abnormal"

"Abnormal" in the word "crash log" More Context and "the Mach abnormal" (in " EXC_ prefix") and " the UNIX signal " (such as: SIGSEGV , SIGBUS etc.). (When there should be a corresponding symbol file dSYM) In some cases the system by mapping the underlying Mach exception translate UNIX signals . That's why you can log in to see helpful "EXC_CRASH (SIGABRT)" and "EXC_BAC_ACCESS (SIGSEGV)" as 异常类型(Exception Type).

With certain exceptions, also comes with an associated processor custom exception code (processor-specific Exception Code) or abnormal subtype (Exception Subtype) , to contain more information about the problem. For example, "EXC_BAC_ACCESS" type, such as a line may have abnormal "KERN_INVALID_ADDRESS at 0x80000010" as "Error Code"; "EXC_RESOURCE" might have a row "WAKEUPS" as "abnormal subcategory."

UNIX signal

iOS developer common UNIX signals are as follows:

UNIX signal Note
SIGSEGV Access an invalid memory address. Address exists, but applications can not access.
SIGABRT program crash. A C function abort()initialized. Generally means that the system detects an error of some transaction, e.g. assert(), or NSAssert()check fails.
SIGBUS Access an invalid memory address. Address does not exist, invalid or alignment. (The address does not exist, or the alignment is invalid.)
SIGTRAP Debugger Related
SEAL Try to perform illegal, defective, or unknown command authority needs.

More UNIX signal can be found here: Unix_signal .

Mach abnormal

Mach abnormal description Note
EXC_BAD_ACCESS Improper Memory Access Access the "wrong" memory address. "Error" may mean "address does not exist" or "application does not have access." It is often the SIGBUS and SIGSEGV associated.
EXC_CRASH Abnormal jump Generally SIGABRT associated meaning code is detected due to the uncaught exception thrown exception exits the application.
EXC_BREAKPOINT Trace / breakpoint capture GM and SIGTRAP associated. It can be triggered when thrown by your own code or NSExceptions.
EXC_GUARD Violation of protection to protected resources (Violated Guarded Resource Protection) Contrary to the protected resource by the trigger guard, e.g. 'certain file descriptor'.
EXC_BAD_INSTRUCTION Illegal Instruction Typically associated with a particular illegal or undefined instruction / operand.
EXC_RESOURCE Resource constraints Because the application resource consumption limit and reach exit.
00000020 Hex exception type Non 'OS Kernel' anomaly.

View the complete list of exceptions please refer Mach here ( sys/osfmk/mach/exception_types.h) source file.

abnormal

EXC_BAD_ACCESS (memory access error)

"EXC_BAD_ACCESS" is one of the most common abnormal APP crash. Unfortunately, it is not easy to debug.

Generally there are two possibilities:

  • Access to certain objects has not been initialized. ( SIGBUS )
  • Access ARC has been released (lead address becomes inaccessible) objects. If this is the case, you can usually in the crash near the top "Backtrace" log in to see objc_release.

As an example:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x6d783f44
...
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000011
复制代码

"EXC_BAD_ACCESS" is also associated with "abnormal code" to help provide additional information. For example, KERN_PROTECTION_FAILUREit indicates that the memory is valid, but does not allow access to its current form, KERN_INVALID_ADDRESSmeaning that the address is invalid.

View here the source file for a complete list of possible values.

To aid in debugging "EXC_BAD_ACCESS" type of exception, you can check in Xcode "Enable Zombie Objects" and try again.

EXC_CRASH (abnormal jump)

Compared to the "EXC_BAD_ACCESS", "EXC_CRASH" more likely to encounter. It usually occurs in the "unrecognized selector sent to instance 0x6a33840" Upon receiving the message is not implemented, Xcode debugger display object.

Generally in this exception will play a role together with the debugger, because the debugger can interrupt the process. If you do not attach a debugger, a crash log is generated.

Examples of information crash logs show:

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
...
## Usually you will see a similar line in the "backtrace" part
2 CoreFoundation 0x36c02e02 -[NSObject(NSObject) doesNotRecognizeSelector:] + 166

复制代码

There may be some special cases and "unrecognized selector" irrelevant. If met, please note that this kind of thing can happen everywhere.

Another common "EXC_CRASH" case is about "application extension (App Extensions)". Applying Extensions "It took too long to initialize" system will be terminated. In this case, the abnormal subtype (Exception Subtype) displayed LAUNCH_HANG, with a decent exception message (Exception the Message) :

Exception Type: EXC_CRASH (SIGABRT)
Exception Subtype: LAUNCH_HANG
Exception Message: The extension took too much time to initialize

复制代码

EXC_BREAKPOINT (trace capture)

And "EXC_CRASH" very similar, EXC_BREAKPOINT often play a role with the debugger, it is captured in the test phase. When using the Swift , the exception will be thrown at run time in the following cases:

  • A non-optional type is nil
  • Cast fail

As examples of information:

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

复制代码

You can manually call in the code __builtin_trap()to trigger this exception.

EXC_GUARD (violation of the protection of protected resources)

Unlike all other abnormal "EXC_" prefix, this exception is not a "native" of Mach exception. In fact, it is XNU - a derivative of Apple developed the operating system kernel and add.

" XNU " on behalf of "X is not Unix" (X is Not Unix) . "EXC_GUARD" can be defined here - osfmk/mach/exception_types.hto find.

A good example of this exception is to close its "file descriptor (file descriptor)" when an application to access SQLite file in Core Data.

Before iOS7, this exception will be incidental part of the "abnormal code (Exception Codes)" to help understand the situation. Exception code includes "two" bit field codes (eg: 0x400000010000005e) and the Subcodes (eg:0x00007f8254a019c0 ).

Bit field decomposed into code portions "3" zones:

  • Type Guard - this time only one type - a protected file descriptor (guarded File descriptor (GUARD_TYPE_FD)) . Value 0x2. If you see a 0x4 as a prefix code, then the collapse associated with "file descriptor."
  • Flavor - different conditions of violation "protected file descriptors" When: If "1" ( ) [32]: "1 << 0"position ( kGUARD_EXC_CLOSE ), it has tried to call in the "protected files Description" on close(). If the "2" ( ) [33]: "1 << 1"position ( kGUARD_EXC_DUP ), it tries to use in the "protected file descriptors," F_DUPFDor F_DUPFD_CLOEXECcall dup(2), dup2(2), fcntl(2). Also it includes attempts to use /dev/fd/to open the "file descriptor." If "3" ( ) [34]: "1 << 2"position ( kGUARD_EXC_NOCLOEXEC ), it tries to close the "close-on-exec" flag on the "file descriptor." If the "4" ( ) [35]: "1 << 3"position ( kGUARD_EXC_SOCKET_IPC ), it tries to send "protected file descriptor" through the socket (socket). If "5" ( ) [36]: "1 << 4"position ( GUARD_FILEPORT ), it has tried to create a file from the port "protected file descriptor" through the socket (socket). If "6" ( [37]: "1 << 5") position ( kGUARD_EXC_MISMATCH ), explained "protected file descriptors" and "guards" do not match. If the "7" ( [38]: << 6) position ( kGUARD_EXC_WRITE), It had tried to write a "protected file descriptor" through the socket (socket).
  • Descriptor File - Protected file descriptor application attempts to operate. - the Subcodes for section contains "protected value."

Details can be defined here ( /bsd/sys/guarded.h) found.

Starting iOS 7, "Exception Codes" is a more detailed explanation "Exception Subtype" and "Exception Message" alternative.

# iOS 6
Exception Type: EXC_GUARD
Exception Codes: 0x400000010000005e, 0x00007f8254a019c0
# The type is "GUARD_TYPE_FD" (0x4), with "kGUARD_EXC_CLOSE". The FD is "94".
# -------
# iOS 7 and above
Exception Type: EXC_GUARD
Exception Subtype: GUARD_TYPE_FD
Exception Message: CLOSE on file descriptor 81 (guarded with 0x0000000017e6eed0)
复制代码

EXC_BAD_INSTRUCTION (illegal instruction)

"EXC_BAD_INSTRUCTION", usually with " SIGILL Association", is a very easy to understand abnormal - that you're using the "wrong" instruction or operation. However, sometimes it is difficult to debug.

The following are some of the more common situation. Since the debug information provided by Xcode, this is very easy to recognize - it is due to unsafe due to unpack.

## Usually show "EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)" in Xcode.
“fatal error: unexpectedly found nil while unwrapping an Optional value”
复制代码

But, like so and so (are issues on StackOverflow) is not easy - the first relates to the use GCD, and the other is Apple's bug. The following is the display format to crash log:

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x000000000000b6d2
复制代码

EXC_RESOURCE

"EXC_RESOURCE" means the process "to reach the upper limit of consumption of resources." Usually, when your application within a certain time duration exceeds the limit it will be triggered. This exception contains " Exception Subtype " to help understand the actual situation:

  • The CPU - is limited to 50%a period not exceeding 180秒.
  • WAKEUPS - represents a wake-up too many threads per second. It is limited to 150次/每秒a period not exceeding 300秒.
  • The MEMORY - No document describes restriction information.

And "EXC_GUARD" Similarly, it had used "bit field" to convey information, but now they use "Exception SubType" and "Exception Message".

Exception Type: EXC_RESOURCE
Exception Subtype: CPU
Exception Message: (Limit 50%) Observed 85% over 180 secs
---
Exception Type: EXC_RESOURCE
Exception Subtype: WAKEUPS
Exception Message: (Limit 150/sec) Observed 206/sec over 300 secs
---
Exception Type: EXC_RESOURCE
Exception Subtype: MEMORY
Exception Message: Crossed High Water Mark
复制代码

00000020

And " EXC_ " exception different, this "exception type" can not actually tell you anything. Instead, you should review the "Exception code" for more details.

  • 0x8badf00d(Pronounced ATE Bad Food ) - said that as a result of the application watchdog timeout terminated by the operating system. Usually means that the application took too long to start, shut down or in response to system events. A very typical case is "doing a synchronized network on the main thread requests."
  • 0xbaaaaaad(Pronounced "plooookhy") - indicates that the log is the stack of the entire system, rather than a crash report.
  • 0xc00010ff(Pronounced cool off (cool) ) - system indicates the application is closed in response to a thermal event.
  • 0xbad22222 - indicates the operating system terminates a VoIP program because it too often perform recovery.
  • 0xdead10cc(Pronounced dead lock (deadlock) ) - Indicates application running in the background while maintaining system resources.
  • 0xdeadfa11(Pronounced Deadfall ) - represents the user application is forced to shut down. Forced off occurs before the user presses the power button until the "slide to power off" appears, and then hold the Home button.

These "Hex" code is actually six-syllable word - create magic number is not as easy to forget that by our developers.

Further reading

You can view this article Demystifying iOS Application Crash Logs to learn iOS exception log structure.

Reproduced in: https: //juejin.im/post/5d04bdf4f265da1b83338b8b

Guess you like

Origin blog.csdn.net/weixin_34375251/article/details/93172045
Recommended