如何捕获无Core Dump的段错误？子进程段错误检测排查

我来帮你理清这个问题——你其实是搞混了信号编号对应的含义，以及core dump和段错误信号的关联逻辑，才导致没抓到无core dump的段错误情况。

首先先明确几个关键信号的定义，别再被手册里的描述误导了：

• SIGSEGV（信号编号11）：这才是标准POSIX系统中，进程发生段错误时会收到的信号，不管有没有生成core dump，只要是段错误导致进程终止，都会触发这个信号。
• SIGBUS（信号编号7）：这是总线错误，和段错误类似但原因不同（比如访问未对齐的内存地址），不属于段错误范畴。
• SIGUSR1（信号编号10）：这是用户自定义信号，完全和段错误无关，手册里的相关描述大概率是你理解错了场景。

你的问题核心在于：core dump只是段错误发生后的可选行为（取决于系统的ulimit -c配置），但不管有没有生成core dump，段错误都会触发SIGSEGV（11）。你之前处理有core dump的段错误时刚好命中了信号11，但错误地把信号10也当成了段错误的触发信号，反而漏掉了无core dump时同样触发的信号11。

接下来修正你的代码逻辑，正确的做法是先判断进程是否被信号终止，再检查终止信号是否为SIGSEGV，同时可以用WCOREDUMP(status)区分是否生成了core dump：

if (WIFSIGNALED(status)) { // 先判断子进程是否被信号终止
    int term_sig = WTERMSIG(status);
    if (term_sig == SIGSEGV) {
        my_putstr("Segmentation fault");
        if (WCOREDUMP(status)) {
            my_putstr(" (core dumped)\n");
        } else {
            my_putstr("\n");
        }
    } else if (term_sig == SIGBUS) {
        my_putstr("Bus error\n");
    }
    // 其他需要处理的信号可以在这里补充
}

这样不管子进程发生段错误时有没有生成core dump，你都能准确捕获到并输出对应的提示。最后再提醒下：建议用信号宏（比如SIGSEGV）代替硬编码的数字，这样代码在不同系统上的兼容性更好，也更易读。

内容的提问来源于stack exchange，提问作者shas