【Linux学习】信号——预备知识 | 信号产生 | 核心转储

🐱作者：一只大喵咪1201
🐱专栏：《Linux学习》
🔥格言：你只管努力，剩下的交给时间！

🔔信号

从生活中入手，例如发令枪，闹钟，红绿灯等等，这些都是信号。信号必须都是动态的，像路标就不能称之为信号。

以红绿灯为例，一看到红绿灯我们就知道红灯行，绿灯停，我们不仅能认识它是一个红绿灯，而且还知道应该产生什么样的行为，这样才算是能够识别红绿灯。

• 识别 = 认识 + 行为产生

对于红绿等这个信号，我们需要有如下几个共识：

• 我们之所以能识别红绿灯，是因为我们受到过教育(手段)，让我们在大脑中记住了不同颜色对应的行为(属性)。
• 当绿灯亮了以后，不一定要立刻过马路，比如有其他的车闯红灯，需要进行避让，所以说我们不一定要立刻产生相应的行为。
• 红灯亮了以后，正好来了一个电话，在接电话这个期间我们会记住此时是红灯，不会将这个状态忘记。
• 红绿灯默认的行为是红灯行，绿灯停，但是也可以产生其他行为，还可以忽略。

现在将生活中红绿灯的例子迁移到进程中：

• 共识：信号是发给进程的。

• 进程之所以能够识别信号，是因为程序员将对应的信号种类和逻辑已经写好了的。
• 当信号发给进程后，进程不一定要立刻去处理，可能有更加紧急的任务，会在合适的时候去处理。
• 进程收到信号到处理信号之前会有一个窗口期，这个期间要将收到的信号进行保存。
• 处理信号的方式有三种：默认动作，自定义动作，忽略。

我们学习信号是学习它的整个生命周期，按照时间轴，分为信号产生，信号保存，信号处理。但是在这之前先需要学习一些预备知识。

🎵预备知识

进程能够识别的信号是已经写好的，它有62个：

• 红色框中的是普通信号，编号从1-31。
• 绿色框中的是实时信号，编号从34-64。

这其中没有32号和33号信号，所以一共有62个信号。而且这里我们只学习普通信号，对实时信号暂不做研究。

• 在使用这些信号时，可以用信号名，也可以用信号编号，它是一样的，都是宏定义后的结果。

根据我们对Linux的了解，信号存放在哪里呢？既然信号是给进程的，而进程是通过内核数据结构来管理的，所以我们可以推断出，信号放在进程的task_struct结构体中。

既然它是在PCB中，而且数量是31个，task_struct中必定不会设置31个变量来存放信号，数组还有可能，但是信号的状态只分为有和没有两种，所以再次推断，31个信号放在一个32位的整形变量中，每个比特位代表一个信号。

本喵写一段伪代码来示意一下：

struct task_struct
{//进程属性unsigned int signal;//.......
}

就像在学习基础IO和进程间通信的时候，那些flags标志中的不同的比特位代表着不同的意义，这31个信号量也是这种方式：

具体的保存细节后面本喵再详细讲解。

问题来了，内核数据结构的修改，这个工作是由谁来完成的？毫无疑问是操作系统，因为task_struct就是它维护的，而且是存在于内存中的，只有操作系统才有权力去修改它，用户是无法直接操作的，因为操作系统不相信任何人。

所以说，无论哪个信号，最后的本质都是由操作系统发生给进程的，这里的发送本质就是在修改task_struct中存放信号那个变量的比特位。

• 信号发送的本质就是在修改PCB中的信号位图。

无论未来我们学习了多少中发送信号的方式，本质都是通过操作系统向目标进程发送信号。

所以操作系统一定会提供相关的系统调用，比如我们之前使用过的各自信号：

kill -9 pid值 	//停止某个进程
kill -19 pid值	//暂停某个进程
kill -18 pid值	//继续某个进程

它们的底层一定是在调用相关的系统调用，来让操作系统修改PCB中的信号位图。

🎵信号处理方法的注册

• 所谓的注册，就是告诉操作系统，当某个进程接收到某个信号后的处理方式。

既然是告诉操作系统，那么肯定会用到系统调用，该系统调用的名字是signal()：

• int signal：要注册的信号编号
• sighandler_t handler：自定义的函数指针

可以将信号的处理方式写成一个函数，然后将函数名传递个signal，此时当进程接收到signum指定的信号编号时，就会执行我们定义的函数。

void handler(int signo)
{cout<<"进程接收到的一个信号，编号："<<signo<<endl;
}

函数的返回类型必须是void类型，形参必须是signo类型，名字可以随意。

补充：

我们之前，在shell的命令行中，会按crtl + c 来结束正在运行的进程。这种键我们称为热键。

ctrl + c本质是上一个组合键，操作系统识别到这种组合键后，会将它解释为2号信号SIGINT。

现在将我们自己写的函数注册为2号信号的处理方式。

运行起来后发现，按上ctrl+c后，进程不会结束了。

• 2号信号SIGINT的默认处理方式就是结束进程。
• 我们自定义的处理方式中并没有结束进程，所以进程在收到2号进程后打印了一句话。

• 所有信号的默认处理方式都是结束进程，只是不同的信号代表的意义不一样。

小实验：

我们将31个信号都自定义处理方式，并且不退出进程，那么这个进程是不是就无法退出了？

此时31个信号的自定义处理方式中都没有进程退出。

可以看到，给这个进程这么多信号，都没有结束，而且自定义处理方式也执行了，打印出了接收到的信号编号，但是进程还是在执行。

那这样是不是意味着这个进程无法结束了？不是的，操作系统就防着你呢，不会让这种恶意的东西存在的。

• 9号信号SIGKILL是不能够自定义处理方式的，所以该信号能够将这个进程结束掉。

kill -9 pid值//杀死指定进程

该指令可以结束任何进程，这就是操作系统留的后手。

🔔信号的产生

有了上面的预备知识以后，就可以正式来研究信号了。

🎵通过终端按键产生信号

也就是在键盘上按一些热键，来给进程发送相应的信号，ctrl+c在上面本喵就讲解过了，它产生的是2号信号SIGINT。

还有常用按键ctrl+\，它产生的是3号信号SIGQUIT。

可以看到通过键盘产生了2号和3号信号。

🎵调用系统调用向进程发信号

系统调用kill():

• pid_t pid：要给发信号的pid
• int sig：要发送的信号编号
• 返回值：发送成功返回0，失败返回-1

该系统调用是一个进程给另一个进程发送指定信号，可以向任意进程发送任意信号。

信号接收端：

这是一个一直在运行的程序，用来接收从其他进程发送过来的信号。

信号发送端：

这是一个带有命令行参数的程序，输入的选项中的pid值和信号编号，在程序中在调用kill系统调用向指定pid的进程发送指定信号。

效果：

左边在执行mysginal的时候，输入对应的信号编号和pid，右边正在运行的进程就会接收到指定的信号而停止运行。

系统调用raise():

• int sig：要发送的信号
• 返回值：发送成功返回0，失败返回-1

该系统调用是由进程自己调用，也就是进程自己可以给自己发送任意信号。

通过命令行参数指定信号，在程序执行5秒钟后给自己发送该信号。

无论命令行输入哪个信号的编号，在5秒钟后，该进程都会给自己发送输入的信号，让进程结束。

系统调用abort():

• 没有参数，没有返回值

该系统调用只能给自己发送指定的信号，该信号是SIGABRT，信号编号是6。

5秒钟后给自己发送SIGABRT信号。

在运行5秒钟后，该进程接收到了6号信号SIGABRT。

虽然有3个系统调用来产生信号，但是归根到底都是在使用kill系统调用。

• kill()可以给任意进程发送任意信号。
• raise()可以给自己发送任意信号。

//raise本质
kill(getpid(),signo);

• abort()可以给自己发送SIGABRT信号。

//abort本质
kill(getpid(),SIGABRT);

🎵硬件异常产生信号

除0操作导致的硬件异常：

在这段代码中，有除0操作，我们知道，除0得到的是无穷大的数，所以在编程的时候是不允许出现的。

• 在运行的时候，直接出错，没有再执行下去，是因为接收到了信号。
• 接收到的信号是SIGFPE信号，编号为8号。

这其实就是一种硬件异常产生的信号。

• CPU中有很多的寄存器，例如eax，ebx，eip等等。

CPU会从内存中将代码中的变量拿到寄存器中进行运算，如果有必要，还会将运算的结果放回到内存中。

• 还有一个状态寄存器，如果CPU在运算的时候发现了除0操作，就会将状态寄存器的溢出标志位置一。

此时就意味着硬件产生了异常。而操作系统是一个进行软硬件资源管理的软件，CPU的中状态寄存器的溢出标志位置一后，操作系统可以第一时间拿到。

• 除0导致硬件异常以后，操作系统会给对应的进程发送SIGFPE信号。

当进程接收到SIGFPE信号以后，默认的处理方式就是结束进程。

现在我们对这个SIGFPE信号注册一个自定义处理方式：

只打印接收到的信号编号，进程不退出。

在进程运行起来后，怎么就开始鞭尸了呢？也就是这个信号被操作系统不停的发送给这个进程。

• 进程收到信号后进程不退出，随着CPU时间片的轮转就会再次被调到。
• CPU中只有一份寄存器，但是寄存器中的内容属于当前进程的上下文。
• 当进程被切换的时候，就有无数次的状态寄存器被保存和恢复的过程。
• 而除0操作导致的溢出标志位置一的数据还会被恢复到CPU中。
• 所以每一次恢复的时候，操作系统就会识别到，并且给对应进程发送SIGFPE信号。

所以就会导致上面不停调用自定义处理函数，不停打印接收到的信号编号。

解引用空指针导致的硬件异常：

上面代码中存在对空指针的解引用操作，空指针的本质是(void*)0，而0地址处是不允许我们用户进行访问的，这部分属于内核空间。

• 运行的时候直接出错，没有再运行下去，也是因为接收到了信号。
• 接收到的信号是SIGSEGV，编号是11。

这同样是一种硬件异常产生的信号。

• 我们之前一直谈论的页表时间上是页表+MMU，而MMU是在CPU中的，未来简便，我们就只说页表。
• 进程地址空间和物理内存之间的映射关系实际上是有MMU去完成映射的。
• 当对空指针解引用的时候，MMU会拒绝这种操作，从而产生异常标志。
• 操作系统拿到MMU产生的异常以后就会给对应的进程发送SIGSEGV信号。

当进程接收到编号为11的SIGSEGV信号以后，默认的处理动作就是结束进程。

将这个信号注册自定义处理方式，同样打印接收到的信号编号，但是不结束进程，可以看到，和除0操作一样，也是在鞭尸，不停的打印。

• 硬件异常所产生的信号，如果不结束这个进程，我们是没有能力去处理这个进程的。
• 随着时间片的轮转，这个导致硬件异常的进程还会不停的调到，所以操作系统会不停的向进程发送信号。

• 硬件异常产生的信号并不会显示发送，而是由操作系统自动发送的。

🎵由软件条件产生信号

读端关闭触发的信号：

比如在学习匿名管道的时候，当读端关闭的时候，写端所在进程就会收到编号为13的SIGPIPE信号结束进程。

读端5秒钟之后关闭，写端进程注册自定义处理方式，打印写端接收到的信号编号，但是不结束进程。

在读端关闭以后，写端的自定义处理方式中就接收到了系统发给的SIGPIPE信号，编号为13。

• 读端是否关闭是软件中的条件。
• 当条件达成以后，产生信号。

闹钟触发的信号：

闹钟就是系统中的定时器，使用的时候同样需要通过系统调用实现：

• 参数：要定的时长。
• 返回值：距离定的时间还差多少。

定时1秒钟，在循环中进行疯狂加1，设置自定义处理方式，打印定时到后收到的信号编号，并且统计这一秒中内进行了多少次加1操作。

当定时1秒钟时间到了以后，自定义处理方式中打印出接收到的信号编号是14号的SIGALRM信号，并且统计出了1秒钟进行加1操作的次数。

• 自定义处理方式中没有退出进程，所以在执行完处理方式以后，进程继续运行。
• 也就是继续进行加1操作，但是不会再收到信号了，因为定时到的条件只达成一次，所以信号也只产生一次。

如果想每隔一秒条件达成一次，产生一次SIGALRM信号，可以在这样处理：

• 在自定义处理方式中定时1s。
• 当1秒定时条件达成以后，产生信号，执行处理方法后会开始新一轮的定时。

• 软件中某个条件达成以后，操作系统就会产生相应的信号，比如上面的SIGPIPE信号和SIGALRM信号。

闹钟的管理：

操作系统中会有很多个进程，我们可以创建一个闹钟，那么其他进程也可以创建闹钟，这样就会存在很多个闹钟，那么这些闹钟是怎么管理的呢？先描述再组织。

首先需要创建一个闹钟的结构体，伪代码：

struct alarm
{unit64_t when;//定时时长int type;//闹钟类型，一次性还是周期性task_struct* p;//所属进程的地址struct_alarm* next;//下一个闹钟的地址//其他属性
}

大概就是这样的一个结构体来描述闹钟，必须由的肯定是定时时长，所属进程。

接下来就是组织了，用某一种数据结构来管理这些闹钟对象，为了方便管理，可以选择优先级队列prority_queuq来管理。

• 将定时时间最小的闹钟放在前面，时间长的放在后面。
• 操作系统每次只需要检测队首的定时时间是否达到就可以。
• 达到了就向对应进程发送SIGALRM信号，并且从队列中取出，以待再次检测。

操作系统会周期性的检测链表中的这些闹钟，伪代码：

curr_timestamp > alarm.when;//超时了
//OS发送SIGALRM信号到alarm.p；

具体的实现细节有兴趣的小伙伴可以看看源码是怎么管理的，这里本喵只是介绍一种思想。

🔔核心转储

是否有一个疑问，31个信号的默认处理方式都是结束进程，并且还可以自定义处理方式，那么为什么要这么多信号呢？一个信号不就行了吗？

• 重要的不是产生信号的结果，而是产生信号的原因。
• 所有出现异常的进程，必然是收到了某一个信号。

在man的7号手册中介绍了信号的名称，对应的编号，默认处理方式，以及产生该信号的原因。

• 我们可以根据这个表找到不同信号产生所对应的不同原因。

以信号2和3为例，他两的默认处理方式一个是Term，一个是Core。

• Term和Core的结果都是结束进程。

那么这两个方式的区别在哪里呢？

• Term方式仅仅是结束进程，结束了以后就什么都不干了。
• 但是Core不仅结束进程，而且还会保存一些信息。

在数据越界非常严重的时候，该进程会接收到SIGSEGV信号，来结束进程。

• 11号信号的默认处理方式是Core。

在云服务器上，默认情况下是看不到Core退出的现象的，这是因为云服务器关闭了core file选项：

• core file size(红色框)的大小是0，意味着这个选项是关闭的。

• 从这里还可以看到别的关于这个云服务器的信息，比如能够打开的最多文件个数，管道个数，以及栈的大小等等信息。

为了能够看到Core方式的明显现象，我们需要将core file选项打开：

此时该选项就打开了，表示的意思就是核心转储文件的大小是1024个数据块。

• 再运行数据越界的程序时，同样会收到SIGSEGV信号停止。
• 但是在当前目录下会多出一个文件，如上图中的绿色框。

• core.1739：被叫做核心转储文件，其中后缀1739是接收到该信号进程的pid值。

对于一个奔溃的程序，我们最关心的是它为什么崩溃，在哪里崩溃？

• 当进程出现异常的时候，将进程在对应的时刻，在内存中的有效数据转储到磁盘中-------核心转储。

• 核心转储的文件我们可以拿着它进行调试，快速定位到出现异常而崩溃的位置。

• 使用gdb调试我们的可执行程序。
• 调试开始后，输入core-file core.pid值，表明调试核心转储文件。
• 此时gdb就会直接定位到产生异常的位置。

这就是核心转储的重要意义，它相比Term方式，能够让我们快速定位出现异常的位置。

篇幅有限，下篇文章再接着介绍。