I see this too. Interestingly, if I have a hung gnome-shell, and then try to replace with metacity, it takes about 10-20 seconds before I can interact with any windows again.

(also see bug 653833 comment 13 and related for some earlier discussion about this problem)

As a quick hack workaround (thanks Ray!):

  $ gsettings set org.gnome.settings-daemon.plugins.keyboard active false
  $ sudo mv /usr/bin/xkbcomp{,.bak}
  $ sudo ln -s /bin/true /usr/bin/xkbcomp

Note that this disables the GNOME code for manipulating keyboard stuff, so things like Alt-<Above_Tab> may break.

I dug into this briefly on the 15th/16th and started to get a picture on what was going on, but didn't quite figure out all the details before I put it down.  I haven't picked it back up since, and I don't know if I'll get back to it for a while, so I thought I should post details now before I forget them.

It seems like gnome-settings-daemon and gnome-shell are in a bit of fight, mucking with the keyboard settings. I think gnome-shell is doing it's alt-above-tab thing, and gnome-settings-daemon is doing it's layout options (like where compose key is).

I my case, the fight was because libgnomekbd didn't think the two options were equal, since one had the name "compose" and one had the name "Compose Key".

running 

gnome-control-center region
Clicking "Layouts"
Clicking "Options"
and then unchecking all the bold entries so there no bold entries

makes the problem go away for me.  It shouldn't be too hard to figure out what's going on from here, and I'll look at some point.

(In reply to comment #4)
> I dug into this briefly on the 15th/16th and started to get a picture on what
> was going on, but didn't quite figure out all the details before I put it down.
>  I haven't picked it back up since, and I don't know if I'll get back to it for
> a while, so I thought I should post details now before I forget them.
> 
> It seems like gnome-settings-daemon and gnome-shell are in a bit of fight,
> mucking with the keyboard settings. I think gnome-shell is doing it's
> alt-above-tab thing, and gnome-settings-daemon is doing it's layout options
> (like where compose key is).

Mutter simply passively reads layout information, so it's hard to see how it would "fight" with gnome-settings-daemon; the only thing I can think of is that somehow the layout is being changed many times, and reading geometry information each time makes that more expensive.

I'll have to dig back into it before i can give any sort of clear answer, but it was calling XkbGetKeyboard() which under the hood made the X server run xkbcomp which woke up gnome-settings-daemon which made libxklavier (or something) wake up and do something that made gnome-shell wake up again, etc etc

okay, i looked into this a little more.  Here's what happening (as far as I understand it):

- On VT switch the keyboard gets hotplugged back into action
- gsd wakes up with the "X-new-device" signal in libxklavier
- It looks at gsettings and tries to figure out what modifications to apply to 
  the device (such as the compose key).  They come from gsettings in the form 
  "Compose key\tcompose:ralt".  The "Compose key" part is an id shipped in 
  xkeyboard-config that the control-center region panel options dialog uses 
  enumerating and identifying options. libgnomekbd calls that part the 
  "option group" and the other part the "option".
- gnome-settings-daemon asks libgnomekbd if the proposed modifications are 
  different from the current configuration. libgnomekbd completes the request 
  by:
   - first loading up the current configuration from the _XKB_RULES_NAMES root 
     window property.
   - comparing it to the proposed configuration 1 by 1.  In order for the 
     function to succeed, the configuration items from the current config 
     and the proposed config need to be in the same order,
     and have the same options with the same option group names.  Note 
     the _XKB_RULES_NAMES property doesn't ever have a copy of the stored
     option group names in it, it only has the options themselves.  So the
     current configuration will never match equal to a proposed configuration
     that contains option group names. For reference, an example of the
     _XKB_RULES_NAMES property is something like:

     _XKB_RULES_NAMES(STRING) = <layout stuff here>,
                                "compose:ralt,terminate:ctrl_alt_bksp"

- Since the current configuration and proposed configuration won't show up equal, libgnomekbd uses libxklavier to apply the new configuration.  This causes all sorts of stuff to happen including forking a call to xkbcomp, which makes all the machinery start over and wake up again. Thus the tight loop.  I don't know why the loop eventually stops after 30-45 seconds.
- All the while, gnome-shell is waking up in a loop trying to refind where the the key above tab is each time the keyboard is mucked with.

moving to libgnomekbd

Created attachment 210291 [details] [review]
config: plug minor leak

gkbd_keyboard_config_split_items allocates its out args, but
those allocations aren't getting cleaned up in
gkbd_keyboard_config_copy_to_xkl_config

This commit plugs that leak.

Created attachment 210292 [details] [review]
config: make gkbd_keyboard_config_equals more forgiving

options should be able to appear in different orders,
or have different group names and still appear as equal.

This commit makes gkbd_keyboard_config_equals more
forgiving.

attachment 210292 [details] [review] breaks the cycle by making the equality check by e.g. considering "Compose key\tcompose:ralt" and "compose:ralt" equal .

Review of attachment 210291 [details] [review]:

Looks correct to me

Review of attachment 210292 [details] [review]:

Might make sense to factor that out as a compare_options() function ?

Created attachment 210378 [details] [review]
config: make gkbd_keyboard_config_equals more forgiving

options should be able to appear in different orders,
or have different group names and still appear as equal.

This commit makes gkbd_keyboard_config_equals more
forgiving.

Comment on attachment 210291 [details] [review]
config: plug minor leak

looks like svu already pushed this one, so marking it as so.

Thank you! All commited.

Seems like the commited memleak fix is crashing g-s-d, see bug #672729

Damnit! Stupid me. The split function does not allocate the memory! It is using the static buffers. That is why the first patch should be reverted. I will do release libgnomekbd 3.4.0.1

The patch is reverted.

my fault, I should have went back and double checked that assumption.  We're going to need fixes in the other commit as well, since it also calls split_items.

Created attachment 210626 [details] [review]
Fix up split_items usage

commit c9d3c0e939c21230d6088aaf915d9b7d965d97d8 introduced a couple
of calls to gkbd_keyboard_config_split_items with the incorrect
assumption that those calls return newly allocated memory.

This commit drops the wrong free calls.

Will commit tonight and release 3.4.0.2

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

Thanks, svu.

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

3.4.0.2 is available