23.5 · Crash reports, symbolication and a production diagnostics pipeline

A crash on a user’s phone arrives as a block of hexadecimal addresses. The skills are reading what the system tells you, turning addresses back into your code, and building the process that finds the crashes that matter.

Mental model. A crash report is a witness statement: it tells you how the process died and where. Symbolication turns that into names, and a pipeline turns thousands of them into a short list.

One crash

Reading a report and symbolicating it.

1. How do you read a crash report, what do the exception types and Swift runtime messages mean, and how does symbolication with dSYMs work? 23.5.1 · L3
   A crash report (an .ips file) starts with who and how: the app, version, OS and device, then the exception type and codes, the termination reason, the…

Many crashes

Collecting, grouping and prioritising diagnostics in production.

1. How do you build a production diagnostics pipeline: collection, symbolication, grouping, prioritisation, breadcrumbs and the response? 23.5.2 · L8
   One crash is a debugging task; ten thousand are a system. Design it in stages. Collect from several sources because each sees different things: the platform’s…

More in Debugging & Instruments

• 23.1 · LLDB and breakpoints
• 23.2 · The view debugger, network inspection and memory bugs
• 23.3 · Sanitizers, and bugs that only appear in Release
• 23.4 · Unified logging: Logger, levels, privacy and reading logs back
• 23.6 · Console, sysdiagnose and reproducing a bug
• 23.7 · Schemes, test plans, simulators and derived data
• 23.8 · Reading sanitizer output, exit codes and runtime traps
• 23.9 · Diagnosing a hang, malloc debugging and leaks from the command line
• 23.10 · Demangling, atos and empty dSYMs, and log formatting