GNOME Bugzilla – Bug 131196
Metacity appears to crash when changing windows
Last modified: 2004-12-22 21:47:04 UTC
The best way I can reproduce this is to: * Log in as a normal user * Open a terminal * Press alt+tab - the terminal window decorations should vanish then reappear and the terminal should move down+to the right slightly. if you continue pressing alt+tab it keeps happening until metacity seems to vanish forever. Occasionally this happens when I've got two windows open and want to switch between them.
what version of metacity are you using? I suspect this is the mru list bug again. Could you try a CVS metacity, perhaps?
Probably should have put this in when I first commented. I'm using metacity 2.6.3. I'll give cvs a try.. when I have a bit more time, can't guarantee this will be speedy though sorry :-/
Window manager warning: Log level 6: file window.c: line 978 (meta_window_free): assertion failed: (g_list_find (workspace->mru_list, window) == NULL) Aborted /tmp/metacity$ grep VERSION Makefile VERSION = 2.7.0 distdir = $(PACKAGE)-$(VERSION) checked out today, compiled in /tmp/metacity, started with src/metacity --replace
What did you do to cause that to happen?
Well, hard to say, working :). I think it happens after alt-tabbing. I am not sure if it only happens if you switch the workspace right before. But opening some windows on diffrent worspaces and regulary switching between them (with alt-ctrl-cursorkeys) and alt-tabbing between the windows on each worspace seems to provoke it. I built cvs metacity with maintainer-mode now and disabled core file limits, so perheps I can provide you with a backtrace some time later.
Something I have noticed is when switching workspaces with alt-control-left and alt-control-right (I think there are default bindings) the active window is no longer focused. Metacity obvously realises that it was active though because alt-tab switches to the window that was second in the list. This is a major pain when developing stuff because I prefer not to touch the mouse and alt-tabbing twice to get my window back is a pain. Don't know if it is related.
Window manager warning: Log level 6: file workspace.c: line 135 (meta_workspace_add_window): assertion failed: (g_list_find (workspace->mru_list, window) == NULL) Aborted (core dumped) I wanted to alt-tab to another application on that workspace and I noticed that a windows was displayed in the mini-icon list that was not on that workspace but on the one just below.
+ Trace 44310
I'm not so sure that Daniel and Stefan are talking about the same bug, even though they may appear to sound similar... Daniel: I believe that your comment as of 2004-02-18 06:23 (Bugzilla time) is a separate issue, but one that I think I know how to fix. I'll look into it. Stefan: So I guess the big issue is how did you get a window that is not in the current workspace to appear in the alt-tab list? I'd like to know how to cause that, because I don't know how to get that to happen and thus I can't duplicate this bug. Of course, I'm still "learning the ropes" with Metacity, so I'll try to dig deeper.
OK I'm returning to my FocusIn theory about what could be causing this. Stefan, could you try current CVS HEAD? I've committed a change that adds an assert in a different place. It should still crash, but hopefully it will crash in a different place. (and send in the line where the assertion failed). I can't reproduce this on my system, so I need you to test this for me.
How it happens: As I said, just working :). I have 15 Workspaces, lots of applications (8+ Shells, galeon, evolution, mozilla, acrobat, pan, nautilus, ...). I switch workspaces with my keyboard (alt+ctrl-cursorkeys). Most workspaces have more than one application running, so I need alt+tab to bring the application I want to the front. And one time I noticed mozilla in the alt+tab icon list though it wasn't on that workspace. After releasing alt metacity crashed. CVS: will try it, but might take a day or two.
Window manager warning: Log level 6: file window.c: line 4138 (meta_window_notif y_focus): assertion failed: (link) Aborted (core dumped)
+ Trace 44487
I saw the effect of a "wrong" application beeing listed in the alt+tab window list again. I found out that nothing bad happens if I do not alt+tab to the "wrong" application.
Should this be marked as a duplicate of bug 122016 (note especially jlaska's most recent comment)?
The only thing is.. I'm not sure if the bug Stefan is describing is the same one I did.. I'm going to install cvs head today and see if the bug I reported has been fixed..
Hi All.. I just installed cvs metacity. The problem with applications not being focused seems to be fixed. I haven't been able to replicated the original bug I posted with this version yet.. I'll keep trying to break it!
I think that the bug was caused by a race condition that I just fixed, which makes the behavior hard to reproduce. Please see #122016 for further updates. *** This bug has been marked as a duplicate of 122016 ***
Daniel and Stefan may have been talking about the same bug after all. While trying to duplicate bug 122016 (using Markus' duplication instructions in that report), I saw the behavior that Daniel described. I didn't get to check into it, because I was concentrating on 122016 at the time (along with bugsquad and gnome-love stuff) and not long thereafter my workstation became toast (suspected hard drive failure, but who knows as the sysadmin has it in his office and is still working on it). My setup in that case was a 2x2 workspace array with four windows per workspace, resized so that jointly they filled up most the screen (and there was perhaps some overlap). Other than that, I did what Markus said, though I kept repeating the steps even when I saw a "funny pause". That funny pause, I didn't realize at the time, was Metacity crashing and restarting. So maybe it was due to metacity not restarting well when under larger load and/or with queued keystrokes? I don't know...but I'll check into it further if anyone's interested. But I do think Rob's patch in bug 122016 either fixed this or effectively avoided it, so I'm not bothering unless someone yells. :)