GNOME Bugzilla – Bug 502603
checking password, evolution freezes
Last modified: 2008-05-13 08:47:57 UTC
Please describe the problem: $gdb evoluton "process number" (gdb) bt
+ Trace 181285
Steps to reproduce: 1. launch evolution 2. click F9 3. Actual results: Expected results: Does this happen every time? Other information: evolution-2.21.3-3.fc9 gnome-keyring-2.21.3.2-1.fc9
I can confirm hanging processes with gnome-keyring 2.21.3 and 2.21.3.2 on Linux x86_64. Sometimes the gnome-keyring-daemon hangs at login time and blocks the login process. Attaching to g-k-d with gdb and detaching again resolves the hang and the login continues. As described by sangu, applications using gnome-keyring frequently block when trying to retrieve a secret, this happens at least with Evolution and ssh here. Sending gnome-keyring an additional request (e.g. a second ssh login), while the application still hangs, unblocks the application again.
Similar bug on https://bugs.launchpad.net/bugs/175682 "GNOME rarely starts from GDM in Hardy Binary package hint: gdm About 90% of the time when logging in from GDM, gnome-session hangs. I don't get any GNOME programs running, just a cursor and a blank, light brown background. If I choose "Failsafe GNOME", the same happens, though for a few days this seemed to work. I have cleaned my session, and I have even tried this with newly created users, and the same thing happens. The only way I can get it to work is by using a "Failsafe Terminal" session and launching gnome-session from that. Most of the time, this method works, but on rare occasions this method hangs in the same way, too. I can simply just kill it and try again in the same terminal and it will work. I have a stack trace from what happens when it hangs:
+ Trace 181671
Thread 1 (Thread 0xb6f166b0 (LWP 9474))
I've committed some fixes to gnome-keyring for x86-64. Could you check SVN trunk and see if it continues to exhibit these problems?
Unfortunately no change with current SVN trunk here. It's also probably not x86_64 specific as the stack traces in the other comments seem to be x86 stack traces.
This bug is unclear. It's especially unclear if all are reporting the same problem. The stack traces are irrelevant, they exhibit a valid synchronous connection to the keyring daemon. Is the *original* problem (filed by sangu) that evolution being unresponsive while gnome-keyring is prompting for the password?
I'm pretty sure it's the same problem as the behavior described by both, sangu and alex-weej, perfectly matches the behavior I'm observing. Tell me if I can be of any help, I can easily reproduce it here, unfortunately... Example to explain behavior: I run in a terminal: ssh someserver # gnome-keyring knows my ssh key to login to someserver Most times it just hangs there. When I now start in another terminal a second ssh (to the same or a different host, no difference), both logins succeed. The same happens with other gnome-keyring using applications as e.g. Evolution or nm-applet.
Yes, please. I'd like help getting to the root of this. Could you do a backtrace on gnome-keyring-daemon (all threads) when this occurs in both the ssh and evolution cases.
gdb doesn't find any threads and the backtrace looks the same for the ssh and the evolution cases.
+ Trace 182631
No threads in the daemon, means that the client (ie: ssh, or evolution) is not actually communicating with the daemon. However the read() at the top of the client stacktrace shows that communication is taking place. It seems like something is wrong with the stack traces. Sorry to ask for this again, but I'd really like to find this problem. Could you provide a stack traces at the exact time that evolution is hung, for both the client (evolution) and the daemon (all threads)? Also is there anything in your syslog auth log (usually at /var/log/auth.log) from gnome-keyring when this happens. All of the daemon's failure messages are logged here.
I have this in the log: Jan 5 14:39:35 pris gnome-keyring-daemon[5745]: gkr_pk_object_manager_unregister: assertion `GKR_IS_PK_OBJECT_MANAGER (objmgr)' failed Jan 5 14:39:35 pris gnome-keyring-daemon[5745]: gkr_pk_object_manager_unregister: assertion `GKR_IS_PK_OBJECT_MANAGER (objmgr)' failed
I can confirm that "GNOME rarely starts from GDM in Hardy However I have somewhat of a work around. I moved /usr/bin/gnome-session to /usr/bin/orig.gnome-session I created /usr/bin/gnome-session with the following line stract /usr/bin/orig.gnome-session With this workaround gnome desktop does start, however Any windows I open, in Applications, Places, System are all locked to the upper left of the Desktop with no Title Bar etc. no way to move them whatever Opening more than one window stacks each window directly on top of the previous window. This is with a machine running restricted Nvidia drivers (not from Nvidia Site)
Timo, although those log lines almost certainly occur on shutdown. Please use the time in the log to verify this. I still need the stack traces referred to in comment #11. It's great that everyone is contributing to this bug, but everyone's symptoms seem to be at least slightly different.
Stef I am a little unclear what stack traces you want. Could you elaborate and I will perform the traces jt
Log messages when GNOME login hangs: Jan 7 08:05:37 juerg-d820 gnome-keyring-daemon[4525]: couldn't read 4 bytes from client: Jan 7 08:06:04 juerg-d820 gnome-keyring-daemon[4525]: couldn't read 4 bytes from client: I can't reproduce the evolution hang right now for the stack traces, have to check on the other system.
Jürg, is this an x64 system? And are you sure this is gnome-keyring from SVN trunk?
I see these issues on two systems, both x86_64. I used SVN trunk on Dec 16, 2007 but upgraded to 2.21.4 later on. I can upgrade to SVN trunk again this evening, if this might fix the issues.
Created attachment 102330 [details] backtrace of keyring Here is the backtrace of keyring after login has completed and gnome desktop has not yet appeared (never does appear)
Thought I would add this to the case to see if anyone can tell me what/how to fix the configure problems. This is a list of the problems I had trying to make gnome-keyring from the svn trunk Got several autoconf errors etc. and fixed some but got down to this error in when running autoconf configure.in:18: error: possibly undefined macro: AM_DISABLE_STATIC If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:19: error: possibly undefined macro: AM_PROG_LIBTOOL configure.in:344: error: possibly undefined macro: AM_PATH_LIBGCRYPT configure.in:363: error: possibly undefined macro: AM_PATH_LIBTASN1 However, I ran configure anyway and it came up with this error checking whether make sets $(MAKE)... (cached) yes ./configure: line 4937: AM_DISABLE_STATIC: command not found ./configure: line 4938: AM_PROG_LIBTOOL: command not found ./configure: line 4939: syntax error near unexpected token `0.35.0' ./configure: line 4939: `IT_PROG_INTLTOOL(0.35.0)'
Created attachment 102489 [details] Make warnings fatal Sorry for the delay. This is tough for me to fix when I can't reproduce it, so your patience with me as I try to figure this out is really appreciated. Jürg, could you apply this patch, and then make the problem happen again? The daemon will should now crash at the point that it logs the 'couldn't read 4 bytes from client' message. The backtrace at this point will point us toward the bug.
Stef No problem with the delay. I have been working out most of the kinks in compiling the trunk version 1001 and have a few more errors to go and hopefully get gnome-keyring compiled from svn. good learning experience. on another note killing gnome-keyring after login screen completed on hardy definitely solves the problem. I have tested and retested and killing gnome-keyring lets the gnome desktop display. thanks jt
There is a new comment on the ubuntu bug with a backtrace of gnome-keyring-daemon during the hang "Thread 2 (Thread 0xb7ac3b90 (LWP 13136)):
+ Trace 184816
Thread 1 (Thread 0xb7c1f6b0 (LWP 13085))
Created attachment 102597 [details] [review] Wakeup mainloop properly. Thanks Sebastian. The attached patch (also committed to SVN trunk) should hopefully fix the problem you're reporting.
Thanks, I've uploaded a patched package to hardy and will let you know if it fixes the issue for the users who were running into the bug
I still see the same issue here with SVN trunk. I'm unable to get a stacktrace with the fatal warnings patch. When the keyring-daemon hangs on login, I attach gdb to it and enter "continue". All I get then is the gdb message "Program terminated with signal SIGTRAP, Trace/breakpoint trap. The program no longer exists.". I don't know why gdb can't catch the signal.
this is a new backtrace of the still hanging gnome-keyring-daemon I just posted as a follow up to the ubuntu bug at https://launchpad.net/bugs/175682. Hope it helps
+ Trace 185376
Created attachment 102878 [details] [review] Fix race condition This patch should fix a race condition present in the code that could (and likely does) cause the deadlock stack trace that has been posted by Sebastian and reynaldo.
Created attachment 102879 [details] [review] Fix race condition This patch should fix a race condition present in the code that could (and likely does) cause the deadlock stack trace that has been posted by Sebastian and reynaldo.
Thanks Stef, sadly I don't have a way to try this fix out right now, I'll let you kbow as soon as I managage to get my hands on the offending machine.
Thanks a lot, that seems to fix the issue here. Login, ssh, and evolution work fine.
Wonderful. Thanks for the backtraces.
Confirmed as fixed by the one I was trying to help out, sorry for the delay, it was hard to get a confirmation. Thanks a lot
*** Bug 532771 has been marked as a duplicate of this bug. ***