Mastering iOS Crash Handling, OOM Monitoring, and Memory Profiling

Introduction

Application crashes provide a terrible user experience; this article examines iOS internals, crash collection methods, OOM monitoring, and analysis techniques as presented in an APM system.

1. Exception Handling

1.1 OS X / iOS System Architecture

The OS X and iOS architectures share four layers: User Experience, Application Framework, Core Framework (including OpenGL), and Darwin (kernel and UNIX shell). Darwin is fully open source and provides the base APIs.

1.2 Mach Layer

Mach is a microkernel handling process/thread abstraction, virtual memory, scheduling, and inter‑process communication. Exception handling in Mach works via message passing: a failing task or thread sends a message with msg_send() to an exception port, which a handler receives with msg_recv() . The handler can process, clear, or terminate the thread. If no port returns KERN_SUCCESS , the task is terminated.

1.3 BSD Layer

BSD builds on Mach, offering POSIX compatibility, UNIX process and thread models, networking, file system access, and device access. BSD converts Mach exceptions into UNIX signals (e.g., SIGBUS , SIGSEGV , SIGABRT , SIGKILL ). The bsdinit_task() function registers a Mach exception port so that UNIX‑style signals are delivered to user‑space.

1.4 Objective‑C Exception Handling

NSException can be caught by registering NSUncaughtExceptionHandler , allowing the crash data to be forwarded to the reporting component.

2. Crash Collection Methods

2.1 Mach Exception Collection (KSCrashMonitor_MachException.c)

<code>static bool installExceptionHandler() { ... }</code>

The code installs a custom exception port, saves previous ports, and creates a kernel thread to receive Mach exception messages, converting them into JSON crash reports.

2.2 Signal Exception Collection (KSCrashMonitor_signal.c)

<code>static bool installSignalHandler() { ... }</code>

It allocates an alternate signal stack with sigaltstack , registers handlers for fatal signals via sigaction , and stores previous handlers to restore later.

2.3 C++ Exception Collection

<code>static void CPPExceptionTerminate(void) { ... }</code>

Uses std::set_terminate to catch uncaught C++ exceptions, converting them into crash reports.

3. OOM (Out‑of‑Memory) Concepts

OOM occurs when an iOS app exceeds its memory limit and the system terminates it. Jetsam logs (starting with "Jetsam") record these events. Two OOM types are defined:

Foreground OOM – the app crashes while in the foreground.

Background OOM – the app is terminated while in the background.

3.1 Jetsam Mechanism

iOS lacks swap space; when memory pressure is high, the kernel terminates low‑priority or high‑memory‑usage processes. The Jetsam log includes fields such as uuid , states , lifetimeMax , rpages , and reason (e.g., "per-process-limit").

3.2 OOM Warning

The APM SDK monitors memory via task_info to obtain phys_footprint . When usage exceeds a configurable threshold, the SDK reports the memory state.

<code>int64_t memoryUsageInByte = 0;
 task_vm_info_data_t vmInfo;
 mach_msg_type_number_t count = TASK_VM_INFO_COUNT;
 kern_return_t kernelReturn = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)&vmInfo, &count);
 if (kernelReturn == KERN_SUCCESS) {
   memoryUsageInByte = (int64_t) vmInfo.phys_footprint;
 }
</code>

3.3 OOM Monitoring

Since Jetsam termination sends SIGKILL , which cannot be caught, the SDK determines OOM by checking the reason for the previous app termination (e.g., not a crash, not a manual exit, not an update). If none of those apply, the SDK logs an OOM event and captures the stack trace.

<code>-(NSDictionary *)parseFoomData:(NSDictionary *)foomDict { ... }</code>

3.4 Memory Snapshot (Memory Imaging)

When OOM is detected, the SDK scans all VM regions using vm_region_recurse_64 to build a snapshot of memory nodes, then analyzes reference relationships between Objective‑C objects, C/C++ objects, and raw buffers.

<code>void VMRegionCollect::startCollet() { ... while (1) { vm_region_submap_info_64 info; ... }</code>

The snapshot includes node addresses, dirty/swapped sizes, and reference graphs, enabling developers to locate large memory allocations.

4. Crash Reporting Flow

4.1 APM Crash Upload Process

KSCrash captures the crash and invokes the APM crashCallBack function.

The callback writes the crash data to the APM log and caches it.

On the next app launch, the SDK uploads the cached crash files to the server.

4.2 Log Parsing

The server uses the crash’s version, binary image list, and UUID to symbolicate the report, making it readable in the management console.

Conclusion

The APM system provides three key OOM‑related capabilities: proactive OOM warnings, post‑OOM monitoring with stack capture, and detailed memory imaging that visualizes reference relationships and memory consumption, helping developers quickly identify and fix memory‑related crashes.