GNOME Bugzilla – Bug 621063
Deadlock if a menu is open when keyring unlock prompt pops up
Last modified: 2012-06-10 15:13:52 UTC
I'm using Ubuntu Lucid Lynx, on an Asus UL80Ag. The subject basically says everything you should need to reproduce this bug. Let me know if more info is needed. The bug gets easier to reproduce if Evolution is set to check mails automatically on startup and then it is started with keyring locked while the computer is connected to a slow internet connection (around 2-3 KB/s). That way you'll have ample time to click on a menu item and wait for the unlock prompt to appear. The bug may in fact not be Evolution-specific, since entire gnome gets deadlocked until I kill the evolution process. However, the fact remains that it poses a serious problem to Evolution users when it occurs (most ppl will simply restart their pc at this point), and it can probably be solved from within the Evolution codebase (wait for menus to close before prompting for keyring, by ensuring mutual exclusion between menu activation and keyring access).
We have no control over that prompt, and it sounds like it could be an issue with any application. Reassigning to gnome-keyring to get their take.
I believe evolution uses synchronous APIs to access gnome-keyring. This is like handing away the beating heart of your application to another process. In particular if you have a menu open (which grabs the mouse) and gnome-keyring prompts (which grabs the mouse) then your menu has no chance to close, because there is no longer a mainloop running inside of evolution. Always use async calls when running a GUI. Alternatively you can use the Secret Service DBus API to access secrets in gnome-keyring. This API gives you much more control over when a prompt is displayed.
Fair enough. Completely redesigning our password API is still on my long-term to-do list. We got away with syncrhonous access to ~/.gnome2_private/Evolution in years past, and I think the keyring integration was hacked in to fit the existing syncrhonous e-passwords API.
A simple, but imperfect, way of making your synchronous password API work with async gnome-keyring calls is to use a modal main loop. Basically you change each synchronous gnome-keyring call to an asynchronous one, and wait for the asynchronous one to complete in its own main loop (similar to a modal dialog).
Thanks, I'll give that a try.
*** Bug 616146 has been marked as a duplicate of this bug. ***
This is resolved in Evolution 3.5.3. Password prompts are now system modal and are handled by a D-Bus service rather than Evolution (or any other EDS-based app).