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:终止，会先进行核心转储，在终止进程
