【原創】Erlang 之 erl_crash.dump 生成

-=-=-=-=- 我是<我是歌手 >的分隔線 -=-=-=-=- 

（以下為原文引用） 

      crashdump 對于 erlang 的系統來講如同 core 對于 c/c++ 程式一樣寶貴，對于系統問題的修複提供了最詳細的資料。當然 erlang 很貼心了提供了網頁版的 crashdump_view 幫助使用者解讀資料，使用方法如下：

      因為 crashdump 文本檔案裡面記錄了大量系統相關的資訊，這些資訊對于分析系統的性能，狀态，排除問題提供了不可替代的功能。是以很需要在系統正常運作的時候，得到 crashdump 檔案。 

      除了坐等系統在發生問題時，自動産生 crashdump 以外，另外還有三種方法來手動産生 crashdump 。 方法如下： 

erlang:halt("abort").

在 erlang shell 下輸入 ctrl+c + “大寫的a”

kill -s sigusr1 [erlang_pid]

（以下為實際驗證） 

【實驗一】 

某業務程序運作中 

通過 remsh 登入，再通過 ctrl+c,a 退出 

可以看到，上述操作對業務程序無影響（不産生影響的原因見後文）。 

再次通過 remsh 登入，并執行 ctrl+c,a 

可以看到，上述操作對 upu 程序同樣無影響（不産生影響的原因見後文），同時能夠産生 erl_crash.dump 檔案 

此時就可以基于該 erl_crash.dump 檔案對 upu 程序的運作時狀态進行分析了（此結論已被我自己證明存在問題）。 

【實驗二】 

通過 remsh 登入，并執行 erlang:halt("abort"). 

退出後發現生成了 erl_crash.dump ，此檔案大小比通過 ctrl+c,a 生成的大（大的原因見後文）。 

可以看到，此時業務程序已經終止。 

【實驗三】 

執行 kill 指令發送信号 sigusr1 到業務程序 

可以看到，這種方式也能夠産生 erl_crash.dump 檔案，但業務程序會終止運作。 

【實驗四】 

執行 kill 指令發送信号 sigusr2 到業務程序 

可以看到，這種方式不會産生 erl_crash.dump 檔案，但 upu 程序會終止運作。 

結論： 隻有通過 ctrl+c,a 生成 erl_crash.dump 檔案才無破壞性； 

==============

重要的補充說明：

上文的一些結論是存在問題的，已經進行了标注；

問題在于上述試驗中，我們是通過 remsh 機制登入到目标節點上的，即在本地建立一個 erlang 節點，但在遠端啟動的初始 shell ，那麼此時無論是使用 ctrl+c,ctrl+c，或 ctrl+c,a ，還是 ctrl+c,a ，終止的都是之前建立的那個初始 shell 。是以才不會導緻目标程序的退出，但與此同時，即使擷取到了 erl_crash.dump 檔案，也不是目标程序對應的崩潰檔案；

通過 remsh 登入，再執行 erlang:halt("abort"). 則是令目标程序（erts）暴力退出，并以 "abort" 字元串作為 slogan 生成 erl_crash.dump 檔案。此時生成的崩潰檔案必然比之前生成的大；

通過 sigusr1 令目标程序退出，并生成 erl_crash.dump 檔案的方式也是可以的。

結論： 

ctrl+c,ctrl+c 和 ctrl+c,a 什麼都不會生成，即使是在 console 上執行；

ctrl+c,a 可以生成 erl_crash.dump 和 core.xxx （要放開 ulimit -c）；

erlang:halt("abort"). 隻會生成 erl_crash.dump （即使放開 unlimit -c）；

erlang:halt(abort). 隻會生成 core.xxx （要放開 unlimit -c）；

通過 sigusr1 終止 erlang 程序，可以生成 erl_crash.dump 和 core.xxx （要放開 ulimit -c）；