https://pycv.github.io/blog/tags/%E8%B0%83%E8%AF%95/Recent content in 调试 on To the MoonHugo -- gohugo.iozh-cnSat, 14 Mar 2026 16:20:15 +0800https://pycv.github.io/blog/excerpts/2026-03-14-embedded-segmentation-fault-debugging/Sat, 14 Mar 2026 16:19:35 +0800https://pycv.github.io/blog/excerpts/2026-03-14-embedded-segmentation-fault-debugging/ <blockquote> <p>本文由 AI 自动摘录整理，原始链接：<a class="link" href="https://mp.weixin.qq.com/s/7cFIPWiEzTIJQEHmR7gOjQ" target="_blank" rel="noopener" >一个数组越界，竟让我排查了几天</a></p> <p><strong>推荐指数</strong>：8/10（推荐读原文）</p> </blockquote> <h2 id="背景">背景 </h2><p>程序跑了几天好好的，换个位置就段错误死机。屏蔽两行三角函数代码就正常，打开就必崩——但问题根源和那两行代码毫无关系。最终真凶是一个&quot;隔山打牛&quot;式的数组越界。</p> <h2 id="核心观点">核心观点 </h2><ul> <li> <p><strong>打印法可能把你带偏</strong>：屏蔽代码后&quot;不崩了&quot;，只是切断了越界的触发路径，并没有解决根本问题。表象往往和根因相隔甚远。</p> </li> <li> <p><strong>远程 GDB 精确定位崩溃点</strong>：gdbserver + VSCode 远程调试，段错误发生时能精确知道崩溃的代码行号，比打印法更可靠。</p> </li> <li> <p><strong>数组越界&quot;隔山打牛&quot;</strong>：一个 5 元素的 float 数组 <code>arr</code>，实际写到了 <code>arr[5]</code>、<code>arr[6]</code>、<code>arr[7]</code>、<code>arr[8]</code>。而 <code>arr[8]</code> 的地址正好是静态全局变量 <code>fd</code> 的地址，写入操作直接篡改了 <code>fd</code> 的值，导致段错误。</p> </li> </ul> <h2 id="关键技巧">关键技巧 </h2><ul> <li> <p><strong>-fdata-sections 编译参数</strong>：让每个变量放到独立的 section 中，链接器生成 map 文件时就会包含 static 变量的地址信息，方便分析内存布局。</p> </li> <li> <p><strong>AddressSanitizer（-fsanitize=address）</strong>：对付内存类 bug 的&quot;大杀器&quot;，会直接报出数组越界的精确位置和调用栈，可能 10 分钟就能定位根因。</p> </li> </ul> <h2 id="调试工具速查表">调试工具速查表 </h2><table> <thead> <tr> <th>工具/方法</th> <th>适用场景</th> <th>优势</th> </tr> </thead> <tbody> <tr> <td>log 打印法</td> <td>快速初筛</td> <td>简单直接，零成本</td> </tr> <tr> <td>远程 GDB</td> <td>精确定位崩溃行</td> <td>可看调用栈和变量值</td> </tr> <tr> <td>core dump + gdb</td> <td>事后分析</td> <td>不需要复现，离线分析</td> </tr> <tr> <td>strace</td> <td>系统调用级跟踪</td> <td>排查文件/网络/权限问题</td> </tr> <tr> <td>AddressSanitizer</td> <td>内存越界/溢出/UAF</td> <td>编译期插桩，精确到行</td> </tr> <tr> <td>map 文件 + -fdata-sections</td> <td>分析变量内存布局</td> <td>查看 static 变量地址</td> </tr> </tbody> </table> <h2 id="经验总结">经验总结 </h2><ol> <li> <p><strong>表象 ≠ 根因</strong>：通过屏蔽/打开某些代码来定位问题时，看到的可能只是 bug 的表象。要多思考&quot;为什么&quot;，从根本上解决。</p> </li> <li> <p><strong>选对工具事半功倍</strong>：打印法虽然常用，但遇到内存踩踏类 bug 时容易把人带偏。远程 GDB 和 map 文件是更高效的手段。</p> </li> <li> <p><strong>AI 辅助排查</strong>：有明显代码缺陷的代码，AI review 分分钟就能检测出来。结对分析可以让 AI 检查可疑代码是否存在缺陷。</p> </li> </ol> <hr> <p><em>摘录时间：2026-03-14</em></p>