Created attachment 128717 [details]
Try for a test case

I'm trying to understand this problem better. I've written a test program for it. The test program shows a menu, and then the keyring ask dialog in attempt lock up the screen similar to this bug.

I can't get it to happen, but I'd like to ask you to try the test program to see if it duplicates the behavior for you.

This test program assumes GNOME is installed in /usr as is usually the case in most distros.

BTW, if anyone needs instructions on how to run the test program:

 * Save the file as gtk-test.c 
 * Install your OS's build packages (on Debian build-essential, libgtk2.0-dev)
 * In same directory as file run command on first line of the file. Remove /* and */

I've also added the strings to gnome-keyring that for the showing of an error dialog (since we're soon entering string freeze) once we figure out what the problem is and how to fix it. 

it takes a few right click, but then it triggers this "grabbing" deadlock as i would say. Only way out was to kill gdm on console.

Also i encounter situations similar to this (nothing gets any focus/clicks), but even alt-ctrl-F1 doesn't work anymore. Could this be related? ... by grabbing even more keyboard/input? (i think the total lockup happens in combination with gtk pinentry for me which seems to grab more aggressively).

Do you need more info?

also of interest that killing the test binary on console doesnt help. once i reach this deadlock situation only restarting X helps.

Alexander, could you describe your X environment so I can try and replicate it more closely:

 * Window manager
 * Use of desktop effects
 * Distro and version?

Thanks!

WM: Compiz with normal desktop effects
Distro: ubuntu jaunty 9.04 (up to date).

Interesting, I'll be upgrading to jaunty shortly and will try to duplicate there. I appreciate the info.

When I try to duplicate this on an up to date Jaunty (ie: using the test program attached) the session doesn't lock up for me.

I get the following output (which is to be expected):

stef@stef-laptop:~/Desktop$ ./gtk-test 
show menu
run gnome-keyring-ask
** Message: could not grab keyboard: 1
** Message: could not grab keyboard: 1
** Message: could not grab keyboard: 1

The number 1 above represents 'GDK_GRAB_ALREADY_GRABBED'. See GdkGrabStatus in the documentation.

Could you duplicate the problem, and paste the output of the test program attached?

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

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

Anyone have the output of the sample program when the hang occurs? I'd like to fix this before 2.28.0. 

I know that this is not the info you want but I had no luck with the test program. Output was as follows. 

And I know that on my system this bug can be replicated since I reported a duplicate 573819 for this bug. 

Hope that this helps a bit since I confirm that the bug does not occur with the test program.

show menu
run gnome-keyring-ask
** Message: could not grab keyboard: 1
** Message: could not grab keyboard: 1
** Message: could not grab keyboard: 1
mypassword


[general]
response=2
show menu
run gnome-keyring-ask
** Message: could not grab keyboard: 1
** Message: could not grab keyboard: 1
** Message: could not grab keyboard: 1
mypassword

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

I just encountered an issue that I think is very similar to the one described.  In my case, I opened evolution.  I right-clicked a folder, which popped up a context menu.  While the context menu was still open, evolution attempted to update my accounts, so a gnome-keyring dialog appeared.  When the dialog appeared, my X session became completely unresponsive to keyboard or mouse.  The only way I could recover was to switch to a virtual console (Ctrl+Alt+F1) and kill evolution.  This is a very serious issue.  For most normal users that don't know about Ctrl+Alt+F1, the only solution would be a hard power-down of the computer.

We need to find a way to reliably duplicate this. It seems to be dependent on the window manager being used, but I'm not sure. 

Do you have a way to reliably duplicate this? Could you describe it? 

If you could had the means and time to write a tiny application which duplicates the problem, that would help immensely toward fixing the problem. But that may be asking too much. I'd be happy with any help you could contribute.

hm, did you try to reproduce the steps I mentioned in my previous comment? (start evolution, right-click a folder, wait for gnome-keyring dialog).  I replicated that several times in a row here, does it not work on your machine?  This requires you to have not granted evolution the ability to always access the keyring, of course.  (btw, I'm just using stock metacity as window manager)

The evolution case is due to them using the sync gnome-keyring APIs, which are not appropriate for use in a GTK mainloop driven GUI application:

~/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);

When evolution grabs the keyboard (due to a menu) and then executes a keyring 'sync' call, it no longer runs its mainloop until that API returns. The API does not return until after the keyring prompt.

In addition this same reason is why network-manager-applet is hanging:

~/contrib/network-manager-applet$ grep -R gnome_keyring * | grep sync
src/gconf-helpers/gconf-upgrade.c:	result = gnome_keyring_find_itemsv_sync (GNOME_KEYRING_ITEM_GENERIC_SECRET,
src/gconf-helpers/gconf-upgrade.c:	result = gnome_keyring_find_network_password_sync (g_get_user_name (), /* user */
src/gconf-helpers/gconf-upgrade.c:	ret = gnome_keyring_find_itemsv_sync (GNOME_KEYRING_ITEM_GENERIC_SECRET,
src/gconf-helpers/gconf-upgrade.c:	gnome_keyring_item_delete_sync (found->keyring, found->item_id);
src/gconf-helpers/gconf-upgrade.c:	ret = gnome_keyring_find_itemsv_sync (GNOME_KEYRING_ITEM_GENERIC_SECRET,
src/gconf-helpers/gconf-upgrade.c:	gnome_keyring_item_delete_sync (found->keyring, found->item_id);
src/gconf-helpers/gconf-upgrade.c:	status = gnome_keyring_find_network_password_sync (g_get_user_name (),     /* user */
src/gconf-helpers/gconf-upgrade.c:		gnome_keyring_item_delete_sync (found->keyring, found->item_id);
src/gconf-helpers/gconf-upgrade.c:		ret = gnome_keyring_find_itemsv_sync (GNOME_KEYRING_ITEM_GENERIC_SECRET,
src/gconf-helpers/gconf-upgrade.c:			ret = gnome_keyring_find_itemsv_sync (GNOME_KEYRING_ITEM_GENERIC_SECRET,
src/gconf-helpers/gconf-upgrade.c:				ret = gnome_keyring_item_delete_sync (found->keyring, found->item_id);
src/gconf-helpers/gconf-upgrade.c:	ret = gnome_keyring_find_itemsv_sync (GNOME_KEYRING_ITEM_GENERIC_SECRET,
src/gconf-helpers/gconf-upgrade.c:		gnome_keyring_item_delete_sync (found->keyring, found->item_id);
src/gconf-helpers/gconf-helpers.c:	if (gnome_keyring_get_info_sync (NULL, &info) == GNOME_KEYRING_RESULT_OK) {
src/gconf-helpers/gconf-helpers.c:	ret = gnome_keyring_item_create_sync (NULL,
src/gconf-helpers/nma-gconf-connection.c:	ret = gnome_keyring_find_itemsv_sync (GNOME_KEYRING_ITEM_GENERIC_SECRET,
src/gconf-helpers/nma-gconf-connection.c:	ret = gnome_keyring_find_itemsv_sync (GNOME_KEYRING_ITEM_GENERIC_SECRET,

Changing product to network-manager-applet. Related bug for evolution-data-server is bug #595421

nm-applet will close the menu before any operation that uses the keyring; see src/gconf-helpers/gconf-helpers.c, pre_keyring_callback().  Yes, it's a hack around using sync keyring functions, but it works.

What version of NM did you see this with?  Because it shouldn't have been happening since early 2009.

0.7.0 but I am still using ubuntu 8.10

(Synaptic reports cryptic 0.7~~svn20081020t00044ubuntu1.8.10.2

Reopening as the requested information has been provided.

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

The fix for this bug was committed on 2008-10-28 (commit 7083b298) so I think the version Ubuntu shipped in 8.10 just missed this fix by a week :(  But it's fixed now.