How to get longer stack dump (tombstone) from android?

Question

As I have noticed, logcat returns always 34 lines of crashlog, like this:

4cf7c700  401c0000 
4cf7c704  48463ff0 
4cf7c708  44d11f7c  
4cf7c70c  afd0cd89 
4cf7c710  00000000  
4cf7c714  82ab29dc  libmyproject.so
4cf7c718  00000000  
4cf7c71c  4cf7c73c  
4cf7c720  836c44f0  libmyproject.so
4cf7c724  82f3a414  libmyproject.so
4cf7c728  4cf7c768  
4cf7c72c  0000008d  
4cf7c730  007ea0a8  [heap]
4cf7c734  00270100  [heap]
4cf7c738  e3a07077  
4cf7c73c  ef900077  
4cf7c740  00000000  
4cf7c744  4cf7c774  
4cf7c748  836c44f0  libmyproject.so
4cf7c74c  00000000  
4cf7c750  836c44f0  libmyproject.so
4cf7c754  82f63768  libmyproject.so
4cf7c758  00000000  
4cf7c75c  4cf7c7e4  
4cf7c760  00000000  
4cf7c764  00000001  
4cf7c768  00000000  
4cf7c76c  0badc0de  
4cf7c770  fffffff8  
4cf7c774  00000000  
4cf7c778  00000168  
4cf7c77c  00000009  
4cf7c780  00000200  
4cf7c784  00000000  

However I know that stack is also saved to /date/tombstones/tombstone_0[0-9]. There I can find many other stacks (I am not fully understand from where they came from) and some of them are twice as long than aforementioned stack.

How to get so long stack dump from crash of my application?

Answer 1

The crash handling program in android, which is called debuggerd, only writes a portion of the stack into the log, but writes the full stack into the tombstone file. This is hardcoded in system/core/debuggerd/debuggerd.c.

Look in the routine debug_stack_and_code() for the calls to _LOG(). The second parameter to _LOG controls whether stuff goes only to the tombstone, or to the log and the tombstone.

Where you see (sp_depth>2||only_in_tombstone), you can change the 2 to something else to get deeper stack frames reported in the log. This assumes that you can re-compile debuggerd and replace it on your system. If not, you're stuck with examining the tombstone files themselves for the longer stack dumps.

The dumps are created by debuggerd when a program crashes under Linux. When this happens, the kernel will send a signal to the dying program. This signal is caught by a special signal handler installed in every native Android app. by the bionic C library. The signal handler contacts debuggerd (via a named pipe), which then connects back to the dying program using ptrace to read registers and memory to produce the tombstone and log entries.

Answer 2

I suggest debugging the stack trace found in the tombstone file like the example below.

Example:

#00  pc 00010a20  /system/lib/libc.so
#01  pc 0000b332  /system/lib/libc.so
#02  pc 0000ca62  /system/lib/bluez-plugin/audio.so
#03  pc 0000d1ce  /system/lib/bluez-plugin/audio.so
#04  pc 0000e0ba  /system/lib/bluez-plugin/audio.so

You can use the command below to know the function name, file name and line no.

$(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/addr2line -f -e /out/product/xxx/symbols/system/<SO filename> <PC address>

Example:

$(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/addr2line -f -e /out/product/xxx/symbols/system/libc.so 0x00010a20