Bug 717912

Might be this ancient bug upstream: 
https://bugzilla.xfce.org/show_bug.cgi?id=441

Did you change the keyboard shortcut for application menu? 

Is this a fresh install? Or an upgraded machine? 

Does the issue persist on a newly created user?

I did not change the keyboard shortcut in Preference/Setting Manager/Keyboard,
but at lease some do not work either <ctrl><esc> <alt>F1/F2 - but <alt>F4 closes the window.
Actually <alt>1/2/3/4 switches the workspaces - I am not shure if I have changed that - somewhere else, as it does not appear in that list.

It is a fresh install - only some days old but I had the problem before - with F14, at least the Menu did not show up in time. I used to take the
application Menu in the panel if right-click did not work and did not hit the mouse more than once, so the memory-leak did not slow down the system as it did yesterday.

New Users do not have that Problem.

I just tried the right click again: memory increase from 3.9% to 28% after 10 right clicks.

AND strace-ing xfdesktop shows many stat/access calls just after the right-click on the desktop: it looks like a scan on my home directory or at least the "tmp" subdirectory (which contains many file):

lstat("/app/home/gasi/tmp/XXX", {st_mode=S_IFREG|0644, st_size=75376, ...}) = 0
access("/app/home/gasi/tmp/XXX", R_OK) = 0
access("/app/home/gasi/tmp/XXX", W_OK) = 0
access("/app/home/gasi/tmp/XXX", X_OK) = -1 EACCES (Permission denied)
stat("/app/home/gasi/.thumbnails/normal/25b1c8cdd332fd92d700acfa31587bd3.png", 0x7fff13c98560) = -1 ENOENT (No such file or directory)
stat("/app/home/gasi/.thumbnails/fail/gnome-thumbnail-factory/25b1c8cdd332fd92d700acfa31587bd3.png", 0x7fff13c98560) = -1 ENOENT (No such file or directory)

How are you determining memory increase? 

So, it's something in the config of your user. Can you attach, or check against a new user, your '~/.config//xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml' file?

The last time I used ps to check to memory - before I have used top with simular results.

Created attachment 511123 [details]
xfdesktop configuration xfce4-desktop.xml

There is no much difference to another working user

Can you run valgrind on xfdesktop for us? 

killall xfdesktop
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --show-reachable=yes -v --log-file=$HOME/valgrind.log xfdesktop

Then attach the log file.

I am not sure what has happened:
I put these to lines in a file and sourced it :

gasi:tmp$ . ./val
xfdesktop[14353] is already running; assuming --reload

gasi:tmp$ psg xfdesktop
gasi     14354 19.1 13.3 757852 268976 ?       S    08:55   0:27 xfdesktop --display :0.0 --sm-client-id 2702d6070-6e7a-4b1b-98b3-b9e284183b5e

So it is probably not what you want
But anyway I attach the log

Created attachment 511259 [details]
valgrind log of xfdesktop

Just another info:
I have move one directory of my ~/tmp aside - it contains nearly 20000 jpeg images.
now the right desktop click is fast enough and there is no more increasing of memory consumption of xfdesktop.
Actually the icon of the tmp directory in thunar has a little painting inside:
a document symbol with something which should look like a second page behind it.

Do you by chance have xfdesktop set to pull backdrops from that ~/tmp dir? 

does: 'grep tmp ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml' output anything?

No, there is not tmp in ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml

But there are many in ~/.config/user-dirs.dirs: all besides

XDG_DESKTOP_DIR="$HOME/.desktop"

So, can you attach the lines with 'tmp' in them from ~/.config/user-dirs.dirs ?

Created attachment 513563 [details]
~/.config/user-dirs.dirs with many references to ~/tmp

Thats odd. That would seem to be the issue... since tmp was set to all those user dirs, xfdesktop scanned tmp many times for each one. 

My ~/.config/user-dirs.dirs here has: 


# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.
# 
XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_TEMPLATES_DIR="$HOME/"
XDG_PUBLICSHARE_DIR="$HOME/"
XDG_DOCUMENTS_DIR="$HOME/"
XDG_MUSIC_DIR="$HOME/Music"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_VIDEOS_DIR="$HOME/"

So, it should be only scanning $HOME and a few subdirs as needed. 
If you change it to that does everything work?

Perhaps this is a bug in xdg-user-dirs-update ?

That should not change anything: it should scan even more because
my config is only a sub-directory of my $HOME:
 XDG_PICTURES_DIR="$HOME/tmp"
and so with the others.
Removing the images from $HOME/tmp speed up the right-click as I wrote already in comment #10.

I thing there are two issues:

1. right-click scans too much - I even do not understand why it scans at all
   but this might be a feature
2. there is a memory-leak and that is definitely a bug

1. yeah, it's scanning things so it can do icons for your desktop if you have that enabled.. so it needs thumbnails and icon types for the files, etc. 

2. Agreed. Filed upstream as 7834.

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

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