Ubuntu
indicator-multiload package

Small memory leak (~200 KiB/h)

Bug #956810 reported by Hernando Torque
42
This bug affects 8 people
Affects Status Importance Assigned to Milestone
DBus Menu
New
Undecided
Unassigned
System Load Indicator
New
Undecided
Unassigned
indicator-multiload (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I let the system idle over night and the indicator-multiload process constantly consumed more memory (about 200 KiB/h). Biggest leak according to valgrind:

==16637== 11,080 bytes in 277 blocks are definitely lost in loss record 7,227 of 7,245
==16637== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16637== by 0x6757BC8: g_malloc (gmem.c:159)
==16637== by 0x676A8B2: g_slice_alloc (gslice.c:1003)
==16637== by 0x67849F9: g_variant_alloc (gvariant-core.c:476)
==16637== by 0x6784B5C: g_variant_new_from_children (gvariant-core.c:562)
==16637== by 0x67821E5: g_variant_builder_end (gvariant.c:3573)
==16637== by 0x6786347: array_get_value (gvariant-parser.c:913)
==16637== by 0x67855C9: maybe_wrapper (gvariant-parser.c:843)
==16637== by 0x6788611: g_variant_parse (gvariant-parser.c:527)
==16637== by 0x74040C5: menuitem_property_idle (server.c:1019)
==16637== by 0x6751DD9: g_main_context_dispatch (gmain.c:2510)
==16637== by 0x675219F: g_main_context_iterate.isra.23 (gmain.c:3118)
==16637== by 0x6752263: g_main_context_iteration (gmain.c:3179)
==16637== by 0x5FEB993: g_application_run (gapplication.c:1496)
==16637== by 0x40C1CF: main_main (main.c:1203)
==16637== by 0x6C3D76C: (below main) (libc-start.c:226)
==16637==
==16637== LEAK SUMMARY:
==16637== definitely lost: 11,225 bytes in 281 blocks
==16637== indirectly lost: 0 bytes in 0 blocks
==16637== possibly lost: 60,704 bytes in 897 blocks
==16637== still reachable: 1,369,295 bytes in 20,094 blocks

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: indicator-multiload 0.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
Date: Fri Mar 16 10:52:57 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20110901)
SourcePackage: indicator-multiload
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Hernando Torque (htorque) wrote :
Revision history for this message
Twbecker (twbecker) wrote :

FYI I'm also seeing a major leak in Precise. Went on vacation for 4 days and indicator-multiload was using ~5GB!

Revision history for this message
Kevin Turner (keturn) wrote :

The filenames in that valgrind stack don't match those in the indicator-multiload source I have. They seem to all be standard glib files. Not sure if that narrows things down at all.

Revision history for this message
Kevin Turner (keturn) wrote :

the menuitem_property_idle -> g_variant_parse bits make it sound like bug LP #784890, but that was marked fixed in libdbusmenu (0.4.90-0ubuntu1) oneiric;

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in indicator-multiload (Ubuntu):
status: New → Confirmed
Revision history for this message
Kevin Turner (keturn) wrote :

I confirmed with massif that the libdbusmenu menuitem_property_idle function in htorque's valgrind traceback allocating the bulk of the memory in the process and it increases linearly with time. See https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/784808/comments/3

Revision history for this message
Kevin Turner (keturn) wrote :

Okay, bug 784808 was instructive, but I think that one really _was_ resolved and it's a related (but not _exactly_ the same) issue we're dealing with here. I suspect the culprit is this patch http://bazaar.launchpad.net/~dbusmenu-team/dbusmenu/trunk.0.6/revision/362.4.1 to libdbusmenu.

It adds g_variant_ref_sink calls to the results of calls to g_variant_parse. But the results of g_variant_parse are *not* floating references*, so this is adding a second reference.

If gotsomething is false (as it may be if we took the g_variant_parse path), we don't call dbus_connection_emit_signal, we only unref once, and that's clearly not enough. (And actually, if !gotsomething && !removeitem_init, we don't seem to do _anything_ with megadata, so it's not clear why we'd do that megadata[1] = g_variant_parse at all).

If gotsomething is true, we g_variant_new_tuple(megadata), and that tuple adds a reference to each of its elements†, so I'm not sure why we'd need to add an additional reference ourselves beforehand.

What any of that has to do with your uninitialized bytes from https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/929707 I haven't figured out.

* https://bugs.launchpad.net/dbusmenu/+bug/784808/comments/1
† http://git.gnome.org/browse/glib/tree/glib/gvariant.c?h=glib-2-32#n877

Revision history for this message
Mike Doherty (doherty) wrote :

Hi, I'm currently seeing ~1GB memory usage, which I noted on #1030293. Are these two bugs duplicates?

Revision history for this message
Giorgio Sintichakis (gsintichakis) wrote :

What's the status of this bug? Is it slated for a fix in an upcoming release?

Revision history for this message
sds (sds-gnu) wrote :

how is this bug different from bug#905854 & bug#1049282

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.