0

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

Sandro
  • 117
  • 4
  • Obvious comment: Are you properly waiting for all threads you spawn to finish (i.e. `join`ing them) _before_ the program finishes? – Mike Vine May 25 '22 at 07:52
  • I have no idea. I'm not spanning any thread explicitly, but I suppose OpenCV is doing it internaly (it's the only reason I see why I could get multithreading), so I have no idea how to check if openCV waits for them. This might be the cause, but I have no clue how I could investigate and/or correct it. – Sandro May 25 '22 at 07:56

2 Answers2

2

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.

Paul Floyd
  • 5,530
  • 5
  • 29
  • 43
  • Thanks, libg seems indeed to be the (major) culprit : by adding the suppression file from your link, 17 out of 19 errors disappeared. Out of the 2 remaining ones, one seems also to be libg related (same format, also going into libgobject-2.0.so). So there remains the leak #19 (that is already at the bottom of the initial post) + one I haven't mentioned before because it goes back to my code (might still be a library issue, but maybe not). For GLib "free ressources" function, I have no idea if there is one, but as I never explicitly include GLib, it shouldn't be my responsability to call it. – Sandro May 25 '22 at 08:57
2

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.

pptaszni
  • 5,591
  • 5
  • 27
  • 43