詳談 UNIX 環境進程異常退出
本文詳細論述 UNIX 環境上的進程異常退出，將導致進程異常退出的各種情景歸納為兩類，對每類情況詳細分析了問題出現的根本原因，同時添加了相應的實例以易於您更好地進行了解。在此基礎上，文章最後論述了應該如何避免和調試進程異常退出問題。希望讀者閱讀此文後，對進程異常退出問題有更深層的認識，有更系統的梳理，對調試此類進程崩潰問題時也能有所幫助，寫出更穩定、更可靠的軟件。
進程異常退出
進程退出意味著進程生命期的結束，系統資源被回收，進程從操作系統環境中銷毀。進程異常退出是進程在運行過程中被意外終止，從而導致進程本來應該繼續執行的任務無法完成。
進程異常退出可能給軟件用戶造成如下負面影響：
軟件喪失部分或者全部功能性，無法完成既定任務。
如果進程正在處理數據，可能造成數據損壞。
如果是關鍵軟件服務，必然導致服務異常中止 , 造成無法預計的損失。
進程異常退出或者進程崩潰 , 也會給軟件用戶造成恐慌和困惑。
進程異常退出是生產環境中經常遇到的問題，它會給軟件用戶造成很多負面影響，所以軟件開發者應當避免這種問題的出現。但是導致進程異常退出的場景和原因是多種多樣的，甚至令人琢磨不透。
本文將所有可能造成進程異常退出的原因歸結為兩類。系統地將其分類，使讀者對此類問題能有清晰的認識。對每類情況詳細論述，分析根本原因，然後分析了這兩類情況之間的聯系，也就是信號與進程異常退出的緊密關系。希望您讀完此文後，能對此類問題有更加全面、深入的理解，對調試此類問題也能有所幫助，寫出更加可靠、更加穩定性、更加健壯的軟件。
首先我們來看導致進程異常退出的這兩類情況：
第一類：向進程發送信號導致進程異常退出;
第二類：代碼錯誤導致進程運行時異常退出。
第一類：向進程發送信號導致進程異常退出
信號：
UNIX 系統中的信號是系統響應某些狀況而產生的事件，是進程間通信的一種方式。信號可以由一個進程發送給另外進程，也可以由核發送給進程。
信號處理程序：
信號處理程序是進程在接收到信號後，系統對信號的響應。根據具體信號的涵義，相應的默認信號處理程序會采取不同的信號處理方式：
終止進程運行，並且產生 core dump 文件。
終止進程運行。
忽略信號，進程繼續執行。
暫停進程運行。
如果進程已被暫停，重新調度進程繼續執行。
前兩種方式會導致進程異常退出，是本文討論的范圍。實際上，大多數默認信號處理程序都會終止進程的運行。
在進程接收到信號後，如果進程已經綁定自定義的信號處理程序，進程會在用戶態執行自定義的信號處理程序;反之，內核會執行默認信號程序終止進程運行，導致進程異常退出。
圖 1. 默認信號處理程序終止進程運行
所以，通過向進程發送信號可以觸發默認信號處理程序，默認信號處理程序終止進程運行。在 UNIX 環境中我們有三種方式將信號發送給目標進程，導致進程異常退出。
方式一：調用函數 kill() 發送信號
我們可以調用函數 kill(pid_t pid, int sig) 向進程 ID 為 pid 的進程發送信號 sig。這個函數的原型是：
#include
#include
int kill(pid_t pid, int sig);
調用函數 kill() 後，進程進入內核態向目標進程發送指定信號;目標進程在接收到信號後，默認信號處理程序被調用，進程異常退出。
清單 1. 調用 kill() 函數發送信號
/* sendSignal.c, send the signal ‘ SIGSEGV ’ to specific process*/
1 #include
2 #include
3
4 int main(int argc, char* argv[])
5 {
6 char* pid = argv[1];
7 int PID = atoi(pid);
8
9 kill(PID, SIGSEGV);
10 return 0;
11 }
上面的代碼片段演示了如何調用 kill() 函數向指定進程發送 SIGSEGV 信號。編譯並且運行程序：
[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 系統調用函數來發送信號。所以本質上，方式一和方式二是一樣的。
操作演示如下：
[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 函數的原型：
#include
void (*signal(int sig, void (*func)(int)))(int);
signal 函數將信號 sig 和自定義信號處理程序綁定，即當進程收到信號 sig 時自定義函數 func 被調用。如果我們希望軟件在運行時屏蔽某個信號，插入下面的代碼，以達到屏蔽信號 SIGINT 的效果：
(void)signal(SIGINT, SIG_IGN);
執行這一行代碼後，當進程收到信號 SIGINT 後，進程就不會異常退出，而是會忽視這個信號繼續運行。
更重要的場景是，進程在運行過程中可能會創建一些臨時文件，我們希望進程在清理這些文件後再退出，避免遺留垃圾文件，這種情況下我們也可以調用 signal 函數實現，自定義一個信號處理程序來清理臨時文件，當外部發送信號要求進程終止運行時，這個自定義信號處理程序被調用做清理工作。代碼清單 2 是具體實現。
清單 2. 調用 signal 函數綁定自定義信號處理程序
/* bindSignal.c */
1 #include
2 #include
3 #include
4 void cleanTask(int sig) {
5 printf( "Got the signal, deleting the tmp file\n" );
6 if( access( "/tmp/temp.lock", F_OK ) != -1 ) {
7 if( remove( "/tmp/temp.lock" ) != 0 )
8 perror( "Error deleting file" );
9 else
10 printf( "File successfully deleted\n" );
11 }
12
13 printf( "Process existing...\n" );
14 exit(0);
15 }
16
17 int main() {
18 (void) signal( SIGINT, cleanTask );
19 FILE* tmp = fopen ( "/tmp/temp.lock", "w" );
20 while(1) {
21 printf( "Process running happily\n" );
22 sleep(1);
23 }
24
25 if( tmp )
26 remove( "/tmp/temp.lock" );
27 }
運行程序：
[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 操作，異常處理函數會終止進程運行，如圖 2：
圖 2. 異常處理函數終止進程運行
實例以及分析
實例一：內存非法訪問
這類問題中最常見的就是內存非法訪問。內存非法訪問在 UNIX 平台即 segmentation fault，在 Windows 平台這類錯誤稱為 Access violation。
內存非法訪問是指：進程在運行時嘗試訪問尚未分配(即，沒有將物理內存映射進入進程虛擬內存空間)的內存，或者進程嘗試向只讀內存區域寫入數據。當進程執行內存非法訪問操作時，內存管理單元 MMU 會產生內存保護異常 GPF(General Protection Fault)，異常號是 13。系統會立刻暫停進程的非法操作，並且跳轉到 GPF 的異常處理程序，終止進程運行。
這種編程錯誤在編譯階段編譯器不會報錯，是運行時出現的錯誤。清單 3 是內存非法訪問的一個簡單實例，進程在執行第 5 行代碼時執行非法內存訪問，異常處理函數終止進程運行。
清單 3. 內存非法訪問實例 demoSegfault.c
1 #include
2 int main()
3 {
4 char* str = "hello";
5 str[0] = 'H';
6 return 0;
7 }
編譯並運行：
[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 行代碼嘗試更改只讀區的字符，所以這是內存非法操作。
進程從開始執行到異常退出經歷如下幾步：
進程執行第 5 行代碼，嘗試修改只讀內存區的字符;
內存管理單元 MMU 檢查到這是非法內存操作，產生保護內存異常 GPF，異常號 13;
處理器立刻暫停進程運行，跳轉到 GPF 的異常處理函數，異常處理函數終止進程運行;
進程 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 #include
2
3 int main()
4 {
5 int a = 1, b = 0, c;
6 printf( "Start running\n" );
7 c = a/b ;
8 printf( "About to quit\n" );
9 }
編譯並運行：
[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。
異常處理函數內幕
異常處理函數在實現上，是通過向掛起進程發送信號，進而通過信號的默認信號處理程序終止進程運行，所以異常處理函數是“間接”終止進程運行。詳細過程如下：
進程執行非法指令或執行錯誤操作;
非法操作導致處理器異常產生;
系統掛起進程，讀取異常號並且跳轉到相應的異常處理函數;
異常處理函數首先查看異常是否可以恢復。如果無法恢復異常，異常處理函數向進程發送信號。發送的信號根據異常類型而定，比如內存保護異常 GPF 相對應的信號是 SIGSEGV，而除 0 異常 DEE 相對應的信號是 SIGFPE;
異常處理函數調用內核函數 issig() 和 psig() 來接收和處理信號。內核函數 psig() 執行默認信號處理程序，終止進程運行;
進程異常退出。
在此基礎上，我們可以把圖 2 進一步細化如下：
圖 3. 異常處理函數終止進程運行(細化)
異常處理函數執行時會檢查異常號，然後根據異常類型發送相應的信號。
再來看一下實例一(代碼清單 3)的運行結果：
[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)的運行結果
[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 的默認信號處理程序終止進程運行。
“信號”是進程異常退出的直接原因
信號與進程異常退出有著緊密的關系：第一類情況是因為外部環境向進程發送信號，這種情況下發送的信號是異步信號，信號的到來與進程的運行是異步的;第二類情況是進程非法操作觸發處理器異常，然後異常處理函數在內核態向進程發送信號，這種情況下發送的信號是同步信號，信號的到來與進程的運行是同步的。這兩種情況都有信號產生，並且最終都是信號處理程序終止進程運行。它們的區別是信號產生的信號源不同，前者是外部信號源產生異步信號，後者是進程自身作為信號源產生同步信號。
所以，信號是進程異常退出的直接原因。當進程異常退出時，進程必然接收到了信號。
避免和調試進程異常退出
建議
軟件開發過程中，我們應當避免進程異常退出，針對導致進程異常退出的這兩類問題，對軟件開發者的幾點建議：
通常情況無需屏蔽外部信號。信號作為進程間的一種通信方式，異步信號到來意味著外部要求進程的退出;
綁定自定義信號處理程序做清理工作，當外部信號到來時，確保進程異常退出前，自定義信號處理程序被調用做清理工作，比如刪除創建的臨時文件。
針對第二類情況，編程過程中確保進程不要做非法操作，尤其是在訪問內存時，確保內存已經分配給進程(映射入進程虛擬地址空間)，不要向只讀區寫入數據。
問題調試和定位
進程異常退出時，操作系統會產生 core dump 文件，cored ump 文件是進程異常退出前內存狀態的快照，運行 GDB 分析 core dump 文件可以幫助調試和定位問題。
1) 首先，分析 core dump 查看導致進程異常退出的具體信號和退出原因。
使用 GDB 調試實例一(代碼清單 3)的分析結果如下：
[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 文件，定位錯誤代碼：
[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) 最後，在定位到錯誤代碼行後，就可以很快知道根本原因，並且修改錯誤代碼。