您的位置:首页 >Linux怎么查看具体的系统崩溃堆栈
发布于2026-08-12 阅读(0)
扫一扫,手机访问
要快速判断问题方向,最直接的办法就是去看/var/crash/最新子目录里dmesg.*文件的最后50行。这里往往最容易暴露panic或Oops的线索,像“Kernel panic - not syncing”“Oops”“Call Trace:”这类关键词,基本一眼就能锁定重点。很多时候,90%的根因就藏在这几行里。

先去看 /var/crash/ 下面最新那个子目录里的 dmesg.* 文件,这基本就是系统崩溃前内核留下的实时日志快照。先别急着上 crash 工具,很多时候真正有用的线索,十有八九就埋在最后几十行里,比如 Kernel panic - not syncing、Oops、Call Trace: 这些关键信息。
执行:cat /var/crash/$(ls -t /var/crash | head -n1)/dmesg.* | tail -n 50
BUG: unable to handle kernel NULL pointer dereference 这类提示,说明是空指针解引用,直接往下找 Call Trace: 后面的函数链IP: 后面的地址是出问题的指令位置,SP: 是栈顶地址,这两个值后续用 crash 时会用到dmesg 尾部时间跳变过大,说明日志可能被截断,得结合 journalctl -b -1 补充看上一次 boot 的日志crash 不是万能日志阅读器,它是用来解析 vmcore 内存镜像的交互式调试器。必须满足两个硬条件:有对应内核版本的 vmlinux 符号文件 + 正确加载了 dump.XXXX 文件。
进入崩溃目录后,运行:crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux dump.XXXX
bt ——这是最常用命令,显示当前 CPU 上崩溃线程的完整调用栈,包括函数名、偏移、源码行号(如果有 debuginfo)bt 输出里全是十六进制地址没函数名,说明 vmlinux 路径不对或 debuginfo 包没装全;查路径用 find /usr/lib/debug -name vmlinux 2>/dev/nullbt 1234;想看所有 CPU 的栈,用 bt -a系统还在跑、但已出现异常(比如软锁死、高延迟),又没配 kdump,可以用 SysRq 触发即时堆栈打印。前提是 /proc/sys/kernel/sysrq 值为 1(默认多数发行版开启)。
物理机或带控制台的虚拟机上操作:
按住 Alt + SysRq(即 Print Screen 键),松开后立刻按 t(小写)
dmesg 缓冲区,立刻执行 dmesg | tail -n 100 查看,里面会有每个 CPU 的 Call Trace:SysRq 可能失效SysRq,检查 cat /proc/sys/kernel/sysrq 返回值,不是 1 就得先 echo 1 > /proc/sys/kernel/sysrq(需 root)内核崩溃和用户程序崩溃是两套机制。用户态程序(如 nginx、python 脚本)崩溃,靠的是 core dump,不是 vmcore。
确认 core 生成已开启:ulimit -c 必须非 0(推荐 ulimit -c unlimited);sysctl kernel.core_pattern 看路径,常见值如 core.%e.%p 或 /var/lib/core/core.%e.%p
gdb ./your_program core.xxx,然后输 bt 查看用户态调用栈bt 显示一堆 ??,说明编译时没加 -g,或者符号被 strip 过;release 版本建议保留 .debug 段或单独存符号文件addr2line -e ./your_program -f -C 0x7f8b12345678 可把任意地址转成函数+行号,前提是二进制含调试信息真正麻烦的不是怎么查,而是堆栈里混着内核态和用户态上下文——比如系统调用陷入内核后 panic,这时候得先用 crash 看内核栈,再用 gdb 对应 core 看用户态现场,两者地址空间完全独立,不能交叉解析。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
4
5
6
7
8
9