通过 wait/waitpid 可以获取子进程的退出状态, 从而判断其退出结果.

记录退出状态的 int 变量 status 的使用情况如下图所示:

如果是收到信号终止的话, 低 7 位为收到的终止信号, 而低第 8 位为 core dump 标志, core dump 标志有什么用呢? core dump 标志只存 0/1, 表示是否被设置, 当 core dump 为 1 时, 表示程序出现异常, 并受到了相应的 Core 信号, 此时 OS 会对该程序的部分核心代码进行核心转储, 将其从内存中转储到磁盘中, 并且生成 core-xxx 文件.

以下是可能发送 Core 的信号:

模拟场景描述: 程序中存在除零错误.

模拟环境: 云服务器.

示例代码:

#include <iostream>
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>
#include <unistd.h>
using namespace std;int main()
{pid_t pid = fork();if(pid == 0){cout << "Running..." << endl;cout << "Running..." << endl;cout << "Running..." << endl;int n = 10 / 0; //测试除零异常cout << "Div Zero Error..." << endl;cout << "Div Zero Error..." << endl;cout << "Div Zero Error..." << endl;}int status = 0;pid_t ret = waitpid(pid, &status, 0);if(WIFEXITED(status)){cout << "Exit Code is " << WEXITSTATUS(status) << endl;}else{cout << "Signal is " << (status & 0x7f) << ", Core Dump is " << ((status >> 7) & 1) << endl;}return 0;
}

代码描述: 子进程中存在除零错误, 收到信号后终止, 父进程等待获取退出信息.

运行结果:

可以看到, 收到的退出信号为:

翻译过来就是浮点异常, 这里没问题, 但是可以看到此时的 core dump 标志为 0, 这不符合预期, 应该是 1 才对, 原因就出在在云服务器环境下, core dump 资源是被默认关闭的, 通过指令:

ulimit -a

可以查看当前系统中特定资源的上限:

 

可以看到 core file size 为 0, 也就是该资源是出于关闭状态的, 自然 core dump 标志就不会被设置了, 通过指令:

ulimit -c 1024

设置该资源上限大小为 1024:

此时再次运行程序观察结果:

可以看到, 因为除零错误 core dump 标志被设置为 1, 除此之外还生成了一个名为 core.2442 的文件, 2442 即为子进程的 pid, 那么该文件有什么用呢? 

该文件的作用为可以通过 gdb 自动定位到程序异常的问题所在处, 省去了我们手动定位问题的时间, 如下:

补充: 为什么云服务器会默认关闭 core file 呢? 往上可以看到单个 core 文件的大小虽然不大, 但如果一个进程因为某种错误大量循环生成 core 文件, 而又恰好因为得不到即时解决, 很可能导致系统服务被宕掉.