The complexity of NDK crash reporting
summary
Explains why on-device tombstones use libunwind/libcorkcrew and debuggerd/crashdump to produce reasonably accurate system frames but often miss app DWARF, why a first attempt to unwind inside a signal handler fails for reliability and safety, and why switching to Breakpad (minidumps + symbol files) then to Crashpad (trampoline process + mini dump) yields much higher reliability and accurate app frames; Crashlytics NDK now uses Crashpad but system symbols remain a hard unsolved gap.
AI-written summary · about
chapters (9)
- 0:00Intro
- 4:00System libraries
- 4:45Inaccuracy
- 6:47Reliability
- 7:42Security
- 9:17System symbols
- 10:02Crashpad
- 11:44Conclusion
- 12:57Takeaways
related talks
43mAndroid NDK Crash Reports
31mWhat's new in Android C++ development
57mModern Linux C++ debugging tools - under the covers
32mGetting Started with the Android NDK
20mHow Debuggers Work
17mHow to crash your app in production and still delight your users
37mPracticing Linux Crash/Panic Issue on Production and Cloud Server: Using Kdump + Crash
57mLessons from 20 years of Debugging C++ Code