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 weeks :-). Steps to Reproduce:see above & previous bug 1. 2. 3. 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 [417211]), 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 XFCE.
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 \ --log-file=xfdesktop-valgrind xfdesktop and then attach the xfdesktop-valgrind log to this bug?
Answers: 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 shortly however. 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] valgrind output 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 debuginfo-install xfdesktop 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: http://bugzilla.xfce.org/show_bug.cgi?id=3812
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: http://koji.fedoraproject.org/koji/taskinfo?taskID=483074 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 comment #9. 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. Thanks.
xfdesktop-4.4.2-4.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/xfdesktop-4.4.2-4.fc9
xfdesktop-4.4.2-2.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/xfdesktop-4.4.2-2.fc8
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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!
Correct. Thanks much.
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.