2008/5/2 Ionutz Borcoman <iborco@xxxxxxxxx>: > 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
