我倾向于不时与Valgrind进行泄漏检查，以确保我的代码没有泄漏。通常，它是无泄漏的，或者我会得到泄漏发生的位置（即，即使在某些库中发生泄漏，我也会将呼叫堆栈返回到我编写的代码）。
但是，这次我得到了19个泄漏（“可能丢失”），这些泄漏不会追溯到我的代码：这是怎么可能的？有什么想法如何找到问题？
valgrind命令：
valgrind --leak-check=full --num-callers=100 ./my_programm
典型的错误未追溯到我的代码：
==5524== 96 bytes in 1 blocks are possibly lost in loss record 3,116 of 3,773
==5524== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==5524== by 0x62DCEF0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==5524== by 0x625B0E7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x625B28A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x625F0C8: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x623AEDE: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x62340B7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x4011B89: call_init.part.0 (dl-init.c:72)
==5524== by 0x4011C90: call_init (dl-init.c:30)
==5524== by 0x4011C90: _dl_init (dl-init.c:119)
==5524== by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
还是
==5524== 16 bytes in 1 blocks are possibly lost in loss record 1,353 of 3,773
==5524== at 0x483B723: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==5524== by 0x483E017: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==5524== by 0x62DCF3F: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==5524== by 0x625BD57: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x625F0D6: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x623AEDE: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x62340B7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x4011B89: call_init.part.0 (dl-init.c:72)
==5524== by 0x4011C90: call_init (dl-init.c:30)
==5524== by 0x4011C90: _dl_init (dl-init.c:119)
==5524== by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
有什么想法？
NB：我正在使用的唯一库（例外）是OpenCV 4.2。
我没有做任何明确的多线程，但是第19个内存泄漏让我认为引擎盖下发生了一些事情：这可能是这些内存泄漏未回到其呼叫堆栈中的用户代码的原因吗？
19th泄漏：
==5524== 544 bytes in 1 blocks are possibly lost in loss record 3,680 of 3,773
==5524== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==5524== by 0x40149CA: allocate_dtv (dl-tls.c:286)
==5524== by 0x40149CA: _dl_allocate_tls (dl-tls.c:532)
==5524== by 0x8229322: allocate_stack (allocatestack.c:622)
==5524== by 0x8229322: pthread_create@@GLIBC_2.2.5 (pthread_create.c:660)
==5524== by 0x8281750: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.2)
==5524== by 0x82819EE: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.2)
==5524== by 0x8281A8C: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.2)
==5524== by 0x8228608: start_thread (pthread_create.c:477)
==5524== by 0x574F162: clone (clone.S:95)
非常感谢
I tend to do a leak-check with valgrind from time to time, just to ensure my code is leak-free. Usually, either it is leak free, or I get some trace to where the leak occurs (ie even if the leak occurs in some library, I get the call-stack back to the code I wrote).
This time, however, I get 19 leaks ("possibly lost") that do NOT trace back to my code : how is this possible? Any idea how to proceed to find the problem?
Valgrind command :
valgrind --leak-check=full --num-callers=100 ./my_programm
typical errors not tracing back to my code :
==5524== 96 bytes in 1 blocks are possibly lost in loss record 3,116 of 3,773
==5524== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==5524== by 0x62DCEF0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==5524== by 0x625B0E7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x625B28A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x625F0C8: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x623AEDE: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x62340B7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x4011B89: call_init.part.0 (dl-init.c:72)
==5524== by 0x4011C90: call_init (dl-init.c:30)
==5524== by 0x4011C90: _dl_init (dl-init.c:119)
==5524== by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
or
==5524== 16 bytes in 1 blocks are possibly lost in loss record 1,353 of 3,773
==5524== at 0x483B723: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==5524== by 0x483E017: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==5524== by 0x62DCF3F: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==5524== by 0x625BD57: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x625F0D6: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x623AEDE: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x62340B7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==5524== by 0x4011B89: call_init.part.0 (dl-init.c:72)
==5524== by 0x4011C90: call_init (dl-init.c:30)
==5524== by 0x4011C90: _dl_init (dl-init.c:119)
==5524== by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
Any idea?
NB : The only library (excepted std) I'm using is openCV 4.2.
I'm not doing any explicit multithreading, but the 19th memory leak lets me think there is some going on under the hood : might this be the reason for those memory leaks not going back to user code in their call-stack?
19th leak :
==5524== 544 bytes in 1 blocks are possibly lost in loss record 3,680 of 3,773
==5524== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==5524== by 0x40149CA: allocate_dtv (dl-tls.c:286)
==5524== by 0x40149CA: _dl_allocate_tls (dl-tls.c:532)
==5524== by 0x8229322: allocate_stack (allocatestack.c:622)
==5524== by 0x8229322: pthread_create@@GLIBC_2.2.5 (pthread_create.c:660)
==5524== by 0x8281750: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.2)
==5524== by 0x82819EE: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.2)
==5524== by 0x8281A8C: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.2)
==5524== by 0x8228608: start_thread (pthread_create.c:477)
==5524== by 0x574F162: clone (clone.S:95)
Thanks a lot in advance
发布评论
评论（2）
GLIB是否具有“免费资源”功能？
否则，会有这篇文章
内存
被打破了，请尝试一下
根据上述文件来判断，这不是您的问题，并且GLIB有很多泄漏。在我看来，有100多次抑制，似乎glib的人们正在滥用抑制以掩盖其缺陷。
Does GLib have a "free resources" function?
Otherwise, there is this post
Memory leak in libwnck
the link to the suppression file is broken, try this one
https://github.com/frida/glib/blob/main/glib.supp
Judging by the above file, it isn't your problem and GLib has many leaks. With over 100 suppressions it seems to me that the GLib folks are abusing suppressions to cover over their defects.
恕我直言，您可以安全地忽略这些泄漏，甚至可以使用他们。
这些行：
建议可能丢失的内存是加载共享库时一次分配的资源，因此只要您不用 dlopen 您应该没事。
IMHO you can safely ignore these leaks, or even use the suppression file to let valgrind discard them.
These lines:
suggest that the possibly lost memory are the resources allocated once when the shared library is loaded, so as long as you don't load your libraries by hand multiple times with dlopen you should be ok.