I think there is a memory leak in the cpugraph plugin. Over time, it uses up more and more memory, and I have to kill it. Here's its consumption (via top) after a day or so: 16201 brho 20 0 336m 142m 15m R 0.0 7.2 5:13.62 xfce4-cpugraph- I checked the /proc/PID/maps, and here's how it changes over a 15 minute window: -08053000-0e734000 rw-p 00000000 00:00 0 [heap] -a906d000-a9073000 rw-p 00000000 00:00 0 +08053000-0e994000 rw-p 00000000 00:00 0 [heap] +a9067000-a9073000 rw-p 00000000 00:00 0 FWIW, netgraph also seems to consume an increasing amount of memory, but it's not as bad: 16202 brho 20 0 98.3m 72m 13m S 0.0 3.6 1:11.53 xfce4-netload-p Is there a way I can run the plugin from the command line with valgrind or something to help track this down? I'm using xfce4-cpugraph-plugin-1.0.1 on Gentoo, kernel 3.2.5-gentoo, on a 32 bit machine.
After about 24 hours, here's the new memory usage info: Top usage info today: 16201 brho 20 0 459m 265m 15m S 0.3 13.3 11:14.22 xfce4-cpugraph- 16202 brho 20 0 136m 110m 13m S 0.0 5.6 2:28.21 xfce4-netload-p Old usage from yesterday: 16201 brho 20 0 336m 142m 15m R 0.0 7.2 5:13.62 xfce4-cpugraph- 16202 brho 20 0 98.3m 72m 13m S 0.0 3.6 1:11.53 xfce4-netload-p Change in heap for cpugraph: -08053000-0e734000 rw-p 00000000 00:00 0 [heap] +08053000-163b4000 rw-p 00000000 00:00 0 [heap]
I have similar issues with this plugin and other ones (wavelan, sensors). Running xfce4-cpugraph-plugin-1.0.1 on a 64-bit Gentoo OS.
I can confirm this issue with v1.0.1 (on gentoo). It seems to eat more and more RAM; I've seen up to a couple of gigs. It's very consistent in leaking! ;-)
I don't have this problem in Xubuntu 12.04. After 4 days it uses 0.2% of main memory. It seems to be a problem specific to Gentoo.
(In reply to comment #4) > It seems to be a problem specific to Gentoo. > Bug 408529 was opened for this: https://bugs.gentoo.org/show_bug.cgi?id=408529
Created attachment 4483 compressed output of cpugraph run through valgrind Here's the valgrind output from cpugraph after running for a couple hours on a Gentoo system. I ran it according to the instructions from http://wiki.xfce.org/howto/panel_plugin_debug#debug_with_valgrind_full_example. One caveat: the wrapped plugin complained with the message "(xfce4-cpugraph-plugin:23479): CRITICAL **: _xpp_provider_signal: assertion `GDK_IS_WINDOW (window)' failed" in the terminal in which I started xfce4-panel. I didn't see the actual plugin running on the panel, and I had to kill the process from the console. I don't know if that messes up the valgrind output or not.
*** Bug 9025 has been marked as a duplicate of this bug. ***
According to the valgrind log most of the leaks are in cairo/drawing code.. i'll try to look into it.
To all the people having this issue.. can you precise the update interval/graph mode/color mode/OS/distro/etc ? We should try to find if the issue is only seen on Linux, or only in certain configurations. I'm definitely seeing a constant & low memory usage here on OpenBSD.
Just to confirm, I am seeing this on Ubuntu Precise 12.04 using the http://ppa.launchpad.net/xubuntu-dev/xfce-4.10/ubuntu repository. As detailed in bug 9025 (which was duped to this bug) my mode of operation is: Mode: "Normal" Color mode: "Solid". Update interval: "Fastest (~250ms)"
I cant reproduce it here on OpenBSD with gtk 2.24/cairo 1.10.2, after some days running cpugraph doesnt eat more than 4Mo.. Can anyone confirm it with code from git ? There were no drawing changes since 1.0.1, but in any case.. The GdkGC code is also now deprecated in gtk, one should rewrite it using directly cairo like it's done in xfce4-taskmanager (see http://git.xfce.org/apps/xfce4-taskmanager/tree/src/process-monitor.c#n170)
http://digamma.cs.unm.edu/~dmohr/cpugraph-valgrind.squisher.log.bz2 Captured on Gentoo with cpugraph 1.0.2, gtk+ 2.24.10-r1, cairo 1.10.2-r2 I had it running for ~2 days.
Hello, To me it looks like a leak in Cairo. @David, Can you try with a different Gtk Engine? You seem you be using the Xfce Gtk Engine. All what these plugins share in common is: - they run on Gentoo - they are plugins that get updated periodically through a short timeout - they update labels, progressbars, or in the case of the cpugraph plugin a custom drawing of lines And the code of these plugins didn't change much if not at all. Last release dates: - xfce4-cpufreq-plugin 2011-01-23 - xfce4-cpugraph-plugin 2012-07-04 (bug was reported in February, from that time the last release was from 2010-12-05) - xfce4-netload-plugin 2012-01-13 I'm not sure if you all use the Xfce Gtk Engine, maybe there is a leak in the engine? Regards, Mike
(In reply to comment #13) > - they run on Gentoo Not only Gentoo, brian reproduces it on Ubuntu, comment 10. @brian, which Gtk theme engine are you using? (name and version)
(In reply to comment #14) > > Not only Gentoo, brian reproduces it on Ubuntu, comment 10. Yup. > @brian, which Gtk theme engine are you using? (name and version) I dunno. I don't typically screw around with look and feel crap beyond getting colours and contrast usable. How do I determine my theme engine name and version?
@Mike, good idea: I can confirm that the leaks stop after switching to a different gtk engine (Clearlooks). Seems like this bug should be reassigned.
Reassigning to Gtk-xfce-engine product
(In reply to comment #15) > (In reply to comment #14) > > > > Not only Gentoo, brian reproduces it on Ubuntu, comment 10. > > Yup. > > > @brian, which Gtk theme engine are you using? (name and version) > > I dunno. I don't typically screw around with look and feel crap beyond > getting colours and contrast usable. How do I determine my theme engine > name and version? The name of your current GTK theme, and the list of installed engines will do. Under Ubuntu run for example the command "dpkg -l | grep gtk.*engines" to retrieve the list of installed GTK theme engines. Mike
*** Bug 8925 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > > The name of your current GTK theme, That's what I don't know how to find. Maybe it's Applications Menu->Settings->Appearance->Style? That says "Xfce". > and the list of installed engines will > do. Yeah, that's the easy part. :-) > Under Ubuntu run for example the command "dpkg -l | grep gtk.*engines" to > retrieve the list of installed GTK theme engines. Right: $ dpkg -l | grep gtk.*engines | sed -e 's/ */ /g' ii gtk2-engines 1:2.20.2-1ubuntu1 theme engines for GTK+ 2.x ii gtk2-engines-aurora 1.5.1-2 Aurora gtk+-2.0 theme engine ii gtk2-engines-candido 0.9.1-pablo4 Candido engine for GTK+ 2.x ii gtk2-engines-murrine 0.98.2-0ubuntu1 cairo-based gtk+-2.0 theme engine ii gtk2-engines-pixbuf 2.24.10-0ubuntu6 pixbuf-based theme for GTK+ 2.x ii gtk2-engines-xfce 3.0.0-0ubuntu1~ppa1 GTK+-2.0 theme engine for Xfce ii gtk3-engines-unico 1.0.2-0ubuntu1 Unico Gtk+ 3 theme engine
FWIW, I was using Xfce-dawn style, and switched to Raleigh. After a couple of days, it seems like the plugins are not leaking memory. The setting (for me, on Gentoo) was under Settings->Appearance->Style.
Can someone confirm that the leaks in the other plugins exhibiting the issue are also fixed
doh, forgot to finish my sentence; Can someone confirm that the leaks in the other plugins (netload ?) exhibiting the issue are also fixed by switching to another theme engine ?
I finally reproduced the issue too, and monitored netload/cpugraph memory use over 16h, with update interval set to 1s : netload VSZ went from 7.5M to 29M cpugraph VSZ went from 18M to 45M as soon as you switch to a theme that doesnt use gtk-xfce-engine, the memory usage becomes stable. Ill check with other plugins but i think any plugin that uses cairo drawing (so progressbars etc) should exhibit the leak.
(In reply to comment #23) > Can someone confirm that the leaks in the other plugins (netload ?) > exhibiting the issue are also fixed by switching to another theme engine ? Yes. I can confirm. Systemload plugin, Bug 8925. After switching to Adwaita theme no memory leak.
I've got a fix: at the end of gradient_draw_shaded() in gtk_2.0/gradient_draw.c of the xfce-engine code, after the line cairo_restore(cr); add the line cairo_pattern_destroy(gradient); The Cairo docs say that the object returned by any of the cairo_pattern_create_* functions is owned by the caller, and must be destroyed using the cairo_pattern_destroy() function. The current code doesn't do this; instead, it leaks a gradient pattern every time it draws something.
Created attachment 4603 dont leak a gradient pattern So, something like this... peter ? can you test/confirm this ? Testing it here to see if it causes no regression.
That seems to fix the leak here.. can anyone experiencing this bug report if the patch fixes the issue for them too ? (btw, mark, good catch :)
(In reply to comment #28) > That seems to fix the leak here.. can anyone experiencing this bug report if > the patch fixes the issue for them too ? 48 hours of running the patched xfce-engine, and cpugraph memory usage hasn't changed.
Testing patched gtk-xfce-engine for 44 hours. No leak in systemload plugin.
Mark, thank you for finding the solution. And also, thank you all for testing the patch. This patch is committed in 964d4a0 It will be in the next bugfix release.
(In reply to comment #27) > Created attachment 4603 > dont leak a gradient pattern > > So, something like this... peter ? can you test/confirm this ? > Testing it here to see if it causes no regression. Thanks. Patch imported as 'gtk-engines-xfce-3.0.0-r201' to Gentoo's Portage. Would be nice to have this released sometime soon.
This is in release 3.0.1
*** Bug 9849 has been marked as a duplicate of this bug. ***