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)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/930291

Title:
  indicator-application-service leaking memory (~10 MiB/h)

To manage notifications about this bug go to:
https://bugs.launchpad.net/indicator-application/+bug/930291/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to