【Linux】段错误（核心已转储）（core dumped）问题的分析方法

😎 作者介绍：我是程序员洲洲，一个热爱写作的非著名程序员。CSDN全栈优质领域创作者、华为云博客社区云享专家、阿里云博客社区专家博主。
🤓 同时欢迎大家关注其他专栏，我将分享Web前后端开发、人工智能、机器学习、深度学习从0到1系列文章。
🌼 同时洲洲已经建立了程序员技术交流群，如果您感兴趣，可以私信我加入社群，可以直接vx联系（文末有名片）v：bdizztt
🖥 随时欢迎您跟我沟通，一起交流，一起成长、进步！点此也可获得联系方式~

前言

在Linux系统中，程序运行时可能会遇到段错误（Segmentation Fault），这是一种常见的运行时错误，通常由于程序试图访问其内存空间中未分配（或不允许）的部分时发生。

当段错误发生时，系统可能会生成一个核心转储（core dump），它是一个包含程序终止时的内存映像的文件，可以用于后续的调试和问题分析。


本文将探讨如何分析段错误，并利用核心转储文件定位问题。

一、段错误概述

段错误发生的原因可能包括但不限于：

• 指针访问无效的内存地址。
• 栈溢出，例如递归调用太深。
• 违反了内存保护规则。
• 内存越界(数组越界，变量类型不一致等) 访问到不属于你的内存区域。
• 访问系统数据区，尤其是往系统保护的内存地址写数据，最常见的就是给一个指针以0地址。
• 多线程程序使用了线程不安全的函数。
• 多线程读写的数据未加锁保护。对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成core dump
• 随意使用指针转换。一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时 就很容易因为bus error而core dump.
• 缓存溢出也可能引起“段错误”，对于这种while(1) {do}的程序，这个问题最容易发生，多此sprintf或着strcat有可能将某个buff填满，溢出，所以每次使用前，最好memset一下，不过 要是一开始就是段错误，而不是运行了一会儿出现的，缓存溢出的可能性就比较小。

段错误就是指访问的内存超出了系统所给这个程序的内存空间，通常这个值是由gd tr来保存的，他是一个48位的寄存器，其中的32位是保存由它指向的 gdt表，后13位保存 相应于gdt的下标，最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别，指向 的gdt是由以64位为一个单位的表，在这张表中就保存着程序运行的代码段以及数据段的

一旦一个程序发生了越界访问，cpu就会产生相应的保护，于是segmentation fault就出现了通过上面的解释，段错误应该就是访问了不可访问的内存，这个内存区要么是不存在的，要么是受到系统保护的，还有可能是缺少文件或者文件损坏。# 二、核心转储文件

当程序因段错误而终止时，如果系统配置允许生成核心转储，将创建一个core文件（或类似的命名模式），这个文件包含了程序终止时的内存映像。

核心转储的配置

其实系统会在程序崩溃的那一刹那将整个内核的信息记录在一个文件里边，（ls 并不会看到这个文件）

确保/proc/sys/kernel/core_pattern配置允许生成核心转储文件。

设置ulimit以允许生成核心文件：

/etc/profile中加入以下一行，这将允许生成coredump文件
ulimit-c unlimited

编译的时候一定要加入-g选项，要不然在最后显示错误的时候只会显示错的地址，而不会显示错误的具体信息。

/proc/sys/kernel/core_uses_pid可以控制core文件的文件名中是否添加pid作为扩展。文件内容为1，表示添加pid作为扩展名，生成的core文件格式为core.xxxx；为0则表示生成的core文件同一命名为core。

可通过以下命令修改此文件：

echo "1" > /proc/sys/kernel/core_uses_pid

一般core路径和可执行程序一个路径。

除此之外，还可以在/proc/sys/kernel/core-pattern里设置core文件的文件名模板。

echo /data/coredump/core.%e.%p> /proc/sys/kernel/core_pattern

三、分析段错误的步骤

1. 确认核心转储文件的存在
   当程序崩溃时，检查当前目录或core_pattern指定的位置是否有核心转储文件生成。

2. 使用调试器分析核心转储
   使用gdb（GNU Debugger）或其他调试器加载核心转储文件和相应的程序可执行文件，分析崩溃时的调用栈和变量状态。

gdb /path/to/program /path/to/coredump

3. 检查调用栈
   在gdb中，使用backtrace（或简写为bt）命令查看崩溃时的调用栈。

4. 检查变量和寄存器状态
   使用print（或简写为p）命令检查特定变量的值，使用info registers查看寄存器状态。

5. 逐行检查源代码
   根据调用栈信息，定位到源代码中的具体行号，检查相关代码逻辑。

6. 考虑内存访问模式
   分析程序的内存访问模式，检查是否有越界访问、错误的指针操作等。

7. 运行时环境检查
   确认程序运行时的配置和环境是否可能导致段错误。

8. 编译器和链接器选项
   使用-g选项编译程序，确保调试信息的完整性。使用valgrind等工具检查内存错误。

注意事项

• 及时更新系统和工具：确保使用的是最新版本的操作系统、编译器和调试工具。
• 详细记录错误信息：记录段错误发生时的完整堆栈跟踪和其他相关信息。
• 多角度分析：从代码、数据和运行环境多个角度分析问题。

总结

📝Hello，各位看官老爷们好，我已经建立了CSDN技术交流群，如果你很感兴趣，可以私信我加入我的社群。

📝社群中不定时会有很多活动，例如每周都会包邮免费送一些技术书籍及精美礼品、学习资料分享、大厂面经分享、技术讨论谈等等。

📝社群方向很多，相关领域有Web全栈（前后端）、人工智能、机器学习、自媒体副业交流、前沿科技文章分享、论文精读等等。

📝不管你是多新手的小白，都欢迎你加入社群中讨论、聊天、分享，加速助力你成为下一个大佬！

📝想都是问题，做都是答案！行动起来吧！欢迎评论区or后台与我沟通交流，也欢迎您点击下方的链接直接加入到我的交流社群！~ 跳转链接社区~