indicator-session is leaking memory on ubuntu 15.10

[Jelle De Loecker]

The `indicator-session-service` is slowly leaking memory, after a while it has used up over 10 gigabytes of RAM and swap and the entire system freezes.

I've reinstalled the entire OS, and even started using a new home folder, but it's still happening.

indicator-session:
  Geïnstalleerd: 12.10.5+15.10.20150915-0ubuntu1
  Kandidaat: 12.10.5+15.10.20150915-0ubuntu1
  Versietabel:
 *** 12.10.5+15.10.20150915-0ubuntu1 0
        500 http://be.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
        100 /var/lib/dpkg/status

[Sebastien Bacher (seb128)]

Thank you for your bug report. Do you have an usual configuration, especially in regards to system users and how they are managed? Could you try to obtain a valgrind log following the instructions at https://wiki.ubuntu.com/Valgrind and attach the file to the bug report. This will greatly help us in tracking down your problem.

[Jelle De Loecker (skerit)]

I haven't encountered it again until today. It doesn't happen all the time, but it doesn't just go away with a reboot either.
I've written a crontab that kills the process every 10 minutes, that's the best workaround for now.
Haven't had time to try valgrind.

However, something strange is going on and it's not limited to indicator-session, as you can see in the attached htop screenshot.
It's also unity-settings-daemon and the accounts-daemon. So I don't really know *what* to try now.

The bug title says "memory leak", that still is the case, though the htop screenshot also shows high cpu usage is a problem.

[Jelle De Loecker (skerit)]

About the configuration:
The system runs on an SSD, with only a root and home partition.

The only special thing is that there is no swap partition, but a swap *file* on the root disk.

It's running on a relative simple nvidia card, with 2 or 3 monitors.

[Jelle De Loecker (skerit)]

The system hasn't been up for 2 hours, but it's leaking memory like crazy again:

indicator-sound-service: 2121M
unity-settings-daemon: 1452M
indicator-messages-service: 1421M
accounts-daemon: 1063M
indicator-session-service: 717M

That's over 6 gigabytes, and restarting any of the processes does not help.

[kevin (kevinsiji)]

Me too.

Fresh installation of 15.10 and old /home partition.
More worse than listed by @Jelle De Loecker (skerit) have listed in #5.

Had to reset many times, if I missed to kill the indicator-session-service process in every minute.

[Jelle De Loecker (skerit)]

So how can we test this with valgrind? Something like this doesn't work:

    killall unity-settings-daemon && G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log /usr/lib/unity-settings-daemon/unity-settings-daemon

I get an error:

    ** (unity-settings-daemon:24485): WARNING **: Name taken or bus went away - shutting down

[Jelle De Loecker (skerit)]

I tried running indicator-sound-service and indicator-session-indicator under valgrind, though it didn't seem to do much.

indicator-sound-session actually used less memory, but it didn't seem to respond too well. Clicking on the indicator didn't show the regular menu.

[Jelle De Loecker (skerit)]

I tracked down the problem to the `accounts-daemon` process.

Once I disabled that, as described in the link below, my problems seem to have gone away.
indicator-sound-service, unity-settings-daemon, ... are all behaving correctly.

I have yet to figure out what impact disabling the `accounts-daemon` process has, though.

http://askubuntu.com/questions/685193/what-starts-accounts-daemon

[Gustavo Carneiro (gjc)]

Today I found this /usr/lib/x86_64-linux-gnu/indicator-session/indicator-session-service consuming 4GB of RAM, before I killed it. I have 16 GB total, but still... Running up-to-date Ubuntu 15.10.

[Chow Loong Jin (hyperair)]

I ran it through valgrind by diverting indicator-session-service and replacing it with the following script:

#!/bin/bash

exec valgrind \
    --tool=massif \
    --alloc-fn={g_slice_alloc,g_malloc,g_realloc} \
    --massif-out-file=$HOME/massif-dump/indicator-session-service.out.%p \
    /usr/lib/x86_64-linux-gnu/indicator-session/indicator-session-service.distrib \
    "$@"

Running ms_print on the output files gave me some stack traces of the highest number of unfreed allocations:

60.92% (1,262,577,672B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->17.05% (353,258,600B) 0x568AC5C: g_variant_new_from_children (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
| ->08.46% (175,306,320B) 0x568798A: g_variant_builder_end (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
| | ->08.46% (175,306,120B) 0x4F05434: parse_value_from_blob (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | ->04.23% (87,682,360B) 0x4F05120: parse_value_from_blob (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | ->04.23% (87,682,360B) 0x4F05400: parse_value_from_blob (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | | ->04.23% (87,682,360B) 0x4F0501F: parse_value_from_blob (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | | ->04.23% (87,682,360B) 0x4F05120: parse_value_from_blob (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | | ->04.23% (87,682,360B) 0x4F051E8: parse_value_from_blob (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | | ->04.23% (87,682,360B) 0x4F0747A: g_dbus_message_new_from_blob (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | | ->04.23% (87,682,360B) 0x4F1168B: _g_dbus_worker_do_read_cb (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | | ->04.23% (87,682,360B) 0x4EB45F1: g_task_return_now (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | | ->04.22% (87,503,000B) 0x4EB4627: complete_in_idle_cb (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | | | ->04.22% (87,503,000B) 0x564FEA8: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
| | | | | | ->04.22% (87,503,000B) 0x565024E: g_main_context_iterate.isra.29 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
| | | | | | ->04.22% (87,503,000B) 0x5650570: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
| | | | | | ->04.22% (87,503,000B) 0x4F0F4C4: gdbus_shared_thread_func (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.1)
| | | | | | ->04.22% (87,503,000B) 0x5676963: g_thread_proxy (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
| | | | | | ->04.22% (87,503,000B) 0x69B96A8: start_thread (pthread_create.c:333)
| | | | | | ->04.22% (87,503,000B) 0x5A1BEEB: clone (clone.S:109)

I've attached the full dump from ms_print.

[Chow Loong Jin (hyperair)]

As a temporary workaround, I've been running this script in background which kills indicator-session-service when it hits 500M of rss:

#!/bin/sh
while sleep 1; do
    rss=$(ps -C indicator-session-service -o rss=)
    if [ -n "$rss" ] && [ "$rss" -gt 500000 ]; then
        pkill -f indicator-session-service -u hyperair && \
            echo "[$(date)] killed at $rss"
    fi
done

[Sebastien Bacher (seb128)]

the valgrind has no indicator code but it could be the same as bug #1545308 which is a glib / GDBusProxy issue, see https://bugzilla.gnome.org/show_bug.cgi?id=758641

[Matthew Willson (matthew-willson)]

I also have an issue with unity-settings-daemon leaking memory.

Usually after leaving the machine overnight I come in to a unity-settings-daemon crash, with no crash report due to lack of free memory.

In the last few hours it's gone from 170M to 316M and still gradually climbing.

This is on 16.04.

[Charles Kerr (charlesk)]

Matthew, please report the separate unity-settings-daemon issue to <https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon> so that it can be tracked there.

Regarding the glib parse_value_from_blob() reported above, it looks like the upstream fix mentioned by seb128 is in 16.04. Is anyone still seeing indicator-session leak memory in >= 16.04?