Crash reporting is the capture of an application’s state at the moment its process terminated, written to disk by a handler installed before the crash and uploaded on the next launch.
A crash handler has to save the signal, the thread list, and register state while the process is dying, and a caught exception is reported by code that is still running.
Example
An iOS crash arrives as unsymbolicated addresses:
Thread 0 Crashed:
0 MyApp 0x0000000102a4c118 0x102a44000 + 32536
1 MyApp 0x0000000102a4b9d4 0x102a44000 + 31188
Symbolication with that build’s dSYM turns the offsets into file and function names. Without the dSYM, the report is a list of numbers.
What Rollbar does with crash reports
Rollbar treats a crash report as a first-class occurrence type alongside exceptions and log messages, so a native crash is grouped into an item and worked in the same feed as a server-side exception. Rollbar exposes the raw report to RQL as body.crash_report.raw, which means crashes are queryable the same way everything else in the project is.
Rollbar’s Apple SDK detects crashes and exceptions automatically across iOS, iPadOS, macOS, watchOS and tvOS and sends the reports to your project. Rollbar accepts iOS dSYM bundles and Android ProGuard files through its symbol map API, so frames resolve to your source rather than to offsets.
Related terms
Sources
- Rollbar Docs, Rollbar Terminology: https://docs.rollbar.com/docs/rollbar-terminology
- Rollbar Docs, RQL: https://docs.rollbar.com/docs/rql
- Rollbar Docs, Apple: https://docs.rollbar.com/docs/apple
- Rollbar API Reference index: https://docs.rollbar.com/reference/post-deploy
