詳談 UNIX 環境進程異常退出
本文詳細論述UNIX環境上的進程異常退出，將導致進程異常退出的各種情景歸納為兩類，對每類情況詳細分析了問題出現的根本原因，同時添加了相應的實例以易于您更好地進行了解。在此基礎上，文章最后論述了應該如何避免和調試進程異常退出問題。希望讀者閱讀此文后，對進程異常退出問題有更深層的認識，有更系統的梳理，對調試此類進程崩潰問題時也能有所幫助，寫出更穩定、更可靠的軟件。
進程異常退出
進程退出意味著進程生命期的結束，系統資源被回收，進程從操作系統環境中銷毀。進程異常退出是進程在運行過程中被意外終止，從而導致進程本來應該繼續執行的任務無法完成。進程異常退出可能給軟件用戶造成如下負面影響：
- 軟件喪失部分或者全部功能性，無法完成既定任務。
- 如果進程正在處理數據，可能造成數據損壞。
- 如果是關鍵軟件服務，必然導致服務異常中止，造成無法預計的損失。
- 進程異常退出或者進程崩潰，也會給軟件用戶造成恐慌和困惑。
進程異常退出是生產環境中經常遇到的問題，它會給軟件用戶造成很多負面影響，所以軟件開發者應當避免這種問題的出現。但是導致進程異常退出的場景和原因是多種多樣的，甚至令人琢磨不透。
本文將所有可能造成進程異常退出的原因歸結為兩類。系統地將其分類，使讀者對此類問題能有清晰的認識。對每類情況詳細論述，分析根本原因，然后分析了這兩類情況之間的聯系，也就是信號與進程異常退出的緊密關系。希望您讀完此文后，能對此類問題有更加全面、深入的理解，對調試此類問題也能有所幫助，寫出更加可靠、更加穩定性、更加健壯的軟件。
首先我們來看導致進程異常退出的這兩類情況：
第一類：向進程發送信號導致進程異常退出；
第二類：代碼錯誤導致進程運行時異常退出。
第一類：向進程發送信號導致進程異常退出
信號：
UNIX系統中的信號是系統響應某些狀況而產生的事件，是進程間通信的一種方式。信號可以由一個進程發送給另外進程，也可以由核發送給進程。
信號處理程序：
信號處理程序是進程在接收到信號后，系統對信號的響應。根據具體信號的涵義，相應的默認信號處理程序會采取不同的信號處理方式：
- 終止進程運行，并且產生core dump文件。
- 終止進程運行。
- 忽略信號，進程繼續執行。
- 暫停進程運行。
- 如果進程已被暫停，重新調度進程繼續執行。
前兩種方式會導致進程異常退出，是本文討論的范圍。實際上，大多數默認信號處理程序都會終止進程的運行。
在進程接收到信號后，如果進程已經綁定自定義的信號處理程序，進程會在用戶態執行自定義的信號處理程序；反之，內核會執行默認信號程序終止進程運行，導致進程異常退出。
圖1.默認信號處理程序終止進程運行
所以，通過向進程發送信號可以觸發默認信號處理程序，默認信號處理程序終止進程運行。在UNIX環境中我們有三種方式將信號發送給目標進程，導致進程異常退出。
方式一：調用函數kill()發送信號
我們可以調用函數kill(pid_t pid, int sig)向進程ID為pid的進程發送信號sig。這個函數的原型是：
- #include <sys/types.h>
- #include <signal.h>
- int kill(pid_t pid, int sig);
調用函數kill()后，進程進入內核態向目標進程發送指定信號；目標進程在接收到信號后，默認信號處理程序被調用，進程異常退出。
清單1.調用 kill() 函數發送信號
- /* sendSignal.c, send the signal ‘ SIGSEGV ’ to specific process*/
- 1 #include <sys/types.h>
- 2 #include <signal.h>
- 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 <signal.h>
- 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 <signal.h>
- 2 #include <stdio.h>
- 3 #include <unistd.h>
- 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. 異常處理函數終止進程運行
#p#
實例以及分析
實例一：內存非法訪問
這類問題中最常見的就是內存非法訪問。內存非法訪問在UNIX平臺即segmentation fault，在Windows平臺這類錯誤稱為Access violation。
內存非法訪問是指：進程在運行時嘗試訪問尚未分配（即，沒有將物理內存映射進入進程虛擬內存空間）的內存，或者進程嘗試向只讀內存區域寫入數據。當進程執行內存非法訪問操作時，內存管理單元MMU會產生內存保護異常GPF(General Protection Fault)，異常號是13。系統會立刻暫停進程的非法操作，并且跳轉到GPF的異常處理程序，終止進程運行。
這種編程錯誤在編譯階段編譯器不會報錯，是運行時出現的錯誤。清單3是內存非法訪問的一個簡單實例，進程在執行第5行代碼時執行非法內存訪問，異常處理函數終止進程運行。
清單3.內存非法訪問實例demoSegfault.c
- 1 #include<stdio.h>
- 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 <stdio.h>
- 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。#p#
異常處理函數內幕
異常處理函數在實現上，是通過向掛起進程發送信號，進而通過信號的默認信號處理程序終止進程運行，所以異常處理函數是“間接”終止進程運行。詳細過程如下：
- 進程執行非法指令或執行錯誤操作；
- 非法操作導致處理器異常產生；
- 系統掛起進程，讀取異常號并且跳轉到相應的異常處理函數；
（1）異常處理函數首先查看異常是否可以恢復。如果無法恢復異常，異常處理函數向進程發送信號。發送的信號根據異常類型而定，比如內存保護異常GPF相對應的信號是SIGSEGV，而除0異常DEE相對應的信號是SIGFPE；
（2）異常處理函數調用內核函數 issig() 和 psig() 來接收和處理信號。內核函數 psig() 執行默認信號處理程序，終止進程運行；
4. 進程異常退出。
在此基礎上，我們可以把圖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 的默認信號處理程序終止進程運行。
“信號”是進程異常退出的直接原因
信號與進程異常退出有著緊密的關系：第一類情況是因為外部環境向進程發送信號，這種情況下發送的信號是異步信號，信號的到來與進程的運行是異步的；第二類情況是進程非法操作觸發處理器異常，然后異常處理函數在內核態向進程發送信號，這種情況下發送的信號是同步信號，信號的到來與進程的運行是同步的。這兩種情況都有信號產生，并且最終都是信號處理程序終止進程運行。它們的區別是信號產生的信號源不同，前者是外部信號源產生異步信號，后者是進程自身作為信號源產生同步信號。
所以，信號是進程異常退出的直接原因。當進程異常退出時，進程必然接收到了信號。#p#
避免和調試進程異常退出
建議
軟件開發過程中，我們應當避免進程異常退出，針對導致進程異常退出的這兩類問題，對軟件開發者的幾點建議：
- 通常情況無需屏蔽外部信號。信號作為進程間的一種通信方式，異步信號到來意味著外部要求進程的退出；
- 綁定自定義信號處理程序做清理工作，當外部信號到來時，確保進程異常退出前，自定義信號處理程序被調用做清理工作，比如刪除創建的臨時文件。
- 針對第二類情況，編程過程中確保進程不要做非法操作，尤其是在訪問內存時，確保內存已經分配給進程（映射入進程虛擬地址空間），不要向只讀區寫入數據。
問題調試和定位
進程異常退出時，操作系統會產生 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) 最后，在定位到錯誤代碼行后，就可以很快知道根本原因，并且修改錯誤代碼。
