Static Analysis Tools for GLib and GDBus

479 views Asked by At

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?

1

There are 1 answers

0
drahnr On BEST ANSWER

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)