我正在使用unittest-cpp库。我决定在valgrind帮助下检查内存泄漏之一。我得到了这样的报告：
== 35820 ==堆摘要：
== 35820 ==在出口处使用：188个块中的26,151字节
== 35820 ==总堆使用量：259个分配，71个释放，32,151个字节分配
== 35820 ==
== 35820 == 1块中的148（80个直接字节，68个间接字节）字节肯定在65的丢失记录中丢失
== 35820 ==在0x100023D81：malloc（vg_replace_malloc.c：303）
== 35820 ==通过0x1002CB8D6：__Balloc_D2A（在/usr/lib/system/libsystem_c.dylib中）
== 35820 ==通过0x1002CC21F：__d2b_D2A（在/usr/lib/system/libsystem_c.dylib中）
== 35820 ==通过0x1002C8877：__dtoa（在/usr/lib/system/libsystem_c.dylib中）
== 35820 ==通过0x1002F13E6：__vfprintf（在/usr/lib/system/libsystem_c.dylib中）
== 35820 ==通过0x10031A6C8：__v2printf（在/usr/lib/system/libsystem_c.dylib中）
== 35820 ==通过0x1002F0389：vfprintf_l（在/usr/lib/system/libsystem_c.dylib中）
== 35820 ==通过0x1002EE223：printf（在/usr/lib/system/libsystem_c.dylib中）
== 35820 ==通过0x10000AA59：UnitTest :: TestReporterStdout :: ReportSummary（int，int，int，float）
（TestReporterStdout.cpp：43）
== 35820 ==通过0x10000AF9E：UnitTest :: TestRunner :: Finish（）const（TestRunner.cpp：43）
== 35820 ==通过0x10000B2F4：int UnitTest :: TestRunner :: RunTestsIf（UnitTest :: TestList
const＆，char const *，UnitTest :: True const＆，int）const（in
./BuilderTests）
== 35820 ==通过0x10000ACEF：UnitTest :: RunAllTests（）（TestRunner.cpp：17）
== 35820 ==
== 35820 ==泄漏摘要：
== 35820 ==绝对丢失：1块中的80个字节
== 35820 ==间接丢失：2个块中的68个字节
== 35820 ==可能丢失：1块中的2,064字节
== 35820 ==仍可达到：1块中4,096字节
== 35820 ==已抑制：183个块中的19,843个字节
但是valgrind没有指向我的代码。
然后，我决定从GSL库构建和检查单元，该库也使用unittest-cpp。我得到了同样的报告。
我可以信任valgrind吗？
最佳答案
通常，您可以信任Valgrind报告事实。但是如何解释这些很重要。并非所有泄漏都是平等的。
并非所有内存泄漏都是问题。如果已知某个程序的析构函数没有相关的工作要做，从而导致程序“泄漏”，则程序在关闭过程中可能会合理地忽略某些对象，从而在进程退出时将其留给操作系统来清除内存。
因此，肯定会有一个实际的问题。但是也可能是由于性能或便利性原因，库有意泄漏某些对象。
仅当内存泄漏导致内存使用量在运行期间不断增加时，它才是真正的问题。
诸如此类的泄漏-资源分配一次并一直持续到程序结束，并且永远不会被释放-仅当该资源的大小很大并且可以提前释放以使内存可以用于更好的情况时，这才是真正的问题，和/或如果资源具有析构函数，则运行很重要。
请记住，程序终止后，它分配的所有内存都将返回给系统（罕见的例外，例如“ sysv共享内存”等）。内存泄漏不会超出程序终止范围而不会影响系统。
关于c++ - Valgrind在unittest-cpp库中显示内存泄漏，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/38286111/