Description of problem:This is a re-submit of an earlier problem w/ the same
description (bug 417211). That was closed out when the leaks apparently
disappeared after upgrading. After several weeks logged in, they seem to be
back, though less severe than before (take longer to show up)
Version-Release number of selected component (if applicable): xfce-4.4.2-1.fc8
How reproducible: log into a FC8-x86_64 box undef XFCE 4.4.2-1.fc8 & wait a few
Steps to Reproduce:see above & previous bug
Actual results: apparent memory leaks (RAM usage grows over time the longer you
are logged in).
Expected results: RAM usage plateaus off after some time & ceases growing.
Additional info: Here is the output from top, sorted by RAM usage as of this A.M.:
top - 08:15:43 up 38 days, 21:56, 1 user, load average: 0.03, 0.05, 0.01
Tasks: 193 total, 1 running, 189 sleeping, 0 stopped, 3 zombie
Cpu(s): 0.2%us, 0.3%sy, 0.0%ni, 99.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1997288k total, 1929940k used, 67348k free, 77032k buffers
Swap: 2031608k total, 56k used, 2031552k free, 1015956k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20176 wam 20 0 1268m 113m 11m S 0 5.8 12:24.07 xfdesktop
20185 wam 20 0 280m 111m 9972 S 0 5.7 10:58.77 xfce4-menu-plug
30471 wam 20 0 7156m 72m 21m S 0 3.7 0:21.25 firefox-bin
20038 root 20 0 195m 53m 10m S 0 2.7 78:37.20 X
30501 wam 20 0 7108m 46m 21m S 0 2.4 0:04.74 thunderbird-bin
27394 wam 20 0 148m 34m 6204 S 0 1.8 0:48.74 xfce4-sensors-p
20184 wam 20 0 2349m 32m 20m S 0 1.7 1:28.30 ekiga
20178 wam 20 0 2130m 20m 9832 S 0 1.1 0:20.69 Thunar
20645 root 20 0 26360 15m 320 S 0 0.8 0:00.25 restorecond
20183 wam 20 0 208m 15m 9628 S 0 0.8 4:31.93 xfce4-panel
20174 wam 20 0 226m 15m 8684 S 0 0.8 0:26.70 xfce-mcs-manage
20225 wam 20 0 172m 15m 7500 S 0 0.8 0:01.71 python
27082 wam 20 0 61108 14m 2572 S 0 0.8 0:00.66 ssh
21794 wam 20 0 61108 14m 2572 S 0 0.7 0:00.87 ssh
5461 wam 20 0 61108 14m 2580 S 0 0.7 0:00.58 ssh
21787 wam 20 0 61108 14m 2572 S 0 0.7 0:00.59 ssh
5465 wam 20 0 61108 14m 2580 S 0 0.7 0:00.58 ssh
5468 wam 20 0 61108 14m 2580 S 0 0.7 0:00.76 ssh
5455 wam 20 0 61108 14m 2520 S 0 0.7 0:00.73 ssh
5473 wam 20 0 61108 14m 2520 S 0 0.7 0:00.92 ssh
21851 wam 20 0 61108 14m 2516 S 0 0.7 0:03.17 ssh
21801 wam 20 0 61108 14m 2516 S 0 0.7 0:01.07 ssh
1973 root 20 0 162m 14m 1932 S 0 0.7 0:00.59 cupsd
20170 wam 20 0 187m 12m 8380 S 0 0.6 0:23.62 xfce4-session
20186 wam 20 0 1256m 10m 8700 S 0 0.5 0:00.34 evolution-alarm
20227 wam 20 0 198m 10m 8300 S 0 0.5 0:00.06 nm-applet
20175 wam 20 0 99.4m 9m 6148 S 0 0.5 0:50.39 xfwm4
20197 wam 20 0 3049m 8360 5744 S 0 0.4 0:00.14 evolution-data-
5267 wam 20 0 190m 6012 4872 S 0 0.3 0:00.04 gpilotd
20172 wam 20 0 127m 5560 3560 S 0 0.3 7:32.27 gnome-screensav
32075 wam 20 0 31800 5396 1756 S 0 0.3 0:01.98 gconfd-2
20694 wam 20 0 31436 5232 1372 S 0 0.3 0:04.79 rxvt
20287 wam 20 0 31524 5216 1372 S 0 0.3 0:02.11 rxvt
20251 wam 20 0 31528 5212 1368 S 0 0.3 0:01.93 rxvt
20246 wam 20 0 31448 5208 1372 S 0 0.3 0:01.41 rxvt
20271 wam 20 0 31420 5204 1368 S 0 0.3 0:02.75 rxvt
clearly visible near the top of the list are xfdesktop & xfce4-menu-plugin, at
over 110 MB each (up from ~12 MB each right after login (Dec 19, '07), see
previous bug ), and xfce4-sensors-plugin at 34 MB, up from ~10 MB right
after login. This growth is slower than in the earlier version of XFCE (~100 MB
/ week then), but still not acceptable. For reference, I have an older PIII
running FC5 & the then current XFCE, which has now been logged in for about 5
months (since Aug 15, '07). RAM usage there is sitting at < 10 MB each for
xfdesktop & xfce4-panel-plugin, the top 2 users from the then-current version of
Sorry to hear you are still seeing this. ;(
I will see about filing an upstream bug to see if they have any ideas.
We may want to try and run valgrind on things, will let you know on that.
ok, two things:
1. Do you have the "Launch Gnome services on startup" or the "Launch kde
services on startup" options set? (In sessions and startup -> advanced).
2. Can you try installing valgrind, logging in, then killing xfdesktop and
running it again via:
G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind --tool=memcheck \
--leak-check=full --leak-resolution=high --num-callers=50 -v \
and then attach the xfdesktop-valgrind log to this bug?
1: no & no.
2: This box is a working box for me, it would be unproductive .... I have
valgruind installed (valgrind.x86_64, 1:3.2.3-7), use it in my own paltry
developement efforts, I'll see if I can get around to it; sorry (in advance) if
I can't be more helpful.
I noticed this today for the first time. xfdesktop and xfce4-menu-plugin were
using up about 600MB's of memory each and were causing my machine to begin swapping.
I just restarted XFCE to clear up the issue.
Neither GNOME nor KDE services are set to start. I'll post a valgrind log
I'm running on i386, so I don't think this is necessarily architecture specific.
Note that this is with xfdesktop-4.4.2-1.fc8. I have also seen an Ubuntu bug
describing the same thing, but haven't yet looked upstream.
Created attachment 292560 [details]
Here's my valgrind output. Bout a three hour runtime or so.
Interesting. I do see a report in the ubuntu bug system, but nothing upstream.
The valgrind output might be more usefull if you can do:
yum install yum-utils
And run the valgrind command from comment #2 again?
I will file something upstream.
Thanks for the report.
I have filed an upstream bug on this:
Created attachment 292574 [details]
Second valgrind run with debuginfo RPM's installed.
Ran it again this time with the debuginfo packages installed. :-) I will send
upstream as well. Thanks!
Looks like Brian upstream has found one leak...
I have created a xfdesktop scratch build for F8:
Would any of you folks who are seeing the leaks be willing to try that build out
and run valgrind/let it run for a few days and see if that the main culprit? Or
if there are further ones to find?
Created attachment 297263 [details]
valgrind output from xfdesktop-4.4.2-2.fc8
Tried with your scratch build. No valgrind expert, but it does look a lot better?
Yeah, it does.
William: Can you give it a try and see what your memory leaking looks like?
William: Have you had any chance to try out the scratch build from comment #9?
I yum-updated 2 XFCE packages (xfce-utils & xfce-mcs-plugins, all I saw
available for update @ that time) last week (the 17th) & rebooted. I am
observing & will keep you posted ....
Ah, no. The updated package here is xfdesktop... see the link in comment #9...
I have not yet pushed this as an update, there is only the scratch build in
Can you update to the xfdesktop there and see if it helps?
I guess I can look at pushing an update for it anyhow, as it does appear to fix
at least some of the memory leaking issues.
Sorry for leaving this hanging so long. I was hoping more leaks would be found.
I have pushed the patch we have to rawhide.
If it looks ok after a few days, I will look at pushing out to f9/f8.
If you folks could test and run valgrind on it after that, that would help us squash any further leaks.
xfdesktop-4.4.2-4.fc9 has been submitted as an update for Fedora 9.
xfdesktop-4.4.2-2.fc8 has been submitted as an update for Fedora 8.
xfdesktop-4.4.2-2.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update xfdesktop'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-8838
xfdesktop-4.4.2-4.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update xfdesktop'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8866
xfdesktop-4.4.2-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
xfdesktop-4.4.2-4.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
So, can any of you folks who were seeing the bad leaks still spot any?
(any release is fine, f8/f9/f10/rawhide).
I haven't had any additional issues (Fedora 8 still).
Excellent, and you are using the xfdesktop-4.4.2-2.fc8 version?
I think this may have at least plugged the worst of the leaks...
Thanks for the feedback!
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.