一. 进程信号概述

1.1 生活中的信号

1.2 进程信号

1.3 信号的查看

二. 信号发送的本质

三. 信号产生的四种方式

3.1 按键产生信号

3.2 通过系统接口发送信号

3.2.1 kill -- 向指定进程发送信号

3.2.2 raise -- 当自身发送信号

3.2.3 abort -- 向自身发送进程终止信号

3.3 软件条件产生信号

3.3.1 管道通信读端关闭

3.3.2 时钟问题

3.4 硬件异常产生信号

3.4.1 除0错误

3.4.2 野指针、越界访问问题

四. Core dump问题

4.1 什么是core dump

4.2 进程退出状态中的core dump标记位

4.3 用core文件调试代码

五. 总结

一. 进程信号概述

1.1 生活中的信号

在生活中，信号作为信息通知的一种手段无处不在，我们看到信号后，需要根据信号的种类，来对信号做出特定的反应。如：红绿灯、起床闹钟、警铃、电话铃声等，都属于信号的范畴。

我们能对信号做出相应的反应，是因为我们能够识别信号，并且知道对应的处理动作。按照日常经常，对于生活中的信号，做出以下的特性总结：

我们能够认识识别某种信号。
即使没有出现特定信号，我们也知道信号发出之后应当做出什么反应。
我们可能暂时不对信号进行处理，等待合适时机再处理。
如果暂时不处理信号，我们需要暂时记住信号，等待处理。

1.2 进程信号

进程信号与生活中的信号，都是用于信息通知的。我们可以这样理解进程信号：进程信号是一种信息通知机制，由用户或操作系统发送给特定的进程，通知进程发生了某事件，进程可以稍后处理。

进程对于信号的处理，与生活中的信号处理策略本质相同，可归为以下三类：

按照默认方式处理。（红灯停绿灯行，铃响后马上起床等）
自定义处理方式。（铃响后再睡十分钟回笼觉然后起床）
忽视信号，即不做任何相应。（铃响后让它一直响，继续在床上睡觉）

同样，我们也可以推断出进程信号应用的特性如下：

进程有识别信号的能力。（每个信号都有对应的编号用于进程识别）
进程有默认处理信号的方法。（由程序员写的代码决定默认处理方法）
进程可以对信号进行延后处理，或根本不处理。
用户可以自定义对于特定信号的处理方式。（signal函数）
信号的产生和进程的运行是异步的，即：产生信号时，进程可能在忙自己的事情，延后对信号的处理，而不是立马处理。

1.3 信号的查看

在Linux系统中，通过kill -l指令，可以查看系统中所有内置信号的编号与对应名称，如图1.1所示。

其中2号信号SIGINT，就对应我们经常使用的 Ctrl + C 终止进程。

观察图1.1，我们发现，信号的最高编号为64，没有0号信号，没有32、33号信号，Liunx总共定义有62个信号。其中：

1 ~ 31：普通信号。
34 ~ 64：实时信号。

普通信号用于OS通过正常的运行调度队列调度的进程，即：进程轮番拿到CPU上去运行，每个进程每次在CPU上运行特定的时间片长度，然后切换运行进程。

实时信号只用于极少数的生产环境，这是OS要求要对某个进程运行完毕才可以从CPU上拿下，且进程不应在调度队列中等待调度，而是应当立马调度运行。如：车载系统接收到刹车指令，不可以等待其他进程运行，也必须一次完成运行。

通过man 7 signal指令，下翻查找，我们可以看到每种信号的默认处理方式。

Term -- 进程终止，不发生核心转储。
Core -- 进程终止，发生核心转储。
Ign -- 子进程暂停运行或终止。
Cont -- 继续运行进程。
Stop -- 暂停运行进程。

二. 信号发送的本质

要理解信号发送的本质，首先要理解进程如何保存信号。对信号进行保存，需要记录：a.哪一种信号，b.特定信号是否产生。

这让我们很容易想到位图这种数据结构，位图中通过对特定比特位设置0/1值，来表示某件事情是否发生或某对象是否存在。进程PCB中存有位图这种数据结构来保存信号，每种信号都有其对应的编号，每个编号对应位图中的一个bit位，1表示产生并保存了某信号，0表示没有保存某信号。

如果进程收到了某信号但暂时不对信号做出响应，那么就应当将位图中对应的bit位由1置0，等待进程做出了响应之后，在置回0。

总结信号发送的本质为：OS向目标进程写信号 -> OS改变进程中记录信号状态的位图中的特点bit位 -> 完成信号发送过程。

Crtl + C 组合键终止进程最终也是改变进程中位图的bit位值，键盘中特定槽位的按键按下，键盘驱动就会将按键按下的信息传给OS，OS就会将按键信息转换为信号，然后发送给进程。

三. 信号产生的四种方式

3.1 按键产生信号

通过组合键的方式，可以向进程发送信号，如：

Ctrl + c：向前台进程发送2号信号SIGINT。
Ctrl + \：向前台进程发送3号信号SIGQUIT。

其中2号信号的默认处理方式为进程终止，不进行核心转储，3号信号的默认处理方式为终止进程，进程核心转储。（本文后面会对核心转储进行讲解）

如代码和图3.1所示，运行一个间隔1s输出进程pid的进程，通过Ctrl + C组合键和Ctrl + \组合键向这个死循环进程发送信号，进程都终止掉了，即使没有运行到最后的代码。

代码3.1：死循环打印进程pid

#include <iostream>
#include <unistd.h>

int main()
{
    while(true)
    {
        std::cout << "This is a process, pid:" << getpid() << std::endl;
        sleep(1);
    }

    return 0;
}

3.2 通过系统接口发送信号

3.2.1 kill -- 向指定进程发送信号

函数原型：int kill(pid_t id, int sig)

头文件：#include<sys/types.h>、#include<signal.h>

函数功能：向特定进程发送指定信号

返回值：发送成功返回0，失败发挥-1

编写信号发送程序的源文件kill.cc如代码3.2所示，编译生成可执行文件取名为kill，在命令行参数中输入 ./kill [id] [sig]，即可向指定进程发送特定信号。如图3.2所示，通过kill向死循环进程发送8号信号，进程被终止掉了。

8号信号SIGFPE：浮点数错误，常发生于 x/0 的情况（除0错误）

代码3.2：信号发送kill.cc

#include <iostream>
#include <sys/types.h>
#include <signal.h>

int main(int argc, char** argv)
{
    // 发送信号，必须要有三个命令行参数
    if(argc != 3)
    {
        std::cout << "参数个数错误" << std::endl;
        exit(1);
    }

    int id = atoi(argv[1]);    // 获取结束信号进程的id
    int sig = atoi(argv[2]);   // 获取信号编号

    kill(id, sig);    // 发信号

    return 0;
}

3.2.2 raise -- 当自身发送信号

函数原型：int raise(int sig)

头文件：#include<signal.h>

函数功能：向自身发送指定编号的信号

返回值：发送成功返回0，失败发挥-1

代码3.3在通过fork创建子进程，在子进程中循环5次后，通过raise向子进程本身发送8号信号，父进程阻塞等待子进程退出，接收子进程的返回信号并输出到屏幕，代码运行结果见图3.3。

代码3.3：raise向自身发信号

#include <iostream>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <signal.h>

int main()
{
    pid_t id = fork();
    if(id < 0)
    {
        perror("fork");
        exit(1);
    }
    else if(id == 0)
    {
        // 子进程代码
        int count = 0;
        while(true)
        {
            std::cout << "[Child process]# [" << getpid() << \
                    "], count:" << ++count << std::endl;

            if(count == 5)
            {
                raise(SIGFPE);    //向吱声发送8号信号
            }

            sleep(1);
        }

        exit(0);
    }

    int status = 0;
    pid_t n = waitpid(id, &status, 0);

    std::cout << "signal:" << (status & 0x7F) << std::endl;

    return 0;
}

3.2.3 abort -- 向自身发送进程终止信号

函数原型：void abort()

头文件：#include <stdlib.h>

函数功能：向自身发送6号终止信号SIGABRT

代码3.3：abort向自身发送进程终止信号

#include <iostream>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <signal.h>

int main()
{
    pid_t id = fork();
    if(id < 0)
    {
        perror("fork");
        exit(1);
    }
    else if(id == 0)
    {
        // 子进程代码
        while(true)
        {
            std::cout << "[Child process]# pid:" << getpid() << ", ppid:" << getppid() << std::endl;
            abort();   // 向子进程自身发送进程终止信号
        }

        exit(0);
    }

    int status = 0;
    pid_t n = waitpid(id, &status, 0);

    std::cout << "signal:" << (status & 0x7F) << std::endl;

    return 0;
}

3.3 软件条件产生信号

软件条件产生信号，就是OS检测到某种软件条件触发或者不满足，由OS向指定进程发送信号。如：a. 管道通信中，读段关闭，写端进程退出 b.时钟问题

3.3.1 管道通信读端关闭

管道通信，是一种提供访问控制的进程间通信方式，一端进程负责写数据（写端），另一端进程负责读数据（读端），如果读端关闭，那么写端就不再有意义，OS会强制终止写端进程。OS终止写端进程的方法就是发送13号信号SIGPIPE。

代码3.4对上述现象进行复现，a. 通过fork创建子进程 -> b. 父进程读数据，子进程写数据 -> c. 父子进程进行一段时间的通信 -> d.关闭父进程读端管道 -> e.父进程阻塞等到子进程退出，输出退出状态信息。运行代码，可见子进程因接收到了13号SIGPIPE信号而终止退出。

代码3.4：管道通信中因软件条件产生信号

#include <iostream>
#include <string>
#include <sys/types.h>
#include <sys/wait.h>
#include <fcntl.h>
#include <unistd.h>

int main()
{
    // 1.创建管道
    int pipefd[2] = {0};
    int n = pipe(pipefd);   // 管道创建

    if(n == -1)
    {
        perror("pipe");
        exit(1);
    }

    // 2.创建子进程
    pid_t id = fork();   

    // 让子进程写数据， 父进程读数据
    if(id == 0)
    {
        // 子进程发送数据
        // 3. 关闭不需要的fd
        close(pipefd[0]);

        // 4. 写数据
        // char send_buffer[1024] = {0};
        std::string message = "[Child process]# Send message to you";

        while(true)
        {
            // 子进程间隔一秒发送数据
            ssize_t sz = write(pipefd[1], message.c_str(), message.size());
            if(sz > 0) sleep(1);
            else break;
        }

        close(pipefd[1]);
        exit(1);
    }

    // 父进程读取数据
    // 3. 关闭不需要的fd
    close(pipefd[1]);

    // 4. 开始读取数据
    char read_buffer[1024] = {0};
    int count = 0;

    while(true)
    {
        ssize_t sz = read(pipefd[0], read_buffer, 1024);
        if(sz > 0)
        {
            read_buffer[sz] = '\0';
            std::cout << "[" << getpid() << "]" << read_buffer << ", count:" << ++count << std::endl;

            if(count == 5)
            {
                // 关掉读端
                // 终止读取死循环
                close(pipefd[0]);
                break;
            }
        }
        else break;
    }

    // 5. 父进程阻塞等待子进程退出
    int status = 0;
    waitpid(id, &status, 0);

    std::cout << "child process exit, write end, exit signal:" \
    << (status & 0x7F) << std::endl;

    return 0;
}

3.3.2 时钟问题

首先要了解一下时钟接口函数alarm。

alarm函数：

函数原型：unsigned int alarm(unsigned int second)

头文件：#include<unistd.h>

功能：调用时钟函数second秒后，向进程发送14号SIGALRM信号，在倒计时期间进程继续运行不受影响。

返回值：如果之前有alarm函数被调用，返回上一个时钟倒计时还有几秒，如果之前没有alarm函数被调用，返回0。

代码3.5为算力评估函数，通过时钟函数，自定义处理14号SIGALRM信号的方法，计算1s内CPU能够进行多少次的++操作，在自定义信号处理方法中输出。

代码3.5：通过alarm函数进行算力评估

#include <iostream>
#include <unistd.h>
#include <signal.h>

uint64_t count = 0;

void handler(int sig)   // 自定义信号处理函数
{
    std::cout << "count end, final count:" << count << std::endl;
    exit(0);
}

int main()
{
    signal(SIGALRM, handler);
    alarm(1);   // 倒计时1秒
    while(true) ++count;
    return 0;
}

3.4 硬件异常产生信号

硬件异常，被硬件以某种方式记录（通常为寄存器中的状态标记信息），由OS检测到，并产生信号发送给进程。比如：除0错误被CPU检查并记录，OS检测到并产生SIGFPE信号发送给进程，再比如野指针、越界访问内存的问题，MMU检测到了非法访问，由硬件记录异常状态，OS检测到后发送SIGSEGV信号给进程。

Linux中越界访问、野指针等问题通常都被记录为段错误Segmentation fault，对应11号SIGSEGV信号。

3.4.1 除0错误

代码3.6自定义了对SIGFPE信号的处理方法handler_signal，出现异常程序不会退出终止，在主函数中，先人为写出除0错误，然后while(true)死循环。

按照我们的一般认知，进程在接收到信号后只会执行一次对应的自定义处理动作，但是，如图3.6所示，handler_signal函数在不断地被运行，这是为什么？更加奇怪的是，如果将代码中发生/0错误的部分注释掉，通过命令行kill -8的方法，人为向进程发送8号信号，handler_signal就只会被执行一次！

代码3.6：除0错误引发硬件异常

#include <iostream>
#include <signal.h>
#include <unistd.h>

void handler_signal(int sig)
{
    std::cout << "recieve a signal:" << sig << std::endl;
    sleep(1);
}

int main()
{
    signal(SIGFPE, handler_signal);
    int a = 10;
    int b = a/0;
    while(true) {}
    return 0;
}

自定义handler_signal后，除零错误产生的现象：

如果代码本身发生除0错误，handler_signal被一次次执行。
如果人为通过kill -8发送信号，handler_signal只被执行一次。

产生这种现象的原因就在于，代码本身产生的除0错误为硬件异常，而人为kill -8发送信号不经由硬件，直接被OS处理后将信号发送给进程。

我们可以以如下的方式理解硬件产生的除0异常和上面的奇怪现象：

计算是由硬件（CPU）来完成的，CPU会赋值进行溢出检查。
CPU的寄存器中会记录有状态信息，其中就包括溢出标志位，如果出现除0错误或其他溢出问题，CPU寄存器中的溢出标志位就会被置1，OS会在计算完成时对CPU寄存器中的状态信息进行检测，如果检测到溢出标记位为1，OS就会向进程发送8号SIGFPE信号。
进程接收到了8号异常信号后，并不一定会退出（如果自定义了处理函数）。
若进程不退出，OS就会对CPU寄存器中的状态信息进行轮巡检测，溢出标记在除零错误发生后并没有被置回0，OS就会不断检测到异常信息，进而不断向进程发送SIGFPE信号，进而一直在调用handler_signal处理信号。
通过kill -8 发送信号，是一种纯软件行为，并没有经过硬件，没有设置过CPU中的标记位，在CPU轮巡检测的过程中也就不会被不断检测出异常。

3.4.2 野指针、越界访问问题

当某个进程需要访问物理内存资源时，需要先拿到进程地址空间的虚拟地址，再通过页表 + MMU(Memery Manager Unit，内存管理模块) 映射到物理内存的方式来访问。

我们获取认为页表映射是OS所进行的软件行为，其实不是，试想一下，通过页表映射物理内存是进程运行过程中大量、高频执行的操作，如果有OS来进行这一操作，就严重延缓了计算机设备的整机效率。

实际的情况是：OS将页表和虚拟地址信息，以二进制的方式写入到硬件中去，通过虚拟地址 + 页表映射物理内存的方法，是由硬件来完成的，那么出现越界、野指针等问题，也理应属于硬件异常。

我们可以按照以下方式理解野指针、越界访问的问题：

进程必须要通过地址来访问物理内存，而现代计算机使用的都是虚拟地址。
虚拟地址需要通过页表 + MMU（Memery Manager Unit，硬件）来完成虚拟地址到实际地址的转换。
在不考虑编译器优化的情况下，如果出现野指针、越界访问等问题，MMU一定会报错。
页表 + MMU映射物理内存地址是硬件层面的操作，出错当然也属于硬件异常，硬件会对相应的寄存器标志位进行设置，供OS进行轮巡检测。

出现野指针、越界访问等问题在Linux中属于段错误，OS会向进程发送11号SIGSEGV信号。

代码3.7模拟了野指针问题产生的硬件异常行为，代码运行结果与3.6一致，都是不间断执行信号处理函数signal_handler，因为OS在对硬件寄存器中的信息进行轮巡检测。

代码3.7：野指针问题引发硬件异常

#include <iostream>
#include <signal.h>
#include <unistd.h>

void handler_signal(int sig)
{
    std::cout << "recieve a signal:" << sig << std::endl;
    sleep(1);
}

int main()
{
    signal(SIGSEGV, handler_signal);
    int* pa = nullptr;
    *pa = 10;
    while(true) {}
    return 0;
}

四. Core dump问题

4.1 什么是core dump

通过man 7 signal，查看每种信号对应的默认处理方法，如果为Core，那么默认会产生Core文件，OS会将当前进程内存中的核心数据全部保存到Core文件中，Core文件是用来调试的。

如：3号SIGQUIT信号、8号SIGFPE信号、11号SIGSEGV信号，默认触发响应都会产生Core文件，而2号SIGINT、9号SIGKILL信号，默认不会产生Core文件。

一般而言，生产环境、云服务器的core dump功能都是关闭的，如果想要在响应信号的时候产生core文件，还必须保证core dump功能打开。

ulimit -a 指令：可用于查看core dump功能是否打开，如果输出结果的第一行core file size为0，那么表示core dump功能没有打开。
ulimit -c [size] 指令 -- 通过指定file文件的大小（非0），来打开core file功能。

4.2 进程退出状态中的core dump标记位

通过wait/waitpid函数，可以实现父进程对子进程的等待，wait/waitpid函数都可以接收int*类型的输出型参数，用于记录子进程的退出状态，我们称之为int status，status在进程正常退出和异常退出的状态下，如图4.2所示根据退出状态和status比特位的划分，对应子进程退出状态。

代码4.1创建进行死循环的子进程，并且waitpid阻塞等待子进程退出，输出信号编号和core dump标记位，在代码运行起来后，通过在命令行中向子进程发送3号信号(kill -3 [pid])，强制子进程终止并在进程终止后通过ll指令查看当前路径下的文件及属性，可以看到生成的core文件。

代码4.1：子进程信号编号和core dump标志的获取

#include <iostream>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

int main()
{
    // 1. 创建子进程
    pid_t id = fork();   
    if(id < 0)
    {
        perror("fork");
        exit(1);
    }
    else if(id == 0)
    {
        // 2. 子进程代码
        while(true)
        {
            std::cout << "[Child process]# pid:" << getpid() << ", getppid:" << getppid() << std::endl;
            sleep(1);
        }

        exit(0);
    }

    // 3. 父进程阻塞等待子进程，并获取退出状态
    int status = 0;
    waitpid(id, &status, 0);

    //4. 检查子进程退出状态
    if(WIFEXITED(status))
    {
        std::cout << "子进程正常终止" << std::endl;
        std::cout << "exit code: " << WEXITSTATUS(status) << std::endl;
    }
    else
    {
        std::cout << "子进程被信号所杀" << std::endl;
        std::cout << "signal:" << (status & 0x7F) << ", core dump:" << ((status >> 7) & 1) << std::endl;
    }

    return 0;
}

4.3 用core文件调试代码

Linux下的gcc/g++编译器默认采用Release版本发布可执行程序，若要对代码进行调试，就需要Debug版本的可执行程序，这就需要在使用gcc/g++编译源文件的时候添加-g选项。

代码4.2人为制造除0错误，这样就会有8号信号发给进程，8号信号默认会产生core文件。编译代码，生成Debug版本的可执行程序。使用gdb启动调试之后，在命令行中输入指令core-file [core文件名]，就会显示出出现异常的行数，以及其他的错误信息。

gdb指令：core-file [core文件名] -- 引入core文件调试代码，定位出错位置，查看错误信息

代码4.2：出现异常并生成Core文件的测试代码

#include <iostream>
#include <unistd.h>

int main()
{
    int a = 10;
    int b = a/0;

    sleep(1);
    std::cout << "run here" << std::endl;

    return 0;
}

五. 总结

进程信号用于向进程发送信息，通知进场某件事情的发生，进程咱叔不响应信号，等待合适的时机再进行响应。
进程处理信号的方式和分为三种：a. 按照默认方式响应 b.按照用户自定义的方式响应 c.直接忽略信号，不做处理。
如果进程暂时不响应信号，则需要对进行进行暂时保存。信号保存需要存储信号编号以及它是否产生，Linux中使用位图保存信号，而位图存于每个进程的PCB中。
发送信号的本质，就是更改位图中对应的二进制位。
信号可以通过四种方式产生：1.按键 2.系统接口调用 3.软件行为 4.硬件异常
如果某种信号的默认处理方式会产生core文件，而且系统的Core dump功能处于开启状态，那么进程在接收到这些信号后会生成core文件，core文件用于对代码的调试，可以帮助快速定代码中出现异常的位置以及错误信息。