valgrind 后接程序路径及参数，所有被测程序参数须置于命令行末尾；错误写法如valgrind --leak-check=full -- ./a.out -i input.txt会导致“no such file”；正确为valgrind --leak-check=full ./a.out -i input.txt，路径、权限、动态链接、shebang均需检查；环境变量需显式传递，信号拦截可关闭，子进程需--trace-children=yes，输出建议重定向。
valgrind 后面直接跟程序路径和参数
Valgrind 本身不解析你程序的参数，它只负责接管并监控目标进程的执行。所以所有你想传给被测程序的参数，都得写在 valgrind 命令行的最后，紧跟在可执行文件路径之后。
常见错误是把参数错放在 valgrind 自己的选项后面，比如：valgrind --leak-check=full -- ./a.out -i input.txt —— 这里 -- 后面的 ./a.out -i input.txt 会被 shell 当作一个整体命令名，导致找不到可执行文件。
- 正确写法：
valgrind --leak-check=full ./a.out -i input.txt - 如果参数含空格或特殊字符，照常加引号：
valgrind ./a.out --config "path/with space.cfg" - 想让 valgrind 忽略自己的选项解析、明确分隔，可用
--（但仅当必要时）：valgrind --tool=memcheck -- ./a.out --help，此时--help才会传给./a.out而非被 valgrind 解析
遇到 “No such file or directory” 错误，先检查路径和权限
这个错误不是 valgrind 报的，而是内核在 execve 阶段返回的，说明它根本没启动你的程序。最常见原因是：
-
./a.out路径不对，或者当前目录不是你认为的那个目录（valgrind 不会自动 cd） - 目标文件没有可执行权限：
chmod +x ./a.out - 动态链接失败（比如用
gcc -static编译的程序反而更稳妥；若依赖特定 libc 版本，valgrind 可能因自身插桩机制触发加载失败） - 程序是脚本且 shebang 指向不存在的解释器（如
#!/usr/bin/python3，但系统只有python3.9）
需要传递环境变量？用 env 或 VALGRIND_OPTS
valgrind 不会自动继承所有 shell 环境变量（尤其某些被它内部屏蔽的），如果你的程序依赖 LD_LIBRARY_PATH、HOME 或自定义变量，得显式传入：
- 推荐方式：
env LD_LIBRARY_PATH=/my/lib valgrind ./a.out arg1 - 也可以用
--trace-children=yes配合env，确保子进程也拿到变量 -
VALGRIND_OPTS是 valgrind 自己读的环境变量，用于预设通用选项（如export VALGRIND_OPTS="--leak-check=full --show-leak-kinds=all"），但它不能用来传你程序的参数或环境
调试 core dump 或信号问题时，注意 valgrind 的信号拦截行为
valgrind 默认会捕获并处理很多信号（如 SIGSEGV、SIGABRT），这可能导致你程序里原本的 signal handler 不被调用，或 gdb 无法 attach 到崩溃点。
- 用
--sigill-handler=no、--sigsegv-handler=no等关闭特定信号拦截（查看valgrind --help中 signal 相关选项） - 若程序依赖
core文件，valgrind 下默认不会生成——需加--keep-stacktraces=yes并配合ulimit -c unlimited，但效果有限；更可靠的方式是先不用 valgrind 复现 crash，再用 valgrind 分析疑似内存问题路径 - 对
fork()+exec类型程序，记得加--trace-children=yes，否则只监控父进程
实际运行时最容易被忽略的是：valgrind 的输出默认混在程序 stdout/stderr 里，而它的报告又很长。建议始终重定向：valgrind --log-file=valgrind-out.txt ./a.out args > app-out.txt 2>&1，不然关键错误信息可能被刷屏冲走。
