Each time you kill and restart xfce-mcs-manager, the panel will take 1-2M extra memory. Valgrind doesn't seem to report it as mem-leak (still learning how to use it), so it may still be reachable.
try this: valgrind --tool=addrcheck --num-callers=20 --leak-resolution=high --leak-check=yes --show-reachable=yes --log-file=val-panel xfce4-panel if you have a good amount of memory that never gets freed (i.e., stuff that doesn't get cleaned up on exit), might want to leave off the --show-reachable. it'll write all the data to a file called val-panel.PID (or something like that).
Interesting addition: with no items in the panel it doesn't happen.
With 1 launcher, memory increase, with only the pager it doesn't. Hmm, might it be icon related, I'll keep investigating...
Situation: panel with only 1 empty launcher, every 8 seconds kill or restart xfce-mcs-manager, watch memory footprint increase with around 100kb every time (Note: this is much more with a full panel). Valgrind log: http://www.loculus.nl/xfce/files/valgrind-log-20041028 (5.9MB!). I'm not sure I'm reading this correctly, but it looks to me like the big memory increase must be in the 'still reachable' part. Brian, would you mind having a look at it at some time. I ran valgrind with the options you suggested: valgrind --tool=addrcheck --num-callers=20 --leak-resolution=high --leak-check=yes --show-reachable=yes --log-file=val-panel xfce4-panel
Hi, I open an XFCE4 session, work a little, and go to bed leaving it open; I go to work the next morning, come back home, and xfce4-panel has grown to: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND shai 20380 0.8 19.9 52960 38012 pts/2 S Mar29 23:36 xfce4-panel I don't know if this means 37M or 51M, but I know it means "memory leak". And the session was just sitting idle for some 20 hours -- no explicit mcs restart (do these things happen on their own?) Of relevance: XFCE 4.2.1.1 on Debian Sid (Morphix based, actually), I'm using KDE services. Hope this data point helps, Shai.
shai@platonix.com: It would be helpful to have a list of the plugins you're using, as well as a look at the memory usage when it's low, and then later when it grows. Assuming it's a plugin and not the panel itself, the only way to figure out which one is the culprit is to remove them one by one until the memory leak goes away. Your bug probably isn't related to this one; but if you do find out which plugin, please file a bug under the panel plugins product with the correct component.
I think it's safe to assume this bug no longer exists since the panel has been more or less completely rewritten, and doesn't use the MCS manager anymore.