在编译时是否可以在 gcc 中启用不进行内存管理？
【问题讨论】：
在调试使用 GCC 编译的 C 代码时使用 Valgrind 的要点：
使用 -O0 编译代码。在一些相对罕见的情况下（例如内联汇编），您可能需要 -O1。 从不使用更高的优化级别。编译器会严重破坏你的代码，以至于让你的生活变得不可能。变量可以完全消失，函数可以在它们被内联时神秘地消失，循环变得展开等等。基本上，使用 -O0 以外的任何内容都会冒可执行代码与源代码几乎没有相似之处的风险。
使用 -g GCC 选项将调试符号添加到您的代码中，并且不要剥离可执行文件。就像任何其他调试器一样，valgrind 将产生无限更多有用的输出，并带有可用的调试符号。它们将帮助 valgrind 将内存地址与代码中的特定文件和行号进行匹配，这是非常宝贵的。
要跟踪内存泄漏和许多其他问题，我建议运行您的程序：
valgrind --log-file=valgrind.log --leak-check=full --track-origins=yes --show-reachable=yes ./program
然后在 valgrind.log 文件中查找发现的任何问题。
编辑：
关于我建议的 valgrind 选项：
--log-file= 告诉 valgrind 将其输出发送到一个文件，我相信当您调试输出到控制台的程序时，或者发现很多问题时，这可以使事情变得更容易。
--leak-check=full 告诉 valgrind 告诉您有关每个泄漏内存块的详细信息。
--track-origins=yes 告诉 valgrind 找出未初始化值的来源。它与内存泄漏没有任何关系，尽管它可以帮助处理其他问题。但是，它会使您的程序变慢，因此您可能希望删除此选项并仅在跟踪未初始化的值时添加它。
--show-reachable=yes 告诉 valgrind 输出已分配但未释放的内存块，即使在程序退出时仍有指向它们的指针。这些块技术上不会丢失/泄露，因为您仍然有指向它们的指针。尽管如此，它们仍然可以 a) 指示程序中的逻辑问题（例如，无限增长的列表） b) 如果您的 main() 被集成为另一个更大的程序中的函数，它们可能并且将成为内存泄漏。最好不要留下这样的问题。
有一个 --track-fds=yes 选项可以帮助查找泄漏的文件描述符，而不仅仅是内存。
一些程序员反对在程序结束时释放内存或关闭文件描述符，因为操作系统无论如何都会这样做。虽然那里 具有性能和代码大小优势，但恕我直言，这只能由经验丰富的程序员完成，并且应该通过 删除生产版本的上述代码来完成，而不仅仅是从不写它。否则，这会鼓励不应允许的不良编码实践。
编辑 2：
一个重要提示：如果 valgrind 表明您的代码存在问题，那么即使您的程序没有崩溃，它也很可能是正确的。取决于结构对齐、内存分配器行为、平台、编译器版本和标志或月相，一些“小”错误（例如，读取缓冲区末尾后的一个字节）可能仍然看不见。如果您更改编译器、libc、平台或位数（例如从 64 位变为 32 位），具有此类问题的代码可能会中断。
【讨论】：
编译您的程序而不进行优化，并使用调试符号以获得最佳结果 (-O0 -g)。
现在运行程序的一个实例，尽可能多地利用功能，像这样包装调用：
valgrind ./myprog my prog args
我经常发现将以下标志传递给 valgrind 很有用：
valgrind --leak-check=full --track-fds=yes --track-origins=yes --malloc-fill=0x80 --free-fill=0x7f ./myprog my prog args
但是 valgrind 会提供很多提示来帮助您了解要传递的参数，如果它在不太彻底的传递中找到东西的话。
【讨论】：