扫码关注
ENGINEER INTERVIEW · 嵌入式Linux /
嵌入式Linux工程师高频面试，讲解SIGSEGV、Core Dump、gdb bt、调试符号、交叉调试和内存越界根因分析。
面试回答，先讲核心结论
Segmentation fault通常表示进程访问了无效或无权限访问的内存，例如空指针、越界或释放后继续使用。定位时先保留崩溃环境与版本，再获取Core Dump或通过GDB现场复现，结合崩溃线程、调用栈和变量值确定错误访问点；但栈顶位置不一定是最早破坏内存的位置。
01 / 先确认符号和Core文件是否可信
在允许调试的环境编译时加入-g等调试信息，确保设备上运行的ELF与本地符号文件匹配；针对交叉编译设备，还需使用对应架构的gdb/gdb-multiarch以及合适的sysroot。
检查core转储配置和文件权限。实际系统中可能由systemd-coredump、apport或自定义服务接管，不应仅依赖当前目录里一定出现core文件。
02 / GDB基本排查顺序
例如使用gdb ./app core文件载入可执行文件与core；使用bt查看当前线程调用链，info threads查看线程，thread apply all bt查看所有线程，并在关键帧检查参数和局部变量。
对优化后的程序，部分变量可能被优化掉或栈帧不完整；必要时通过可复现的调试构建、ASan或其他内存检查手段进一步验证。
03 / 为什么出错位置未必是根因
01.数组越界或Use-After-Free可能先破坏其他内存，直到稍后访问才触发崩溃。需要结合最后一次正常操作、边界条件、对象生命周期和并发竞争追溯。
02.修复后要编写回归场景，覆盖空指针、异常长度、并发调用和资源释放路径，不应只把触发崩溃的那一行做空指针判断就认为全部解决。
面试中容易失分的地方
把SIGSEGV简单等同“内存不够”，或者只凭GDB第一行地址就断言问题根因，会漏掉历史内存破坏与多线程条件。
面试官可能继续追问
如果Core里的栈信息显示在libc的memcpy崩溃，但你怀疑更早的缓冲区越界，该怎样验证？
