用 LLM 揪出 Python C 扩展的 bug

# 用 LLM 查找 Python C 扩展中的 bug 来源：https://lwn.net/SubscriberLink/1067234/e5312bed2037a102/ > ### 欢迎来到 LWN.net > 以下内容仅对 LWN 订阅者开放，由一位订阅者分享给您。数千名读者依赖 LWN 获取 Linux 与自由软件社区的最佳资讯。如果您觉得本文有价值，欢迎[订阅 LWN](https://lwn.net/subscribe/)。感谢访问 LWN.net！ 开源社区最近被“LLM 发现 bug 与漏洞”的报告淹没（见 [LWN 报道](https://lwn.net/Articles/1066581/)），给维护者带来额外负担；不过，这一波报告大多以负责任的方式提交，尽量降低影响。一份[最新报告](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875)介绍了对 Python C 扩展进行系统性漏洞挖掘的尝试，同样秉持这一原则。爱好者 Daniel Diniz 借助 Claude Code，在 44 个扩展、近百万行代码中找出 500 多个各类 bug；他正与维护者协作将修复合入上游，其方法论堪称“人机协同、避免维护者过劳”的典范。 数字相当惊人：“575+ 已确认 bug（人工复核后误报率约 10–15%，其中约 140 个已在 Python 层面复现），已有 14 个项目合入修复”。缺陷类型五花八门：“从硬崩溃、内存损坏到正确性违规、规范违背”。Diniz 希望与维护者一起让这项努力“对维护者更有用、更可扩展”，目标是提供高质量报告，覆盖“一大类人工极难发现的非平凡 bug”。 为此，Diniz 编写了 Claude Code 插件 [cext-review-toolkit](https://github.com/devdanzin/cext-review-toolkit)，专门针对 Python C 扩展的常见问题（引用计数、GIL 处理、异常状态等）。工具“并行运行 13 个专项分析代理，每个代理聚焦不同 bug 类别”。 #### 成果 报告很长，建议通读，这里摘录几点： 工具[战果累累](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875#p-289697-what-it-found-3)，已提交大量 issue 与 PR，涵盖十余个 C 扩展项目，包括 [Cython](https://cython.org/)、[Guppy 3](https://zhuyifei1999.github.io/guppy3/)、[regex](https://github.com/mrabarnett/mrab-regex?tab=readme-ov-file#introduction)、[Pillow](https://python-pillow.github.io/) 等。Guppy 3 维护者朱一斐（YiFei Zhu）深入阅读[详尽报告](https://gist.github.com/devdanzin/b30771d22104e6fa0c30c41a6e27a355)，已修复 30 个问题中的 24 个，还发现了“工具遗漏的额外 bug”。其在[总揽 issue](https://github.com/zhuyifei1999/guppy3/issues/51)中的反馈“价值极高”，促使工具改进以减少误报。 报告[描述了工具与流程](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875#p-289697-how-it-works-4)：先对项目运行代理，人工复核结果，尽可能给出纯 Python 复现，再通过私密 GitHub gist 分享给维护者。另有一份文档[介绍如何编写 Python 复现](https://github.com/devdanzin/cext-review-toolkit/blob/main/docs/reproducer-techniques.md)，报告本身也[列出代理针对的 bug 类型](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875#p-289697-how-its-different-5)。 更重要的是，考虑到维护者常被低质量报告与 PR 淹没，Diniz 明显在确保自己的工作对项目真正有用： > 这类报告对维护者而言耗时耗力。历史上，自动找 bug 工具误报远多于真知，而 AI 会让误报看起来更可信。[…] 一旦维护者指出误报，我立即更新代理提示词，避免再踩同一坑。除了打磨工具，我还尽量以非侵入、有助的方式沟通。节奏永远由维护者掌控：我先问他们希望如何接收信息（总揽 issue？独立 issue？直接 PR？抑或完全忽略），再让他们自行决定如何处理发现。 报告还包含[bug 示例与复现](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875#p-289697-a-deep-dive-7)、[踩坑记录](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875#p-289697-what-didnt-work-8)等。文末他向社区[抛出若干问题](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875#p-289697-questions-for-the-community-11)：这是否有用？如何改进工具与报告？未来还想做哪些工具？他提到正在开发[针对无 GIL Python 的 C 扩展分析工具](https://github.com/devdanzin/ft-review-toolkit)以及[另一款扫描 CPython 源码的工具](https://github.com/devdanzin/cpython-review-toolkit)。 #### 社区反馈 反响普遍积极。几位 Python 开发者与维护者现身分享体验，并提改进建议。James Parrott[好奇](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875/2)：若用 Rust 写扩展，能消灭多少 bug？Cython 维护者 David Woods[认为](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875/6)，Rust 可消除引用计数问题，但报告中大量异常处理 bug 未必能幸免。Diniz[把“Rust 能防多少”抛给 Claude Code](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875/7)，模型答“60–70% 防不住”；Diniz 提醒“LLM 对数字与估算常不靠谱”，但大类划分也值得商榷。Matthias Urlichs[表示](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875/8)，若 Rust API 按“Rust 意义上的安全”设计，而非照搬 C API，能防的问题会更多。 Parrott 还建议用 [GitHub Actions](https://docs.github.com/en/actions) 自动复现 bug，以改善报告体验：“我不想啃巨型机器报告再自己梳理”。Diniz[欢迎该建议](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875/3)，认为实现不难；定制报告已在计划之中：“我想按维护者需求裁剪报告，有人要复现与补丁，有人只要简短描述与代码位置。” Pillow 维护者 Eric Soroos[评价](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875/4)：“这是我们在安全/正确性问题上收到的较好报告之一”。他也指出覆盖不全，自己就在相邻函数里发现了类似 bug。部分 bug 需要让内存分配在特定点失败才能触发，于是提出工具建议： > 不妨做个 fuzzer，用覆盖率引导让 malloc（或 C API 函数）按点失败，再跑在 valgrind 下抓泄漏或非法访问，可更好覆盖 `if(ptr==null){free 函数内所有已分配内存}` 这类重复性 C 级错误处理。 该想法获众人赞同，Soroos 稍后又[做了补充](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875/13)。 bug 的严重程度、是否值得维护者投入也是议题。Maurycy Pawłowski-Wieroński[提到](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875/14)，他用 Diniz 的 LLM 工具扫描 CPython 结果参差，部分 bug 触发条件用户几乎遇不到： > 除非问题关键（即便可完美复现），很多修复只是干扰。维护者自有项目、计划、排期，某个病态引用泄漏并不那么重要。过去这类 PR 被接受，是因为被视为对潜在维护者的一种投资（教育），未来同事。如今却像刷“贡献者”徽章。 Diniz[一如既往给出思考周到的回应](https://discuss.python.org/t/systematically-finding-bugs-in-python-c-extensions-575-confirmed-so-far/106875/16)，认同“并非所有发现都值得修”。维护者自会划定修复门槛，“我所能做的就是列出工具发现，让他们自行挑选”。目前他尚未收到太多关于“针对小毛病、泄漏等微型 PR 是否欢迎”的反馈，但愿意继续讨论。 这一问题还会反复出现。例如，内存分配失败的处理当然重要，但未必高于维护者手头其他任务。让 LLM 按“现实可利用概率”排序报告将是下一步。那些把工具用于恶意目的的人，早已瞄准*可被利用*的 bug；LLM 提供方若能捕获（或共享）这类提示，亦可用于防御。供应商自己也可能有工具和模型可投入此类任务。 让维护者完全掌控，或许是整个行动中最重要的一环；赋予他们“一键退订”尤为关键。当然，也要平衡——有时即便项目不感兴趣，发现的 bug 仍需升级。LLM 找 bug 尚属早期，机器生成报告的速度远胜人类处理，未来必然出现各种或善或恶的做法。就目前而言，此例展示了“善”的范本。 Index entries for this article [Python](https://lwn.net/Archives/PythonIndex/) [Bug reporting](https://lwn.net/Archives/PythonIndex/#Bug_reporting) [Python](https://lwn.net/Archives/PythonIndex/) [Large language models (LLMs)](https://lwn.net/Archives/PythonIndex/#Large_language_models_LLMs)