直接查/var/log/messages（RHEL/CentOS）或/var/log/syslog（Ubuntu/Debian），以及运行dmesg -T | grep segfault，可快速定位段错误的进程名、异常地址（at）、指令指针（ip）和错误码（error）；结合core文件与gdb回溯调用栈才能深挖根因。
直接查 /var/log/messages（RHEL/CentOS）或 /var/log/syslog（Ubuntu/Debian），以及运行 dmesg | grep -i segfault，就能快速定位哪个进程、在什么地址、因哪条指令触发了段错误。日志只告诉你“崩在哪”，配合 core 文件和调试工具才能知道“为什么崩”。
抓取内核记录的 segfault 日志
Linux 内核在进程因非法内存访问被终止时，会主动写入一条日志。两种最常用方式：
- 查系统日志文件：
grep "segfault" /var/log/messages（CentOS/RHEL）或grep "segfault" /var/log/syslog（Ubuntu/Debian） - 查内核环形缓冲区：
dmesg -T | grep segfault（-T加时间戳，方便关联故障时刻）
典型输出如：Jul 28 14:22:03 host app[12345]: segfault at 0 ip 00000000004012ab sp 00007fffabcd1230 error 4 in app[400000+13000]
解读日志关键字段含义
每条 segfault 日志都含几个核心字段，必须看懂：
- at 后是触发异常的虚拟地址：0 或低地址常为空指针解引用；高位地址可能是野指针或已释放内存
-
ip 是指令指针（崩溃时正在执行的代码地址）：结合二进制可反查源码行（需带
-g编译） - error 是页错误码：4 表示用户态写非法地址，6 常见于空指针读操作
- 方括号中
app[400000+13000]表示该进程可执行段基址与长度，可用于判断 ip 是否落在主程序内
结合进程名和内存布局缩小范围
光看地址不够，要联系上下文判断问题归属：
- 确认日志中的进程名（如
app[12345]）是否为你部署的应用，避免误判为 systemd 或 libc 等系统组件问题 - 若
ip落在libc、ld-linux或其他库范围内（如libc-2.31.so[7f8a12345000+200000]），说明可能有内存越界破坏了堆栈或函数指针 - 用
objdump -d ./app | grep 4012ab可定位对应汇编指令；若带调试符号，再用addr2line -e ./app -f -C 0x4012ab直接得到源码行
用 core 文件 + gdb 深挖调用栈
日志只能定位到崩溃点，真正根因得靠 core 文件回溯：
- 先检查 core 是否启用：
ulimit -c，若为 0 需临时开启：ulimit -c unlimited - 崩溃后找最近生成的 core：
find /tmp /var/tmp / -name "core*" -mmin -5 2>/dev/null - 用日志中进程的绝对路径和找到的 core 启动 gdb：
gdb /path/to/app core.xxx，再输入bt full查看完整调用栈和变量值 - 若没生成 core，
sp（栈指针）和ip就是唯一线索，务必保留原始二进制及调试符号文件
