概要
當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 (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-***.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分析將會在下一章節講解。
Bug產生原因的深入分析
一 前後端使用架構導致 前端使用es7 react node使用，在開發方面增大了工作量 後端屬於大資料基礎上做各種條件篩選，在具體實現上採用了 重記憶體 方案，即 1 將資料定時更新到記憶體中 2 在記憶體中做多條件的篩選 帶來的問題就是 1 fullgc問題 導致需要大記憶體伺服器 2 定時資料...
使用DB2 sequence自動產生主鍵
要寫乙個跟蹤程式，記錄使用者對資料進了那些操作。覺得access中有乙個自動編號的型別，可以自動為字段產生主鍵。查了一下db2，感覺sequence有點象此類功能。建立sequence,產生id create sequence xixi.id log as bigint start with 1 i...
使用DB2 sequence自動產生主鍵 收藏
要寫乙個跟蹤程式，記錄使用者對資料進了那些操作。覺得access中有乙個自動編號的型別，可以自動為字段產生主鍵。查了一下db2，感覺sequence有點象此類功能。建立sequence,產生id create sequence xixi.id log as bigint start with 1 i...