Re: checking for memory leaks in gtk

[jcupitt gmail com]

2008/5/2 Ionutz Borcoman <iborco gmail com>:
>  Actually my own leak are my greatest concern. The problem is that having those
>  leaks reported because of how glib caches data makes debugging your own code
>  harder.
>
>  Any recipe to easily spot or isolate your allocations/dealocations from those
>  from GTK/Glib?
>
>  How do you know the leak is because I haven't freed the memory or because I've
>  freed it, but Glib hasn't?

Here's an example. I started my app (about 250,000 line of C, so quite
large), did a few things, and shut it down again. Run with:

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind  --leak-check=yes
nip2 &> leaklog

It's about 500 lines of output, so I won't paste it here. Looking at
leaklog, I have a lot of crap at the start with 'invalid read' in
ld.so as my program is linked (I really need to update my suppressions
file), then the first reported leak is this (trimmed a bit):

==18092== 292 (52 direct, 240 indirect) bytes in 1 blocks are
definitely lost in loss record 59 of 199
==18092==    by 0xA77C240: (within /lib/libc-2.7.so)
==18092==    by 0xA77CAFE: __nss_database_lookup (in /lib/libc-2.7.so)
==18092==    by 0xA730A40: getpwnam_r (in /lib/libc-2.7.so)
==18092==    by 0xA21ECDF: (within /usr/lib/libglib-2.0.so.0.1600.3)
==18092==    by 0xA220444: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.1600.3)

This is clearly some platform nonsense. The next one (again, trimmed a bit) is:

==18092== 98 bytes in 6 blocks are definitely lost in loss record 73 of 199
==18092==    by 0x9953DC3: FcStrCopy (in /usr/lib/libfontconfig.so.1.3.0)
==18092==    by 0x995705A: (within /usr/lib/libfontconfig.so.1.3.0)
==18092==    by 0xD13EFEA: (within /usr/lib/libexpat.so.1.5.2)
==18092==    by 0xD136000: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
==18092==    by 0x9956533: FcConfigParseAndLoad (in
/usr/lib/libfontconfig.so.1.3.0)
==18092==    by 0x9956623: (within /usr/lib/libfontconfig.so.1.3.0)

Obviously something to do with the fontconfig parser. Next is:

==18092== 729 (360 direct, 369 indirect) bytes in 3 blocks are
definitely lost in loss record 118 of 199
==18092==    by 0x6DECEF6: xmlNewText (in /usr/lib/libxml2.so.2.6.31)
==18092==    by 0x5341E3: prettify_tree_sub (util.c:438)
==18092==    by 0x5342AE: prettify_tree (util.c:467)
==18092==    by 0x45F8A5: filemodel_save_all_xml (filemodel.c:282)
==18092==    by 0x45FACA: filemodel_real_save_all (filemodel.c:338)
==18092==    by 0x545487: workspace_save_all (workspace.c:1271)
==18092==    by 0x45F27B: filemodel_save_all (filemodel.c:128)
==18092==    by 0x54387C: workspace_checkmark_timeout (workspace.c:637)
==18092==    by 0xA1EF98A: (within /usr/lib/libglib-2.0.so.0.1600.3)
==18092==    by 0xA1EF261: g_main_context_dispatch (in
/usr/lib/libglib-2.0.so.0.1600.3)
==18092==    by 0xA1F2515: (within /usr/lib/libglib-2.0.so.0.1600.3)

And this is one of mine. I know about this one: for debugging, I paste
some whitespace into my xml savefiles to make then easier to read and
don't bother freeing the strings (it's just debugging code). This is
clearly one of mine, since the calls are all rooted in my source
files.

A useful trick is to run a gtk 'hello world' program under valgrind
with the --gen-suppressions flag. Assuming you don't have any leaks in
your gtk hello-world program (!!), the generated suppressions file
will then make valgrind remove all the system and background leaks and
errors from your reports.

John