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 【NE问题分析之db文件及信号】信号处理方式
1.忽略：接收到信号后不做任何反应。
2.捕获：用自定义的信号处理函数来执行特定的动作。
3.默认：接收到信号后按系统默认的行为处理该信号。（这是多数应用采取的处理方式）
推荐阅读
- parallels|parallels desktop 解决网络初始化失败问题
- PMSJ寻平面设计师之现代(Hyundai）
- 太平之莲
- 闲杂“细雨”
- 七年之痒之后
- 深入理解Go之generate
- jhipster|jhipster 升级无效问题
- 由浅入深理解AOP
- 如何寻找情感问答App的分析切入点
- 期刊|期刊 | 国内核心期刊之（北大核心）