进程崩溃的根本原因（结合底层分析）

我们在使用VS出现程序崩溃的时候，程序出错时会显示错误信息，会定位到哪一行出错。下面我们将在Linux系统下分析进程崩溃的原因是什么？怎么知道哪一行崩溃了？

---

目录

一、进程崩溃的根本原因（结合底层分析）

二、如何知道哪一行崩溃了？

1、查看系统资源

2、运行程序

 3、使用core文件定位崩溃所在行

---

一、进程崩溃的根本原因（结合底层分析）

开始运行以后，用户层的代码加载到内存中，进程被创建出来让CPU开始运行，CPU中有一个状态寄存器，记录着计算结果，这个时候计算出错，错误信息会记录在状态寄存器中

OS作为硬件的管理者，硬件的状态异常，OS会立马识别到，然后OS就会循着路径，反过来知道这份代码是哪个进程的，那就说明这个进程的代码有问题，所以OS会给这个进程发送一个信号来中止这个进程

此时父进程也就是bash通过waitpid获取到子进程的状态码status，status & 0x7F就是中止信号，中止信号对应的内容就是我们所看到的错误信息

注意：如果有必要，OS还会设置退出信息中的core dump标志位，core dump标志位默认是0，当被设置为1的时候，OS会将进程中的数据转储到磁盘，生成一个名为core的文件，方便我们后期调试。并非每种中止信号都会设置core dump标志位

二、如何知道哪一行崩溃了？

要想知道具体是哪一行崩溃了，关键在于上面的core dump生成的core文件，8号信号和11号信号会生成core文件，我们先编写一个浮点数运算错误，故意让进程崩溃。下面就来了解如何通过core文件知道哪一行崩溃了

1、查看系统资源

在命令行输入 ulimit -a查看系统资源，我们会发现系统没有给core文件分配空间，这样的话，core dump的标志位在任何情况下都是 0 ，即不存储核心数据。

 所以我们手动分配一下core文件的大小，在命令行输入 ulimit -c 1024，这里的 -c 是core file size 对应的选项，我们可以使用这个选项修改大小，然后我们再重新看一下系统资源，这个时候core文件默认大小就被设置成了1024 （ 注意：core文件最大不超过1024K）

2、运行程序

make出错先暂时无视，因为还是会正常生成 执行文件，然后我们直接运行这个执行文件，和之前相比多了“core dumped”，说明核心数据被存起来了

 我们在当前目录下，就会看到core文件了

 3、使用core文件定位崩溃所在行

其实本质上还是要通过gdb调试来定位，所以我们要在Makefile中加一个 -g 来显示详细的调试信息

（1） 重新make一下

（2） 命令行输入 gdb ./test 进入调试模式

（3） 输入core-file命令来解析core文件，即core-file  core.5405