wingpanel using too much memory

[gfilippi]

Hi,

I'm using ElementaryOS Loki 0.4.1 and wingpanel is leaking memory.

using "top" I can see virt memory taking up 100G (gigabytes).

I never paid attention to this issue for almost 1y .. but now suddenly I noticed the huge amount of memory wasted by wingpanel.

any help?
anyone else having the same problem?

[biswaz]

I have the same problem. Virtual memory in the order of GBs (98).

[tintou]

Hi there, we need more data to figure-out what is happening, do you have the legacy indicator installed with some indicators like Dropbox, Slack or Skype? Any non-default app? did you setup your calendar in the calendar application? Do you have Wifi, Bluetooth? Are you using a laptop or a desktop?

[gfilippi]

I have a default installation on a i7 desktop.

absolutely no extra indicators, I never added anything.
I don;t use calendar at all.

the only indicators that are present from your list are BT and WiFi

thanks

[biswaz]

Kdeconnect, redshift indicators are installed. Tried to install the nightlight indicator from github, after executing all installation commands from github readme file, no visible results where observed. (I am running loki). Have setup calender with google account. Wifi and bluetooth are working fine, mostly. Using a laptop.

[biswaz]

lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 260M 0 part /boot/efi
├─sda2 8:2 0 128M 0 part
├─sda3 8:3 0 812.3G 0 part
├─sda4 8:4 0 37.9G 0 part /
├─sda5 8:5 0 3.9G 0 part [SWAP]
├─sda6 8:6 0 20.4G 0 part
└─sda7 8:7 0 55.9G 0 part /home

Mounted partition has largest size of 55.9GB then how is it even possible to have 98 GB of virtual memory?

[gfilippi]

in my case I have two disks in raid1

lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
└─isw_jfdcheega_samsung-r1 252:0 0 477G 0 dmraid
├─isw_jfdcheega_samsung-r1p1 252:2 0 512M 0 part /boot/efi
├─isw_jfdcheega_samsung-r1p2 252:3 0 460.5G 0 part /
└─isw_jfdcheega_samsung-r1p3 252:4 0 15.9G 0 part [SWAP]
sdb 8:16 0 477G 0 disk
└─isw_jfdcheega_samsung-r1 252:0 0 477G 0 dmraid
├─isw_jfdcheega_samsung-r1p1 252:2 0 512M 0 part /boot/efi
├─isw_jfdcheega_samsung-r1p2 252:3 0 460.5G 0 part /
└─isw_jfdcheega_samsung-r1p3 252:4 0 15.9G 0 part [SWAP]
sr0 11:0 1 1024M 0 rom

[quequotion]

Interesting. Not sure if this is much use, but it doesn't seem to be a problem with wingpanel-standalone-git
This a fork based on the development version--which itself may not be having this issue--that has patches to remove Gala-dependent functions.

Wingpanel-standalone opens with an initial VIRT of 1354468, which jumps to 2673460 after opening slingshot. From there it goes up a little for each initial click on an indicator, but I haven't been able to get it over 3GB even though I have wingpanel-indicator-{session,notifications,sound,ayatana}-git and the Ayatana indicators glippy-indicator, indicator-powersave, indicator-sensors, and ubuntu-indicator-weather.

It may just be that the development versions of wingpanel and/or the indicators don't have the problem, but I also suspect that being plugged into Gala could cause significant leakage or at least much greater demand for virtual memory.

[JosephMcc]

The use of Virtual memory doesn't matter here. Small bit of info: https://serverfault.com/questions/138427/top-what-does-virtual-memory-size-mean-linux-ubuntu

[eighthave]

I have this problem also, except wingpanel is using up all RAM, not virtual memory, making my machine lock up. It seems to be accelerated by having the owncloud-client v2.1.1 from Ubuntu/xenial running. Sounds like this https://elementaryos.stackexchange.com/questions/7743/owncloud-client-makes-loki-unresponsive

[drequivalent]

Affects me as well.
I have Nextcloud client running, I don't know if it is an issue

[electricduck]

Usually uses about 150-200MiB of RAM for me. In comparison, Xfce's panel only uses about 25MiB (which I use to provide systray apps for apps that still use them -- boo!).

Have bluetooth on, and get notifications every few minutes. Apart from that, no other modifications or anything.

[andey]

I just did a fresh install of elementary OS two days ago and I noticed wingpanel uses up a solid 350mb+ in memory just sitting there idle.

Is there a reason why it uses so much memory? Is there some points I can use to help bring it down?

[bigalgeorge]

me too using 113Gb

[Akryum]

Still seeing this in eOS 6.1:

(Cleared notifications)

Looks like a memory leak to me

[Akryum]

After killing wingpanel so it restarts:

[tintou]

@Akryum is it with elementary Juno/Jólnir? Can you try running valgring io.elementary.wingpanel to understand where the memory leak might come from?

[Akryum]

I'll post you the result of the command after a while, when wingpanel memory usage will increase.

[Akryum]

Currently wingpanel uses 1GB of memory (notifications cleared)

valgrind io.elementary.wingpanel
==143897== Memcheck, a memory error detector
==143897== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==143897== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==143897== Command: io.elementary.wingpanel
==143897== 
--143897-- WARNING: unhandled amd64-linux syscall: 315
--143897-- You may be able to write your own handler.
--143897-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--143897-- Nevertheless we consider this a bug.  Please report
--143897-- it at http://valgrind.org/support/bug_reports.html.
==143897== 
==143897== HEAP SUMMARY:
==143897==     in use at exit: 200,755 bytes in 2,266 blocks
==143897==   total heap usage: 6,151 allocs, 3,885 frees, 409,254 bytes allocated
==143897== 
==143897== LEAK SUMMARY:
==143897==    definitely lost: 0 bytes in 0 blocks
==143897==    indirectly lost: 0 bytes in 0 blocks
==143897==      possibly lost: 3,296 bytes in 28 blocks
==143897==    still reachable: 181,891 bytes in 2,115 blocks
==143897==                       of which reachable via heuristic:
==143897==                         length64           : 1,696 bytes in 28 blocks
==143897==                         newarray           : 1,840 bytes in 35 blocks
==143897==         suppressed: 0 bytes in 0 blocks
==143897== Rerun with --leak-check=full to see details of leaked memory
==143897== 
==143897== For lists of detected and suppressed errors, rerun with: -s
==143897== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[tintou]

Thanks, it looks like it's not really a memory leak but probably some objects stucks in a queue, could you rerun it with:

valgrind --leak-check=full --suppressions=/usr/share/glib-2.0/valgrind/glib.supp --suppressions=/usr/share/gtk-3.0/valgrind/gtk.supp io.elementary.wingpanel

Which would give us pointers about where the issue might be in your system

[Akryum]

valgrind --leak-check=full --suppressions=/usr/share/glib-2.0/valgrind/glib.supp --suppressions=/usr/share/gtk-3.0/valgrind/gtk.supp io.elementary.wingpanel
==185968== Memcheck, a memory error detector
==185968== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==185968== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==185968== Command: io.elementary.wingpanel
==185968== 
==185968== FATAL: can't open suppressions file "/usr/share/gtk-3.0/valgrind/gtk.supp"

[Akryum]

@tintou Am I missing some dependencies for run this command?

[tintou]

Ah yes, the gtk.supp is in libgtk-3-dev same for the glib one that is in libglib2.0-dev

[Akryum]

~$ valgrind --leak-check=full --suppressions=/usr/share/glib-2.0/valgrind/glib.supp --suppressions=/usr/share/gtk-3.0/valgrind/gtk.supp io.elementary.wingpanel
==478964== Memcheck, a memory error detector
==478964== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==478964== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==478964== Command: io.elementary.wingpanel
==478964== 
--478964-- WARNING: unhandled amd64-linux syscall: 315
--478964-- You may be able to write your own handler.
--478964-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--478964-- Nevertheless we consider this a bug.  Please report
--478964-- it at http://valgrind.org/support/bug_reports.html.
==478964== 
==478964== HEAP SUMMARY:
==478964==     in use at exit: 200,756 bytes in 2,266 blocks
==478964==   total heap usage: 6,174 allocs, 3,908 frees, 410,438 bytes allocated
==478964== 
==478964== 24 bytes in 1 blocks are possibly lost in loss record 606 of 1,834
==478964==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==478964==    by 0x48C7EF0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x4BB333C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB2E84: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B9EF07: g_param_spec_flags (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4A79D3D: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x4BB31D0: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB2E84: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB2E84: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B95C37: g_object_new_with_properties (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B966F0: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x111FBF: main (in /usr/bin/io.elementary.wingpanel)
==478964== 
==478964== 32 bytes in 1 blocks are possibly lost in loss record 886 of 1,834
==478964==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==478964==    by 0x48C7EF0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x4BB333C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB2E84: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B9EDF7: g_param_spec_enum (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4AB5A78: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x4BB31D0: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB2E84: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B965E0: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x49E9633: g_async_initable_new_valist_async (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x49E970C: g_async_initable_new_async (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x1148B9: ??? (in /usr/bin/io.elementary.wingpanel)
==478964== 
==478964== 80 bytes in 1 blocks are possibly lost in loss record 1,340 of 1,834
==478964==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==478964==    by 0x48C7EF0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x4BB333C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB2E84: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB4FC7: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B9A5FF: g_param_spec_internal (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B9F13C: g_param_spec_string (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4A79CEC: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x4BB31D0: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB2E84: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB2E84: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B95C37: g_object_new_with_properties (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964== 
==478964== 96 bytes in 1 blocks are possibly lost in loss record 1,587 of 1,834
==478964==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==478964==    by 0x48C7EF0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x4BB00E7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4BB028A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B88FDE: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4011B89: call_init.part.0 (dl-init.c:72)
==478964==    by 0x4011C90: call_init (dl-init.c:30)
==478964==    by 0x4011C90: _dl_init (dl-init.c:119)
==478964==    by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==478964== 
==478964== 368 bytes in 1 blocks are possibly lost in loss record 1,782 of 1,834
==478964==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==478964==    by 0x40149CA: allocate_dtv (dl-tls.c:286)
==478964==    by 0x40149CA: _dl_allocate_tls (dl-tls.c:532)
==478964==    by 0x5872322: allocate_stack (allocatestack.c:622)
==478964==    by 0x5872322: pthread_create@@GLIBC_2.2.5 (pthread_create.c:660)
==478964==    by 0x490F2BA: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x48EBEC3: g_thread_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x48EC9D3: g_thread_pool_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x4A4DD1B: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x4A4E144: g_task_get_type (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x4A4E2FC: g_task_new (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x115C5E: ??? (in /usr/bin/io.elementary.wingpanel)
==478964==    by 0x4B9426B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B95B44: g_object_new_with_properties (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964== 
==478964== 368 bytes in 1 blocks are possibly lost in loss record 1,783 of 1,834
==478964==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==478964==    by 0x40149CA: allocate_dtv (dl-tls.c:286)
==478964==    by 0x40149CA: _dl_allocate_tls (dl-tls.c:532)
==478964==    by 0x5872322: allocate_stack (allocatestack.c:622)
==478964==    by 0x5872322: pthread_create@@GLIBC_2.2.5 (pthread_create.c:660)
==478964==    by 0x490F2BA: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x48EBEC3: g_thread_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x48C3423: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x4A4DD97: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x4A4E144: g_task_get_type (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x4A4E2FC: g_task_new (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x115C5E: ??? (in /usr/bin/io.elementary.wingpanel)
==478964==    by 0x4B9426B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964==    by 0x4B95B44: g_object_new_with_properties (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==478964== 
==478964== 368 bytes in 1 blocks are possibly lost in loss record 1,784 of 1,834
==478964==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==478964==    by 0x40149CA: allocate_dtv (dl-tls.c:286)
==478964==    by 0x40149CA: _dl_allocate_tls (dl-tls.c:532)
==478964==    by 0x5872322: allocate_stack (allocatestack.c:622)
==478964==    by 0x5872322: pthread_create@@GLIBC_2.2.5 (pthread_create.c:660)
==478964==    by 0x490F2BA: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x48EBF40: g_thread_try_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x48EC189: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x48EBAD0: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x5871608: start_thread (pthread_create.c:477)
==478964==    by 0x571D292: clone (clone.S:95)
==478964== 
==478964== 368 bytes in 1 blocks are possibly lost in loss record 1,785 of 1,834
==478964==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==478964==    by 0x40149CA: allocate_dtv (dl-tls.c:286)
==478964==    by 0x40149CA: _dl_allocate_tls (dl-tls.c:532)
==478964==    by 0x5872322: allocate_stack (allocatestack.c:622)
==478964==    by 0x5872322: pthread_create@@GLIBC_2.2.5 (pthread_create.c:660)
==478964==    by 0x490F2BA: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x48EBEC3: g_thread_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x4AB8A53: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x4AABBE6: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x49E909B: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x4A4EC61: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.6)
==478964==    by 0x48EC373: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x48EBAD0: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==478964==    by 0x5871608: start_thread (pthread_create.c:477)
==478964== 
==478964== LEAK SUMMARY:
==478964==    definitely lost: 0 bytes in 0 blocks
==478964==    indirectly lost: 0 bytes in 0 blocks
==478964==      possibly lost: 1,704 bytes in 8 blocks
==478964==    still reachable: 139,454 bytes in 1,385 blocks
==478964==                       of which reachable via heuristic:
==478964==                         length64           : 1,696 bytes in 28 blocks
==478964==                         newarray           : 1,840 bytes in 35 blocks
==478964==         suppressed: 44,030 bytes in 750 blocks
==478964== Reachable blocks (those to which a pointer was found) are not shown.
==478964== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==478964== 
==478964== For lists of detected and suppressed errors, rerun with: -s
==478964== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 20 from 20)

Current memory usage is 1.4 GiB

[peteruithoven]

Possibly related issues:

• Large number of notifications slow down whole panel wingpanel-indicator-notifications#237
• By opening Applications Menu, Wingpanel begin to use too much memory applications-menu#117 (comment)

@Akryum could you maybe check whether any of these apply to you?