How to get extra call stack depth in crash dumps on Android?
I have some C ++ code that uses the NDK. When a glitch occurs in C ++ code (on the device, not through the emulator), I get a headstone (crash dump) containing a call stack that is always 2 levels deep:
I/DEBUG ( 5089): pid: 5048, tid: 5062 >>> com.example.site <<<
I/DEBUG ( 5089): #00 pc 0059e08c /data/data/com.example.site/lib/libexample.so (_ZNK10MyNamespaceAPI11MyClass12GetDataEv)
I/DEBUG ( 5089): #01 lr 5bc9ef2c /data/data/com.example.site/lib/libexample.so
I/DEBUG ( 5089): 5cc6e764 5bce3070 /data/data/com.example.site/lib/libexample.so
I/DEBUG ( 5089): 5cc6e774 5bce309c /data/data/com.example.site/lib/libexample.so
I/DEBUG ( 5089): 5cc6e784 5bce2af4 /data/data/com.example.site/lib/libexample.so
I/DEBUG ( 5089): 5cc6e788 5c27ea9c /data/data/com.example.site/lib/libexample.so
Is there a way to tweak my application or Android to provide more details and depth in the call stack printed on the crash dump? What actually determines this? I've seen several examples where people get up to 15 levels deep in the call stack.
source to share
The backtrace mechanism, which has evolved over the past few years, shows as many frames as it can find (up to a fixed limit of 32, IIRC). It will stop earlier if something prevents it from going further onto the stack.
The call mechanism on ARM puts the return address in the reference register (LR), but the compiler is allowed to spill it onto the stack. For the "noreturn" functions, you don't technically need to install it at all. There are assembly pseudo-operators that add metadata to help figure out where to find the return address, and in later versions of Android that should work.
When you get a trace with two stack depths, it means that the unwinding failed with the current method, and it can only display the program counter (PC) value and the value that is in LR.
Make sure you compile with -g
to enable debugging.
Is the failure function called directly from the JNI? In some older versions of Android, tracing stopped at the JNI call bridge due to the way the code was structured, although this was fixed in Dalvik back in 2011 . Recent devices use Art, although I believe it has a different way of doing things.
A similar question here .
source to share