Valgrind需用-g -O0编译并配合--track-origins=yes、--leak-check=full等参数，再通过grep筛选your_module.cpp或main.cpp行号，才能准确定位自身代码错误。
valgrind 怎么过滤出自己代码的报错行
Valgrind 默认会把 libc、libstdc++、第三方库甚至 Valgrind 自身的调用栈全打出来，真正要修的 main.cpp 或 network_module.cpp 行反而埋在底下。想快速聚焦，不能靠肉眼翻，得靠参数和技巧。
-
--suppressions不是用来“过滤”，而是用来“压制已知无害问题”的，别误用它试图隐藏自己模块的错误 - 真正有效的办法是结合
--track-origins=yes（查未初始化） +--leak-check=full+--show-leak-kinds=all，再用 shell 管道筛 - 最简过滤命令：
valgrind --leak-check=full --track-origins=yes ./app 2>&1 | grep -A5 -B5 "your_module\.cpp\|main\.cpp"—— 注意\.转义点号，避免匹配到your_module.cpp.o - 如果调用栈太深，加
--num-callers=20把栈拉长，否则默认只显示 12 层，可能截断你关心的函数
为什么 valgrind 报错里看不到自己的 .cpp 文件名
不是 Valgrind 漏了，是编译时没给它留线索。常见原因就两个：
-
g++编译时漏了-g：运行file ./app，输出里没有with debug_info就说明符号缺失 - 用了
-O2或更高优化：编译器把函数内联、删掉中间变量、重排指令，导致源码行号和实际执行流对不上；-O0是硬性要求，-O1已开始失真 - CMake 用户容易踩坑：即使设了
set(CMAKE_BUILD_TYPE Debug)，也要确认CMAKE_CXX_FLAGS_DEBUG真包含-g -O0，有些模板会悄悄覆盖
怎么判断一个 “Invalid read” 是自己写的 bug 还是第三方库的噪声
看调用栈顶部三行 —— 不是看最上面（那是 memcheck.so），而是从第一个非系统路径开始往上看：
- 如果顶部是
/usr/include/c++/或/lib/x86_64-linux-gnu/libstdc++.so，大概率是 std::string 内部缓冲池或 malloc arena 的延迟释放，可忽略 - 如果顶部出现
boost::或Qt5Core，先查对应版本的已知 issue，再考虑加 suppression 文件（路径如/usr/share/valgrind/debian.supp） - 真正要修的是：调用栈里你自己的源文件名出现在第 2～4 行（比如
at 0x401234: parse_json (parser.cpp:42)），且错误类型是Invalid write、Use of uninitialised value或definitely lost
report 里 “still reachable” 多，但 “definitely lost” 是 0，还用管吗
绝大多数情况不用修 —— 这类泄漏通常来自全局对象（static std::vector、单例缓存、log 模块预分配 buffer），进程退出时 OS 会回收。但有两个例外：
- 你的模块在
main()之后还手动调用了exit()或被signal(SIGABRT)中断：Valgrind 来不及扫描 final leak，definitely lost就是假阴性；确保测试路径能自然走到return 0 - 调用栈里
still reachable的内存分配点明确指向你写的new或malloc，且没被任何全局指针持有：比如某个工厂类在初始化时 new 了一块配置内存，但没存进 static map，那就是真泄漏
最难的从来不是看懂 Valgrind 报什么，而是分清哪些报错是程序没跑完导致的假象，哪些是跑完了但你没意识到自己握着指针不放。
