要快速判断问题方向，最直接的办法就是去看/var/crash/最新子目录里dmesg.*文件的最后50行。这里往往最容易暴露panic或Oops的线索，像“Kernel panic - not syncing”“Oops”“Call Trace:”这类关键词，基本一眼就能锁定重点。很多时候，90%的根因就藏在这几行里。
崩溃后怎么快速定位 panic 或 Oops 行？
先去看 /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时会用到- 注意时间戳是否连续——有些系统在 panic 前会卡住几秒，
dmesg尾部时间跳变过大，说明日志可能被截断，得结合journalctl -b -1补充看上一次 boot 的日志
crash 工具里怎么看进程级堆栈？
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/null - 想看特定进程（比如 PID=1234）的栈，用
bt 1234；想看所有 CPU 的栈，用bt -a
没 kdump 怎么临时抓内核堆栈？
系统还在跑、但已出现异常（比如软锁死、高延迟），又没配 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
- 找到 core 文件后，用
gdb ./your_program core.xxx，然后输bt查看用户态调用栈 - 如果
bt显示一堆??，说明编译时没加-g，或者符号被 strip 过；release 版本建议保留.debug段或单独存符号文件 addr2line -e ./your_program -f -C 0x7f8b12345678可把任意地址转成函数+行号，前提是二进制含调试信息
真正麻烦的不是怎么查，而是堆栈里混着内核态和用户态上下文——比如系统调用陷入内核后 panic，这时候得先用 crash 看内核栈，再用 gdb 对应 core 看用户态现场，两者地址空间完全独立，不能交叉解析。
