android signal 處理總結

在Android 開發中遇到一些signal 的情況，簡要總結如下：     1）Zygote 監控 子進程的退出情況   jellybean/dalvik/vm/native/dalvik_system_Zygote.cpp#151     151     sa.sa_handler = sigchldHandler;       153     err = sigaction (SIGCHLD, &sa, NULL);   當進程結束的時候，log 中有類似下面的消息，這就是 Zygote打印出來，它會報告子進程被什麼 signal 終結的   D Zygote  : Process 749 terminated by signal (11)   2）DVM 生成單獨的信號處理線程，用來對三個信號做特殊處理：   每個進程包含多個線程，當進程受到 signal 的時候，可能被其中任何一個線程處理   一個應用運行在虛擬機上dvm上一個應用也是一個dvm 進程，dvm 專門創建了一個信號處理線程來處理這3個信號，其他的線程都要block對這三個信號的處理。   這三個信號是 SIGQUIT, SIGUSR1, SIGUSR2, 看下面代碼，後面兩個信號 vm 內部要使用   dalvik/vm/Init.cpp  

static void blockSignals()    
{    
    sigset_t mask;    
    int cc;    
    
    sigemptyset(&mask);    
    sigaddset(&mask, SIGQUIT);    
    sigaddset(&mask, SIGUSR1);      // used to initiate heap dump    
#if defined(WITH_JIT) && defined(WITH_JIT_TUNING)    
    sigaddset(&mask, SIGUSR2);      // used to investigate JIT internals    
#endif    
    //sigaddset(&mask, SIGPIPE);    
    cc = sigprocmask(SIG_BLOCK, &mask, NULL);    
    assert(cc == 0);    
}    

 

  為何處理 quit   Android 應用在收到異常終止信號（SIGQUIT）時，沒有遵循傳統 UNIX信號模型的默認行為 （終止 + core ）。而是打印出trace 文件來，以利於記錄應用異常終止的原因。    Trace文件是 android davik 虛擬機在收到異常終止信號 （SIGQUIT）時產生的。 最經常的觸發條件是 android應用中產生了 FC （force close）。由於是該文件的產生是在 DVM裡，所以只有運行 dvm實例的進程（如普通的java應用，java服務等）才會產生該文件，android 本地應用 （native app，指 運行在 android lib層，用c/c++編寫的linux應用、庫、服務等）在收到 SIGQUIT時是不會產生 trace文件的。 參考   http://blog.csdn.net/rambo2188/article/details/7017241     3) 其他基於 bionic 的應用，都被  Android 動了手腳   android的實現是在 main 運行之前 先運行 debugger_init 方法，以實現攔截系統異常的幾個singal：SIGILL, SIGABRT, SIGBUS, SIGFPE, SIGSEGV和SIGPIPE， 代碼位於： bionic/linker/debugger.c， 把 debugger_init 注入 是通過在 linker 中做手腳 （bionic/linker/linker.c#2255）   而後當程序收到那幾個信號後，不是安裝 linux  缺省的處理方法，而是運行 debugger_init 中設定的信號處理方法，此方法就是和 debuggerd （守護進程）通信，通過socket告訴其  tid ，   而後  debuggerd 通過調用   tid_attach_status= ptrace(PTRACE_ATTACH, tid, 0, 0);   這裡，debuggerd就掛上ptrace了，attach到出問題的線程，debuggerd進程就是被調試進程的父進程了，這樣debuggerd就可以控制tid線程了，最終生成  tomestone的信息