直接查/var/log/messages或dmesg中含segfault的日志可快速定位崩溃进程、地址及指令指针；典型字段包括at（异常地址）、ip（崩溃指令地址）、error（页错误码），结合进程名和内存布局可缩小范围，再用core文件与gdb回溯调用栈深挖根因。
直接看 /var/log/messages 或 dmesg 输出，重点抓 kernel 日志里带 segfault 关键字的行，就能快速定位到哪次崩溃、哪个进程、什么地址出的问题。
查 kernel 日志里的 segfault 记录
系统内核在进程因段错误被强制终止时，会主动记一条日志。常用两种方式获取：
- 查系统日志文件：
grep "segfault" /var/log/messages（CentOS/RHEL）或/var/log/syslog（Ubuntu/Debian） - 查内核环形缓冲区：
dmesg | grep -i segfault，加-T可显示时间戳：dmesg -T | grep segfault
典型输出像这样：Apr 15 05:22:33 server kernel: myapp[12345]: segfault at 7f8de69a9e18 ip 00000000004012ab sp 00007fff0ef9d540 error 4 in myapp[400000+13000]
其中关键字段含义：
- at 后是触发异常的虚拟地址（比如空指针解引用常为 0 或低地址）
- ip 是指令指针，即崩溃时正在执行的代码地址
- error 是页错误码，4 表示用户态写访问非法地址，6 常见于空指针读
结合进程名和内存布局缩小范围
日志里出现的进程名（如 myapp[12345]）和地址范围（如 myapp[400000+13000]）很重要：
- 确认该进程是否是你自己的程序，避免误判为系统服务问题
-
[400000+13000]表示可执行段从0x400000开始、长0x13000字节；用objdump -d ./myapp | grep "4012ab"可反查对应源码行（需带-g编译） - 如果
ip落在libc、ld或其他库地址段（如libc-2.12.so[...]），说明可能是 glibc 版本缺陷、内存破坏扩散，或调用了不安全函数（如strcpy写穿缓冲区）
注意 core dump 是否启用，它和日志互补
kernel 日志只告诉你“谁在哪崩了”，但不告诉你“为什么崩”。要深挖原因，得靠 core 文件配合 gdb：
- 先检查是否生成了 core：
ulimit -c，若为0需临时开启：ulimit -c unlimited - 崩溃后找 core：
find / -name "core*" -mmin -10 2>/dev/null（最近 10 分钟内的） - 用日志中记录的进程路径和找到的 core 一起调试：
gdb /path/to/myapp core.xxx，再输入bt看完整调用栈
没有 core 时，日志里的 sp（栈指针）和 ip 就是唯一线索，务必保留原始二进制和调试符号（.debug 或 -g 编译）。
排查常见诱因，对照日志特征
不同原因在日志中往往有倾向性表现：
-
空指针解引用：常见
segfault at 0或at 8、at 10等极小地址 -
数组/缓冲区越界：
at地址看起来“随机”但接近已知变量地址（如离栈顶不远），且常伴随error 4（写越界） -
野指针或 use-after-free：
at地址是明显已释放的堆块地址（如0x7f...a000类似 malloc 返回值），ip可能在free后的某次访问 -
多线程竞态破坏栈：
sp值异常（如远小于正常栈范围），或多个线程日志交织出现 segfault
