Lots of windows needing Force Quit can hang metacity

This is on an uptodate dapper beta.

Thank you for your bug. Is that metacity hanging when that happen (like no action is doing something)? Could you get a backtrace by attaching it with gdb from an another account opened by example? Could you attach a small test case or describes some steps to get the issue?

Yes, the wm was hung, it wasn't possible to change focus. It did seem to hand over nicely to a new wm though I don't know whether the X protocol for that needs the previous one to be alive.

It happened several times, but since then, I can't reproduce it with latest updates, even though I've carefully not got around to fixing my bug :-) It never really used to happen when I tried though anyway.

So who knows. I'll keep an eye out for it, and try to debug if I can.

you can switch to an another VT when the window manager is frozen to get the backtrace

It happened again. I'm not so convinced its metacity and not the X server.

I had two instances of the deadlocked program. I clicked on one close box, got the force quit dialog, clicked on force quit, and got a frozen display. The force quit button was still pressed.

ctrl-alt-f1 switched to another VT, logged in, looked at the processes running.
There were still 2 deadlocked ones, so I thought "It might be waiting for one to die." I kill -9ed them. Switch back to X with alt-f7. Redraw doesn't happen for the hung windows, for the gnome panels, for the backdrop. It /does/ happen for a firefox in background. I try alt-tab a bit, and ctrl-shift-right to switch desktops. Nothing works. But strangely, Neither does ctrl-alt-f1 anymore!! Isn't that implemented at the X server level? How can it be blocked?

I ssh into laptop from another machine and chvt 1. This works fine.

From vt 1, I gdb attach to metacity to get a backtrace.
Not very exciting:
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb772b88d in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb78f57d8 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#3 0xb78f5ca8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4 0x080749e2 in ?? ()
#5 0x080ec3b8 in ?? ()
#6 0x080bd760 in _IO_stdin_used ()
#7 0x00000000 in ?? ()
(gdb) quit
How about strace?
Process 5649 attached - interrupt to quit
ioctl(12, FIONREAD, [0]) = 0
poll( <unfinished ...>
Process 5649 detached

Ok.
I switch back to the screen with alt-f7. Still broken, crtl-alt-f1 still fails. sshed chvt again.

Now I try DISPLAY=:0 metacity --replace on vt1.

alt-f7, and interestingly, the desktop switch has happened, all the windows are gone, backdrop and panels redraw properly. But the desktop switch panel is stuck visible in the centre, no mouse or keyboard response. ctrl-alt-f1 still not working.

sshed chvt again.

ctrl-c that metcity. Check ps - no metacity processes around. Run fvwm in the same way. switch to vt7. Redrawn ugly window borders, still no key/mouse response. (Pointer moves tho). sshed chvt.

Re-run metacity from vt1. Still non-resposive.

Hmm..... while typing this, the screensaver kicked in. Working fine. pressing space prompts for pw.... pw dialog works fine... its back!!! Everything now working fine.

I'm stumped. ideas anyone?

How is X keyboard grabbing supposed to integrate with ctrl-alt-f1?

marking as unconfirmed since details have been provided, maybe somebody is wanting to work on debugging that

This bug is quite old and is listed as being in a beta of Dapper....

Is it still an issue?

Marking as invalid as the bug is from Dapper Beta and the submitter has not replied that it is still an issue.