2

Does anyone know of any tools or techniques for detecting memory leaks when using GLib and GDBus? I am relatively new to using both libraries and believe I am using the API's correctly, but it would be great if there was a tool that I could use to confirm that I am cleaning up my resources correctly. I have ran my code through various lint-type programs, but these likely do not detect anything abstracted away into a library.

I am looking for either a tool aimed specifically at GLib or GDBus or a tool that I could instrument so target these libraries? Maybe there are even some compile time flags that I can set for GLib or GDBus?

waffleman
  • 4,159
  • 10
  • 39
  • 63

1 Answers1

3

I just recently did some voodoo with glib/gdbus/libsoup and from my experience valgrind and valgrind/massif do a very good job (though not really static analysis but runtime analysis).

valgrind (use malloc even for g_slice_alloc/g_slice_new, makes valgrind less confused, gc-friendly nullifies all glib internal pointers)

G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind ./yourapp

There will be still false positives in the output – use a supression file to hide them.

massif (use resident modules to prevent a lot of noise)

G_DEBUG=resident-modules valgrind --tool=massif --depth=10 --max-snapshots=1000 --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc          --alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc --threshold=0.01 ./yourapp --your --app --options

Use some visualization tool to make massifs output readable (couple of MB logs) massif-visualizer does a good job

Keep in mind that glib has a couple of MB of static allocated stuff (all the GObject type classes)

If you need to debug the libraries themself, there is no way around compiling them with debug flags (-g)

drahnr
  • 6,782
  • 5
  • 48
  • 75