簡介： 本文詳細論述 UNIX 環境上的進程異常退出，將導致進程異常退出的各種情景歸納為兩類，對每類情況詳細分析了問題出現的根本原因，同時添加了相應的實例以易於您更好地進行了解。在此基礎上，文章最後論述了應該如何避免和調試進程異常退出問題。希望讀者閱讀此文後，對進程異常退出問題有更深層的認識，有更系統的梳理，對調試此類進程崩潰問題時也能有所幫助，寫出更穩定、更可靠的軟體。
進程異常退出
進程退出意味著進程生命期的結束，系統資源被回收，進程從操作系統環境中銷毀。進程異常退出是進程在運行過程中被意外終止，從而導致進程本來應該繼續執行的任務無法完成。
進程異常退出可能給軟體用戶造成如下負面影響：
●軟體喪失部分或者全部功能性，無法完成既定任務。
●如果進程正在處理數據，可能造成數據損壞。
●如果是關鍵軟體服務，必然導致服務異常中止 , 造成無法預計的損失。
●進程異常退出或者進程崩潰 , 也會給軟體用戶造成恐慌和困惑。
進程異常退出是生產環境中經常遇到的問題，它會給軟體用戶造成很多負面影響，所以軟體開發者應當避免這種問題的出現。但是導致進程異常退出的場景和原因是多種多樣的，甚至令人琢磨不透。
本文將所有可能造成進程異常退出的原因歸結為兩類。系統地將其分類，使讀者對此類問題能有清晰的認識。對每類情況詳細論述，分析根本原因，然後分析了這兩類情況之間的聯繫，也就是信號與進程異常退出的緊密關係。希望您讀完此文後，能對此類問題有更加全面、深入的理解，對調試此類問題也能有所幫助，寫出更加可靠、更加穩定性、更加健壯的軟體。
首先我們來看導致進程異常退出的這兩類情況：
●第一類：向進程發送信號導致進程異常退出；
●第二類：代碼錯誤導致進程運行時異常退出。
第一類：向進程發送信號導致進程異常退出
信號：
UNIX 系統中的信號是系統響應某些狀況而產生的事件，是進程間通信的一種方式。信號可以由一個進程發送給另外進程，也可以由核發送給進程。
信號處理程序：
信號處理程序是進程在接收到信號后，系統對信號的響應。根據具體信號的涵義，相應的默認信號處理程序會採取不同的信號處理方式：
●終止進程運行，並且產生 core dump 文件。
●終止進程運行。
●忽略信號，進程繼續執行。
●暫停進程運行。
●如果進程已被暫停，重新調度進程繼續執行。
前兩種方式會導致進程異常退出，是本文討論的範圍。實際上，大多數默認信號處理程序都會終止進程的運行。
在進程接收到信號后，如果進程已經綁定自定義的信號處理程序，進程會在用戶態執行自定義的信號處理程序；反之，內核會執行默認信號程序終止進程運行，導致進程異常退出。
所以，通過向進程發送信號可以觸發默認信號處理程序，默認信號處理程序終止進程運行。在 UNIX 環境中我們有三種方式將信號發送給目標進程，導致進程異常退出。
方式一：調用函數 kill() 發送信號
我們可以調用函數 kill(pid_t pid, int sig) 向進程 ID 為 pid 的進程發送信號 sig。這個函數的原型是：
| 1 2 3 | #include #include int kill(pid_t pid, int sig); |
調用函數 kill() 后，進程進入內核態向目標進程發送指定信號；目標進程在接收到信號后，默認信號處理程序被調用，進程異常退出。
清單 1. 調用 kill() 函數發送信號
| 1 2 3 4 5 6 7 8 9 10 11 12 | /* sendSignal.c, send the signal ‘ SIGSEGV ’ to specific process*/ #include #include int main(int argc, char* argv[]) { char* pid = argv[1]; int PID = atoi(pid); kill(PID, SIGSEGV); return 0; } |
上面的代碼片段演示了如何調用 kill() 函數向指定進程發送 SIGSEGV 信號。編譯並且運行程序：
| 1 2 3 4 5 6 7 8 | [root@machine ~]# gcc -o sendSignal sendSignal.c [root@machine ~]# top & [1] 22055 [root@machine ~]# ./sendSignal 22055 [1]+ Stopped top [root@machine ~]# fg %1 top Segmentation fault (core dumped) |
上面的操作中，我們在後台運行 top，進程 ID 是 22055，然後運行 sendSignal 向它發送 SIGSEGV 信號，導致 top 進程異常退出，產生 core dump 文件。
方式二：運行 kill 命令發送信號
用戶可以在命令模式下運行 kill 命令向目標進程發送信號，格式為：
kill SIG*** PID
在運行 kill 命令發送信號后，目標進程會異常退出。這也是系統管理員終結某個進程的最常用方法，類似於在 Windows 平台通過任務管理器殺死某個進程。
在實現上，kill 命令也是調用 kill 系統調用函數來發送信號。所以本質上，方式一和方式二是一樣的。
操作演示如下：
| 1 2 3 4 5 6 7 | [root@machine ~]# top & [1] 22810 [root@machine ~]# kill -SIGSEGV 22810 [1]+ Stopped top [root@machine ~]# fg %1 top Segmentation fault (core dumped) |
方式三：在終端使用鍵盤發送信號
用戶還可以在終端用鍵盤輸入特定的字元（比如 control-C 或 control-\）向前台進程發送信號，終止前台進程運行。常見的中斷字元組合是，使用 control-C 發送 SIGINT 信號，使用 control-\ 發送 SIGQUIT 信號，使用 control-z 發送 SIGTSTP 信號。
在實現上，當用戶輸入中斷字元組合時，比如 control-C，終端驅動程序響應鍵盤輸入，並且識別 control-C 是信號 SIGINT 的產生符號，然後向前台進程發送 SIGINT 信號。當前台進程再次被調用時就會接收到 SIGINT 信號。
使用鍵盤中斷組合符號發送信號演示如下：
[root@machine ~]# ./loop.sh ( 註釋：運行一個前台進程，任務是每秒鐘列印一次字元串 )
i’m looping …
i’m looping …
i’m looping … ( 註釋：此時，用戶輸入 control-C)
[root@machine ~]# ( 註釋：接收到信號后，進程退出 )
對這類情況的思考
這類情況導致的進程異常退出，並不是軟體編程錯誤所導致，而是進程外部的非同步信號所致。但是我們可以在代碼編寫中做的更好，通過調用 signal 函數綁定信號處理程序來應對信號的到來，以提高軟體的健壯性。
signal 函數的原型：
| 1 2 | #include void (*signal(int sig, void (*func)(int)))(int); |
signal 函數將信號 sig 和自定義信號處理程序綁定，即當進程收到信號 sig 時自定義函數 func 被調用。如果我們希望軟體在運行時屏蔽某個信號，插入下面的代碼，以達到屏蔽信號 SIGINT 的效果：
(void)signal(SIGINT, SIG_IGN)；
執行這一行代碼后，當進程收到信號 SIGINT 后，進程就不會異常退出，而是會忽視這個信號繼續運行。
更重要的場景是，進程在運行過程中可能會創建一些臨時文件，我們希望進程在清理這些文件后再退出，避免遺留垃圾文件，這種情況下我們也可以調用 signal 函數實現，自定義一個信號處理程序來清理臨時文件，當外部發送信號要求進程終止運行時，這個自定義信號處理程序被調用做清理工作。代碼清單 2 是具體實現。
清單 2. 調用 signal 函數綁定自定義信號處理程序
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | /* bindSignal.c */ #include #include #include void cleanTask(int sig) { printf( "Got the signal, deleting the tmp file\n" ); if( access( "/tmp/temp.lock", F_OK ) != -1 ) { if( remove( "/tmp/temp.lock" ) != 0 ) perror( "Error deleting file" ); else printf( "File successfully deleted\n" ); } printf( "Process existing...\n" ); exit(0); } int main() { (void) signal( SIGINT, cleanTask ); FILE* tmp = fopen ( "/tmp/temp.lock", "w" ); while(1) { printf( "Process running happily\n" ); sleep(1); } if( tmp ) remove( "/tmp/temp.lock" ); } |
運行程序：
| 1 2 3 4 5 6 7 | [root@machine ~]# ./bindSignal Process running happily Process running happily Process running happily ( 註釋：此時，用戶輸入 control-C) Got the signal, deleting the tmp file ( 註釋：接收到信號后，cleanTask 被調用 ) File successfully deleted ( 註釋：cleanTask 刪除臨時文件 ) Process existing... ( 註釋：進程退出 ) |
第二類：編程錯誤導致進程運行時異常退出
相比於第一類情況，第二類情況在軟體開發過程中是常客，是編程錯誤，進程運行過程中非法操作引起的。
操作系統和計算機硬體為應用程序的運行提供了硬體平台和軟體支持，為應用程序提供了平台虛擬化，使進程運行在自己的進程空間。在進程看來，它自身獨佔整台系統，任何其它進程都無法干預，也無法進入它的進程空間。
但是操作系統和計算機硬體又約束每個進程的行為，使進程運行在用戶態空間，控制許可權，確保進程不會破壞系統資源，不會幹涉進入其它進程的空間，確保進程合法訪問內存。當進程嘗試突破禁區做非法操作時，系統會立刻覺察，並且終止進程運行。
所以，第二類情況導致的進程異常退出，起源於進程自身的編程錯誤，錯誤的編碼執行非法操作，操作系統和硬體制止它的非法操作，並且讓進程異常退出。
在實現上，操作系統和計算機硬體通過異常和異常處理函數來阻止進程做非法操作。
異常和異常處理函數
當進程執行非法操作時，計算機會拋出處理器異常，系統執行異常處理函數以響應處理器異常，異常處理函數往往會終止進程運行。
廣義的異常包括軟中斷 (soft interrupts) 和外設中斷 (I/O interrupts) 。外設中斷是系統外圍設備發送給處理器的中斷，它通知處理器 I/O 操作的狀態，這種異常是外設的非同步異常，與具體進程無關，所以它們不會造成進程的異常退出。本文討論的異常是指 soft interrupts，是進程非法操作所導致的處理器異常，這類異常是進程執行非法操作所產生的同步異常，比如內存保護異常，除 0 異常，缺頁異常等等。
處理器異常有很多種，系統為每個異常分配異常號，每個異常有相對應的異常處理函數。以 x86 處理器為例，除 0 操作產生 DEE 異常 (Divide Error Exception)，異常號是 0；內存非法訪問產生 GPF 異常 (General Protection Fault)，異常號是 13，而缺頁 (page fault) 異常的異常號是 14。當異常出現時，處理器掛起當前進程，讀取異常號，然後執行相應的異常處理函數。如果異常是可修復，比如內存缺頁異常，異常處理函數會修復系統錯誤狀態，清除異常，然後重新執行一遍被中斷的指令，進程繼續運行；如果異常無法修復，比如內存非法訪問或者除 0 操作，異常處理函數會終止進程運行。
實例以及分析
實例一：內存非法訪問
這類問題中最常見的就是內存非法訪問。內存非法訪問在 UNIX 平台即 segmentation fault，在 Windows 平台這類錯誤稱為 Access violation。
內存非法訪問是指：進程在運行時嘗試訪問尚未分配（即，沒有將物理內存映射進入進程虛擬內存空間）的內存，或者進程嘗試向只讀內存區域寫入數據。當進程執行內存非法訪問操作時，內存管理單元 MMU 會產生內存保護異常 GPF(General Protection Fault)，異常號是 13。系統會立刻暫停進程的非法操作，並且跳轉到 GPF 的異常處理程序，終止進程運行。
這種編程錯誤在編譯階段編譯器不會報錯，是運行時出現的錯誤。清單 3 是內存非法訪問的一個簡單實例，進程在執行第 5 行代碼時執行非法內存訪問，異常處理函數終止進程運行。
清單 3. 內存非法訪問實例 demoSegfault.c
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | #include int main() { char* str = "hello"; str[0] = 'H'; return 0; } 編譯並運行： [root@machine ~]# gcc demoSegfault.c -o demoSegfault [root@machine ~]# ./demoSegfault Segmentation fault (core dumped) [root@machine ~]# gdb demoSegfault core.24065 ( 已省略不相干文本 ) Core was generated by `./demoSegfault'. Program terminated with signal 11, Segmentation fault. |
分析：實例中，字元串 str 是存儲在內存只讀區的字元串常量，而第 5 行代碼嘗試更改只讀區的字元，所以這是內存非法操作。
進程從開始執行到異常退出經歷如下幾步：
1、進程執行第 5 行代碼，嘗試修改只讀內存區的字元；
2、內存管理單元 MMU 檢查到這是非法內存操作，產生保護內存異常 GPF，異常號 13；
3、處理器立刻暫停進程運行，跳轉到 GPF 的異常處理函數，異常處理函數終止進程運行；
4、進程 segmentation fault，並且產生 core dump 文件。GDB 調試結果顯示，進程異常退出的原因是 segmentation fault。
實例二：除 0 操作
實例二是除 0 操作，軟體開發中也會引入這樣的錯誤。當進程執行除 0 操作時，處理器上的浮點單元 FPU(Floating-point unit) 會產生 DEE 除 0 異常 (Divide Error Exception)，異常號是 0。
清單 4. 除 0 操作 divide0.c
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | #include int main() { int a = 1, b = 0, c; printf( "Start running\n" ); c = a/b ; printf( "About to quit\n" ); } 編譯並運行： [root@machine ~]# gcc -o divide0 divide0.c [root@machine ~]# ./divide0 & [1] 1229 [root@machine ~]# Start running [1]+ Floating point exception(core dumped) ./divide0 [root@xbng103 ~]# gdb divide0 /corefiles/core.1229 ( 已省略不相干文本 ) Core was generated by `./divide0'. Program terminated with signal 8, Arithmetic exception. |
分析：實例中，代碼第 7 行會執行除 0 操作，導致異常出現，異常處理程序終止進程運行，並且輸出錯誤提示：Floating point exception。
異常處理函數內幕
異常處理函數在實現上，是通過向掛起進程發送信號，進而通過信號的默認信號處理程序終止進程運行，所以異常處理函數是“間接”終止進程運行。詳細過程如下：
1、進程執行非法指令或執行錯誤操作；
2、非法操作導致處理器異常產生；
3、系統掛起進程，讀取異常號並且跳轉到相應的異常處理函數；
a、異常處理函數首先查看異常是否可以恢復。如果無法恢復異常，異常處理函數向進程發送信號。發送的信號根據異常類型而定，比如內存保護異常 GPF 相對應的信號是 SIGSEGV，而除 0 異常 DEE 相對應的信號是 SIGFPE；
b、異常處理函數調用內核函數 issig() 和 psig() 來接收和處理信號。內核函數 psig() 執行默認信號處理程序，終止進程運行；
3、進程異常退出。
異常處理函數執行時會檢查異常號，然後根據異常類型發送相應的信號。
再來看一下實例一（代碼清單 3）的運行結果：
| 1 2 3 4 5 6 | [root@machine ~]# ./demoSegfault Segmentation fault (core dumped) [root@machine ~]# gdb demoSegfault core.24065 ( 已省略不相干文本 ) Core was generated by `./demoSegfault'. Program terminated with signal 11, Segmentation fault. |
運行結果顯示進程接收到信號 11 后異常退出，在 signal.h 的定義里，11 就是 SIGSEGV。MMU 產生內存保護異常 GPF（異常號 13）時，異常處理程序發送相應信號 SIGSEGV，SIGSEGV 的默認信號處理程序終止進程運行。
再來看實例二（代碼清單 4）的運行結果
| 1 2 3 4 5 6 7 8 | [root@machine ~]# ./divide0 & [1] 1229 [root@machine ~]# Start running [1]+ Floating point exception(core dumped) ./divide0 [root@xbng103 ~]# gdb divide0 /corefiles/core.1229 ( 已省略不相干文本 ) Core was generated by `./divide0'. Program terminated with signal 8, Arithmetic exception. |
分析結果顯示進程接收到信號 8 后異常退出，在 signal.h 的定義里，8 就是信號 SIGFPE。除 0 操作產生異常（異常號 0），異常處理程序發送相應信號 SIGFPE 給掛起進程，SIGFPE 的默認信號處理程序終止進程運行。
“信號”是進程異常退出的直接原因
信號與進程異常退出有著緊密的關係：第一類情況是因為外部環境向進程發送信號，這種情況下發送的信號是非同步信號，信號的到來與進程的運行是非同步的；第二類情況是進程非法操作觸發處理器異常，然後異常處理函數在內核態向進程發送信號，這種情況下發送的信號是同步信號，信號的到來與進程的運行是同步的。這兩種情況都有信號產生，並且最終都是信號處理程序終止進程運行。它們的區別是信號產生的信號源不同，前者是外部信號源產生非同步信號，後者是進程自身作為信號源產生同步信號。
所以，信號是進程異常退出的直接原因。當進程異常退出時，進程必然接收到了信號。
避免和調試進程異常退出
建議
軟體開發過程中，我們應當避免進程異常退出，針對導致進程異常退出的這兩類問題，對軟體開發者的幾點建議：
1、通常情況無需屏蔽外部信號。信號作為進程間的一種通信方式，非同步信號到來意味著外部要求進程的退出；
2、綁定自定義信號處理程序做清理工作，當外部信號到來時，確保進程異常退出前，自定義信號處理程序被調用做清理工作，比如刪除創建的臨時文件。
3、針對第二類情況，編程過程中確保進程不要做非法操作，尤其是在訪問內存時，確保內存已經分配給進程（映射入進程虛擬地址空間），不要向只讀區寫入數據。
問題調試和定位
進程異常退出時，操作系統會產生 core dump 文件，cored ump 文件是進程異常退出前內存狀態的快照，運行 GDB 分析 core dump 文件可以幫助調試和定位問題。
1) 首先，分析 core dump 查看導致進程異常退出的具體信號和退出原因。
使用 GDB 調試實例一（代碼清單 3）的分析結果如下：
| 1 2 3 4 | [root@machine ~]# gdb demoSegfault core.24065 ( 已省略不相干文本 ) Core was generated by `./demoSegfault'. Program terminated with signal 11, Segmentation fault. |
分析結果顯示，終止進程運行的信號是 11，SIGSEGV，原因是內存非法訪問。
2) 然後，定位錯誤代碼。
在 GDB 分析 core dump 時，輸入“bt”指令列印進程退出時的代碼調用鏈，即 backtrace，就可以定位到錯誤代碼。
用 gcc 編譯程序時加入參數 -g 可以生成符號文件，幫助調試。
重新編譯、執行實例一，並且分析 core dump 文件，定位錯誤代碼：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | [root@machine ~]# gcc -o demoSegfault demoSegfault.c -g [root@machine ~]# ./demoSegfault & [1] 28066 [1]+ Segmentation fault (core dumped) ./demoSegfault [root@machine ~]# gdb demoSegfault /corefiles/core.28066 ( 已省略不相干文本 ) Core was generated by `./demoSegfault'. Program terminated with signal 11, Segmentation fault. #0 0x0804835a in main () at demoSegfault.c:5 5 str[0] = 'H'; (gdb) bt #0 0x0804835a in main () at demoSegfault.c:5 (gdb) |
在加了參數 -g 編譯后，我們可以用 gdb 解析出更多的信息幫助我們調試。在輸入“bt”后，GDB 輸出提示錯誤出現在第 5 行。
3) 最後，在定位到錯誤代碼行后，就可以很快知道根本原因，並且修改錯誤代碼。
參考資料
學習
●參考 developerWorks 中國文章“Linux 環境進程間通信（二）: 信號”，了解信號的概念。
●Computer Systems A Programmer’s Perspective， 作者是 Randal E. Bryant 和 David R. O’Hallaron。
●UNIX Internals – The New Frontiers，作者是 Uresh Vahalia。
●Advanced programming in the unix environment，作者是 W. Richard Stevens。
●參考 wikipedia 文章，http://en.wikipedia.org/wiki/Floating-point_unit，了解處理器 FPU。
●參考 GDB 開源主頁 http://www.gnu.org/software/gdb/documentation/，學習 GDB。
●AIX and UNIX 專區：developerWorks 的“AIX and UNIX 專區”提供了大量與 AIX 系統管理的所有方面相關的信息，您可以利用它們來擴展自己的 UNIX 技能。
●AIX and UNIX 新手入門：訪問“AIX and UNIX 新手入門”頁面可了解更多關於 AIX 和 UNIX 的內容。
●AIX and UNIX 專題匯總：AIX and UNIX 專區已經為您推出了很多的技術專題，為您總結了很多熱門的知識點。我們在後面還會繼續推出很多相關的熱門專題給您，為了方便您的訪問，我們在這裡為您把本專區的所有專題進行匯總，讓您更方便的找到您需要的內容。
●AIX and UNIX 下載中心：在這裡你可以下載到可以運行在 AIX 或者是 UNIX 系統上的 IBM 伺服器軟體以及工具，讓您可以提前免費試用他們的強大功能。
●IBM Systems Magazine for AIX 中文版：本雜誌的內容更加關注於趨勢和企業級架構應用方面的內容，同時對於新興的技術、產品、應用方式等也有很深入的探討。IBM Systems Magazine 的內容都是由十分資深的業內人士撰寫的，包括 IBM 的合作夥伴、IBM 的主機工程師以及高級管理人員。所以，從這些內容中，您可以了解到更高層次的應用理念，讓您在選擇和應用 IBM 系統時有一個更好的認識。
討論
加入 developerWorks 中文社區。查看開發人員推動的博客、論壇、組和維基，並與其他 developerWorks 用戶交流。
解維東是 IBM 中國系統與技術實驗室的軟體工程師，擔任 IBM Systems Director 的產品工程師，主要職責是解決客戶報告的問題。在加入 IBM 之前，在因特爾公司做了 10 個月的 Linux 實習開發人員。2007 年，畢業於中國南京大學，取得了碩士學位。
[火星人 ] 詳談 UNIX 環境進程異常退出已經有390次圍觀
