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

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)

Oh, apparently I opened the wrong valgrind log when I looked into this. I was looking at a log where it was leaking a GVariant. Thanks for pointing that out Ted.

This bug was fixed in the package indicator-application - 0.4.91-0ubuntu1

---------------
indicator-application (0.4.91-0ubuntu1) precise; urgency=low

  * New upstream release.
    * Unref approval data after use (lp: #930291)
 -- Ted Gould <email address hidden> Wed, 15 Feb 2012 12:08:30 -0600

A leak was fixed, unfortunately not this one yet. :-)

Hernando, could you attach a new valgrind log from 0.4.91 ?

The biggest one is still the same

==7902== 9,926,465 (737,712 direct, 9,188,753 indirect) bytes in 10,246 blocks are definitely lost in loss record 1,562 of 1,562
==7902== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7902== by 0x5A6ABC8: g_malloc (gmem.c:159)
==7902== by 0x5A7D892: g_slice_alloc (gslice.c:1003)
==7902== by 0x5A7DDD5: g_slice_alloc0 (gslice.c:1029)
==7902== by 0x57FE839: g_type_create_instance (gtype.c:1872)
==7902== by 0x57E2FB8: g_object_constructor (gobject.c:1849)
==7902== by 0x57E4B21: g_object_newv (gobject.c:1632)
==7902== by 0x57E510B: g_object_new (gobject.c:1542)
==7902== by 0x553E8A8: g_dbus_message_new_from_blob (gdbusmessage.c:1685)
==7902== by 0x55497BD: _g_dbus_worker_do_read_cb (gdbusprivate.c:752)
==7902== by 0x54E594C: g_simple_async_result_complete (gsimpleasyncresult.c:744)
==7902== by 0x54E5A7B: complete_in_idle_cb (gsimpleasyncresult.c:756)
==7902== by 0x5A64DD9: g_main_context_dispatch (gmain.c:2510)
==7902== by 0x5A6519F: g_main_context_iterate.isra.23 (gmain.c:3118)
==7902== by 0x5A65599: g_main_loop_run (gmain.c:3312)
==7902== by 0x5547445: gdbus_shared_thread_func (gdbusprivate.c:276)
==7902== by 0x5A867D4: g_thread_proxy (gthread.c:801)
==7902== by 0x5D18E99: start_thread (pthread_create.c:308)
==7902== by 0x601E74C: clone (clone.S:112)

Seems fixed in 0.4.92-0ubuntu1 (more precisely, with revision 72: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/indicator-application/precise/revision/72).

Valgrind from one hour:

==26238== LEAK SUMMARY:
==26238== definitely lost: 208 bytes in 25 blocks
==26238== indirectly lost: 240 bytes in 10 blocks
==26238== possibly lost: 9,028 bytes in 156 blocks
==26238== still reachable: 397,582 bytes in 10,729 blocks
==26238== suppressed: 0 bytes in 0 blocks

Oops, forgot the attachment.