Comment 2 for bug 930291

Revision history for this message
Ted Gould (ted) wrote :

It seems like the biggest leak there is coming from a GDBus message. Probably one getting created that we're either keeping a ref when we shouldn't or not unref'ing when we should. I looked through the code and didn't see anything. But, I thought I'd leave a comment for the next person :-/

==5285== 7,458,523 (554,328 direct, 6,904,195 indirect) bytes in 7,699 blocks are definitely lost in loss record 1,568 of 1,568
==5285== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5285== by 0x5A69918: g_malloc (gmem.c:159)
==5285== by 0x5A7C5E2: g_slice_alloc (gslice.c:1003)
==5285== by 0x5A7CB25: g_slice_alloc0 (gslice.c:1029)
==5285== by 0x57FD859: g_type_create_instance (gtype.c:1872)
==5285== by 0x57E1FC8: g_object_constructor (gobject.c:1839)
==5285== by 0x57E3B41: g_object_newv (gobject.c:1622)
==5285== by 0x57E412B: g_object_new (gobject.c:1532)
==5285== by 0x553E558: g_dbus_message_new_from_blob (gdbusmessage.c:1685)