Could you please start evolution under gdb from terminal. When evolution hangs, do Ctrl+C, then t a a bt and paste the traces here. Please install debug info packages of evolution, evolution-data-server and glib2 in case you don't have, thanks. 

See http://live.gnome.org/GettingTraces/Details#gdb-not-yet-running for details about how to do this),

Hmm, strange enough while running in GDB I haven't been able to recreate that bug.  It's been checking mail for days now when normally it locks up like that in a matter of hours.

This morning however Evolution finally hung as a whole(as apposed to hanging while receiving mail) so I got the trace and I'll paste it in here

+ Trace 218229

Another Trace from another crash

+ Trace 218239

Ok Finally was able to reproduce the error where it just sits at the receiving mail screen indefinitely.. Woke up and it was stuck in receiving mail for 6 hours.  Here's the trace:

+ Trace 218279

looks like lock due to password pop up

This one:
> #0  strcmp from /lib/tls/i686/cmov/libc.so.6
> #1 IA__g_str_equal at /build/buildd/glib2.0-2.20.1/glib/gstring.c line 77
> #2 org_gnome_mail_new_notify

is not on gnome, it's on ubuntu, and as I was told it is fixed in the most recent version (I do not know which version, though).

The hang itself, Akhil has right, it's waiting on a password prompt due to some issue in gnome-keyring-daemon, as is shown in Thread 6535. I doubt it being Evolution issue. The first trace shows the same, just it's in Thread 1.

Hmm, the unfortunate thing is that I'm not receiving a password prompt(which would explain why it is hanging there indefinitely) so I have no way of entering in a password at all and must resort to killing evolution through shell.  Good to know at least it's not an evolution issue, thanks for checking into that for me

Evolution uses the synchronous gnome_keyring APIs. This is what blocks the application. Sometimes this happens during while evolution has the keyboard grabbed (like during a menu display). This causes the evolution and sometimes the entire X session to hang.

Please see bug #571423 for more information.

~/contrib/evolution-data-server$ grep -R gnome_keyring * | grep sync 
libedataserverui/e-passwords.c:		result = gnome_keyring_item_delete_sync (NULL, found->item_id);
libedataserverui/e-passwords.c:	result = gnome_keyring_item_create_sync (
libedataserverui/e-passwords.c:	result = gnome_keyring_find_items_sync (
libedataserverui/e-passwords.c:		gnome_keyring_get_default_keyring_sync (&default_keyring);

( downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=528393 )

Thanks for the explanation, Stef. Having e-passwords using strictly async calls to gnome-keyring will be quite tough, I guess.

Yes, i imagine it would be tough. But essentially handing the life of your application to a third party process while it is grabbing the keyboard is a recipe for disaster. That is:

 * An evolution menu is open, the keyboard and mouse is grabbed.
 * While this is happening, evolution-data-server makes a call into 
   gnome-keyring-daemon
 * gnome-keyring-daemon puts up a prompt.
 * That prompt can not be acted on, because evolution has grabbed the 
   keyboard and mouse.
 * Evolution cannot relinquish keyboard and mouse without running its 
   mainloop. 

Possible solutions:

 * Run gnome_keyring calls in async mode, but don't return to the main
   mainloop. Loop the (a/the) mainloop yourself. Similar to what a 
   modal dialog does in gtk_dialog_run()
   * There's no need to return to the parent function, just to loop
     the mainloop while executing an out of process call.
   * You could disable the evolution UI to get a 'modal' effect.

 * Never call out of the evolution process while the keyboard or mouse 
   is grabbed.

 * Run gnome_keyring calls from a seperate thread that does not 
   interact with the mainloop. 

FWIW, I'm in the process of redesigning gnome-keyring's prompting. If there is any way that a new API could ease this problem please let me know. However it seems like a pretty intractable problem: 

Unless evolution's mainloop runs when calling out of process to something that prompts, there's a good chance someone somewhere is going to deadlock.

Would it be possible to add a parameter to gnome-keyring that it should always produce the secrets?  I run a small desktop system, used only by me, and I think gnome-keyring is mostly a bother; it's just one more thing to type in at startup time.  My keyring contains only one secret that I know of, namely the password for my pop server.  

Or maybe I just don't understand.

(In reply to comment #11)
> Would it be possible to add a parameter to gnome-keyring that it should always
> produce the secrets?  I run a small desktop system, used only by me, and I
> think gnome-keyring is mostly a bother; it's just one more thing to type in at
> startup time.  My keyring contains only one secret that I know of, namely the
> password for my pop server.  

I think I do not understand here. Do you mean by "always produce the secrets" something like "being unlocked on login"? It works for me as long as I have the same password for a default keyring as is my login password. I noticed somewhere some issues with defined two keyrings, but, if I recall correctly, it was after some update between major versions or something. It's quite long time ago.

Anyway, I do not think it is a question for this bug report.

Created attachment 145855 [details] [review]
proposed eds patch

for evolution-data-server;

Stef, did you mean anything like this, please? I tried to produce something not much invasive, to keep the actual concept as much as possible. You know, there are enough rewrites in the code already. Note I sort of miss a function to copy GnomeKeyringFound structure. I left there the call of gnome_keyring_get_default_keyring_sync
because it's called in a main thread, before any window creation, thus I believe it's ok to have it done this way.

Also, I'm not able to reproduce the hang myself, it'll be great if someone can try this patch and report back whether it works for him/her.

(In reply to comment #12)
> (In reply to comment #11)
> > Would it be possible to add a parameter to gnome-keyring that it should always
> > produce the secrets?  I run a small desktop system, used only by me, and I
> > think gnome-keyring is mostly a bother; it's just one more thing to type in at
> > startup time.  My keyring contains only one secret that I know of, namely the
> > password for my pop server.  
> 
> I think I do not understand here. Do you mean by "always produce the secrets"
> something like "being unlocked on login"? It works for me as long as I have the
> same password for a default keyring as is my login password. I noticed
> somewhere some issues with defined two keyrings, but, if I recall correctly, it
> was after some update between major versions or something. It's quite long time
> ago.

This is exactly what I mean: that gnome-keyring should be unlocked at login given some condition, and having the keyring password be the same as the login password is better than most.  But my keyring password *is* the same as my login password, and the keyring has never been unlocked at login, at least since the Fedora-11 release.

> Anyway, I do not think it is a question for this bug report.

Right again!  I will post this as a bug or suggestion for gnome-keyring.

(In reply to comment #14)
> This is exactly what I mean: that gnome-keyring should be unlocked at login
> given some condition, and having the keyring password be the same as the login
> password is better than most.  But my keyring password *is* the same as my
> login password, and the keyring has never been unlocked at login, at least
> since the Fedora-11 release.

Might be something with your setup, as it works fine on my F11. I do not know how, but try to check how many keyrings you have defined and ensure you'll have only one. (If I recall correctly, there can be a "default" and  "login" keyring, but only one of those is The One. I've no knowledge of keyrings, maybe Stef knows more.)

Hmm, this is quite outdated now, and I didn't notice any similar bugreport since, not with keyring which is used exclusively now. Did this solve itself in the time?

I changed my mail fetching method to be fetchmail and the local retrieval by evolution long ago; a method much less prone to these kinds of problems than direct use of POP by evolution.  So my own quiet doesn't mean much.

BTW: My old problem with the keyring has got better.  Probably solved itself.

I suppose this is is obsolete by 3.4.0, thus I'm closing it now. Please reopen if you see such issue in 3.4.0 or any later releases. Thanks in advance.