一次 C++ 程序三重 bug 的调试之旅：double-free、静态初始化 fiasco 与 RTSP 死锁
借助 AI 在 30 分钟内定位并修复了三个偶发性崩溃问题。本文复盘整个排查过程，记录诊断思路和修复方案。 一、背景项目是一个基于 ZLMediaKit 的嵌入式多媒体客户端，运行在 ARM 平台上。最近重构了 RTSP 服务管理代码后，程序同时出现三个症状： 偶尔 double-free 崩溃（ARM 和 x86 都有） ARM 启动即段错误，x86 却正常 RTSP 服务无法正常退出（卡死） 前两个问题看起来像内存错误，第三个像死锁，直觉上互不相干。但折腾一圈后发现，三个 bug 共享同一个根——静态库与动态库的符号冲突。下面按排查顺序逐个说。 二、Bug 1：偶尔 double-free —— ELF 符号介入症状程序退出时偶尔报 double-free，不是每次都出现。valgrind 能抓到，但指向的调用栈涉及动态库的析构阶段，信息模糊。 排查过程让 AI 遍历 src/ 下所有源文件做内存管理分析。AI 很快从 CMakeLists.txt 中拎出一段关键注释： 1234# libcore_api.so 提供 toolkit 基础库符号（SocketHelpe...
AI 辅助调试的误区：为什么让 AI 直接修 bug 是低效的
一、你可能用错了 AI过去两周，我修复了一个 C++ 无人机地面站服务的两类问题： 内存问题：Valgrind 报告 112 个 use-after-free 错误，分布在关机顺序、容器清理、回调生命周期等多个维度。 性能问题：gperftools 火焰图显示 CPU 被三个瓶颈吞噬——一个 0.5ms 间隔的定时器线程独占 50.7% 采样，日志系统的无差别 flush 占 17.4%，protobuf 热路径深拷贝占 11.6%。 两次排查经历得出同一个结论：AI 最适合的角色不是"修 bug 的人"，而是"读工具输出的人"。 这不是一个关于 AI 能力边界的哲学讨论。这是两组真实火焰图、112 个 Valgrind 错误、和 11 个代码修复的工程复盘。 二、一个典型的 AI 调试场景（以及它为什么失败）假设你遇到这样一个问题：程序在退出时偶尔 crash，日志的最后几行是乱序的。 如果你把出问题的代码直接丢给 AI： 1234567用户：这段代码退出时崩溃，帮我修一下void SystemFactory::stop() ...
C++ 服务崩溃复盘：从 Valgrind 112 个错误到零
一、十点夜晚的 Valgrind 日志那是一个周四的晚上。我已经盯着终端看了一个小时，屏幕上是一份 Valgrind 报告——112 个错误，全是 use-after-free。 123456789101112==3300263== Invalid read of size 1==3300263== at 0x4852A10: memmove==3300263== by 0x60818AD: basic_streambuf::xsputn==3300263== by 0x6073B64: __ostream_insert==3300263== by 0x15C2DB: operator<<==3300263== by 0x15C2DB: MqttClient::publish (mqttClient.cpp:382)==3300263== by 0x1935E7: LogPublisher::publish (LogPublisher.cpp:68)==3300263== by 0x191540: Logger::worker...
