扫码关注
Linux崩溃定位题考的是日志阅读和证据链。要能从panic/oops上下文、Call Trace、PC/LR、模块、符号和触发条件一步步缩小根因。
面试先答结论：Kernel Panic/Oops定位时，我不会只截最后一行“panic”去猜原因，而是保留完整日志，先看异常类型、当前进程、CPU、PC/LR、Call Trace和加载模块，再结合对应的vmlinux、System.map或带符号模块把地址映射回源码，最后用可重复的触发条件验证修复。
Oops和Panic有什么区别？
Oops表示内核遇到严重异常并打印诊断信息，某些情况下系统还能勉强继续运行；Panic表示内核认为系统已经无法安全继续，通常会停止或按配置重启。面试时重点不是死背定义，而是说明两者都要先抓完整上下文。
一个完整排查流程
保存从异常前到panic后的完整串口日志，不只截图最后几行。
确认运行内核、DTB和模块版本，符号文件必须和崩溃版本一致。
用addr2line、gdb或内核脚本把PC/LR和Call Trace地址解析到函数/源码行。
结合异常类型判断NULL指针、use-after-free、栈溢出、锁问题还是硬件访问异常。
缩小触发条件，尽量做到稳定复现；不能复现时增加关键路径日志或tracepoint。
修复后跑压力和边界条件验证，而不是“再也没遇到过”就结束。
90秒参考回答
“遇到Kernel Panic，我先保留完整串口日志和对应固件版本，看PC/LR、Call Trace、当前进程和fault address。若是模块地址，会用同版本ko和vmlinux解析符号，避免版本不一致导致定位错行。定位到函数后再结合上下文看是NULL指针、越界还是并发释放。如果问题偶发，我会记录触发条件、加trace或统计，把偶发问题变成可复现问题。修复后再用原场景和压力测试验证。”
追问
Q：Call Trace最上面一行就是根因吗？
A：不一定。它是异常发生时的调用链，要结合异常类型和最早出现异常状态的位置判断，有时真正原因发生在更早的内存破坏。
Q：为什么符号版本必须一致？
A：编译优化、代码变化和模块装载地址都会改变地址映射，版本不一致可能把同一个地址解析到完全错误的函数。
核心关键词：嵌入式Linux面试Kernel PanicOopsCall TraceLinux崩溃定位
