SIGPIPE(Signal?13,?Code?0)?異常排查及處理

更新時間：2023年01月29日 14:00:17 作者：yuec

這篇文章主要為大家介紹了SIGPIPE(Signal?13,?Code?0)?異常排查原因解析及處理詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

問題現(xiàn)象

最近一個版本 APP 更新之后，sentry 大量異常數(shù)據(jù)上報，影響用戶的數(shù)量非常夸張 10w +，具體報錯如下

排查過程

首先查看 SIGPIPE 的報錯原因，在官網(wǎng)搜索到了相關信息

大意是 Socket 連接關閉后，如果客戶端仍在發(fā)送數(shù)據(jù)，這個時候就會產(chǎn)生 SIGPIPE 信號，如果信號沒有被處理就會產(chǎn)生崩潰，這里截取了部分關鍵信息。

文檔上說可以使用 signal(SIGPIPE, SIG_IGN) 全局忽略，確認客戶端添加了該邏輯，但是異常還是上報到了 sentry。signal 這個函數(shù)是給信號關聯(lián)一個 handler，收到這個信號的時候去執(zhí)行。 SIG_IGN 是系統(tǒng)提供的忽略信號的處理方式，定義如下:

#define SIG_IGN         (void (*)(int))1

嘗試手動觸發(fā) SIGPIPE, 運行后可以正常輸出。

void signalHandler(int signal) {
    printf("bingo");
}
int main(int argc, char * argv[]) {
    signal(SIGPIPE, signalHandler);
    kill(getpid(), SIGPIPE);
}

多次添加 handler 繼續(xù)嘗試, 控制臺輸出 333, 也就是說只有最后添加的 handler 會執(zhí)行到，比較容易理解一個信號只能關聯(lián)一個 handler。

void signalHandler(int signal) {
    printf("111");
}
void signalHandler2(int signal) {
    printf("222");
}
void signalHandler3(int signal) {
    printf("333");
}
int main(int argc, char * argv[]) {
    signal(SIGPIPE, signalHandler);
    signal(SIGPIPE, signalHandler2);
    signal(SIGPIPE, signalHandler3);
    kill(getpid(), SIGPIPE);
}

現(xiàn)狀是 sentry 可以捕獲并處理這個異常，所以此時懷疑是 sentry 把客戶端的處理給覆蓋了。

查看 sentry 里面的邏輯，sentry 使用了 sigaction 函數(shù)關聯(lián) handler，這個函數(shù)與 signal 函數(shù)一樣，可以設置與信號 sig 關聯(lián)的動作，而 oact 如果不是空指針的話，就用它來保存原先對該信號的動作的位置，act 則用于設置指定信號的動作。sentry 關聯(lián)了自己的處理 handleSignal 并且會把之前的handler 存儲到數(shù)組 g_previousSignalHandlers 里面。

int sigaction(int sig, const struct sigaction *act, struct sigaction *oact);
// sentry 關聯(lián)的 action 為 handleSignal
sigaction(fatalSignals[i], &action, &g_previousSignalHandlers[i])

sentry 在 handleSignal 里面上報異常并且執(zhí)行了了 sentrycrashcm_handleException，然后使用 raise 重新拋出這個信號。

static void handleSignal(int sigNum, siginfo_t *signalInfo, void *userContext)
{
    SentryCrashLOG_DEBUG("Trapped signal %d", sigNum);
    if (g_isEnabled) {
        // 這里省略上報邏輯
        sentrycrashcm_handleException();
    }
    SentryCrashLOG_DEBUG("Re-raising signal for regular handlers to catch.");
    // This is technically not allowed, but it works in OSX and iOS.
    raise(sigNum);
}

查看 handleException 簡化后的調(diào)用棧:

void sentrycrashcm_handleException(**struct** SentryCrash_MonitorContext *context)
{
    sentrycrashcm_setActiveMonitors(SentryCrashMonitorTypeNone);
}
void sentrycrashcm_setActiveMonitors(SentryCrashMonitorType monitorTypes)
{
    // isEnabled = false
    setMonitorEnabled(monitor, isEnabled);
}
static inline void setMonitorEnabled(Monitor *monitor, bool isEnabled) {
    uninstallSignalHandler();
}
static void uninstallSignalHandler(void) {
    sigaction(fatalSignals[i], &g_previousSignalHandlers[i], **NULL**);
}

可以看到 handleException 這個函數(shù)最終會重新關聯(lián)保存在 g_previousSignalHandlers里面的 handler，也就是客戶端設置的 SIG_IGN 默認忽略。sentry 關聯(lián)的函數(shù) handleSignal 會在處理完會重新拋出信號，這個信號會觸發(fā) SIG_IGN，所以這里并不存在覆蓋關系，sentry 不會影響到客戶端默認忽略的邏輯。

綜上客戶端設置的 SIG_IGN 是會生效的，sentry 只是上報了異常，并沒有崩潰產(chǎn)生。在 APP 里面手動觸發(fā) SIGPIPE，Charles 抓包可以看到 sentry 上報，APP 未出現(xiàn)崩潰。

原因與處理

和多個業(yè)務方確認這個版本并沒有 socket 相關的改動，那為什么在這個版本之后突然有大量異常上報呢？

后面 diff 代碼發(fā)現(xiàn)是改動了 sentry 的初始時機造成的。之前的邏輯是 sentry 初始化，客戶端調(diào)用 signal 關聯(lián) SIG_IGN，這個時候 SIG_IGN 覆蓋了 sentry 的 signalHandler，并且沒有保存和恢復之前 handler 的邏輯，sentry 捕獲不到信號不會上報，當前版本的改動使這個順序顛倒了，導致了大量異常數(shù)據(jù)上報。后續(xù)嘗試去定位具體的 socket 無果，重新修改了順序 SIG_IGN 在 sentry 初始化之后關聯(lián)，之后的版本不再有異常數(shù)據(jù)上報。