?前言
硬件异常被硬件以某种⽅式被硬件检测到并通知内核,然后内核向当前进程发送适当的信号。例如当前进程执⾏了除以0的指令,cpu的运算单元会产⽣异常,内核将这个异常解释为sigfpe信号发送给进程。再⽐如当前进程访问了⾮法内存地址,mmu会产⽣异常,内核将这个异常解释为sigsegv信号发送给进程。
?模拟除0
代码语言：javascript代码运行次数：0运行复制
#include #include #include #include #include int main(){ if(fork() == 0) { sleep(1); int a = 10; a /= 0; exit(0); } int status = 0; waitpid(-1, &status, 0); printf("exit sinal: %d, core dump: %dn", status&0x7F,(status>>7)&1); return 0;}
?除0出错？
操作系统如何检测进程内部错误 当进程执行指令时，CPU 硬件会在执行某些操作（如除法运算）的过程中检查操作数是否合法。以整数除法为例，CPU 的算术逻辑单元（ALU）在执行除法操作时，会检查除数是否为零。如果除数为零，这是一种非法的算术操作，硬件会自动触发一个异常条件。
整个程序的执行流程是：
首先,在地址内存空间中加载好了代码和数据，开始：通过地址寄存器eax进行存储操作，存储10,存储时将寄存器ebx的值设为0。CPU中存在一个状态寄存器,称为eFlags寄存器。
CPU的算术逻辑单元(ALU)在执行操作时,会检查除数是否为0。如果除数为0,这是一种非法操作,会触发异常条件。此时,硬件会将状态eFlags寄存器中的溢出标志位置为1。
OS系统要不要知道CPU(硬件)内部出错了? 操作系统需要知道CPU内部出现了错误。它可以通过找到引发异常的进程,然后向该进程发送信号来终止该进程。但即使进程被杀死,其他进程仍需要进行调度和上下文切换等操作。
OS会说：谁把我的CPU搞坏了，接下来就要通过信号杀掉进程!，那OS怎么知道是哪个信号？此时进程中，我们把8号信号补捉了，但是我们进程没有立刻退出，立刻被杀掉！因为进程还需要进行被OS调度：切换（保存上下文数据），进行（比如后续的代码操作）等等
当这个异常进程被杀死前，OS需要保存上下文数据，保证下次再调用时恢复。因此，在上下文切换时,需要保存eax，ebx，ecx，eFlags等一系列寄存器的值。当保存好后，OS调度下一个进程，CPU寄存器只有一套，把上下文数据恢复进来，这时，Efalgs标志位被恢复，溢出标志位一直都是1~这个时候，这个进程又开始死循环异常。
总结： 无论OS需要等待该死循环进程结束后，进程假如后面还有代码，没有退出，再进行后面代码处理，Efalgs标志位，溢出标志位一直都是1~，一样死循环。当重新进来下一个进程，恢复执行时,上下文数据，Efalgs标志位被恢复，溢出标志位一直都是1，会再次触发异常,陷入死循环。
巧文书
巧文书是一款AI写标书、AI写方案的产品。通过自研的先进AI大模型，精准解析招标文件，智能生成投标内容。
61 查看详情 
总的来说,这段描述了CPU发生除零错误时的异常处理流程,包括硬件触发异常、OS发现错误、终止异常进程,以及进程切换时上下文保存等步骤。整个过程涉及CPU硬件和操作系统的协作。
?野指针异常?
首先数据和代码在磁盘中，然后磁盘的随物理地址加载到物理内存中，物理内存中也有地址，这个地址为虚拟地址，页表右边是虚拟地址，左边是物理地址。pc存放的下一条执行指令的虚拟，经过pc指令传递给MMU硬件和CR3命令的处理，虚拟地址就可以找到页表的右边的物理地址，当除0这个指令传递给MMU去查页表时，访问0号地址，但是零号地址是无法访问的，这个时候MMU开始出错，一出错，找到这个进程，处理这个进程，进程还不能退出，后续代码也许需要执行，OS需要对进程进行调度，切换，执行，而MMU也有一套寄存器，当这个寄存器除以0出错之后，然后寄存器喵喵也会进行上下文的数据保存。保存之后，他就即使OS调度下一个进程，或者切换这个状态，寄存器状态一直同样也为一，MMU会一直报错，然后就会进程异常终止，但一直没退出。
总结： 由此可以确认，我们在C/C++当中除零，内存越界等异常，在系统层⾯上，是被当成信号处理的。
注意： 通过上⾯的实验，我们可能发现： 发现⼀直有8号信号产⽣被我们捕获，这是为什么呢？上⾯我们只提到CPU运算异常后，如何处理后续的流程，实际上OS会检查应⽤程序的异常情况，其实在CPU中有⼀些控制和状态寄存器，主要⽤于控制处理器的操作，通常由操作系统代码使⽤。状态寄存器可以简单理解 为⼀个位图，对应着⼀些状态标记位、溢出标记位。OS会检测是否存在异常状态，有异常存在就会调⽤对应的异常处理⽅法。
除零异常后，我们并没有清理内存，关闭进程打开的⽂件，切换进程等操作，所以CPU中还保留上下⽂数据以及寄存器内容，除零异常会⼀直存在，就有了我们看到的⼀直发出异常信号的现象。访问⾮法内存其实也是如此，⼤家可以⾃⾏实验。
?⼦进程退出coredump
代码语言：javascript代码运行次数：0运行复制
int main(){ if(fork() == 0) { sleep(1); int a = 10; a /= 0; exit(0); } int status = 0; waitpid(-1, &status, 0); printf("exit sinal: %d, core dump: %dn", status&0x7F,(status>>7)&1); return 0;}指令：wks@hcss-ecs-ab43:~/code/signal24$ man 7 signal
代码语言：javascript代码运行次数：0运行复制
Standard signals Linux supports the standard signals listed be‐ low. The second column of the table indicates which standard (if any) specified the signal: "P1990" indicates that the signal is described in the original POSIX.1-1990 standard; "P2001" indicates that the signal was added in SUSv2 and POSIX.1-2001. "P1990" indicates that the signal is described in the original POSIX.1-1990 standard; "P2001" indicates that the signal was added in SUSv2 and POSIX.1-2001. Signal Standard Action Comment ──────────────────────────────────────────────────────────────────────── SIGABRT P1990 Core Abort signal from abort(3) SIGALRM P1990 Term Timer signal from alarm(2) SIGBUS P2001 Core Bus error (bad memory access) SIGCHLD P1990 Ign Child stopped or terminated SIGCLD - Ign A synonym for SIGCHLD SIGCONT P1990 Cont Continue if stopped SIGEMT - Term Emulator trap SIGFPE P1990 Core Floating-point exception SIGHUP P1990 Term Hangup detected on controlling terminal or death of controlling process SIGILL P1990 Core Illegal Instruction SIGINFO - A synonym for SIGPWR SIGINT P1990 Term Interrupt from keyboard SIGIO - Term I/O now possible (4.2BSD) SIGIOT - Core IOT trap. A synonym for SIGABRT SIGKILL P1990 Term Kill signal SIGLOST - Term File lock lost (unused) SIGPIPE P1990 Term Broken pipe: write to pipe with no readers; see pipe(7) SIGPOLL P2001 Term Pollable event (Sys V); synonym for SIGIO SIGPROF P2001 Term Profiling timer expired SIGPWR - Term Power failure (System V) SIGQUIT P1990 Core Quit from keyboard SIGSEGV P1990 Core Invalid memory reference SIGSTKFLT - Term Stack fault on coprocessor (unused) SIGSTOP P1990 Stop Stop process SIGTSTP P1990 Stop Stop typed at terminal SIGSYS P2001 Core Bad system call (SVr4); see also seccomp(2) SIGTERM P1990 Term Termination signal SIGTRAP P2001 Core Trace/breakpoint trap SIGTTIN P1990 Stop Terminal input for background process SIGTTOU P1990 Stop Terminal output for background process SIGUNUSED - Core Synonymous with SIGSYS SIGURG P2001 Ign Urgent condition on socket (4.2BSD) SIGUSR1 P1990 Term User-defined signal 1 SIGUSR2 P1990 Term User-defined signal 2 SIGVTALRM P2001 Term Virtual alarm clock (4.2BSD) SIGXCPU P2001 Core CPU time limit exceeded (4.2BSD); see setrlimit(2) SIGXFSZ P2001 Core File size limit exceeded (4.2BSD); see setrlimit(2) SIGWINCH - Ign Window resize signal (4.3BSD, Sun) The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
?Core Dump
SIGINT的默认处理动作是终止进程,SIGQUIT的默认处理动作是终止进程并且Core Dump,现在我们来验证一下。⾸先解释什么是CoreDump。当⼀个进程要异常终⽌时,可以选择把进程的⽤⼾空间内存数据全部保存到磁盘上,⽂件名通常是core,这叫做CoreDump。进程异常终⽌通常是因为有Bug,⽐如⾮法内存访问导致段错误,事后可以⽤调试器检查core⽂件以查清错误原因,这叫做Post-mortem Debug （事后调试）。一个进程允许产生多大的core文件取决于进程的Resource Limit(这个信息保存在PCB中)。默认是不允许产生core文件的,因为core文件中可能包含用户密码等敏感信息,不安全。在开发调试阶段可以用ulimit命令改变这个限制,允许产生core文件。首先用ulimit|命令改变shell进程的Resource Limit ,如允许core|文件最大为1024K: $ ulimit -c1024
core-file core :事后调试
?总结
以上就是【linux学习指南】Linux进程信号产生(三) 硬件异常&&除零出错？&&野指针异常？&&core文件的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/431570.html
微信扫一扫 
支付宝扫一扫 
