When running xfdesktop and leaving it idle for a long time (overnight), there appears to be an about 10% chance that xfdesktop will grow in size until it uses all memory on the computer, after which the machine crashes. xfdesktop was identified as the probable cause by doing a 'ps' every 5 minutes. The xscreensaver is running, and uses only the 'Blank Screen' setting. It seemed that with fancier screensavers, crashes happened more often, but I cannot quantify that. I realize this is very little to work with, and if you can recommend additional tests I'll try to comply. Reproducible: Sometimes Steps to Reproduce: 1. Start up xfce, xfdesktop. 2. Walk away from the computer for several hours/days. 3. Installed via 'standard' rpms for RedHat/Fedora. Problem first noticed at 4.2 version of xfce, and has persisted across kernel/glibc/ upgrades/glibc (minor) upgrades gtk+-1.2.10-31 gtk2-2.2.4-15 gtk-xfce-engine-2.2.6-1 xscreensaver-4.10-8 glibc-2.3.2-95.33
Now running xfdesktop manually from a window, I noticed that once korganizer is active (which I use regularly), a reload-like occurrance happens every minute or two, at each of which the memory used by xfdesktop grows by 2MB or so. The korganizer installed is from the RPM kdepim-1.3.1-3.3. The errors that pop up at each 'reload-like' event in the xterm from which xfdesktop is running are: *** attempt to put segment in horiz list twice Extra content at the end of the document ( repeated 10 more times ) *** attempt to put segment in horiz list twice ( repeated a couple hundred times ) Extra content at the end of the document ( repeated 4 more times) At first glance, it might be related to Bug 955. I hope this helps.
When running 'xfdesktop -reload' by hand, each time the size of xfdesktop grows by roughly 2MB. I can include a 'strace' log, if that would be useful.
I probably won't have time to look at this for another week at least. The only thing really useful here is a valgrind log, with --tool=memcheck, -v, --leak-check, and --num-callers=15 or so. Generally it's easiest to use --log-file (or whatever the option is) to get the output to a file rather than stdout/stderr. Note that the app will run *dirt slow* in valgrind, as valgrind will emulate the host CPU.
Created attachment 269 valgrind dump from running xfdesktop xfdesktop did not contain debug symbols, so this valgrind dump is probably not as useful as it could be. I understand you don't have time to look into it now. Let me know if something else would be useful.
Yeah, debug symbols would be more useful, and it looks like the stacks are taller than I thought: --num-callers=30 or so would give a better result.
When added xfce-menu -plugin to xfce4-panel, It also started hoggin memory (now it takes 107megabytes). Only '*** attempt to put segment in horiz list twice' error messages go into ~/.xsession-errors file.
Created attachment 321 xfdesktop valgrind log here is a valgrind log with debug syms and --num-callers=30. this was left idle for ~2hrs during which time the valgrind.bin process grew ~10MB
Hmm... well, I'm not seeing anything I've not seen before. Some memory lost in librsvg opening SVG icons, but I've been over that code many times, and I'm relatively sure I'm not leaking anything. It's possible I'm wrong, but... I dunno.
This is real and is most definitely tied to xfce-menu (in 4.2.2 at least; just fetched 4.2.3.1 and have not compiled it yet). I'd seen the "desktop" process get as large as 400 MB and thought "I don't need that anyway" so killed it. But I rather missed the menu, so added it to the panel. Now the panel gets to several hundred MB... In the xterm from which I've launched the menu-containing panel, I get the errors mentioned previously on stderr: *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice (sometimes hundreds? of such lines!) (xfce4-panel:7647): libxfce4util-CRITICAL **: xfce_desktop_entry_new: assertion `g_file_test (priv->file, G_FILE_TEST_EXISTS)' failed This happens every couple of minutes on average. Sometimes more, sometimes less frequently. In my X session started last October 10, the running log file I'm "tee"ing to 2>&1 is currently 50199516 bytes and of 1064715 lines, 1056719 are the "attempt to put segment" message, and 3732 are the .*failed message.
Ok, what version of librsvg do you have installed? Can you try something? I'd like you to remove gdk-pixbuf's SVG image loader and see if that solves the problem. Depending on your GTK version, it'll probably be in /usr/lib/gtk-2.0/$major_version.$minor_version.0/engines/libsvg.* (Note that 2.6.x and 2.8.x still use the 2.4.0 directory.) Anyway just move the libsvg.* files somewhere else, and then restart xfdesktop and/or xfce4-panel. Watch the memory usage and see if it still leaks memory and report back. (BTW, those warning messages are harmless. The former is a librsvg bug, and the latter is weird but couldn't be causing a memleak.)
In my case, it's: "checking for librsvg-2.0 >= 2.0... 2.6.5" Moving the libsvg.* files which were mentioned to somewhere else had no effect on a fresh xfce startup. So long as the menu is in service, whichever of the desktop or panel components is carrying it will progressively enlarge their memory footprint when so "equipped". I've not had the chance yet to compile the latest xfce release.
Any progess on this ? I may well be having a similar issue. I have been using xfce4 for about 18mths and have found it very reliable but I have had a number of lockups recently. Having made a number of changes recently xfce was not the prime suspect. I have not started any phorensics on them yet but this seems to fit. I generally shut down once a day but have been leaving the maching switched on for serveral days at a time recently. So I have only seen it 2 or 3 times. I need to get to the bottom of this , I do not expect to need the reset button on a linux box! What is the best way to see the per process memory usage? (I need the machine so I can't cripple it by running xfce4 in valgrind.) Thanks.
Ok guys, here's the deal. I haven't been able to reproduce this, and I haven't run 4.2.x in a long time. If you want to try out SVN and report if that still gives you trouble, fine, but I don't have the time to debug the 4.2 branch. 4.4.0 should be out before April, so you may just have to wait. I'm sorry about this, but my time is very limited, and I don't have enough to devote to this bug. If anyone else wants to give it a shot, feel free.
maybe this bug is caused by a bug in pango[1] then a bug in librsvg[2]. only MAYBE. [1] http://bugzilla.gnome.org/show_bug.cgi?id=143542 [2] http://bugzilla.gnome.org/show_bug.cgi?id=344235
(In reply to comment #14) > maybe this bug is caused by a bug in pango[1] then a bug in librsvg[2]. only > MAYBE. > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=143542 > [2] http://bugzilla.gnome.org/show_bug.cgi?id=344235 [1] has nothing to do with this bug. I doubt [2] does either. Comment #11 seems to indicate this isn't related to SVG. I'm closing this for now. There won't be any new work on the 4.2 branch. We can track memleaks in the 4.4 branch over at bug 1910.