多线程内存泄漏需专用方法：valgrind需加--show-leak-kinds=all才报still reachable；禁用pthread_cancel，确保线程正常退出；gdb条件断点定位未释放内存；mtrace多线程不可靠，应改用addresssanitizer配合core dump与线程过滤分析。

多线程环境下的资源泄漏（尤其是内存）不能靠单线程工具直接套用，必须区分泄漏类型、线程上下文和工具链兼容性——否则你会看到“没泄漏”的假阳性结果。

为什么 valgrind --leak-check=full 在多线程程序里常漏报

Memcheck 默认不跟踪线程退出时的栈帧清理过程，如果某线程在 malloc 后未 free 就直接退出（比如被 pthread_cancel 或异常终止），那块内存会被标记为 “still reachable”，而非 definitely lost。这类泄漏在长期运行的服务中会持续累积，但 valgrind 默认不告警。

• 必须加 --show-leak-kinds=all，否则 still reachable 和 possibly lost 类型全被忽略
• 避免使用 pthread_cancel：它绕过栈展开，std::unique_ptr 或 RAII 析构函数不会触发，导致资源未释放
• 确保所有线程都正常 return 或调用 pthread_exit，而不是让主线程 exit 强制结束整个进程

如何用 GDB 捕获线程退出前的泄漏现场

不是等程序跑完再查，而是在线程即将销毁时中断，检查其堆分配状态。关键在于识别「谁分配了但没释放」的上下文。

C++ 算法竞赛自动化测试数据生成与校验框架

根据原题生成新题面、验证器及完整测试数据，自动套用 testlib 模板，用于用户要求生成测试数据时。

下载

• 在 pthread_create 的 start_routine 入口设断点：break thread_worker_func
• 用 info threads 查看线程列表，切换到目标线程：thread 3
• 对可能泄漏的路径加条件断点：break free if $rdi == 0x7f8b3c0012a0（地址来自之前 malloc 的返回值）
• 若该地址从未被 free 命中，说明泄漏发生在该线程生命周期内

mtrace 在多线程下基本不可靠，别用

mtrace 内部依赖全局锁保护日志写入，在高并发 malloc/free 频率下极易丢记录或错序；更严重的是，它不支持线程局部存储（TLS）中的分配行为，而现代 C++ 线程池常通过 thread_local std::vector 或 boost::pool 管理内存——这些分配完全不出现在 mtrace.log 中。

• 如果你的代码用了 new，mtrace 默认不捕获（除非你重载 operator new 调用 malloc 并显式调用 mtrace()）
• 动态库初始化阶段（如 __attribute__((constructor))）早于 mtrace() 调用，这部分分配永远漏检
• 替代方案：用 AddressSanitizer 编译时插桩：g++ -g -fsanitize=address,leak -pthread test.cpp，它对多线程分配/释放配对跟踪更健壮

真正能定位线程级泄漏的组合：ASan + core dump + 线程过滤

当泄漏已发生且程序卡死或 OOM，不要重启，先保留现场：

• 用 gcore -o core.<pid><pid></pid></pid> 抓当前内存镜像
• 用 gdb ./your_program core.<pid></pid> 加载后执行：thread apply all info proc mappings，确认各线程堆段是否异常膨胀
• 对疑似泄漏线程执行：thread 5 → info registers → 查 rdi/rsi 是否指向大量未释放的 malloc 地址
• 配合 ASan 编译的二进制，启动时加 ASAN_OPTIONS=detect_leaks=1:abort_on_error=1，它会在进程退出时强制报告所有线程的未配对分配

最易被忽略的一点：线程私有资源（如 TLS 变量、std::thread_local 对象）的析构函数是否真的运行了？GDB 里用 info symbol <address></address> 查看地址是否落在析构函数符号范围内，而不是默认假设“线程退出=资源释放”。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！