valgrind参数应固化在shell脚本中，使用完整命令行和显式路径，必加--leak-check=full、--show-leak-kinds=all、--track-origins=yes、--log-file=valgrind.out；用"$@"透传被测程序参数，校验valgrind版本并检查日志中的内存泄漏关键字判断成败。
Valgrind 常用参数怎么固化到 shell 脚本里
直接把 valgrind 命令和参数写进脚本最稳妥，别依赖环境变量或 alias —— 它们在非交互式 shell（比如 CI 或 crontab）里大概率不生效。
核心原则：用完整命令行 + 显式路径（可选），避免歧义。比如你本地装的是 valgrind-3.20，但系统默认是 valgrind-3.18，不写全路径就可能跑错版本。
-
--leak-check=full必加，漏检内存泄漏太常见 -
--show-leak-kinds=all补全--leak-check=full，否则默认只报definitely lost -
--track-origins=yes一并加上，定位未初始化内存的源头非常有用 -
--log-file=valgrind.out固定日志名，方便脚本后续解析或归档 - 避免用
--tool=memcheck（默认值），冗余且易被误删
脚本里怎么传被测程序和参数
别把被测程序硬编码进脚本。用 $@ 接收所有后续参数，保持灵活性。
例如你写了个 run-valgrind.sh：
#!/bin/bash valgrind \ --leak-check=full \ --show-leak-kinds=all \ --track-origins=yes \ --log-file=valgrind.out \ ./myapp "$@"
这样调用时就能带参：./run-valgrind.sh --input test.dat --verbose，"$@" 会原样透传给 ./myapp。
注意两点：
- 被测程序路径必须是相对或绝对路径（如
./myapp或../build/app），不能只写myapp——valgrind不走$PATH查找 - 如果被测程序本身要读取当前目录下的配置文件，记得在脚本开头加
cd "$(dirname "$0")/.."切工作目录，否则路径错乱
怎么让脚本自动处理 valgrind 退出码
valgrind 自身退出码永远是 0（即使检测出严重泄漏），真正有用的信号藏在输出里 —— 所以不能靠 $? 判断成败。
更可靠的做法：检查日志里有没有 "ERROR SUMMARY: [^0]+" 这类模式，或者直接 grep "definitely lost:"、"still reachable:"。
示例追加判断逻辑：
if grep -q "definitely lost:" valgrind.out; then echo "Memory leak detected!" >&2 exit 1 fi
注意：still reachable: 是否算失败得看项目规范，有些嵌入式项目允许它，CI 脚本里建议先明确策略再写条件。
容易被忽略的兼容性坑
不同 Valgrind 版本对参数容忍度差异大。比如 --suppressions 在 3.17+ 才支持相对路径；--read-var-info=yes 在旧版会直接报错退出。
实操建议：
- 在脚本开头加版本校验：
valgrind --version | grep -q "valgrind-3\.2[0-9]" || { echo "Need valgrind >= 3.20"; exit 1; } - 避免用
--gen-suppressions=all自动生成 suppressions —— 生成内容不稳定，不同版本输出格式不一致，CI 上容易误判 - 如果程序用
fork()，记得加--trace-children=yes，否则子进程的泄漏完全不会上报
复杂点在于：泄漏是否“可接受”往往取决于上下文，脚本能做的只是忠实呈现结果，最终判断还得人来盯日志细节。
