Memory leaking from the unityshell plugin

[Hernando Torque]

I let the system idle for 8 hours (directly after session start), and compiz' memory usage constantly increased. Over eight hours it gained around 15 MiB. I tried the same without the Unity plugin and the memory usage didn't change at all. I've then run another 8 hour session with valgrind:

==9167== LEAK SUMMARY:
==9167== definitely lost: 13,650,435 bytes in 225,382 blocks
==9167== indirectly lost: 4,042,819 bytes in 228,218 blocks
==9167== possibly lost: 567,041 bytes in 2,276 blocks
==9167== still reachable: 13,597,443 bytes in 67,918 blocks
==9167== suppressed: 0 bytes in 0 blocks

Complete log attached, HTH.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity 4.24.0-0ubuntu2b1
ProcVersionSignature: Ubuntu 3.1.0-2.3-generic 3.1.0
Uname: Linux 3.1.0-2-generic x86_64
ApportVersion: 1.25-0ubuntu1
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,compiztoolbox,decor,move,vpswitch,place,mousepoll,resize,imgpng,regex,gnomecompat,grid,snap,wall,session,animation,expo,workarounds,ezoom,staticswitcher,fade,scale,unityshell]
Date: Sat Nov 5 09:04:50 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20110112)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

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

[Hernando Torque (htorque)]

I'd like to confirm this with Unity in Precise from the testing PPA.

Also the amount stayed about the same (~20MB in 8h30m).

[Omer Akram (om26er)]

subscribed Daniel, incase he might be interested. I hope I am not doing that more often?

[Daniel van Vugt (vanvugt)]

I think this bug is either going to be a duplicate (because I have seen a few of these over the past year) or never resolved. Because Unity is too big and complex to declare that all its leaks are fixed any time soon.

Instead, I think it's more appropriate to separate each leak into a separate bug. So at least we can realistically test and verify that individual leaks are fixed.

[Hernando Torque (htorque)]

Sounds great, but how? Is there anything else a user can do than runnig valgrind while the problem arises? E.g., I can reliably reproduce _this_ (bunch of) leak(s): 1. log in, 2. do nothing, 3. goto 2.

Would it maybe help to let it collect data even longer so possible culprits stand out a bit more?

[Daniel van Vugt (vanvugt)]

Simply log each leak as a separate bug, putting the stack of the leak in the bug description. For example:

==9167== 5,062,678 (2,251,200 direct, 2,811,478 indirect) bytes in 56,280 blocks are definitely lost in loss record 19,601 of 19,602
==9167== at 0x4C293CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9167== by 0x66AD632: g_malloc (gmem.c:164)
==9167== by 0x66C23B6: g_slice_alloc (gslice.c:842)
==9167== by 0x66E09F9: g_variant_alloc (gvariant-core.c:475)
==9167== by 0x66E0AD2: g_variant_new_from_buffer (gvariant-core.c:509)
==9167== by 0x66DA87E: g_variant_new_from_trusted (gvariant.c:320)
==9167== by 0x91329D0: parse_value_from_blob (gdbusmessage.c:1219)
==9167== by 0x9132BBA: parse_value_from_blob (gdbusmessage.c:1446)
==9167== by 0x913437D: g_dbus_message_new_from_blob (gdbusmessage.c:1800)
==9167== by 0x913F718: _g_dbus_worker_do_read_cb (gdbusprivate.c:713)
==9167== by 0x90E6C16: g_simple_async_result_complete (gsimpleasyncresult.c:749)
==9167== by 0x90E6D28: complete_in_idle_cb (gsimpleasyncresult.c:761)
==9167== by 0x66A6A0C: g_main_context_dispatch (gmain.c:2425)
==9167== by 0x66A7207: g_main_context_iterate.isra.21 (gmain.c:3073)
==9167== by 0x66A7741: g_main_loop_run (gmain.c:3281)
==9167== by 0x913D5C5: gdbus_shared_thread_func (gdbusprivate.c:276)
==9167== by 0x66CC265: g_thread_create_proxy (gthread.c:1962)
==9167== by 0x6B68EFB: start_thread (pthread_create.c:304)
==9167== by 0x77FE89C: clone (clone.S:112)
==9167==

Then we can investigate each one separately and have a realistic chance of being able to fully resolve some of them. Maybe just start with those that say "definitely lost" :)

Longer runs are usually helpful, but in the case of unity I think it has so many leaks that we're already overwhelmed with data.

[Daniel van Vugt (vanvugt)]

I would suggest picking the leaks that are several megs in size and say "definitely lost". They're much more likely to get the attention of a developer.