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?

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?

• c
• memory-leaks
• valgrind

2 Answers 2

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

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.