GNOME Bugzilla – Bug 590004
gnome-keyring-daemon crashed with signal 5 in g_thread_join()
Last modified: 2009-08-30 02:07:06 UTC
this report has been filed here: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-keyring/+bug/405667 reporters stated that they get the crash after updating the package to 2.27.5 ".
+ Trace 216667
Thread 1 (process 3217)
Thanks for the bug report. Please attach the output of gnome-keyring-daemon when this happens. This may be in /var/log/auth.log or ~/.xsession-errors
There is several logs in the launchpad bug now: http://launchpadlibrarian.net/29629590/.xsession-errors http://launchpadlibrarian.net/29629604/auth.log http://launchpadlibrarian.net/29629678/var-log-auth.log http://launchpadlibrarian.net/29629679/home.xsession-errors http://launchpadlibrarian.net/29630217/home.xsession-errors
You might want to read directly the launchpad comments too
Thanks. I'm looking into this further. A very odd stack trace. The stack trace shows that gnome-keyring-daemon was in the process of exiting (such as during a logout), and yet the users say they were just using their computers...
The crash could be a crash on closing, users would not notice until getting the apport notification in the next session
Is there anything else we could provide to help the bug to be fixed? Downstream report has currently ~50 duplicates. Thanks in advance.
Created attachment 141813 [details] output of "strace gnome-keyring-daemon --debug" Confirming the bug too. I killed the gnome-keyring-daemon and tried to restart it using: strace gnome-keyring-daemon --debug I have attached the log, I hope it gives more information. :)
Created attachment 141986 [details] [review] Patch which instruments quit paths with messages Sorry for taking a while to get back to this... Could you apply the attached patch. I'm interested in the messages generated in /var/log/auth.log. Since this bug seems to happen at logout, after applying the patch and rebuilding gnome-keyring, you'll need to log out twice. Once to start running the new code, and the second time to make the bug happen with the messages this patch adds. All the comments on launchpad are pretty useless, because Ubuntu doesn't seem to tell people that the crash happened during their last session, and so everyone thinks what they're currently doing is causing the bug :(
If it helps: The following procedure makes gnome-keyring-daemon crash reliably for me: $ gnome-keyring-daemon ** Message: couldn't set environment variable in session: Setenv interface is only available during the Initialization phase GNOME_KEYRING_SOCKET=/tmp/keyring-IWfyTd/socket SSH_AUTH_SOCK=/tmp/keyring-IWfyTd/socket.ssh GNOME_KEYRING_PID=32713 $ export GNOME_KEYRING_SOCKET=/tmp/keyring-IWfyTd/socket $ export SSH_AUTH_SOCK=/tmp/keyring-IWfyTd/socket.ssh $ export GNOME_KEYRING_PID=32713 $ gnome-keyring-daemon --start GNOME_KEYRING_SOCKET=/tmp/keyring-IWfyTd/socket SSH_AUTH_SOCK=/tmp/keyring-IWfyTd/socket.ssh $ kill 32713 Messages in /var/log/auth.log: Aug 30 01:35:09 apophis gnome-keyring-daemon[32713]: quitting via signal: 15 Aug 30 01:35:09 apophis gnome-keyring-daemon[32713]: quitting main loop... Aug 30 01:35:09 apophis gnome-keyring-daemon[32713]: GThread: file /build/buildd/glib2.0-2.21.5/gthread/gthread-posix.c: line 385 (g_thread_join_posix_impl): error 'No such process' during 'pthread_join (*(pthread_t*)thread, &ignore)'
Thank you Andreas. I can now replicate this bug on my local setup.
These commits should fix the problem. Could you confirm that this fixes the problem? They're committed to git master at git.gnome.org: commit 0fa6f05cfcedef35dd5de25908cbc1aceb50e61d Author: Stef Walter <stef@memberwebs.com> Date: Sun Aug 30 02:02:38 2009 +0000 [egg] Remove unneeded signal handling code. commit 7d19e6eb281a60b6f39af32b1242b808f0f7edd0 Author: Stef Walter <stef@memberwebs.com> Date: Sun Aug 30 02:00:07 2009 +0000 [daemon] Rework signal handling, startup procedure. Reworking the signal handling, so we have a specific thread for handling signals. All other threads ignore signals. This is the recommended way to 'mix' signals and threads. In addition we move the part of startup that we can perform after forking into separate procedures. In particular we try to prevent starting threads until after we've forked. Besides the obvious sanity, this helps the signal handling to work for all threads.
*** Bug 591415 has been marked as a duplicate of this bug. ***