直接查/var/log/messages或dmesg中含segfault的日志可快速定位崩溃进程、地址及指令指针；典型字段包括at（异常地址）、ip（崩溃指令地址）、error（页错误码），结合进程名和内存布局可缩小范围，再用core文件与gdb回溯调用栈深挖根因。
直接看
或
输出，重点抓 kernel 日志里带
关键字的行，就能快速定位到哪次崩溃、哪个进程、什么地址出的问题。
查 kernel 日志里的 segfault 记录
系统内核在进程因段错误被强制终止时，会主动记一条日志。常用两种方式获取：
查系统日志文件：
（CentOS/RHEL）或
（Ubuntu/Debian）
查内核环形缓冲区：
，加
可显示时间戳：
典型输出像这样：
其中关键字段含义：
-
at
后是触发异常的虚拟地址（比如空指针解引用常为
或低地址）
-
ip
是指令指针，即崩溃时正在执行的代码地址
-
error
是页错误码，
表示用户态写访问非法地址，
常见于空指针读
结合进程名和内存布局缩小范围
日志里出现的进程名（如
）和地址范围（如
）很重要：
确认该进程是否是你自己的程序，避免误判为系统服务问题
表示可执行段从
开始、长
字节；用
可反查对应源码行（需带
编译）
如果
落在
、
或其他库地址段（如
），说明可能是 glibc 版本缺陷、内存破坏扩散，或调用了不安全函数（如
写穿缓冲区）
注意 core dump 是否启用，它和日志互补
kernel 日志只告诉你“谁在哪崩了”，但不告诉你“为什么崩”。要深挖原因，得靠 core 文件配合 gdb：
CentOS Linux 7.9.2009
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
下载
先检查是否生成了 core：
，若为
需临时开启：
崩溃后找 core：
（最近 10 分钟内的）
用日志中记录的进程路径和找到的 core 一起调试：
，再输入
看完整调用栈
没有 core 时，日志里的
（栈指针）和
就是唯一线索，务必保留原始二进制和调试符号（
或
编译）。
排查常见诱因，对照日志特征
不同原因在日志中往往有倾向性表现：
空指针解引用
：常见
或
、
等极小地址
数组/缓冲区越界
：
地址看起来“随机”但接近已知变量地址（如离栈顶不远），且常伴随
（写越界）
野指针或 use-after-free
：
地址是明显已释放的堆块地址（如
类似 malloc 返回值），
可能在
后的某次访问
多线程竞态破坏栈
：
值异常（如远小于正常栈范围），或多个线程日志交织出现 segfault
/var/log/messagesdmesgsegfaultgrep "segfault" /var/log/messages/var/log/syslogdmesg | grep -i segfault-Tdmesg -T | grep segfaultApr 15 05:22:33 server kernel: myapp[12345]: segfault at 7f8de69a9e18 ip 00000000004012ab sp 00007fff0ef9d540 error 4 in myapp[400000+13000]046myapp[12345]myapp[400000+13000][400000+13000]0x4000000x13000objdump -d ./myapp | grep "4012ab"-giplibcldlibc-2.12.so[...]strcpyulimit -c0ulimit -c unlimitedfind / -name "core*" -mmin -10 2>/dev/nullgdb /path/to/myapp core.xxxbtspip.debug-gsegfault at 0at 8at 10aterror 4at0x7f...a000ipfreesp