GNOME Bugzilla – Bug 613399
gvfsd-(sftp/ftp) hang on 100%CPU if they try to read password from gnome-keyring
Last modified: 2019-02-22 11:45:58 UTC
Created attachment 156615 [details] gdb backtrace of hanging gvfsd-sftp Tested on ubuntu 10.04 Version gvfs-1.5.5-0ubuntu1 If you try to connect to a sftp / ftp share via a password the gvfsd-(sftp/ftp) process hangs without results at 90-100%. This only happens if you have been connected to the share before and the password is stored in the gnome-keyring. (View with seahorse). Steps to reproduce: 1) Connect to a server (you haven't connected before) and select "forget password immediatly". The share will be mounted successfully. Disconnect from the server. 2) Connect to a server and select "store password forever". The share won't be mounted and gvfsd-xx will eat your cpu. As long as the password is stored you won't be able to connect. Delete the password (seahorse) and you will be able to do 1).
Created attachment 157080 [details] improved backtrace improved backtrace. Does anyone care?
Created attachment 157245 [details] [review] Possible fix for the problem Here's a possible fix for this problem. Are either of you willing to get into building libgnome-keyring from source?
The change seems to solve some issues but not be enough to be working correctly, see https://bugs.edge.launchpad.net/ubuntu/+source/libgnome-keyring/+bug/530605/comments/25 The issue is probably the same as bug #611584 there?
other comments suggest the change is not working
Review of attachment 157245 [details] [review]: ::: library/gkr-operation.c @@ +256,3 @@ + if (g_once_init_enter (&inited_threads)) { + if (g_thread_supported ()) + dbus_threads_init_default (); gvfs daemons seem to call this already. See http://git.gnome.org/browse/gvfs/tree/daemon/daemon-main.c?h=gnome-2-28#n65 And D-Bus document says that "dbus_threads_init/init_default must be called BEFORE the second thread is started", so calling it in here may be late.
I'm hoping to get to the bottom of this before 2.30.1. I've tried again to duplicate this issue but have not been able to. Does anyone have time and expertise to debug this issue in a debugger and step around and answer the following questions: Where does the loop in gvfsd occur? In other words which of the following functions are running during the loop? __pthread_mutex_unlock_usercnt _dbus_pthread_mutex_unlock _dbus_mutex_unlock _dbus_connection_unlock dbus_pending_call_get_completed _dbus_connection_block_pending_call dbus_pending_call_block gkr_operation_block Secondly is the mutex being passed to _dbus_mutex_unlock really NULL? I see this in the stack trace:
+ Trace 221287
Stef, not sure if the workaround on https://bugzilla.gnome.org/show_bug.cgi?id=606902 could give you useful information but ubuntu lucid is using it now and it seems to make the gvfs cpu usage better the ubuntu bug has a collection of issues, the gvfs one seems fixed by the workaround but some users still get issues in gvfs or say seahorse uses cpu too. there was another class of issues which started with the new libgnome-keyring version too coming from software using gnome-keyring in threads, it seems using libdbus or libdbus-glib is such context is an issue
the bug with the workaround point to dbus bugs which might be interesting too...
*** This bug has been marked as a duplicate of bug 606902 ***
I still have a mount problem in ubuntu when trying to store the password, so the CPU issue in Lucid is not here, the password / keyring problem is. If any1 needs traces, please tell me the commands to use, since I have the tools installed, but have not found out (yet) how to debug this issue.