Description of problem: If I click-right on the desktop the application menu does not appear (or it takes at least 10 seconds). If I continue to click-right the memory of the xfdesktop process increases (top says about 5% more with each click of 2GB total memory) and some messages can be found in ~/.xsession-errors: ** (xfdesktop:29522): CRITICAL **: Unable to get keyboard/mouse grab. Unable to pop up menu Version-Release number of selected component (if applicable): xfdesktop-4.8.2-1.fc15.x86_64 Additional info: Other Users will see the menu immediately. For me it works before too but someday with Fedora 14 it was gone.
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