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

Bug #930291 reported by Hernando Torque on 2012-02-10
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Application Indicators
Fix Released
indicator-application (Ubuntu)

Bug Description

I monitored some processes while the system was idling (see Over seven hours, indicator-application-service gained ~70 MiB resident memory consumption.

I'm attaching a valgrind log (less than an hour runtime), though I've been told on IRC that this isn't really helpful, but at least the issue is now reported. :-)

==5285== LEAK SUMMARY:
==5285== definitely lost: 554,553 bytes in 7,712 blocks
==5285== indirectly lost: 6,904,435 bytes in 169,367 blocks
==5285== possibly lost: 7,313 bytes in 132 blocks
==5285== still reachable: 388,048 bytes in 10,436 blocks
==5285== suppressed: 0 bytes in 0 blocks

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: indicator-application 0.4.90-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-15.24-generic 3.2.5
Uname: Linux 3.2.0-15-generic x86_64
ApportVersion: 1.91-0ubuntu1
Architecture: amd64
Date: Fri Feb 10 18:33:28 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20110901)
SourcePackage: indicator-application
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Hernando Torque (htorque) wrote :
Omer Akram (om26er) on 2012-02-10
Changed in indicator-application (Ubuntu):
importance: Undecided → High
Sven Baars (sbte) on 2012-02-11
Changed in indicator-application (Ubuntu):
status: New → In Progress
assignee: nobody → sbte (sbte)
Omer Akram (om26er) on 2012-02-11
Changed in indicator-application:
importance: Undecided → High
status: New → In Progress
assignee: nobody → sbte (sbte)
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/
==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)

Sven Baars (sbte) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in indicator-application (Ubuntu):
status: In Progress → Fix Released
Hernando Torque (htorque) wrote :

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

Changed in indicator-application (Ubuntu):
status: Fix Released → In Progress
Charles Kerr (charlesk) wrote :

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

Hernando Torque (htorque) wrote :

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/
==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)

Hernando Torque (htorque) wrote :

Seems fixed in 0.4.92-0ubuntu1 (more precisely, with 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

Hernando Torque (htorque) wrote :

Oops, forgot the attachment.

Sven Baars (sbte) on 2012-03-14
Changed in indicator-application:
assignee: sbte (sbte) → nobody
Changed in indicator-application (Ubuntu):
assignee: sbte (sbte) → nobody
Changed in indicator-application:
status: In Progress → Fix Committed
Changed in indicator-application (Ubuntu):
status: In Progress → Fix Committed
Changed in indicator-application:
status: Fix Committed → Fix Released
Changed in indicator-application (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers