XFCE 4.8 on Ubuntu 12.04.1 LTS Heap is 1.7GB. Could this be a memory leak? martin@lennie:~$ ps uaxwww | grep cpugraph martin 3117 0.7 14.8 2021068 591148 ? Sl Dec12 166:36 /usr/lib/xfce4-cpugraph-plugin/xfce4/panel-plugins/xfce4-cpugraph-plugin 25 14680120 cpugraph CPU Graph Graphical representation of the CPU load martin@lennie:~$ uptime 21:13:07 up 15 days, 21:39, 30 users, load average: 0.73, 1.19, 1.46 martin@lennie:~$ uname -a Linux lennie 3.5.0-18-generic #29-Ubuntu SMP Thu Oct 25 07:26:14 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux martin@lennie:~$ cat /proc/3117/maps | grep '\[' 7fc4a6ed0000-7fc4a76d0000 rw-p 00000000 00:00 0 [stack:23770] 7fc4b7e5a000-7fc51fbae000 rw-p 00000000 00:00 0 [heap] 7fffb2507000-7fffb2528000 rw-p 00000000 00:00 0 [stack] 7fffb25ff000-7fffb2600000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] martin@lennie:~$
Which version of cpugraph plugin and gtk-xfce-engine do you have ? I'm pretty sure it's a duplicate of https://bugzilla.xfce.org/show_bug.cgi?id=9125 which has been fixed when the leak in gtk-xfce-engine got fixed in https://bugzilla.xfce.org/show_bug.cgi?id=8521. To make it short, make sure to have gtk-xfce-engine 3.0.1, or report a bug against your distro.
I can confirm this, it happends on both my machines: Archlinux x86_64 gtk-xfce-engine 3.0.1 after ?14? days cpugraph was eating 4GiB!!! of ram (i have 8GiB ram and 6 core CPU) Archlinux i686 gtk-xfce-engine 3.0.1 after 10 days cpu cpugraph was eating ~1200MiB of ram (i have 2GiB ram and 2 core CPU on this machine) I restarted cpugraph yesterday and now it eats 200MiB! xfce4-cpugraph-plugin 1.0.5
Created attachment 4874 Screenshot of htop Here is screenshot of htop after ~2 days of run
Why do you have 3 instances of the plugin running ? What gtk theme are you using ?
(In reply to comment #4) > Why do you have 3 instances of the plugin running ? > > What gtk theme are you using ? I have a similar report of a user using xfce4-cpugraph-plugin 1.0.4 with the Adwaita gtk theme, see https://bugzilla.novell.com/show_bug.cgi?id=777527
Created attachment 4968 cpugraph valgrind log I've been able to reproduce this myself now on openSUSE 12.3 with xfce4-cpugraph-plugin 1.0.4, see the attached the valgrind log. I'm using the adwaita 3.6.2 theme engine, not gtk-xfce-engine. The plugin configuration is as follows: UpdateInterval=0 TimeScale=0 Size=16 Mode=0 Frame=1 Border=1 Bars=1 TrackedCore=0 Command=xfce4-taskmanager InTerminal=0 StartupNotification=1 ColorMode=1 Foreground1=#0000ffff0000 Foreground2=#ffff00000000 Foreground3=#00000000ffff Background=#ffffffffffff BarsColor=#4b4b69698383
==8985== 3,816,192 bytes in 14,907 blocks are definitely lost in loss record 3,599 of 3,599 ==8985== at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==8985== by 0x969BEAA: _pixman_image_allocate (pixman-image.c:184) ==8985== by 0x966AAC7: create_bits_image_internal (pixman-bits-image.c:1490) ==8985== by 0x5BEAC19: _cairo_xlib_shm_surface_create.isra.11 (cairo-xlib-surface-shm.c:768) ==8985== by 0x5BEB4F6: _cairo_xlib_surface_create_shm (cairo-xlib-surface-shm.c:1085) ==8985== by 0x5BEB599: _cairo_xlib_surface_create_similar_shm (cairo-xlib-surface-shm.c:1112) ==8985== by 0x5BE6150: _cairo_xlib_source_create_for_pattern (cairo-xlib-source.c:955) ==8985== by 0x5BCC3E5: clip_and_composite_boxes (cairo-traps-compositor.c:1272) ==8985== by 0x5BCD196: _cairo_traps_compositor_fill (cairo-traps-compositor.c:2198) ==8985== by 0x5B7A5B9: _cairo_compositor_fill (cairo-compositor.c:203) ==8985== by 0x5BE7597: _cairo_xlib_surface_fill (cairo-xlib-surface.c:1594) ==8985== by 0x5BBABF3: _cairo_surface_fill (cairo-surface.c:2222) So that's a leak from cairo, but nothing here tells us where it comes from - if its from the gtk engine (adwaita in that case) or the plugin itself... not really helpful. Another interesting data point would be to figure if all the display modes leak, or only one (le leds vs grid vs normal vs no history..) Same for the color mode: fire vs gradient vs solid.
Note that the plugin itself doesnt use cairo directly, the gtk engine uses cairo.
(In reply to comment #4) > Why do you have 3 instances of the plugin running ? I have no clue, i just added plugin on panel :-) And this is default behavior. > What gtk theme are you using ? Adawatia
(In reply to comment #7) > ==8985== 3,816,192 bytes in 14,907 blocks are definitely lost in loss record > 3,599 of 3,599 > ==8985== at 0x4C2C27B: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==8985== by 0x969BEAA: _pixman_image_allocate (pixman-image.c:184) > ==8985== by 0x966AAC7: create_bits_image_internal > (pixman-bits-image.c:1490) > ==8985== by 0x5BEAC19: _cairo_xlib_shm_surface_create.isra.11 > (cairo-xlib-surface-shm.c:768) > ==8985== by 0x5BEB4F6: _cairo_xlib_surface_create_shm > (cairo-xlib-surface-shm.c:1085) > ==8985== by 0x5BEB599: _cairo_xlib_surface_create_similar_shm > (cairo-xlib-surface-shm.c:1112) > ==8985== by 0x5BE6150: _cairo_xlib_source_create_for_pattern > (cairo-xlib-source.c:955) > ==8985== by 0x5BCC3E5: clip_and_composite_boxes > (cairo-traps-compositor.c:1272) > ==8985== by 0x5BCD196: _cairo_traps_compositor_fill > (cairo-traps-compositor.c:2198) > ==8985== by 0x5B7A5B9: _cairo_compositor_fill (cairo-compositor.c:203) > ==8985== by 0x5BE7597: _cairo_xlib_surface_fill > (cairo-xlib-surface.c:1594) > ==8985== by 0x5BBABF3: _cairo_surface_fill (cairo-surface.c:2222) > > So that's a leak from cairo, but nothing here tells us where it comes from - > if its from the gtk engine (adwaita in that case) or the plugin itself... > not really helpful. > > Another interesting data point would be to figure if all the display modes > leak, or only one (le leds vs grid vs normal vs no history..) Same for the > color mode: fire vs gradient vs solid. Leak is same for all color modes (if i remember right), but i will test it for you to be sure. + it looks like memory usage is affected by number of monitored CPU cores (14days == 2 cores ~1,2GiB / 6 cores ~4,5GiB)
It looks that the problem might be in adwaita gtk2 engine - not really surprising since it's not used a lot outside gtk3.. Can you switch to a theme provided by gtk-xfce-engine 3.0.1 (any of the default Xfce theme) and confirm that over time the memory usage doesnt grow ?
*** Bug 9956 has been marked as a duplicate of this bug. ***
Mass-reassign all bugs from florian@ to goodies-dev@, thanks for the maintenance work! (and sorry for the bugmail spam..)
Probably fixed after the gtk3 port, if not please reopen.