在上一个文章中,关于信号的产生,还有没补充完的,所以在这篇文章补充一下
文章目录
- 1.信号的产生
 - 硬件异常产生信号
 - a/=0问题
 - 验证为8号信号
 
- 野指针问题
 - 验证为11号信号
 
- 核心转储
 - 设置核心转储大小
 - Core与Term的区别
 - 核心转储的作用
 
- 2.信号保存
 - 1. 概念
 - 2. 信号列表
 - 3. 信号处理动作
 
1.信号的产生
硬件异常产生信号
a/=0问题
创建mysignal.cc文件
#include<iostream>
using namespace std;
int main()
{
   int a=10;
   a/=0;
   
   cout<<"div zero"<<endl;
    return 0;
}
 

 使用make 生成可执行程序时,a/=0会报警

 依旧可以生成可执行程序mysignal,但是运行可执行程序会报错
为什么除0就报错了呢?
 当代码除0时,程序运行后就崩溃了,程序运行变为进程,进程运行代码时出现了非法代码,进程退出了

 将内存中的指令数据load到CPU中
 状态寄存器中有比特位表示当前计算的状态
 CPU中有的寄存器保存未来的计算结果,用状态寄存器来表示其计算结果的正确或错误
 状态寄存器中有一个比特位为0/1,表示本次计算是否有溢出问题
 假设本来有32/64位,除0时,导致有更高的进位,计算机识别有溢出了,若溢出,状态寄存器的溢出标记位就会置1
操作系统发现状态寄存器的标记位为1,即识别到硬件异常,从而会立马向目标进程发送信号
 而该信号为:Floating point exception 浮点数异常

 FPE为结尾的正好为8号信号
 除0的本质就是触发硬件(CPU)异常
验证为8号信号
通过设置使进程不退出
 把8进程默认方法变为自定义方法
 
 
再次运行可执行程序就会一直循环打印 ,只能通过其他信号终止进程
为什么会一直循环打印?
 操作系统发现溢出标志位被置1,硬件发生了异常,传给进程8号信号,但是由于8号信号实现自定义方法,进程并没有退出,而溢出标志位属于进程的上下文,一直作为1存在,操作系统就会一直检测到标志位是1,从而一直给进程发8号信号
野指针问题
 
p作为指针变量,有4/8个字节空间
 1是将100作为地址数据写到p变量中
 2是 p作为nullptr,*p取的是内存中的0号地址
 *p=100,相当于向0号地址处写入100,但是0号地址并没有申请过, 所以就造成了野指针问题

 运行可执行程序后,发生段错误
为什么越界会使程序崩溃呢?
 实际上语言上所呈现的地址为虚拟地址

 将虚拟地址通过页表映射到物理内存
 页表查询kv关系,查表的动作是由MMU硬件(内存管理单元)完成的
 将输入数据导入到MMU中,再通过MMU转出
 所以从虚拟地址到物理地址,采用软硬件结合的方式
*p=100,并不是进行写入,而是进行虚拟到物理的转换
 若没有映射关系存在,MMU硬件会报错
 若有映射关系存在,但是没有权限,MMU直接报错
 MMU的报错,会使操作系统识别到,操作系统会找到对应的目标进程中的PCB,发送对应的信号,从而终止进程

 Segmentation fault对应11号信号
验证为11号信号
 
 
执行可执行程序后,会一直无线循环打印
 由于MMU硬件报错没有被修复,一直存在,所以每一次进程被调度,操作系统都会识别到异常,向进程发送11号信号
 导致一直无线循环打印
核心转储
 
在众多信号中,存在Core和Term类型,都可以终止进程
 两者之间有什么区别呢?
 容我慢慢来说
Linux在系统级别提供了一种能力,可以将一个进程异常的时候,
 操作系统可以将该进程在异常的时候,核心代码部分进行核心转储
 (将内存中进程的相关数据,全部dump到磁盘中)
 一般会在当前进程的运行目录下,形成core.pid的二进制文件,如core.pid就被叫做核心转储文件
在云服务器上看不到核心转储文件,因为在云服务器上默认关闭这个功能
输入 ulimit -a 指令
 查看当前系统中特定资源对应的上限
 
core file size 代表核心转储,默认大小为0,不允许当前系统在当前目录下形成core文件
设置核心转储大小
 
通过 ulimit -c +大小,如 core file size大小变为10240
Core与Term的区别
 
通过复制SSH渠道,创建终端2

 2号信号对应Term ,终止进程

 在终端1中运行可执行程序,在终端2中发送2号信号干掉进程
 
当干掉进程后,并没有发现以pid结尾的文件
 说明使用Term类型的信号,干掉进程后,不发生核心转储

 8号信号 Core,浮点数异常

 在终端1中运行可执行程序,在终端2中发送8号信号干掉进程,并出现core dump即核心转储

 再次使用 ls -l 指令,发现多出来一个 core.2257的文件 即核心转储文件
Term:终止就是终止,没有多余动作
 Core:终止,会先进行核心转储,在终止进程
核心转储的作用
方便异常后,进行调试

 为了让代码从release变为debug,所以在makefile中 加入 -g
 如果不懂请看 : gdb调试器的使用

 输入 gdb 可执行程序 进入gdb调试器
 再次输入 core-file +core文件
 gdb直接定位到当前进程终止是因为8号信号,信号的更详细描述为 Arithmetic exception
core文件的作用:
 不用自己定位了,有gdb自动定位,事后调试
核心转储为什么一般都是被关闭的?
 云服务器属于生产环境即测试测过以后真正的做服务的

 core.6288文件的大小为232字节,核心转储的文件往往比较大一些
 线上部署的某种服务可能会挂掉,不断进行挂掉重启就会不断形成core dump文件,就有可能导致主机挂掉
2.信号保存
1. 概念
1.实际执行信号的处理动作被称为 信号递达
 2.信号从产生到递达之间的状态,称为信号未决
 3.进程可以选择 阻塞某个信号
假设你不太喜欢一个老师,所以当一个老师留作业时,你只是把作业是什么记录下来,因为你当前正在上课,没有时间去写作业,只有当下午找个时间去写作业
 老师布置作业的行为就是操作系统发信号的过程,你作为一个进程,当前因为做优先级更高的事情正在上课,所以没有时间处理信号,只能把作业记下来,等有时间在写作业 ,即递达信号
4.被阻塞的信号产生时将保持未决状态,直到进程解除对此信号的阻塞才执行的递达动作
假设有老师ABC,每个人都留了作业,由于老师AB对你很好,所以你打算先写AB老师留的作业,但是你不太喜欢老师C,所以就不愿意老师C的作业,宁愿去打游戏,所以你把老师C给你留的作业未决了
 由于你并不会递达它,所以你把老师C的作业阻塞了
 突然有一天,你喜欢老师C了,所以开始想写老师C留的作业,即解除阻塞,写完作业即递达
5.阻塞和忽略是不同的,只要信号被阻塞就不会递达,而忽略是在递达之后的可选的一种处理工作
同样有一个老师,布置作业后,你记录下来了,可是这个老师平时不查作业,所以直接把这个作业划掉,默认写完了,即忽略该信号
忽略是把作业划掉,默认写完了也就完成了递达动作
 而阻塞是把作业记录下来了,不想去写作业,即没有完成也就没有递达动作
2. 信号列表

 pending 表:位图结构
 比特位的位置表示哪一个信号
 比特位的内容表示是否收到该信号
 如:00000000…0001000 代表收到4号信号
bolck 表:位图结构
 比特位的位置表示哪一个信号
 比特位的内容代表是否对应的信号被阻塞
 如:0000000…0010 代表2号信号被屏蔽
handler表:函数指针数组

 返回值为void,参数为int的函数指针
 该数组的下标表示信号编号
 数组的特定下标的内容表示该信号的递达动作
3. 信号处理动作
除了自定义捕捉外,还有SIG_DFL(默认动作)与SIG_IGN(忽略信号)
 

 把0强制转化成函数指针类型 即默认情况 终止进程
 对2号信号进行SIG_DFL即默认处理

运行可执行程序后,使用2号信号可终止进程
 

 把1强制转化成函数指针类型 即忽略信号
 对2号信号做忽略

 忽略信号,所以对其做什么动作都没有用了



















