Valgrind未预装于UOS，需先运行valgrind --version验证；若提示“command not found”，则执行sudo apt update && sudo apt install valgrind安装。
确认Valgrind是否已安装并获取目标程序
Valgrind不是UOS默认预装工具，需手动安装；未安装时直接运行会报“command not found”，必须先验证环境。打开终端，输入valgrind --version回车，若提示“未找到命令”，则执行sudo apt update && sudo apt install valgrind安装。
确保你已有待检测的可执行程序（如./myapp），且该程序已编译完成、具备调试符号（推荐使用gcc -g -O0编译）。若程序为Release版且剥离了符号表，Valgrind仍能报告内存错误，但无法定位到具体行号——【这会导致你只能看到“Address 0x... is 8 bytes inside a block of size 16 alloc'd”，却找不到是哪一行malloc出的问题】。
基础内存泄漏检测：单次运行+详细报告
在程序所在目录下，执行：valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose ./myapp。
参数含义：--leak-check=full启用全量检查；--show-leak-kinds=all覆盖definitely、possibly、still reachable三类；--track-origins=yes可追溯未初始化值来源；--verbose输出额外上下文信息，便于排查复杂调用链。该命令会阻塞终端，等待程序自然退出后才输出完整报告。
注意：不要对GUI程序（如DDE桌面组件）直接加valgrind运行，它会劫持X11连接导致界面卡死或崩溃；应优先检测后台服务或控制台程序。
定位重复分配与释放失配：结合GDB交互式调试
当基础检测发现大量“Invalid read/write”或“Use after free”时，需进入交互调试模式：
第一步：启动Valgrind并挂起进程等待GDB连接：valgrind --tool=memcheck --vgdb-error=0 ./myapp；
第二步：新开一个终端，运行gdb ./myapp，然后在GDB中输入target remote | vgdb建立通信；
第三步：在GDB中设置断点（如b malloc或b my_custom_alloc_func），再用c继续执行；Valgrind会在每次触发内存操作时暂停，供你逐帧查看调用栈和寄存器状态。
此方式能精准捕获“同一块内存被free两次”或“malloc后未free就重赋指针”的瞬态错误，而静态日志扫描无法还原这类时序问题。
过滤系统库干扰，聚焦业务代码
Valgrind默认会追踪所有内存操作，包括libc、Qt、DDE框架内部调用，导致报告冗长难读。在命令末尾添加--suppressions=/usr/lib/valgrind/debian.supp可屏蔽常见系统库误报。
更彻底的做法是自定义抑制文件：用valgrind --gen-suppressions=all ./myapp 2> myapp.supp生成初始抑制规则，再手动编辑myapp.supp，删掉含/usr/lib/x86_64-linux-gnu/或libQt5Core.so等路径的条目，只保留真正属于你工程源码的函数名（如MyDataProcessor::parse()）。之后运行时加上--suppressions=myapp.supp，报告将干净聚焦于你的逻辑层。
这一步不做，你可能在300行报告里翻找10分钟才找到第297行那个真实的new[] without delete[]错误。
导出结构化结果供持续集成比对
在CI流水线或回归测试中，需将泄漏结果转为机器可读格式：
执行：valgrind --leak-check=full --xml=yes --xml-file=valgrind-report.xml ./myapp。
该命令生成标准XML报告，含<error><kind>Leak_DefinitelyLost</kind></error>等标签，可被Jenkins插件或Python脚本解析统计。注意：XML模式下--verbose失效，且--track-origins不可用——若需溯源，必须切换回文本模式重新跑一次。
生成的valgrind-report.xml文件可提交至Git LFS或归档系统，用于跨版本泄漏趋势分析。
