Bug 528393

Thanks for a bug report. Please install debug info packages for evolution, evolution-data-server and gtkhtml3 and when this happens again, please do this:
a) find process ID (PID) of a frozen evolution
   (for example by: ps -A | grep evo)
b) get a backtrace of the frozen evolution, to see what it is doing:
   $ gdb --batch --ex "t a a bt" -pid=PID &>evo.bt
   (replace PID with a real process ID from step a)
c) upload evo.bt here, so we can check its state.

Thanks in advance.

Created attachment 364514 [details]
Stacktrace of hanging evolution

Milan: Your wish is my command.

Evolution was unable to send a message.  File->Quit caused the evo window to turn grey and stop responging, but did not cause evolution to quit.  Clicking on the close window decoration ("X") did not close the window, and gnome did not respond with a pop-up asking if it should kill the process.  When evo was killed from the console and restarted the message was sent immediately.

System notes:
4 processor x86_64 system with 8 Gbytes memory
All updates installed
Fairly reliable DSL connection.
All mail and addresses are local.

NB: I have just ticked:
    Mail Preferences->Junk->Lookup in local address book only
which had been unticked.

Created attachment 364552 [details]
Stacktrace of hanging evolution

Here's a much better stacktrace.  I have now downloaded all the apprporiate foo-debuginfo...rpm packages.  

The situation is now that Evolution is unable to download mail.  Clicking "Send/Receive" starts the usual pop-up window.  Clicking "Cancel All" on this window does not cause it to disappear.  Clicking File->Quit greys out the Inbox, Drafts, etc. pane but not the pane of message subjects, etc.  Clicking the close decoration on evolution's window causes no change at all -- the evolution window does not disappear and gnome does not query whether evolution should be killed.

Thanks for the update. I see from backtraces that Evolution is waiting on a response from GnomeKeyring, thus assigning to them for an advice.

> Thread 4 (Thread 0x7f93d5e65910 (LWP 9728)):
> #0  0x0000003bda40de1b in read () from /lib64/libpthread.so.0
> #1  0x000000324de0bcaa in read (__nbytes=<value optimized out>, 
>     __buf=<value optimized out>, __fd=<value optimized out>)
>     at /usr/include/bits/unistd.h:45
> #2  gnome_keyring_socket_read_all (__nbytes=<value optimized out>, 
>     __buf=<value optimized out>, __fd=<value optimized out>)
>     at gnome-keyring-socket.c:184
> #3  0x000000324de0bd37 in gnome_keyring_socket_read_buffer (fd=54, 
>     buffer=0x7f93d5e64c30) at gnome-keyring-socket.c:229
> #4  0x000000324de06a12 in run_sync_operation (buffer=0x7f93d5e64c60, 
>     receive_buffer=0x7f93d5e64c30) at gnome-keyring.c:386
> #5  0x000000324de0917b in gnome_keyring_get_default_keyring_sync (
>     keyring=0x7f93fc027cb8) at gnome-keyring.c:651
> #6  0x00007f93fbe1485c in e_passwords_init () at e-passwords.c:1277
> ...

(In reply to comment #5)
> Thanks for the update. I see from backtraces that Evolution is waiting on a
> response from GnomeKeyring, thus assigning to them for an advice.

This makes perfect sense.  The problem started about the time that GnomeKeyring appeared as part of my Fedora system -- maybe this was when I switched from KDE to gnome.  Though I never associated the trouble with GnomeKeyring till now.  

I've never liked GnomeKeyring.  For a home system, which mine is, it's just another password to type in when the system starts, and I suspect that I'm not alone in that opinion.  Is there any way to make it go away?

BTW: Your last comment is dated 2009-10-13 04:37:21 EDT, which is pretty late.  Are you a night owl (like myself), or are you in Europe, where it's about 11:00AM now.

(In reply to comment #6)
> I've never liked GnomeKeyring.  For a home system, which mine is, it's just
> another password to type in when the system starts, and I suspect that I'm not
> alone in that opinion.  Is there any way to make it go away?

If I recall correctly, I wasn't able to uninstall GnomeKeyring from a system, as couple other packages are depending on it. An ugly hack, which I did on my machine, and which I would never advice to anybody publicly, is to rename the gnome-keyring-daemon executable to some other name, thus any attempt to start it will fail, which means to use password file in Evolution. You can try that, but the better would be to find out what's going wrong in there for sure. (Don't forget to stop any running daemon before renaming it.)

> BTW: Your last comment is dated 2009-10-13 04:37:21 EDT, which is pretty late. 
> Are you a night owl (like myself), or are you in Europe, where it's about
> 11:00AM now.  

Yup, I'm a European :)

Created attachment 364665 [details]
Stacktrace of hanging evolution

Yet one more stack trace.  This time evolution is completely hung.  Clicking the window decoration to close the process *does* provoke the message from gnome asking if the process should be killed.  Hopefully the last trace I'll submit.

Thanks for the update. Thread 1 is doing the same thing as copied in comment #5, thus it's the same issue as before.

There is an upstream bug for this [1], with some explanations what's causing the hang. I'm upstreaming this, and moving it to evolution-data-server.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=595421

*** Bug 459356 has been marked as a duplicate of this bug. ***