Bug 427819 - Evolution is freezing
Evolution is freezing
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-01-07 13:03 EST by Matěj Cepl
Modified: 2008-02-18 13:54 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-18 13:54:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
backtrace (8.87 KB, text/plain)
2008-01-07 13:03 EST, Matěj Cepl
no flags Details
new backtrace with gnome-keyring-debuginfo installed (8.87 KB, text/plain)
2008-01-07 13:23 EST, Matěj Cepl
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 502603 None None None Never

  None (edit)
Description Matěj Cepl 2008-01-07 13:03:35 EST
Description of problem:
When Evolution is left opened for some time, it freezes and killevo has to be used.

Version-Release number of selected component (if applicable):

How reproducible:
pretty often (when evo is left around lying long enough -- like an hour or so --
it is almost 100% on this computer)

Steps to Reproduce:
1.start Evolution
2.do something
3.let it be opened on different desktop
4.return to it after some time
Actual results:
evolution is just a grey rectangle and no matter what I do it it won't revive

Expected results:
ready and purring waiting for my orders

Additional info:
Comment 1 Matěj Cepl 2008-01-07 13:03:35 EST
Created attachment 290990 [details]
Comment 2 Matthew Barnes 2008-01-07 13:13:16 EST
It appears to be stuck in the main thread waiting on gnome-keyring:

Thread 1 (Thread 0x2aaaaaaf15a0 (LWP 29617)):
#0  0x000000378960d7bb in read () from /lib64/libpthread.so.0
#1  0x000000379c204deb in ?? () from /usr/lib64/libgnome-keyring.so.0
#2  0x000000379c206168 in ?? () from /usr/lib64/libgnome-keyring.so.0
#3  0x000000379c2065d2 in gnome_keyring_find_items_sync ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib64/libgnome-keyring.so.0
#4  0x000000379421c600 in ep_get_password (msg=<value optimized out>)
    at e-passwords.c:702
#5  0x000000379421c212 in ep_idle_dispatch (data=<value optimized out>)
    at e-passwords.c:237

A backtrace with gnome-keyring-debuginfo installed might be helpful.
Comment 3 Matěj Cepl 2008-01-07 13:23:41 EST
Created attachment 290991 [details]
new backtrace with gnome-keyring-debuginfo installed

Is this better?
Comment 4 Matthew Barnes 2008-01-07 13:25:45 EST
Yes, thanks.
Comment 5 Matthew Barnes 2008-02-18 10:16:55 EST
This thread may help. It suggests destroying your default keyring and rebooting.
Seems like overkill, but other users have reported it works.

I would really like to know what caused gnome-keyring to break so badly.


Setting status to NEEDINFO until you have a chance to try it.
Comment 6 Matěj Cepl 2008-02-18 10:51:23 EST
I don’t remember when this happened to me last time (probably couple of weeks
already), but I will try to use this (pretty bad) fix when it happens next time.
Do we have upstream bug for this (so you can close this as UPSTREAM)?

BTW, IMHO, gnome-keyring would need to get some really good dose of code review
love. It is worrisome how something which is supposed to be a central piece of
security in Gnome is breaking all the time.
Comment 7 Matthew Barnes 2008-02-18 11:12:54 EST
Seahorse to the rescue, right?  :)

I'll hunt for an appropriate upstream gnome-keyring bug for this.
Comment 8 Matěj Cepl 2008-02-18 11:17:41 EST
I got lost in these two again -- isn't seahorse just for PGP? And besides, it
crashes even more often than gnome-keyring... :-(
Comment 9 Matthew Barnes 2008-02-18 12:48:47 EST
You might be right.  I was thinking seahorse was poised to eventually supersede
gnome-keyring, but I haven't been paying close attention.
Comment 10 Matthew Barnes 2008-02-18 13:54:26 EST
This looks close: http://bugzilla.gnome.org/show_bug.cgi?id=502603

A race condition was causing the deadlock and is supposedly fixed upstream now,
though I'm not sure if it's found its way into Rawhide yet.

Note You need to log in before you can comment on or make changes to this bug.