Extract and Analyze Android Crash Dumps (Tombstones) with ADB

Why you need tombstone files

When a native Android app crashes (for example, due to a segmentation fault in C/C++ code), the kernel writes a tombstone file. This file contains the register state, memory map, and a stack trace that can pinpoint the offending library or line of code. Unlike the Java‑level logcat output, a tombstone gives you the low‑level details required to debug native crashes.

Before you start

• Charge your device – a sudden power loss while pulling files can corrupt the dump.
• Enable Developer Options → Settings > About phone > tap Build number seven times.
• Enable USB debugging → Settings > System > Advanced > Developer options > USB debugging.
• Install ADB on your PC. The adb binary is part of the Android SDK Platform‑Tools package.
• Have a copy of the app’s symbols (the .so files or an NDK debug symbol file) if you want to translate raw addresses into readable function names.

Step‑by‑step extraction

Decoding the tombstone

The raw tombstone shows hexadecimal addresses. To translate them into readable symbols you need the ndk-stack tool (included in the NDK) or llvm-symbolizer. Both accept the tombstone and a directory containing the matching .so files.

Using ndk-stack

1. Ensure the NDK is installed and ndk-stack is on your PATH.
2. Run the command, pointing to the folder that holds the unstripped .so libraries:

   ndk-stack -sym /path/to/symbols -dump ./tombstone_XX.txt

   The output will replace each address with function_name+offset and show the source file if debug info is present.

Using llvm-symbolizer

1. Locate the llvm-symbolizer binary (it ships with the NDK as well).
2. Extract the stack trace lines that contain raw addresses (they start with #00 pc).
3. Pipe each address through the symbolizer:

   echo "0x7f8a1234" | llvm-symbolizer -obj /path/to/libexample.so

   Repeat for each address or write a small script to automate it.

Interpreting the results

Typical sections you will see:

• PID / TID – process and thread IDs involved.
• Signal – e.g., SIGSEGV (segmentation fault) or SIGABRT.
• Backtrace – the call stack at the moment of the crash. The first frame (#00) is where the crash occurred.
• Memory map – a list of loaded libraries with their load addresses. This is essential for matching addresses to binaries.

When you see a native library you recognize (e.g., libexample.so) and a function name, you can trace the problem back to your source code or a third‑party SDK.

Common pitfalls and how to avoid them

• Missing symbols – If you only have the release .so (stripped), ndk‑stack will show raw addresses only. Keep a copy of the unstripped libraries from your build server for debugging.
• Wrong tombstone version – Some devices (e.g., Samsung) store crash logs in /data/system/dropbox instead of /data/tombstones. If the tombstone directory is empty, check adb shell ls /data/system/dropbox for files like system_app_crash.
• Permission denied – On Android 11+ the /data/tombstones directory may be inaccessible without the android.permission.READ_LOGS permission, which third‑party apps cannot obtain. ADB’s shell user still has access, but you must use adb root on an engineering build. For production devices, stick to the standard adb pull method shown above.

Troubleshooting extraction failures

If adb pull returns permission denied or the file is empty, try the following:

1. Restart ADB server: adb kill-server && adb start-server.
2. Re‑connect the device and ensure the RSA dialog is accepted.
3. Use adb shell su -c "cat /data/tombstones/tombstone_XX" only on devices with a rooted user (not required for most).
4. Check that the crash actually generated a tombstone. Some Java‑only crashes only produce logcat entries.

Putting it all together – a quick workflow

1. Enable USB debugging and connect the phone.
2. Reproduce the native crash.
3. Run adb shell ls -l /data/tombstones to find the newest tombstone_XX.
4. Pull it: adb pull /data/tombstones/tombstone_XX ./crash.txt.
5. Decode with ndk-stack -sym <symbol_dir> -dump ./crash.txt.
6. Read the backtrace, locate the offending function, and fix the code.

After fixing, repeat the steps to confirm the crash no longer appears.

Safety notes

When to seek further help

If you cannot map the address to a symbol despite having the correct .so files, the crash may be occurring in a system library that you cannot recompile. In that case, consider filing a bug report with the device manufacturer, providing the tombstone and device details (model, Android version, kernel version).

With these steps you can reliably extract, decode, and act on Android tombstone crash dumps without rooting your device, turning opaque native crashes into actionable debugging information.