GNOME Bugzilla – Bug 361097
metacity 2.14.5 freezes desktop
Last modified: 2006-10-14 02:53:32 UTC
Please describe the problem: I'm running VMWare broser appliance upgraded to Ubuntu Edgy. After last upgrade to metacity 2.14.5 desktop freezes after a few minutes. Using Alt+F2 and killall metacity "resolves" the problem temporarily, but in next few minutes metacity freezes again. After 3 attempts even Alt+F2 stops working. Downgrade to 2.14.3 is stable, no metacity freezes so far (2 days). Steps to reproduce: Actual results: Expected results: Does this happen every time? Yes Other information:
Edgy is using 2.14.5?? That makes no sense. 2.16.x is out and is basically just bugfixes to 2.14.x, so there's no reason for us to really support 2.14.x. Anyway there were only 6 patches between 2.14.3 and 2.14.5. If someone else wants to look into which caused such a problem (if anyone else can reproduce), it may be useful. I don't have time to do so with 2.14.x.
edgy is using 2.16.3 currently
So, something's wrong with the bug report. Vitezslav: are you using dapper or edgy? what's the metacity version? If you really are using edgy but somehow have metacity 2.14.5, I suspect something to be wrong with the way you upgraded and that it may just be your machine that's broken...
The submitter opened the same bug on launchpad too: https://launchpad.net/distros/ubuntu/+source/metacity/+bug/65025 I've asked him for precisions on the version too when we got the bug, he's using dapper, not edgy
I'm sorry for the confusion - yes, I have problem with metacity 2.14.5 on _Dapper_Drake_. Sebastien Bacher asked me for backtrace, here it is. Please note I'm experiencing these problems on virtual machine running in VMWare player environment. As the desktop froze on the affected vm (and there was no ssh access configured, nor was it possible to switch to text console), I had to manually write down the backtrace, so I'm sorry for possible typos: ... 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt
+ Trace 75662
Thread 1 (Thread -1217673536 (LWP 4123))
Warning - long story follows: Today I've been trying to reproduce the bug on another vm clone, but for some reasons it was stable for several hours. Nevertheless other users reported problems before and I also experienced this freeze several times yesterday. Please let me once again sum up the problem: - user experiences desktop environment freeze - windows don't focus or move, gnome-panel is not resposive, *but* the multiload-applet-2 and clock still work - user can press Alt+F2 and run gnome-terminal - killall metacity works, windows lose decorations and get them again as a result of window manager being restarted - "freeze" is relieved, desktop environment works fine again - in a few minutes user experiences freeze again, some users reported that after 3 or so attempts the desktop "froze" totally and Alt+F2 didn't work. They closed VMWare Player, but while doing so they could see system shutting down in text mode, so not everything has been "frozen" anyway. - after downgrade to metacity 2.14.3 none of affected users reported the problem again. I'll reconfigure those vm's for remote ssh access to be able to see inside if it happens again. Sorry for long comment and thank you all for your time.
The fact that Alt+F2 can continue to work makes it sound like metacity isn't really frozen since metacity handles that keystroke (though it simply forwards it on to the panel); if it was really frozen, that keystroke wouldn't work. That also means a stack trace, even if it had debugging symbols, isn't going to be useful. It sounds like maybe there's a stuck mouse grab somewhere? I really don't see anything in the ChangeLog that would cause this; someone with time to debug this should try out the individual patches between 2.14.3 and 2.14.5 (there were only 6 of them) and also look at any ubuntu specific patches that may have changed between the two.
Thanks for the stuck mouse grab comment - I've lost keyboard and mouse completely several times when debugging that virtual machine image, but I thought it was just some obscure hardware (read: vmware) problem triggered by resizing and switching vmware player window. But as killing metacity helps (at least in the first few attemps), I am worried the problem lies somewhere in the hosted system.
I did some thorough testing, right now I've one "frozen" vm in front of me, I'm also connected via ssh. It looks like left mouse button doesn't work - clicking windows doesn't bring them to foreground, but mouse cursor changes shape on window borders and I can resize the window, which is then automatically foregrounded. Mouse clicking icons in Nautilus add new highlighted icons, as if CTRL was pressed. (I have tail -f /var/log/messages running in teminal, so if someone holds CTRL for me, maybe just pressing 'C' will send CTRL+C ... nope. Keyboard is gone). Clicking on menus in gnome-panel (Applications Places System) hightlights the menu "buttons", but doesn't show the menus themselves. But clicking gedit icon on panel runs gedit successfully. I can switch desktops using panel applet, clicking on system monitor applet runs gnome-system-monitor and I can switch its tabs, but menus don't work. To make long story short - keyboard input gone, mouse in application working, but menus don't show and windows don't came to front when clicked (but they can be foregrounded by resizing using mouse). Does it sound a bell to someone? No errors in .xsession-errors (except for some ALSA complaints on nonexistent devices, but we don't need sound on this vm), dmesg shows nothing new, /var/log/messages says -- MARK --. I believe something is very wrong on virtualization level. I've even lost ssh connection to the vm two times (putty says 'software caused connection abort'). I'll try to rebuild the vm from scratch, it now really looks like bug 361097 affects metacity just as a "colatteral damage". Consider RESOLVED, reason force majeure or possibly (virtual) hardware failure. Sorry for the buzz and thanks for your time and patience.
In reply to comment #8) > Consider RESOLVED, reason force majeure or possibly (virtual) hardware failure. Okay, will do. Thanks for following up. :) If you find it still gives problems after fixing everything else and can narrow down the patch that caused it, feel free to reopen.