深入ne_产生DB

概要
    当debuggerd处理完后，程序再次回到发生异常的环境，此时还会发生1次异常，同样的会再次发送信号。
    由于linker里的debuggerd_init()里注册的几个信号，默认行为都会产生coredump，因此接下来会介绍coredump产生以及db打包过程。
    【TIPS】到这里，目标进程已经收到3次同样的信号了！！！
1. 产生coredump
    当一个程序崩溃时，OS会将该进程的的地址空间保存起来，然后通过工具(GDB,trace32)离线调试。
        有的问题仅仅通过backtrace是无法直接定位问题的 (指针错误，访问无效内存，内存被踩坏，函数参数错误)。
    coredump默认是关闭的，并且有些参数可以设置它，如下：
(1). 参数
    /proc/sys/kernel/core_pattern
        这个参数用于设置coredump文件的名称，支持的参数有
            %p: 添加pid                                   %u: 添加当前uid
            %g: 添加当前gid                             %s: 添加导致产生core的信号
            %t: 添加core文件生成时的unix时间  %h: 添加主机名
            %e: 添加命令名
        在aed起来时会对其做初始化
            eng build: |/system/bin/aee_core_forwarder /data/core/ %p %s UID=%u GID=%g
            user build: /bad_core_pattern
    ulimit -a
        查看/设置coredump文件的大小，默认为0，也就是不抓coredump

        可以用ulimit -c <filesize>(KB)改变大小
        【TIPS】当core_pattern里有管道时忽略此参数(也就是第1个字符为'|')！
    /proc/$pid/coredump_filter
        coredump是抓取进程空间内的内存并保存到文件上，并不是所有内存都需要保存的，你可以通过该参数过滤，只抓取部分内存。
        该参数是一个值，每个bit位都有对应的含义，用来表示是否抓取这部分内存。
            bit0: 私有匿名                      bit1: 共享匿名
            bit2: 有底层文件的私有映射   bit3: 有底层文件共享映射
            bit4: ELF头                          bit5: 私有大尺寸页
            bit6: 共享大尺寸页
        当前默认值是0x23，也就是只会抓取：私有匿名/共享匿名/私有大尺寸页
(2). 抓取
    在eng版本，/proc/sys/kernel/core_pattern被设置为|/system/bin/aee_core_forwarder /data/core/ %p %s UID=%u GID=%g，也就是说进程内存数据会导向aee_core_forwarder这个程序。
    aee_core_forwarder会向aee询问要保存到哪里，aee会提供db所在路径，然后倒入该路径，最后由aee统一压缩为db。

    【TIPS】当coredump没有正常生成时可以通过log分析问题点
    如果aee没有反馈，则aee_core_forwarder会保存到/data/core/目录下以zcore-xxx.zip文件（可以用GAT解压）保存。当然了data空间很宝贵，如果生成coredump后如果空间小于4M，则删除coredump。

(3). 无coredump原因和解决方法
    有时候发现进程崩溃了，但是没有db或有db但是没有coredump。这边总结如下：
        1. 进程重新注册了几个NE的信号，导致异常时被捕获了，没有正常的NE流程。
        2. init之中发生NE。init进程如果有人尝试杀死则会演变为KE。
        3. 存储空间满。
        4. 进程异常后其他线程提前退出。
        5. fd leak，导致无法打开socket，只能直接触发coredump放在/data/core目录下。
        6. user版本没有开mtkloger也是没有coredump的。
        ......
    解决方法
        adb shell aee -d coreon之后删除/system/bin/debuggerd。然后重启机器设置adb shell echo "|/system/bin/aee_core_forwarder /data/core/ %p %s UID=%u GID=%g" > /proc/sys/kernel/core_pattern（注意重启后失效）
        复现问题，coredump可以在data/core目录下找到。
(4). 主动触发coredump
    有时为了分析问题，需要主动触发coredump，然后通过工具分析。
    你可以通过adb shell kill -5 $pid或连发3次adb shell kill -11 $pid。
    coredump会在/data/core或db里面。
2. 产生db
    debuggerd完成之后会通知aee，aee就开始了打包db的工作。
    1个完整的NE的db，里面除了coredump还有其他文件，这些文件绝大部分是通过aee_dumpstate保存起来的。

    整个压缩过程会有log印出来，因此如果有什么问题也可以通过log分析。

    db中有些文件对分析NE是至关重要的，必须掌握。比如PROCESS_MAPS，这只文件就是/proc/$pid/maps，里面是对进程空间的描述：

(1). db解包
    db需要GAT工具才可以解包，更多细节请查看DCC上的GAT使用文档。

    大致结果如下：

(2). db相关配置
    db个数：user版本：4个，eng版本：20个
    coredump只有在以下设置才会抓取：
        eng版本
        user版本+打开mtklogger
    详情请看DCC上的文档：MediaTek Logging SOP.pptx

结语

    至此，整个NE的流程就结束了，那么大家就应该可以简单分析NE产生的问题了。coredump分析将会在下一章节讲解。