Bug 375921

Created attachment 254651 [details]
clicked & dragged output from top ....

Note that most of that memory isn't resident... ie, VSZ vs RSS on your
screenshot has: 

VSZ: 208m
RSS: 15m

So only 15m is Resident, so this isn't too unusual. 
Do you see any of the values go over time? From what/To what?

Also, do you have any panel plugins enabled? Or just the default panel...?

Thanks for the bug report. 

look at xfdesktop, 570-ish MB resident, that seems a bit high :-). free -m gives:

[wam@AthlonCube, ~/FTP, 8:24:49am] 603 % free -m
             total       used       free     shared    buffers     cached
Mem:          1943       1927         15          0         48        315
-/+ buffers/cache:       1563        379
Swap:         1983          1       1982
[wam@AthlonCube, ~/FTP, 12:17:01pm] 604 %

i.e. 1.5 GB out of 2 GB onboard used. This number has been (slowly) climbing for
weeks (machine has been up 81 days, I have been logged in the whole time, I use
this box to access others on my network). I have 4 desktops, about a dozen rxvt
terminals open & that's it, no other panels (that I know of :-) ), nothing else.
please advise if you need more info.

Ah, I was looking at the wrong line... sorry about that... 

Yeah, that does seem excessive. ;( 

Possibly you are seeing this bug: 
http://bugzilla.xfce.org/show_bug.cgi?id=2427

Are you doing any F5 or xfdesktop --reload calls (to change backgrounds)?

Nope, not that sophisticated :-/. Just *LOTS* of rxvt/csh's, & sporadic
Firefox/Thunderbird's, *very* plain vanilla ....

Here is top, sorted by resident memory usage:

top - 15:36:53 up 81 days, 23:54,  0 users,  load average: 0.06, 0.08, 0.02
Tasks: 181 total,   1 running, 174 sleeping,   0 stopped,   6 zombie
Cpu(s):  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1989992k total,  1953740k used,    36252k free,    64856k buffers
Swap:  2031608k total,     1852k used,  2029756k free,   318728k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
                                             
 9310 wam       15   0 1717m 568m  10m S    0 29.3 153:04.09 xfdesktop         
                                              
 9320 wam       15   0  733m 568m 8584 S    0 29.2 141:18.43 xfce4-menu-plug   
                                              
 4957 wam       15   0 5200m  61m  21m S    0  3.2   0:09.70 thunderbird-bin   
                                              
 9222 root      15   0  204m  52m 9716 S    0  2.7  99:11.06 Xorg              
                                              
19441 wam       15   0 2282m  25m  14m S    0  1.3   0:13.67 ekiga             
                                              
 9312 wam       15   0 2181m  24m  13m S    0  1.3   0:49.41 Thunar            
                                              
 9314 wam       15   0  208m  15m 9944 S    0  0.8   2:06.71 xfce4-panel       
                                              
 1724 root      15   0 22364  12m  452 S    0  0.6   0:00.25 restorecond       
                                              
 9308 wam       15   0  217m  12m 6696 S    0  0.6   0:17.93 xfce-mcs-manage   
                                              
 9309 wam       15   0  119m  11m 6520 S    0  0.6   0:44.08 xfwm4             
                                              
 9305 wam       15   0  175m  11m 8080 S    0  0.6   0:20.13 xfce4-session     
                                              
10729 wam       15   0 2214m  10m 8844 S    0  0.6   0:00.29 evolution-alarm   
                                              
10723 wam       15   0 2159m 8056 5472 S    0  0.4   0:00.16 evolution-data-   
                                              
19219 root      23   0  102m 5416 1048 S    0  0.3   0:05.81 automount         
                                              


Better, now, non ?

I'm not sure what else to do to track this down more... and FC 6 reaches End of
Life in a week or so... ;( 

Xfce 4.4.2 is going to be out very soon, and there are some leak fixes in
xfdesktop, but I don't think thats going to make it in as a update for FC6. ;( 

Are you planning on upgrading? Can you try and duplicate things with a newer
release? I also have some prerelease 4.4.2 packages for 7/8/devel if you were on
any of those to try... 

Thoughts?

I have indeed downloaded & burned FC8 & will install it shortly. However ....
this is happening w/ XFCE 4.4.1, i.e. the latest & greatest, so I doubt newer
OS/XFCE is going to change anything. I have an older box, 933 MHz P3, FC5 &
whatever XFCE came w/ that, still up & running (& logged in :-) ), it is
currently hogging 19.9 MB of RES RAM between xfdesktop & xfce4-panel after
250-ish days logged in (vs. ~1350 MB under XFCE 4.4.1 & FC6) :-( ....
Something's up here ....

P.S. That's not xfce4-panel, it's xfce4-menu-plug, right at 665 MB RES each,
sorry 'bout that ....

Well, the OS often has a lot to do with things. Xfce is liked to many other
libraries (gtk2, glib, etc). If there was some issue there it might show up as a
bug like this... 

From the 4.4.2 changelog for xfdesktop: 
modules/menu/desktop-menuspec.c: fix possible memleak (unlikely tho)
panel-plugin/desktop-menu-plugin.c: fix memleak

So, it's possible that 4.4.2 will fix the leak you are seeing... 
or it's possible it's something else in the OS related and upgrading will fix it. 

Update: I logged out & rebooted w/ the FC8 DVD in place & tried to update to
FC8. The install hung during the resolve-dependencies task, about 1/4 way
through according to the progress bar. I Ctrl-Alt-Del'ed out & rebooted my FC6.
FC8 had apparently messed with my /etc/sysconfig/networking scripts, because
eth0 (static) didn't come back up correctly. Neither did X-windows, but that was
due to a lingering lock file in /tmp which didn't get deleted after my unkind
restart. I am back up & running FC6 after another reboot w/ eth0 properly
configured & X cleaned up. RAM usage is back down to normal, at this time. I had
earlier upgraded my kernel to get sensors support, so I am now at kernel
2.6.22.9-61.fc6, rather than the original stock kernel. Still XFCE 4.4.1, so
we'll see about leaks w/ newer kernel & XFCE 4.4.1 :-) ....

Sorry to hear it... you may have run into: 
https://fedoraproject.org/wiki/Bugs/F8Common#head-7b9bf2dab0e2bdd97d98334c7198cd9cd3eaf9be

Can you try the updates image there and see if it fixes it? 

How long do leaks take to show up for you?

They took weeks for me :-/. But, they did show up eventually. The RES RAM usage
steadily climbed over time, ~75 MB/week total between xfdesktop &
xfce4-menu-plug (the 2 worst offenders). I have a lot of RAM (2 GB) onboard, so
it never really slapped me in the face until I noticed that 'free -m' was
reporting over 1 GB on the 2nd line (-/+ buffers/cache) ....

I am up to FC8 now, went to FC7 & then to FC8 & that worked, though it shot
several hours. That is the sort of thing that *really* shouldn't happen
(installer problems), really a bummer for newbies. I have an existing bug about
the installer failing w/ >2GB of RAM onboard, is anyone looking at that ?

ok, so shall we leave this open and check in a few weeks to see if you still see
the leaks? Also, I am going to be updating to 4.4.2 very soon, so you can try that. 

Or would you prefer I close this bug now and you can re-open or file a new one
if you see the leak return in F8? 

I have no control over the installer... I suggest you check that bug for
response from the maintainer(s). 

I'm easy either way. I wouldn't call it solved or resolved :-) .... Go ahead &
close it, & if I observe the same thing under FC8, I'll re-open it. I noticed
that the XFCE people announced 4.4.2 a few days ago, so whenever it shows up as
an update under FC8, I'll upgrade & log back in. Until then, I'll observe my
current 4.4.1 under FC8 ....

ok. I'll go ahead and close this now... feel free to re-open or file a new bug
against F8 if you see it happen again, and we will get to the bottom of it. ;) 

I have been building the 4.4.2 updates the last few days. Expect to see them
show up in updates-testing very soon and then updates shortly after.