"still reachable" 和 "possibly lost" 块的 C++ 中的 valgrind 输出不引用我的来源
valgrind output in C++ of "still reachable" and "possibly lost" blocks do not reference my sources
我很难确定我的代码中哪里有内存泄漏。
valgrind 命令我 运行:
valgrind --leak-check=full --log-file=vg1.log --show-leak-kinds=all --leak-resolution=low --track-origins=yes --leak-check-heuristics=all ./enalu_dbg
和输出
==22866== Memcheck, a memory error detector
==22866== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==22866== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==22866== Command: ./enalu_dbg
==22866== Parent PID: 21933
==22866==
==22866==
==22866== HEAP SUMMARY:
==22866== in use at exit: 47,252 bytes in 240 blocks
==22866== total heap usage: 288 allocs, 48 frees, 55,138 bytes allocated
==22866==
==22866== 4 bytes in 1 blocks are still reachable in loss record 1 of 23
==22866== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x77018CD: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x7701D28: g_private_get (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x76DB20C: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x76AF17D: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x76CF494: g_quark_from_static_string (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x74314AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
...
==22866== 184 bytes in 1 blocks are possibly lost in loss record 13 of 23
==22866== at 0x4C2CE8E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x76C56AE: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x7451618: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74560D4: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x7442DE6: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74449AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74315E9: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==22866==
...
==22866== 6,028 bytes in 60 blocks are still reachable in loss record 21 of 23
==22866== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x76C5668: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x74514D9: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74560D4: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x7442DE6: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x744423A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74315E9: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==22866==
==22866== 10,360 bytes in 5 blocks are still reachable in loss record 22 of 23
==22866== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x8B16E9A: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2)
==22866== by 0x8B15ACE: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2)
==22866== by 0x8B17585: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2)
==22866== by 0x8AC9508: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==22866==
==22866== 16,600 bytes in 4 blocks are still reachable in loss record 23 of 23
==22866== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x76C5610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x76CF445: g_quark_from_static_string (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x74314AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==22866==
==22866== LEAK SUMMARY:
==22866== definitely lost: 0 bytes in 0 blocks
==22866== indirectly lost: 0 bytes in 0 blocks
==22866== possibly lost: 1,352 bytes in 18 blocks
==22866== still reachable: 45,900 bytes in 222 blocks
==22866== of which reachable via heuristic:
==22866== newarray : 1,536 bytes in 16 blocks
==22866== suppressed: 0 bytes in 0 blocks
==22866==
==22866== For counts of detected and suppressed errors, rerun with: -v
==22866== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
显示的大多数记录（但 1 条）是 "still reachable blocks"。我读到这些可能是由于池释放延迟所致。即在我的 main(argc,argv){} 函数终止后释放容器（例如我经常使用的 vectors ）。
但是，肯定有问题，因为在执行大约 8-9 小时后，我清楚地看到可执行文件使用的内存比开始时多（在我的电脑中，它开始时内存使用量为 0.6%，之后8h用了大概6%).
问题是这些是神秘的消息 - 绝对 none 来自我的源文件。正如我所读 here “_dl*” 调用与 linux 加载程序有关。那么我怎样才能查明问题的根源呢？
我应该补充一点，这段代码使用了
- 1+3 个线程（用于所有阻塞操作，即从标准输入和串行端口读取数据并将数据写入文件），
- boost 库（尤其是循环缓冲区），以及
- gsl 库。
然而，我已经从小的概念验证部分构建了代码，这些代码在 valgrind 中没有显示任何 errors/warnings。
此外，我的代码中只有有限数量的指向 class 对象的指针，我在各自的析构函数中验证了 delete。
原始分配调用来自共享库初始化代码，当您的应用程序链接的共享库在 运行 加载时执行，通常在您的任何应用程序代码实际加载之前 运行s。这就是为什么您在回溯中看不到您的代码的原因。它甚至还没有 运行。
要查找的关键符号是_dl_init，共享库初始化的入口点。查看它的上游会告诉您正在初始化哪个库。在您的例子中，它是一堆 Gnome 库和一个名为 "libpixman".
的库
共享库也有一个清理函数，当共享库被卸载时会被调用。
well-organized 共享库将使用共享库清理函数有序地释放它在启动时分配的所有内存。不幸的是，这种对细节的疏忽很常见：共享库从堆中分配一堆内存，用于共享库的内部静态表，而无需在共享库卸载时重新分配该内存。
这不太可能是您在应用程序 运行ning 期间观察到的内存泄漏的原因，但我稍后会提到的一种情况除外。根据我的经验，这种草率的分配做法仅用于共享库在加载时分配一次的静态表。这里的想法是没有必要在自己之后明确清理，因为当进程退出时，库只会被卸载一次。
遗憾的是，偷工减料的开发人员从未听说过 dlopen() 和 dlclose()。这使得大型应用程序无法仅在需要时按需加载共享库，然后再卸载它，直到再次需要它。
因此，除非您的应用程序代码重复 dlopen()ing 和 dlclose()ing 所有这些 Gnome 库和 libpixman，否则您将不得不继续在其他地方寻找漏洞.您应该继续阅读并使用 valgrind 的抑制文件，以抑制其输出中的这种烦人的噪音。
我很难确定我的代码中哪里有内存泄漏。
valgrind 命令我 运行:
valgrind --leak-check=full --log-file=vg1.log --show-leak-kinds=all --leak-resolution=low --track-origins=yes --leak-check-heuristics=all ./enalu_dbg
和输出
==22866== Memcheck, a memory error detector
==22866== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==22866== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==22866== Command: ./enalu_dbg
==22866== Parent PID: 21933
==22866==
==22866==
==22866== HEAP SUMMARY:
==22866== in use at exit: 47,252 bytes in 240 blocks
==22866== total heap usage: 288 allocs, 48 frees, 55,138 bytes allocated
==22866==
==22866== 4 bytes in 1 blocks are still reachable in loss record 1 of 23
==22866== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x77018CD: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x7701D28: g_private_get (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x76DB20C: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x76AF17D: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x76CF494: g_quark_from_static_string (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x74314AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
...
==22866== 184 bytes in 1 blocks are possibly lost in loss record 13 of 23
==22866== at 0x4C2CE8E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x76C56AE: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x7451618: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74560D4: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x7442DE6: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74449AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74315E9: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==22866==
...
==22866== 6,028 bytes in 60 blocks are still reachable in loss record 21 of 23
==22866== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x76C5668: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x74514D9: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74560D4: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x7442DE6: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x744423A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x74315E9: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==22866==
==22866== 10,360 bytes in 5 blocks are still reachable in loss record 22 of 23
==22866== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x8B16E9A: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2)
==22866== by 0x8B15ACE: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2)
==22866== by 0x8B17585: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2)
==22866== by 0x8AC9508: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==22866==
==22866== 16,600 bytes in 4 blocks are still reachable in loss record 23 of 23
==22866== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22866== by 0x76C5610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x76CF445: g_quark_from_static_string (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==22866== by 0x74314AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==22866== by 0x4010139: call_init.part.0 (dl-init.c:78)
==22866== by 0x4010222: call_init (dl-init.c:36)
==22866== by 0x4010222: _dl_init (dl-init.c:126)
==22866== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==22866==
==22866== LEAK SUMMARY:
==22866== definitely lost: 0 bytes in 0 blocks
==22866== indirectly lost: 0 bytes in 0 blocks
==22866== possibly lost: 1,352 bytes in 18 blocks
==22866== still reachable: 45,900 bytes in 222 blocks
==22866== of which reachable via heuristic:
==22866== newarray : 1,536 bytes in 16 blocks
==22866== suppressed: 0 bytes in 0 blocks
==22866==
==22866== For counts of detected and suppressed errors, rerun with: -v
==22866== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
显示的大多数记录（但 1 条）是 "still reachable blocks"。我读到这些可能是由于池释放延迟所致。即在我的 main(argc,argv){} 函数终止后释放容器（例如我经常使用的 vectors ）。
但是，肯定有问题，因为在执行大约 8-9 小时后，我清楚地看到可执行文件使用的内存比开始时多（在我的电脑中，它开始时内存使用量为 0.6%，之后8h用了大概6%).
问题是这些是神秘的消息 - 绝对 none 来自我的源文件。正如我所读 here “_dl*” 调用与 linux 加载程序有关。那么我怎样才能查明问题的根源呢？
我应该补充一点，这段代码使用了
- 1+3 个线程（用于所有阻塞操作，即从标准输入和串行端口读取数据并将数据写入文件），
- boost 库（尤其是循环缓冲区），以及
- gsl 库。
然而，我已经从小的概念验证部分构建了代码，这些代码在 valgrind 中没有显示任何 errors/warnings。
此外，我的代码中只有有限数量的指向 class 对象的指针，我在各自的析构函数中验证了 delete。
原始分配调用来自共享库初始化代码，当您的应用程序链接的共享库在 运行 加载时执行，通常在您的任何应用程序代码实际加载之前 运行s。这就是为什么您在回溯中看不到您的代码的原因。它甚至还没有 运行。
要查找的关键符号是_dl_init，共享库初始化的入口点。查看它的上游会告诉您正在初始化哪个库。在您的例子中，它是一堆 Gnome 库和一个名为 "libpixman".
共享库也有一个清理函数，当共享库被卸载时会被调用。
well-organized 共享库将使用共享库清理函数有序地释放它在启动时分配的所有内存。不幸的是，这种对细节的疏忽很常见：共享库从堆中分配一堆内存，用于共享库的内部静态表，而无需在共享库卸载时重新分配该内存。
这不太可能是您在应用程序 运行ning 期间观察到的内存泄漏的原因，但我稍后会提到的一种情况除外。根据我的经验，这种草率的分配做法仅用于共享库在加载时分配一次的静态表。这里的想法是没有必要在自己之后明确清理，因为当进程退出时，库只会被卸载一次。
遗憾的是，偷工减料的开发人员从未听说过 dlopen() 和 dlclose()。这使得大型应用程序无法仅在需要时按需加载共享库，然后再卸载它，直到再次需要它。
因此，除非您的应用程序代码重复 dlopen()ing 和 dlclose()ing 所有这些 Gnome 库和 libpixman，否则您将不得不继续在其他地方寻找漏洞.您应该继续阅读并使用 valgrind 的抑制文件，以抑制其输出中的这种烦人的噪音。