什么情况下产生/data/tombstone 墓碑日志

Android中较容易出现以下三类问题:Force close / ANR / Tombstone

Force close / ANR 前两者主要是查看当前的进程或者系统框架层的状态和堆栈就基本可以分析出来，本文主要讨论一下tombstone的情况。

tombstone一般是由Dalvik错误、状态监视调试器、C层代码以及libc的一些问题导致的。

当系统发生tombstone的时候，kernel首先会上报一个严重的警告信号（signal）,上层接收到之后，进程的调试工具会把进程中当时的调用栈现场保存起来，并在系统创建了data/tombstones目录后把异常时的进程信息写在此目录里面，开发者需要通过调用栈来分析整个调用流程来找出出问题的点。

如何分析墓碑日志呢？

基本工具：

prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin

在分析的时候仔细读取汇编会获得更多有用的异常发生时的信息。

1.arm-eabi-addr2line 将类似libxxx.so 0x00012345的调用栈16进制值翻译成文件名和函数名

  arm-eabi-addr2line -e libxxx.so 0x00012345

2.arm-eabi-nm 列出文件的符号信息

  arm-eabi-nm -l -C -n -S libdvm.so > dvm.data

3.arm-eabi-objdump 列出文件的详细信息

  arm-eabi-objdump -C -d libc.so > libc.s

通过以上工具的分析 ，我们可以得到较完整的调用栈以及调用逻辑的汇编码。

然后需要结合ARM架构及ARM汇编的知识（有些情况下可能需要使用gdb）

来分析出现tombstone的原因，以下是本人遇到过的一些tombstone的情况：

1.无效的函数指针：指针为NULL或者已经被重新赋值

2.strlen崩溃：导致不完全的栈信息，栈被破坏

3.FILE操作：因为stdio并非线程安全的，多线程操作时，容易出现异常。
 

    本文涉及到的tombstone处理的主要逻辑所在文件如下：
    BootReceiver.java -- frameworks\base\services\java\com\android\server
    Debuggerd.c -- system\core\debuggerd
    ThreadLocal.java -- libcore\luni\src\main\java\java\lang

请看下面专业的网友分析墓碑日志的博文：

最近在学习通过墓碑文件定位bug所在位置，网上浏览了很多的博客，大多数只能做到利用addr2line定位到行号

但是对于大型项目，尤其是C++代码较多的情况下，很难去准确定位到内存越界、内存溢出等问题（全球性难题，没办法）。

在这里整理一下，尽量给自己和大家提供一些路径：

1. https://blog.csdn.net/Zhanganliu/article/details/87715961

这篇文章讲了墓碑文件中大致分为哪几个部分，并且能够通过addr2line定位出错文件行号（大多程序都能通过这个方法解决）。

并且提供了.so库反编译为汇编文件的方法。

2. https://blog.csdn.net/a254373829/article/details/8295861

第二篇文章是别人解决墓碑的步骤，主要是通过反编译出来的汇编语言定位（比addr2line更精准，但对一些大型项目中的内存问题还是难以解决），并且要求自身对汇编语言有所掌握。

3.https://blog.csdn.net/matrix_laboratory/article/details/48498157

这篇文章比较详细地分析了tombstone文件中各个部分的含义，并且基于相对地址、绝对地址的方法来定位bug位置，对理解墓碑文件很有帮助。（我们公司的大佬大多也是对这个方法有所心得，通过各种地址来解决内存问题，但是对于大型C++项目来说，还是有所限制，毕竟是世界性难题，能这么简单解决是不可能的）

希望这几篇文章能给大家提供一些帮助，毕竟深层次的墓碑能够解决掉的话，就算去大厂也都能令人刮目相看。
————————————————
版权声明：本文为CSDN博主「ZalGGboy」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Zhanganliu/article/details/88292763