NE问题分析之db文件及信号

本文将简单介绍NE问题的db文件以及问题信号类型，

拿前几天项目上遇到一个SIGABRT类型的NE问题来说

如下是main.log中打印出来的tombstone

03474cb4-656b-4be1-a02b-9fb7edbc025b.png

详细的日志信息需要分析mtklog/aee_exp文件夹下的db文件，使用GAT工具打开db文件后
目录示例如下：

图片.png

db文件的整个压缩过程会有log印出来，在main.log中都能够找到

这里需要先介绍下 tombstone，tombstone的本意是“墓碑”，形象的用于描述进程挂了之后留下供调试的线索
如下是tombstone中涉及的信息
版本信息：
主要是fingerprint，可以看出异常版本是eng还是user。
寄存器信息：
主要查看是哪个进程崩溃，信号是什么。寄存器信息需要配合下面的调用栈信息及数据信息结合GNU的工具（objdump -S反汇编）分析。
调用栈信息：
这个是最直接可以看出异常的信息。

可以看到NE的原因是sig 6，前面哪里调用了aboart（类似于assert），这就需要从调用栈入手分析

在main.log打印出tombstone的地方往上查找，可以看到是Nfc的Native层调用了abort()函数，至于调用abort()函数使得nfc进程退出的原因是由于加载fw出错，这里不加多说

这里的举得NE例子是SIGABRT原因，除此之外还有各种各样的NE原因

NE问题信号类型

图片.png

信号处理方式
1.忽略：接收到信号后不做任何反应。
2.捕获：用自定义的信号处理函数来执行特定的动作。
3.默认：接收到信号后按系统默认的行为处理该信号。（这是多数应用采取的处理方式）