正如我所注意到的，logcat 总是返回 34 行崩溃日志，如下所示:
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
但是我知道堆栈也保存到 /date/tombstones/tombstone_0[0-9]。在那里我可以找到许多其他堆栈(我不完全了解它们的来源)，其中一些堆栈的长度是上述堆栈的两倍。
如何从我的应用程序崩溃中获取如此长的堆栈转储？
最佳答案
android中的crash处理程序，叫做debuggerd，只将堆栈的一部分写入log，而是将整个堆栈写入tombstone文件。这是在 system/core/debuggerd/debuggerd.c 中硬编码的。
在例程 debug_stack_and_code() 中查找对 _LOG() 的调用。 _LOG 的第二个参数控制内容是只进入逻辑删除，还是发送到日志和逻辑删除。
在您看到 (sp_depth>2||only_in_tombstone) 的地方，您可以将 2 更改为其他内容，以便在日志中报告更深的堆栈帧。这假定您可以重新编译 debuggerd 并在您的系统上替换它。否则，您将不得不检查逻辑删除文件本身以查找更长的堆栈转储。
当程序在 Linux 下崩溃时，转储由 debuggerd 创建。当这种情况发生时，内核会向垂死的程序发送一个信号。此信号由安装在每个 native Android 应用程序中的特殊信号处理程序捕获。通过仿生 C 库。信号处理程序联系 debuggerd(通过命名管道)，然后 debuggerd 使用 ptrace 连接回垂死的程序以读取寄存器和内存以生成墓碑和日志条目。
关于android - 如何从 android 获取更长的堆栈转储(墓碑)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5106581/