iOS: How to catch exception?

Table of Contents

1. System Crash

2. Processing signals

• Here are some signal descriptions
• Key points to note

3. Actual Combat

4. Crash Callstack Analysis – Further Analysis

5. Demo address

VI. References

Preface

Today in the iOS senior group, a friend asked about the problem of iOS exception capture. I have never studied this before, so I took this opportunity to study it. I also wrote a demo, which can be downloaded at the bottom of the article if needed.

Before reading this article, it is recommended that you read the article Talking about iOS Crash Collection Framework after reading this article to understand the principle.

When developing iOS applications, solving the Crash problem is always a difficult problem. There are two types of Crash. One is caused by EXC_BAD_ACCESS, which is caused by accessing a memory address that does not belong to the process, which may be accessing released memory; the other is an uncaught Objective-C exception (NSException), which causes the program to send a SIGABRT signal to itself and crash. In fact, for uncaught Objective-C exceptions, we have a way to record it. If the log is recorded properly, most crash problems can be solved. Here are the UI threads and background threads respectively.

1. System Crash

The abnormal exit of the program caused by system crash can be caught by the UncaughtExceptionHandler mechanism; that is, the content outside the catch in the program is caught by the system's built-in error handling. All we have to do is replace the ExceptionHandler with a custom function.

2. Processing signals

Using Objective-C's exception handling does not get signals. If we want to handle it, we also need to use the Unix standard signal mechanism to register processing functions for signals such as SIGABRT, SIGBUS, and SIGSEGV. In this function, we can output stack information, version information, and everything else we want.

Here are some signal descriptions

1) SIGHUP

This signal is sent when a user terminal connection ends (normally or abnormally), usually when the controlling process of the terminal ends, to notify the jobs in the same session that they are no longer associated with the controlling terminal.

When you log in to Linux, the system will assign a terminal (Session) to the logged-in user. All programs running in this terminal, including the foreground process group and the background process group, generally belong to this Session. When the user logs out of Linux, the foreground process group and the background process with terminal output will receive the SIGHUP signal. The default operation of this signal is to terminate the process, so the foreground process group and the background process with terminal output will be terminated. However, this signal can be captured. For example, wget can capture the SIGHUP signal and ignore it, so that even if you log out of Linux, wget can continue to download.

In addition, for a daemon that is disconnected from a terminal, this signal is used to notify it to re-read the configuration file.

2) SIGINT

Program termination (interrupt) signal, sent when the user types the INTR character (usually Ctrl-C), is used to notify the foreground process group to terminate the process.

3) SIGQUIT

Similar to SIGINT, but controlled by the QUIT character (usually Ctrl-). A process creates a core file when it exits due to SIGQUIT, which is similar to a program error signal in this sense.

4) SIGILL

An illegal instruction was executed. This is usually caused by an error in the executable file itself, or an attempt to execute a data segment. This signal may also be generated by a stack overflow.

5) SIGTRAP

Generated by a breakpoint instruction or other trap instruction. Used by the debugger.

6) SIGABRT

The signal generated by calling the abort function.

7) SIGBUS

Illegal address, including memory address alignment errors. For example, accessing a four-word integer, but its address is not a multiple of 4. It is different from SIGSEGV in that the latter is triggered by illegal access to a legal storage address (such as accessing non-own storage space or read-only storage space).

8) SIGFPE

Emitted when a fatal arithmetic error occurs. This includes not only floating point errors, but also overflows and division by zero and all other arithmetic errors.

9) SIGKILL

Used to terminate the program immediately. This signal cannot be blocked, processed or ignored. If the administrator finds that a process cannot be terminated, he can try to send this signal.

10) SIGUSR1

Leave it to the user

11) SIGSEGV

An attempt was made to access memory that was not allocated to the user, or an attempt was made to write data to a memory address that the user did not have permission to write to.

12) SIGUSR2

Leave it to the user

13) SIGPIPE

Pipeline Broken. This signal is usually generated in inter-process communication. For example, if two processes communicate using FIFO (pipe) and the reading pipe is not open or terminated unexpectedly, the writing process will receive the SIGPIPE signal. In addition, if two processes communicate using Socket, the reading process has terminated when the writing process writes to the Socket.

14) SIGALRM

Clock timing signal, which calculates the actual time or clock time. The alarm function uses this signal.

15) SIGTERM

The program terminate signal. Unlike SIGKILL, this signal can be blocked and processed. It is usually used to require the program to exit normally. The shell command kill generates this signal by default. If the process cannot be terminated, we will try SIGKILL.

17) SIGCHLD

When the child process ends, the parent process will receive this signal.

If the parent process does not handle this signal and does not wait for the child process, the child process will terminate but will still occupy an entry in the kernel process table. This child process is called a zombie process. We should avoid this situation (the parent process should either ignore the SIGCHILD signal, capture it, wait for its derived child process, or terminate the parent process first, in which case the termination of the child process will be automatically taken over by the init process).

18) SIGCONT

Allows a stopped process to continue execution. This signal cannot be blocked. A handler can be used to allow the program to complete specific work when it changes from the stopped state to the continued state. For example, redisplay the prompt

19) SIGSTOP

The execution of the process is stopped. Note the difference between it and terminate and interrupt: the process is not terminated, but just suspended. This signal cannot be blocked, processed or ignored.

20) SIGTSTP

Stops the process from running, but the signal can be handled and ignored. This signal is emitted when the user types the SUSP character (usually Ctrl-Z).

21) SIGTTIN

When a background job tries to read data from the user terminal, all processes in the job will receive a SIGTTIN signal. By default, these processes will stop executing.

22) SIGTTOU

Similar to SIGTTIN, but received when writing to the terminal (or changing the terminal mode).

23) SIGURG

Generated when "urgent" data or out-of-band data arrives at the socket.

24) SIGXCPU

CPU time resource limit exceeded. This limit can be read/changed with getrlimit/setrlimit.

25) SIGXFSZ

When a process attempts to enlarge a file so that it exceeds the file size resource limit.

26) SIGVTALRM

Virtual clock signal. Similar to SIGALRM, but it counts the CPU time used by the process.

27) SIGPROF

Similar to SIGALRM/SIGVTALRM, but includes CPU time used by the process as well as time spent in system calls.

28) SIGWINCH

Emitted when the window size changes.

29) SIGIO

The file descriptor is ready for input/output operations.

30) SIGPWR

Power failure

31) SIGSYS

Illegal system call.

Key points to note

• Among the signals listed above, the signals that cannot be captured, blocked or ignored by the program are: SIGKILL, SIGSTOP
• Signals that cannot be restored to default actions are: SIGILL, SIGTRAP
• The default signals that cause process abortion are: SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGIOT, SIGQUIT, SIGSEGV, SIGTRAP, SIGXCPU, SIGXFSZ
• The default signals that cause the process to exit are:
• SIGALRM,SIGHUP,SIGINT,SIGKILL,SIGPIPE,SIGPOLL,SIGPROF,SIGSYS,SIGTERM,SIGUSR1,SIGUSR2,SIGVTALRM
• The default signals that will cause the process to stop are: SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU
• The signals ignored by the default process are: SIGCHLD, SIGPWR, SIGURG, SIGWINCH
• In addition, SIGIO exits in SVR4 and is ignored in 4.3BSD; SIGCONT continues when the process is suspended, otherwise it is ignored and cannot be blocked.

3. Actual Combat

1. AppDelegate.m

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 
 
 // Override point for customization after application launch. 
 
     
 
 InstallSignalHandler(); //Signal truncation 
 
 InstallUncaughtExceptionHandler(); //System exception capture 
 
     
 
 return YES; 
 
 }

2. Implementation of SignalHandler.m

 void SignalExceptionHandler( int signal) 
 
 { 
 
    NSMutableString *mstr = [[NSMutableString alloc] init]; 
 
    [mstr appendString:@ "Stack:\n" ]; 
 
 void* callstack[128]; 
 
 int i, frames = backtrace(callstack, 128); 
 
 char ** strs = backtrace_symbols(callstack, frames); 
 
 for (i = 0; i 
 
        [mstr appendFormat:@ "%s\n" , strs[i]]; 
 
 } 
 
    [SignalHandler saveCreash:mstr]; 
 
  
 
 } 
 
  
 
 void InstallSignalHandler(void) 
 
 { 
 
    signal(SIGHUP, SignalExceptionHandler); 
 
    signal(SIGINT, SignalExceptionHandler); 
 
    signal(SIGQUIT, SignalExceptionHandler); 
 
     
 
    signal(SIGABRT, SignalExceptionHandler); 
 
    signal(SIGILL, SignalExceptionHandler); 
 
    signal(SIGSEGV, SignalExceptionHandler); 
 
    signal(SIGFPE, SignalExceptionHandler); 
 
    signal(SIGBUS, SignalExceptionHandler); 
 
    signal(SIGPIPE, SignalExceptionHandler); 
 
 }

For more information about error types, see the description above. SignalExceptionHandler is the callback for signal errors. When a signal error occurs, you can call back to this method.

3. Implementation of UncaughtExceptionHandler.m

 void HandleException(NSException *exception) 
 
 { 
 
 // Exception stack information 
 
    NSArray *stackArray = [exception callStackSymbols]; 
 
 // Cause of the exception 
 
    NSString *reason = [exception reason]; 
 
 // Exception name 
 
    NSString * name = [exception name ]; 
 
    NSString *exceptionInfo = [NSString stringWithFormat:@ "Exception reason: %@\nException name: %@\nException stack: %@" , name , reason, stackArray]; 
 
    NSLog(@ "%@" , exceptionInfo); 
 
    [UncaughtExceptionHandler saveCreash:exceptionInfo]; 
 
 } 
 
  
 
 void InstallUncaughtExceptionHandler(void) 
 
 { 
 
    NSSetUncaughtExceptionHandler(&HandleException); 
 
 }

4. Testing – the key to avoiding pitfalls

The most critical step here is not to test SignalHandler in debug environment. Because the system debug will intercept first. We need to run it once and then turn off debug status. We should directly click on the app we built on the simulator to run it. UncaughtExceptionHandler can capture it in debug mode.

 - (IBAction)buttonClick:(UIButton *)sender { 
 
 //1.Semaphore 
 
 Test *pTest = {1,2}; 
 
 free (pTest); // Causes SIGABRT error, because there is no such space in the memory, where does the free come from ? It is just an object in the stack. 
 
 pTest->a = 5; 
 
 } 
 
 - (IBAction)buttonOCException:(UIButton *)sender 
 
 { 
 
 //2.ios crash 
 
    NSArray *array= @[@ "tom" ,@ "xxx" ,@ "ooo" ]; 
 
 [array objectAtIndex:5]; 
 
 } 

4. Crash Callstack Analysis – Further Analysis

5. Demo address

iOSCrashUncaught Download

https://github.com/xcysuccess/iOSCrashUncaught

VI. References

1. Debugging skills after program crash

2. The problem of iOS socket program being terminated by SIGPIPE signal

3. Beautiful Nian Xi

4. How to locate random crashes of wild pointers in Obj-C (I): First, increase the wild pointer crash rate

5. How to locate random crashes in Obj-C wild pointers (Part 2): Make non-necessary crashes mandatory

6. How to locate the random crash of Obj-C wild pointer (Part 3): Add some black technology to make the crash reveal itself