GNOME Bugzilla – Bug 133584
Occasional loss of window decorations
Last modified: 2005-01-26 16:55:54 UTC
I encounter a strange bug with Metacity sometimes when I am launching a program (specifically, launching "acroread" from an Emacs compile process), in which the window decorations do not show, and the window doesn't get input focus. It doesn't always happen, but when it does it's a pain because I can't resize the window etc. To reproduce: From emacs, type "M-x compile (Ret) acroread file.pdf". You might have to do it a few times, as it is an intermittent problem. I don't know if this is a Metacity thing, or an Acrobat Reader thing, or an Emacs thing, but Metacity probably should never let this happen. It's a very rare confluence of events for the average user though, so I imagine it's low priority, but it might illustrate something fundamental that's out of whack.
Is it just acrobat reader that has no decorations, or all windows? That is, did metacity just crash?
Just Acrobat reader. Doesn't look like a crash. I also tried gedit, launched from "M-x compile", and couldn't get it to do the same thing.
Hmm. Here's a simplification of the usage case: the same thing happens if I launch acroread from the terminal. I don't think it used to do that. It is still intermittent, so it may be a race condition. Attaching two screenshots, with and without window decorations.
Created attachment 24161 [details] no window decorations
Created attachment 24162 [details] with window decorations
N.B. Metacity version is 2.6.4.
Is this helpful? $ metacity --replace (metacity:13194): GLib-CRITICAL **: file gstrfuncs.c: line 2129 (g_strsplit): assertion `string != NULL' failed (metacity:13194): GLib-CRITICAL **: file gstrfuncs.c: line 2241 (g_strjoinv): assertion `str_array != NULL' failed -- No additional errors are reported on the terminal when the decorations fail to show up.
bizarre. I use acroread all the time and I've never seen that happen. Is it perhaps just that theme? Is that acroread 5.08?
Yes, same version. And it's not doing it now either, without me changing anything at all -- but I've seen this sporadically for the last 2 months (usually many times a day) so I'm sure it'll come back :o) I can't seem to turn any debug info on for Metacity -- is there a way to do it?
run: METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity--replace & then reproduce the problem, then restart metacity again with: metacity --replace You'll end up with a very very verbose debug spew in a file call /tmp/metacity-[something]. gzip the file and attach it to this bug report if you can get the problem reproduced again. The only thing that I could possibly think of is that metacity incorrectly decides that acroread is a borderless window.
Created attachment 24169 [details] the debug file
Here it is -- I got the problem again. The window you want comes up as "(Fast Regis)" in the debug file. Interestingly, by the time I had gone through the two steps that you outlined, then pressed Ctrl-C to kill the last version of Metacity and restart it for the third time, the window decorations were back, and I don't know when they appeared. Can you see anything unusual in the debug file?
Looks like a Heisenbug -- it goes away if you look at it :) I added the debug commands again after upgrading to Metacity 2.7.0, and never had the problem once in 2 days. Then I stopped running Metacity in debug mode, and the problem came back. It must be a race condition. I hope there is some info in the log file I attached above, because catching this with all the debug stuff turned on is very difficult.
*** Bug 138661 has been marked as a duplicate of this bug. ***
There are some warnings that valgrind lists relating to uninitialized variables and in dealing with the frame (i.e. decoration) code. See bug 153338 (which was marked as fixed merely because I was able to fix some of the issues, but I didn't have the patience/time/understanding/desire to track down the other problems). It appears that running metacity under valgrind requires around 1.5GB of ram so most probably won't be able to do so, but I can generate a new log upon demand.
The log file Luke posted claims that the windows were decorated correctly, so if the bug happened during that log slice the problem would have to be something like the X reparent into the frame failing, though that sounds far-fetched. Those valgrind errors look like they would have to be a GDK bug - the args metacity passes to gdk_window_new() are fully initialized as far as I can see.
Havoc: uninitialized variables don't trigger errors in valgrind upon copy (e.g. passing the varible to another function) until they are used for something such as printing or such. Thus, the valgrind stack trace is usually much deeper in some other function than where the uninitialized variable really occurs. See the other bugs I fixed in 153338 for two examples. While it's possible those are uninitialized variables in gdk instead of metacity, I think it's likely that they really are metacity problems. Especially since I'm sure other programs utilizing g_hash and such have already been valgrinded...
What I'm saying is just that if we pass only fully-initialized stuff to gdk_window_new() then it must get uninitialized stuff from elsewhere. The elsewhere could be some sort of global variable that metacity has affected, of course.
Bug 145131 has a simple test program that one can run, and which fairly often results in at least one of the windows that it displays not getting decorations. I believe these two bugs are dupes, and that the test program from 145131 will hopefully help us be able to track this down (I can at least duplicate at will now, and valgrind does appear to give some warnings when that program is run, though I haven't had much time to look into it...)
I'm going to go ahead and mark this as a duplicate of 145131... *** This bug has been marked as a duplicate of 145131 ***