📝个人主页:@Sherry的成长之路
🏠学习社区:Sherry的成长之路(个人社区)
📖专栏链接:Linux
🎯长路漫漫浩浩,万事皆有期待
上一篇博客:【Linux】Linux进程间通信(四)
文章目录
- 信号入门
- 生活角度的信号
- 技术应用角度的信号
- 信号的发送与记录
- 信号处理常见方式概述
- 产生信号
- 通过终端按键产生信号
- 通过系统函数向进程发信号
- 由软件条件产生信号
- 由硬件异常产生信号
- 总结:
信号入门
生活角度的信号
你在网上买了很多件商品,在等待不同商品快递的到来。但即便快递还没有到来,你也知道快递到了的时候应该怎么处理快递,也就是你能“识别快递”。
当快递到达目的地了,你收到了快递到来的通知,但是你不一定要马上下楼取快递,也就是说取快递的行为并不是一定要立即执行,可以理解成在“在合适的时候去取”。
在你收到快递到达的通知,再到你拿到快递期间,是有一个时间窗口的,在这段时间内你并没有拿到快递,但是你知道快递已经到了,本质上是你“记住了有一个快递要去取”。
当你时间合适,顺利拿到快递之后,就要开始处理快递了,而处理快递的方式有三种:1、执行默认动作(打开快递,使用商品)2、执行自定义动作(快递是帮别人买的,你要将快递交给他)3、忽略(拿到快递后,放在一边继续做自己的事)。
快递到来的整个过程,对你来讲是异步的,你不能确定你的快递什么时候到。
技术应用角度的信号
编写以下程序并运行:
#include <stdio.h>
#include <unistd.h>
int main()
{
while (1){
printf("hello signal!\n");
sleep(1);
}
return 0;
}
我们知道该程序的运行结果就是死循环地进行打印,而对于死循环来说,最好的方式就是使用Ctrl+C对其进行终止。
为什么使用Ctrl+C后,该进程就终止了?
实际上当用户按Ctrl+C时,这个键盘输入会产生一个硬中断,被操作系统获取并解释成信号(Ctrl+C被解释成2号信号),然后操作系统将2号信号发送给目标前台进程,当前台进程收到2号信号后就会退出。
我们可以使用signal函数对2号信号进行捕捉,证明当我们按Ctrl+C时进程确实是收到了2号信号。使用signal函数时,我们需要传入两个参数,第一个是需要捕捉的信号编号,第二个是对捕捉信号的处理方法,该处理方法的参数是int,返回值是void。
例如,下面的代码中将2号信号进行了捕捉,当该进程运行起来后,若该进程收到了2号信号就会打印出收到信号的信号编号。
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
void handler(int sig)
{
printf("get a signal:%d\n", sig);
}
int main()
{
signal(2, handler); //注册2号信号
while (1){
printf("hello signal!\n");
sleep(1);
}
return 0;
}
此时当该进程收到2号信号后,就会执行我们给出的handler方法,而不会像之前一样直接退出了,因为此时我们已经将2号信号的处理方式由默认改为了自定义了。
由此也证明了,当我们按Ctrl+C时进程确实是收到了2号信号。
注意:
Ctrl+C产生的信号只能发送给前台进程。在一个命令后面加个&就可以将其放到后台运行,这样Shell就不必等待进程结束就可以接收新的命令,启动新的进程。
Shell可以同时运行一个前台进程和任意多个后台进程,但是只有前台进程才能接到像Ctrl+C这种控制键产生的信号。
前台进程在运行过程中,用户随时可能按下Ctrl+C而产生一个信号,也就是说该进程的用户空间代码执行到任何地方都可能收到SIGINT信号而终止,所以信号相对于进程的控制流程来说是异步的。
信号是进程之间事件异步通知的一种方式,属于软中断。
信号的发送与记录
我们使用kill -l命令可以查看Linux当中的信号列表。
其中1~ 31号信号是普通信号,34~64号信号是实时信号,普通信号和实时信号各自都有31个,每个信号都有一个编号和一个宏定义名称:
信号是如何记录的?
实际上,当一个进程接收到某种信号后,该信号是被记录在该进程的进程控制块当中的。我们都知道进程控制块本质上就是一个结构体变量,而对于信号来说我们主要就是记录某种信号是否产生,因此,我们可以用一个32位的位图来记录信号是否产生。
其中比特位的位置代表信号的编号,而比特位的内容就代表是否收到对应信号,比如第6个比特位是1就表明收到了6号信号。
信号是如何产生的?
一个进程收到信号,本质就是该进程内的信号位图被修改了,也就是该进程的数据被修改了,而只有操作系统才有资格修改进程的数据,因为操作系统是进程的管理者。也就是说,信号的产生本质上就是操作系统直接去修改目标进程的task_struct中的信号位图。
注意: 信号只能由操作系统发送,但信号发送的方式有多种。
信号处理常见方式概述
执行该信号的默认处理动作。
提供一个信号处理函数,要求内核在处理该信号时切换到用户态执行这个处理函数,这种方式称为捕捉(Catch)一个信号。
忽略该信号。
在Linux当中,我们可以通过man手册查看各个信号默认的处理动作。
man 7 signal
产生信号
通过终端按键产生信号
当面对下面的死循环程序时,我们都知道可以按Ctrl+C可以终止该进程。
#include <stdio.h>
#include <unistd.h>
int main()
{
while (1){
printf("hello signal!\n");
sleep(1);
}
return 0;
}
但实际上除了按Ctrl+C之外,按Ctrl+\也可以终止该进程。
按Ctrl+C终止进程和按Ctrl+\终止进程,有什么区别?
按Ctrl+C实际上是向进程发送2号信号SIGINT,而按Ctrl+\实际上是向进程发送3号信号SIGQUIT。查看这两个信号的默认处理动作,可以看到这两个信号的Action是不一样的,2号信号是Term,而3号信号是Core。
Term和Core都代表着终止进程,但是Core在终止进程的时候会进行一个动作,那就是核心转储。
什么是核心转储?
在云服务器中,核心转储是默认被关掉的,我们可以通过使用ulimit -a命令查看当前资源限制的设定。
其中,第一行显示core文件的大小为0,即表示核心转储是被关闭的。
我们可以通过ulimit -c size命令来设置core文件的大小。
core文件的大小设置完毕后,就相当于将核心转储功能打开了。此时如果我们再使用Ctrl+\对进程进行终止,就会发现终止进程后会显示core dumped。
并且会在当前路径下生成一个core文件,该文件以一串数字为后缀,而这一串数字实际上就是发生这一次核心转储的进程的PID。
说明一下: ulimit命令改变的是Shell进程的Resource Limit,但myproc进程的PCB是由Shell进程复制而来的,所以也具有和Shell进程相同的Resource Limit值。
核心转储功能有什么用?
当我们的代码出错了,我们最关心的是我们的代码是什么原因出错的。如果我们的代码运行结束了,那么我们可以通过退出码来判断代码出错的原因,而如果一个代码是在运行过程中出错的,那么我们也要有办法判断代码是什么原因出错的。
当我们的程序在运行过程中崩溃了,我们一般会通过调试来进行逐步查找程序崩溃的原因。而在某些特殊情况下,我们会用到核心转储,核心转储指的是操作系统在进程收到某些信号而终止运行时,将该进程地址空间的内容以及有关进程状态的其他信息转而存储到一个磁盘文件当中,这个磁盘文件也叫做核心转储文件,一般命名为core.pid。
而核心转储的目的就是为了在调试时,方便问题的定位。
如何运用核心转储进行调试?
我们用下面这段代码进行演示:
很明显,该代码当中出现了除0错误,该程序运行3秒后便会崩溃。
此时我们便可以在当前目录下看到核心转储时生成的core文件。
使用gdb对当前可执行程序进行调试,然后直接使用core-file core文件命令加载core文件,即可判断出该程序在终止时收到了8号信号,并且定位到了产生该错误的具体代码。
说明一下: 事后用调试器检查core文件以查清错误原因,这种调试方式叫做事后调试。
core dump标志
还记得进程等待函数waitpid函数的第二个参数吗:
pid_t waitpid(pid_t pid, int *status, int options);
waitpid函数的第二个参数status是一个输出型参数,用于获取子进程的退出状态。status是一个整型变量,但status不能简单的当作整型来看待,status的不同比特位所代表的信息不同,具体细节如下(只关注status低16位比特位):
若进程是正常终止的,那么status的次低8位就表示进程的退出状态,即退出码。若进程是被信号所杀,那么status的低7位表示终止信号,而第8位比特位是core dump标志,即进程终止时是否进行了核心转储。
打开Linux的核心转储功能,并编写下列代码。代码中父进程使用fork函数创建了一个子进程,子进程所执行的代码当中存在野指针问题,当子进程执行到*p = 100时,必然会被操作系统所终止并在终止时进行核心转储。此时父进程使用waitpid函数便可获取到子进程退出时的状态,根据status的第7个比特位便可得知子进程在被终止时是否进行了核心转储。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/types.h>
int main()
{
if (fork() == 0){
//child
printf("I am running...\n");
int *p = NULL;
*p = 100;
exit(0);
}
//father
int status = 0;
waitpid(-1, &status, 0);
printf("exitCode:%d, coreDump:%d, signal:%d\n",
(status >> 8) & 0xff, (status >> 7) & 1, status & 0x7f);
return 0;
}
可以看到,所获取的status的第7个比特位为1,即可说明子进程在被终止时进行了核心转储。
因此,core dump标志实际上就是用于表示程序崩溃的时候是否进行了核心转储。
其他组合按键?
我们可以通过以下代码,将1~31号信号全部进行捕捉,将收到信号后的默认处理动作改为打印收到信号的编号。
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
void handler(int signal)
{
printf("get a signal:%d\n", signal);
}
int main()
{
int signo;
for (signo = 1; signo <= 31; signo++){
signal(signo, handler);
}
while (1){
sleep(1);
}
return 0;
}
此时,当我们按下组合按键Ctrl+C、Ctrl+\、Ctrl+Z后,便可以得知这些组合按键分别是向前台进程发送几号信号了。
但如果我们此时向该进程发送9号信号,该进程并不会打印收到了9号信号,而是执行收到9号信号后的默认处理动作,即被终止。
说明: 有些信号是不能被捕捉的,比如9号信号。因为如果所有信号都能被捕捉的话,那么进程就可以将所有信号全部进行捕捉并将动作设置为忽略,此时该进程将无法被杀死,即便是操作系统。
通过系统函数向进程发信号
当我们要使用kill命令向一个进程发送信号时,我们可以以kill -信号名 进程ID的形式进行发送。
也可以以kill -信号编号 进程ID的形式进行发送。
kill函数
实际上kill命令是通过调用kill函数实现的,kill函数可以给指定的进程发送指定的信号,kill函数的函数原型如下:
int kill(pid_t pid, int sig);
kill函数用于向进程ID为pid的进程发送sig号信号,如果信号发送成功,则返回0,否则返回-1。
我们可以用kill函数模拟实现一个kill命令,实现逻辑如下:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <signal.h>
void Usage(char* proc)
{
printf("Usage: %s pid signo\n", proc);
}
int main(int argc, char* argv[])
{
if (argc != 3){
Usage(argv[0]);
return 1;
}
pid_t pid = atoi(argv[1]);
int signo = atoi(argv[2]);
kill(pid, signo);
return 0;
}
为了让生成的可执行程序在执行时不用带上路径,我们可以将当前路径导入环境变量PATH当中。
此时我们便模拟实现了一个kill命令,该命令的使用方式为mykill 进程ID 信号编号。
raise函数
raise函数可以给当前进程发送指定信号,即自己给自己发送信号,raise函数的函数原型如下:
int raise(int sig);
raise函数用于给当前进程发送sig号信号,如果信号发送成功,则返回0,否则返回一个非零值。
例如,下列代码当中用raise函数每隔一秒向自己发送一个2号信号。
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
void handler(int signo)
{
printf("get a signal:%d\n", signo);
}
int main()
{
signal(2, handler);
while (1){
sleep(1);
raise(2);
}
return 0;
}
运行结果就是该进程每隔一秒收到一个2号信号。
abort函数
raise函数可以给当前进程发送SIGABRT信号,使得当前进程异常终止,abort函数的函数原型如下:
void abort(void);
abort函数是一个无参数无返回值的函数。
例如,下列代码当中每隔一秒向当前进程发送一个SIGABRT信号。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
void handler(int signo)
{
printf("get a signal:%d\n", signo);
}
int main()
{
signal(6, handler);
while (1){
sleep(1);
abort();
}
return 0;
}
与之前不同的是,虽然我们对SIGABRT信号进行了捕捉,并且在收到SIGABRT信号后执行了我们给出的自定义方法,但是当前进程依然是异常终止了。
说明一下: abort函数的作用是异常终止进程,exit函数的作用是正常终止进程,而abort本质是通过向当前进程发送SIGABRT信号而终止进程的,因此使用exit函数终止进程可能会失败,但使用abort函数终止进程总是成功的。
由软件条件产生信号
SIGPIPE信号
SIGPIPE信号实际上就是一种由软件条件产生的信号,当进程在使用管道进行通信时,读端进程将读端关闭,而写端进程还在一直向管道写入数据,那么此时写端进程就会收到SIGPIPE信号进而被操作系统终止。
例如,下面代码当中,创建匿名管道进行父子进程之间的通信,其中父进程是读端进程,子进程是写端进程,但是一开始通信父进程就将读端关闭了,那么此时子进程在向管道写入数据时就会收到SIGPIPE信号,进而被终止。
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
int main()
{
int fd[2] = { 0 };
if (pipe(fd) < 0){ //使用pipe创建匿名管道
perror("pipe");
return 1;
}
pid_t id = fork(); //使用fork创建子进程
if (id == 0){
//child
close(fd[0]); //子进程关闭读端
//子进程向管道写入数据
const char* msg = "hello father, I am child...";
int count = 10;
while (count--){
write(fd[1], msg, strlen(msg));
sleep(1);
}
close(fd[1]); //子进程写入完毕,关闭文件
exit(0);
}
//father
close(fd[1]); //父进程关闭写端
close(fd[0]); //父进程直接关闭读端(导致子进程被操作系统杀掉)
int status = 0;
waitpid(id, &status, 0);
printf("child get signal:%d\n", status & 0x7F); //打印子进程收到的信号
return 0;
}
运行代码后,即可发现子进程在退出时收到的是13号信号,即SIGPIPE信号。
SIGALRM信号
调用alarm函数可以设定一个闹钟,也就是告诉操作系统在若干时间后发送SIGALRM信号给当前进程,alarm函数的函数原型如下:
unsigned int alarm(unsigned int seconds);
alarm函数的作用就是,让操作系统在seconds秒之后给当前进程发送SIGALRM信号,SIGALRM信号的默认处理动作是终止进程。
alarm函数的返回值:
若调用alarm函数前,进程已经设置了闹钟,则返回上一个闹钟时间的剩余时间,并且本次闹钟的设置会覆盖上一次闹钟的设置。
如果调用alarm函数前,进程没有设置闹钟,则返回值为0。
例如,我们可以用下面的代码,测试自己的云服务器一秒时间内可以将一个变量累加到多大。
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
int main()
{
int count = 0;
alarm(1);
while (1){
count++;
printf("count: %d\n", count);
}
return 0;
}
运行代码后,可以发现我当前的云服务器在一秒内可以将一个变量累加到两万左右。
但实际上我当前的云服务器在一秒内可以执行的累加次数远大于两万,那为什么上述代码运行结果比实际结果要小呢?
主要原因有两个,首先,由于我们每进行一次累加就进行了一次打印操作,而与外设之间的IO操作所需的时间要比累加操作的时间更长,其次,由于我当前使用的是云服务器,因此在累加操作后还需要将累加结果通过网络传输将服务器上的数据发送过来,因此最终显示的结果要比实际一秒内可累加的次数小得多。
为了尽可能避免上述问题,我们可以先让count变量一直执行累加操作,直到一秒后进程收到SIGALRM信号后再打印累加后的数据。
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
int count = 0;
void handler(int signo)
{
printf("get a signal: %d\n", signo);
printf("count: %d\n", count);
exit(1);
}
int main()
{
signal(SIGALRM, handler);
alarm(1);
while (1){
count++;
}
return 0;
}
此时可以看到,count变量在一秒内被累加的次数变成了近五亿,由此也证明了,与计算机单纯的计算相比较,计算机与外设进行IO时的速度是非常慢的。
由硬件异常产生信号
为什么C/C++程序会崩溃?
当我们程序当中出现类似于除0、野指针、越界之类的错误时,为什么程序会崩溃?本质上是因为进程在运行过程中收到了操作系统发来的信号进而被终止,那操作系统是如何识别到一个进程触发了某种问题的呢?
我们知道,CPU当中有一堆的寄存器,当我们需要对两个数进行算术运算时,我们是先将这两个操作数分别放到两个寄存器当中,然后进行算术运算并把结果写回寄存器当中。此外,CPU当中还有一组寄存器叫做状态寄存器,它可以用来标记当前指令执行结果的各种状态信息,如有无进位、有无溢出等等。而操作系统是软硬件资源的管理者,在程序运行过程中,若操作系统发现CPU内的某个状态标志位被置位,而这次置位就是因为出现了某种除0错误而导致的,那么此时操作系统就会马上识别到当前是哪个进程导致的该错误,并将所识别到的硬件错误包装成信号发送给目标进程,本质就是操作系统去直接找到这个进程的task_struct,并向该进程的位图中写入8信号,写入8号信号后这个进程就会在合适的时候被终止。
那对于下面的野指针问题,或者越界访问的问题时,操作系统又是如何识别到的呢?
#include <stdio.h>
#include <unistd.h>
int main()
{
printf( "I am running. . .\n" );
sleep(3);
int *p = NULL;
*p = 100;
return 0;
}
运行结果:
首先我们必须知道的是,当我们要访问一个变量时,一定要先经过页表的映射,将虚拟地址转换成物理地址,然后才能进行相应的访问操作。
其中页表属于一种软件映射关系,而实际上在从虚拟地址到物理地址映射的时候还有一个硬件叫做MMU,它是一种负责处理CPU的内存访问请求的计算机硬件,因此映射工作不是由CPU做的,而是由MMU做的,但现在MMU已经集成到CPU当中了。
当需要进行虚拟地址到物理地址的映射时,我们先将页表的左侧的虚拟地址导给MMU,然后MMU会计算出对应的物理地址,我们再通过这个物理地址进行相应的访问。
而MMU既然是硬件单元,那么它当然也有相应的状态信息,当我们要访问不属于我们的虚拟地址时,MMU在进行虚拟地址到物理地址的转换时就会出现错误,然后将对应的错误写入到自己的状态信息当中,这时硬件上面的信息也会立马被操作系统识别到,进而将对应进程发送SIGSEGV信号。
总结一下:
C/C++程序会崩溃,是因为程序当中出现的各种错误最终一定会在硬件层面上有所表现,进而会被操作系统识别到,然后操作系统就会发送相应的信号将当前的进程终止。
总结:
今天我们学习了Linux进程信号的相关知识,了解了信号入门,产生信号等 。接下来,我们将继续学习Linux的其他知识。希望我的文章和讲解能对大家的学习提供一些帮助。
当然,本文仍有许多不足之处,欢迎各位小伙伴们随时私信交流、批评指正!我们下期见~