NE问题分析之框架

本文是NE问题分析的第一篇，将先对NE问题做一个简要说明

1. Native application

在Android软件架构里，这些应用程序组成了native layer，native layer里的应用程序崩溃统称为Native Exception，比如空指针，非法指针，程序跑飞，内存踩坏等，好比像windows下，程序崩溃弹出某某地址不能为read/write。

图片.png

2. 总流程图
   原始的linux，对于用户进程崩溃之后，处理方式有2种：直接终止进程；输出coredump再终止进程。 而在Android，为了方便调试，在收到崩溃信号后，会先输出tombstone，然后在根据设置是否抓取coredump，最后再终止进程。

   mtk平台上会在这基础上将coredump及其他关键信息打包成一个db文件，位于mtklog下的aee_exp中，db文件的生成前提条件是eng版本或是user版本打开了mtklog

   以下是完整的NE处理流程图：

图片.png

信号捕获：
程序分为2种，1种为静态链接的程序，另一种为动态链接的程序。
静态链接：由链接器在链接时将库的内容加入到可执行程序中的做法。最大缺点是生成的可执行文件太大，需要更多的系统资源，在装入内存时也会消耗更多的时间。

动态链接：将独立的模块先编译成动态库（比如libc.so/libutils.so等），程序运行有需要它们时才加载。最大缺点是可执行程序依赖分别存储的库文件才能正确执行。如果库文件被删除了，移动了，重命名了或者被替换为不兼容的版本了，那么可执行程序就可能工作不正常。

在Android里，大部分都是动态链接，而只有init等少部分是静态链接。动态链接程序是需要链接器才能跑起来，linker就是Android的链接器。

linker也在程序的进程空间内。当内核将应用程序加载起来后，并不是先跑应用程序代码，而是先跑linker。linker负责将应用程序所需的库加载到进程空间内，之后才跑应用程序代码。  【TIPS】

kernel加载完应用程序/动态链接器后并不帮忙加载所需的动态库，这些工作只能由动态链接器完成。动态链接器可以使用2种方式加载动态库：立即模式：将所需的动态库一次性全部加载，这样可以提高性能但延长加载时间。懒惰模式：程序需要的时候再加载，前期加载时间快但是如果程序在执行关键的代码，动态链接会影响性能

NE问题产生的通常来源：
1、硬件发生异常，即硬件(通常是CPU)检测到一个错误条件并通知Linux内核，内核处理该异常，给相应的进程发送信号。硬件异常的例子包括执行一条异常的机器语言指令，诸如，被0除，或者引用了无法访问的内存区域。大部分信号如果没有被进程处理，默认的操作就是杀死进程。在本文中，SIGSEGV(段错误)，SIGBUS(内存访问错误)，SIGFPE(算数异常)属于这种信号。
2、进程调用的库发现错误，给自己发送中止信号，默认情况下，该信号会终止进程。在本文中，SIGABRT(中止进程)属于这种信号。
3、其它应用通过kill-信号 pid的方式给错误进程发送，这时signal中的si_code会小于0。

参考文章：
https://onlinesso.mediatek.com/_layouts/15/mol/topic/ext/Topic.aspx?MappingId=fc6dd989-890d-444d-b4bf-13a93219702d