我正在编写一个生成 C 代码的编译器。生成的程序仅包含 main 函数，并且它们使用大量内存，这些内存是由 malloc() 分配的。分配的大部分内存仅用于程序的一小部分，我认为在使用后释放（）它是个好主意，因为它不会再次使用。那么，如果 valgrind 在程序结束时向我报告内存 not free()d，即仍然可访问的内存，我会很高兴。我在 Makefile 中使用带有 --error-exitcode=1 的 valgrind 来自动检查此类问题。
问题是：有没有办法让 valgrind 以 1 退出，以防仍有可到达的分配？
【问题讨论】：
标签： c free valgrind exit exit-code
通过 Valgrind 输出 grepping 的替代方法：修改编译器使其发出：
int main() { return foo_main(); }
int foo_main() { /* whatever you've emitted before */ }
假设您没有将分配的块分配给全局变量（这没有任何意义，因为您只有一个函数），您只是将“仍然可访问”转换为“肯定泄漏”。
可能更好的转换：不要在你的 main 中调用 exit(0)；改为return 0;。实际效果应该和上面一样——__libc_main 现在会为你调用exit，到那时main 中的所有局部变量都将超出范围。
【讨论】：
间接丢失但仍可访问 块不计为真 “错误”，即使 --show-reachable=yes 已指定并打印； 这是因为这样的块不需要 程序员直接修复。
我发现没有办法让 valgrind 将“仍然可访问”报告为错误。似乎您唯一的选择（除了修补 valgrind）是捕获 valgrind 的输出并解析“仍然可以访问”行。
【讨论】：
当退出时存在可到达块时，用于错误退出的 poroper 选项：
valgrind --tool=memcheck --leak-check=full --show-reachable=yes --errors-for-leak-kinds=all
因为有不同类型的泄漏具有不同的严重性，一个有趣的问题是：哪些泄漏应该算作真正的“错误”，哪些不应该？
此问题的答案会影响打印在 ERROR Summary 行中的数字，以及 --error-exitcode 选项的效果。首先，如果指定了 --leak-check=full，则仅将泄漏计为真正的“错误”。然后，选项 --errors-for-leak-kinds= 控制泄漏种类集以将其视为错误。默认值为 --errors-for-leak-kinds=defined,possible
【讨论】：
或者，您可以在您的 makefile 中使用一个小的 shell 脚本来 grep 通过 valgrind 的输出日志并相应地退出。
【讨论】：