问题
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?
回答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.
回答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
来源：https://stackoverflow.com/questions/5106581/how-to-get-longer-stack-dump-tombstone-from-android