Valgrind memory leaks : callstack not going back to my code-CodePudding

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)

==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

CodePudding user response：

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.

CodePudding user response：

IMHO you can safely ignore these leaks, or even use the suppression file to let valgrind discard them.

These lines:

==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)

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.