段错误可通过启用核心转储并用GDB分析定位。首先使用ulimit -c unlimited开启core dump，配置/proc/sys/kernel/core_pattern设置文件路径格式，确保程序编译时包含-g选项以保留调试信息。程序崩溃后，用gdb [可执行文件] [core文件]加载转储，执行bt查看调用栈，结合frame、print、list等命令定位非法内存访问位置。常见原因包括空指针解引用、数组越界、使用已释放内存和函数指针错误，需结合寄存器与变量状态综合判断。
程序出现段错误（Segmentation Fault）是开发中常见的问题，通常由非法内存访问引起。Linux 提供了核心转储（Core Dump）机制配合 GDB 调试工具，可以高效定位段错误根源。以下是完整的分析流程和实用方法。
启用核心转储功能
默认情况下，部分系统可能禁用核心转储。需手动开启才能生成崩溃时的内存快照。
• 检查当前限制：ulimit -c若返回 0，表示未启用。
• 临时开启（当前会话有效）：
ulimit -c unlimited• 永久开启：编辑 /etc/security/limits.conf，添加：
* soft core unlimited重启或重新登录后生效。
* hard core unlimited
配置核心转储文件命名与路径
通过 kernel.core_pattern 控制生成的核心文件名和位置，便于管理。
• 查看当前模式：cat /proc/sys/kernel/core_pattern• 设置自定义路径（如 /tmp/core.%e.%p.%t）：
echo "/tmp/core.%e.%p.%t" | sudo tee /proc/sys/kernel/core_pattern%e 程序名，%p 进程 ID，%t 时间戳，方便区分不同崩溃事件。
使用 GDB 分析核心转储文件
当程序崩溃并生成 core 文件后，可用 GDB 加载进行分析。
• 假设程序名为 a.out，core 文件为 core.1234：
gdb a.out core.1234GDB 启动后会自动显示崩溃时的调用栈。
• 常用调试命令：
- bt：打印完整 backtrace，查看函数调用链
- frame N：切换到指定栈帧
- info registers：查看寄存器状态
- print 变量名：输出变量值（在对应栈帧中）
- list：显示崩溃点附近的源码
常见段错误原因及排查线索
结合 GDB 信息可快速判断典型问题。
• 空指针解引用：bt 显示某函数访问结构体成员时崩溃，print 指针值为 0。
• 数组越界或栈溢出：
访问地址异常高或低，可能破坏了栈帧，GDB 中 frame 切换失败。
• 使用已释放内存：
指向堆内存的指针在 free 后仍被使用，valgrind 更易捕捉此类问题。
• 函数指针错误：
crash 在非预期地址执行，info registers 查看 rip/eip 寄存器值是否合理。
基本上就这些。只要开启 core dump 并保留带符号表的可执行文件，GDB 就能准确还原崩溃现场。关键是养成编译时加 -g 选项的习惯，并在生产环境合理配置日志与转储策略。整个过程不复杂，但容易忽略细节导致无法生成 core 文件。
