iOS Crash Interception, Reporting, and Post‑Crash Handling

In the previous article we covered the four stages of crash handling and the methods of crash protection. This article discusses the remaining three stages: crash interception, crash reporting, and post‑crash processing.

Crash Interception

All crashes that are not protected will eventually reach this step. The interception must be comprehensive and stable , capturing as many exception types as possible without generating new exceptions. The following aspects need to be considered.

I: Crash Types

Similar to most operating systems, iOS exceptions are mainly divided into three categories: user‑level , system‑level , and signal . The article then explains each type.

Mach Exception – includes hardware‑level or system‑level exceptions (native to Mach micro‑kernel) and iOS‑specific logical exceptions that are first lowered to Mach.

Exception – common exceptions with a typical trigger flow (illustrated by an image).

Signal – generated from MachException conversion, abort signals from exceptions, or user‑defined signals. Note: receiving a signal does not always mean a crash, but every crash will emit a signal.

II: Crash Propagation Process

The article shows how the three crash types propagate through the app lifecycle and transform into each other.

Key points extracted from the diagram:

1: Exception eventually converts to Mach Exception.

2: Interception via Mach port is relatively comprehensive.

3: If an exception occurs, the corresponding signal is not thrown; only abort is.

4: Signals cannot intercept exceptions.

III: Choice of Interception

Although Mach‑port interception is comprehensive, it captures all exceptions and signals, which may cause deadlocks or conflicts when the callback performs further interception. Therefore, a combination of signal and exception handling is recommended.

Signal can capture all exceptions except those handled by Exception.

Exception can capture user‑level exceptions but not signals.

The final approach uses both signal and exception handlers.

IV: Pitfalls

Only one custom crash handler can exist in iOS. When multiple SDKs register crash handlers, conflicts arise, causing unclear or lost stack traces. The solution is to save the previous handler pointer and invoke it after the custom handler finishes.

Exception: obtain previous handler via NSGetUncaughtExceptionHandler and restore with NSSetUncaughtExceptionHandler(oldHandler) .

Signal: obtain previous handler via sigaction and restore similarly.

Stack Retrieval

Because iOS uses Address Space Layout Randomization (ASLR), online stack traces must be symbolicated using the symbol table; otherwise they appear as raw memory addresses. The article outlines the steps to reconstruct symbols by iterating over Mach‑O images, obtaining base addresses, translating stack offsets to function addresses, and looking up the nlist_64 structures.

Post‑Crash Handling

After a crash, the handler may perform reporting, but Apple discourages heavy operations inside the handler because the app may be terminated before network requests finish.

The run‑loop is interrupted; its do‑while condition is set to NO . After the handler returns, the current loop ends, but the app can start a new run‑loop to execute limited logic (e.g., show a friendly prompt) before finally aborting.

Example code to continue after a crash:

void continueAfterCrash()
{
    CFRunLoopRef runLoop = CFRunLoopGetCurrent();
    CFArrayRef allModes = CFRunLoopCopyAllModes(runLoop);

    for (NSString *mode in (__bridge NSArray *)allModes)
    {
        CFRunLoopRunInMode((CFStringRef)mode, 1.0e10, false);
    }
}

When using this new run‑loop, keep in mind:

The original run‑loop state remains in memory and must not be accessed.

Only safe, system‑provided APIs should be used; avoid third‑party libraries.

Perform minimal work and terminate the app promptly.

References

Apple iOS API – https://developer.apple.com/documentation

iOS Open Source – https://opensource.apple.com/

CFRunLoop source – https://opensource.apple.com/source/CF/CF-1151.16/

XNU 3248.60.10 source – http://opensource.apple.com/tarballs/xnu/xnu-3248.60.10.tar.gz

Understanding Crash Reports on iPhone OS – https://developer.apple.com/documentation/xcode/diagnosing_issues_using_crash_reports_and_device_logs/analyzing_a_crash_report

《深入解析 MAC OS X & IOS 操作系统》

Overall, this article provides a comprehensive overview of iOS crash protection processes, including interception, stack symbolication, and safe post‑crash handling.