CODEWITHSUNDEEP
cmemory-leaksvalgrind
abqjln
abqjln

Reputation: 19

frame level valgrind library suppressions confusion

Learning stackoverflow and how to suppress library leaks in glib. If I run my code using the included glib.supp file

valgrind --suppressions=/usr/share/glib-2.0/valgrind/glib.supp --leak-check=full --track-origins=yes --show-leak-kinds=all <executable>

I get, for example

==11014== 64 bytes in 1 blocks are still reachable in loss record 684 of 1,144
==11014== at 0x48850C8: malloc (vg_replace_malloc.c:381)
==11014== by 0x4BAD48F: g_malloc (in /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0.7400.6)
==11014== by 0x4BC813B: g_memdup2 (in /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0.7400.6)
==11014== by 0x4B928FB: ??? (in /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0.7400.6)
==11014== by 0x49E206F: g_dbus_connection_signal_subscribe (in /usr/lib/aarch64-linux-gnu/libgio-2.0.so.0.7400.6)
==11014== by 0x133A3F: setup_signal_subscribers (adapter.c:692)
==11014== by 0x133D57: binc_adapter_create (adapter.c:760)
==11014== by 0x133FFB: binc_adapter_find_all (adapter.c:813)
==11014== by 0x126DDF: gl_adapter_init_all (gl_adapter.c:33)
==11014== by 0x124E2F: main (k2cps.c:157)

which I have been interpreting as my code (adapter.c and gl_adapter.c) using the g_dbus_connection_signal_subscribe improperly.

But valgrind finds no issues if I use my own suppression file

valgrind --suppressions=/myfile.supp --leak-check=full --track-origins=yes --show-leak-kinds=all <executable>

where myfile.supp is

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   ...
   obj:/usr/lib/aarch64-linux-gnu/libgio-2.0.so.*
   ...
}

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   ...
   obj:/usr/lib/aarch64-linux-gnu/libglib-2.0.so.*
   ...
}

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   ...
   obj:/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.*
   ...
}

Am I suppressing an issue in my code? If in the library, I would have expected the included /usr/share/glib-2.0/valgrind/glib.supp to suppress this?

Upvotes: 1

Views: 36

Answers (2)

Paul Floyd
Paul Floyd

Reputation: 6936

I would expect it not to leak and as a last resort for the suppression file to do its job. That seems to be to much to ask of glib.

In your suppressions, you don't need ... on the last line.

Also your suppressions are extremely broad. In particular there will be issues if there are any callbacks from those libs to your code. Any leaks in your callbacks will be masked. It would be better if you could make the suppressions more specific.

Upvotes: 0

legendaryCoder69
legendaryCoder69

Reputation: 21

dbus has known memory leaks as shown by valgrind. A workaround is to close dbus entirely, sdl dbus issues

Upvotes: 2

Related Questions