深入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