GNOME Bugzilla – Bug 422242
metacity crashed with SIGSEGV in event_callback()
Last modified: 2008-07-16 22:02:17 UTC
The bug has been described on https://launchpad.net/bugs/92502 "Binary package hint: metacity Same as bug 85763, however, with different hardware. Creating the bug report anyway, even though it is quite likely that it is going to be filed as a duplicate. I have the i810 in a dual-screen setup. This crash does not occur when there is only one screen. I thought we were past the dual-head problems on the i810…? :-) ProblemType: Crash Architecture: i386 CrashCounter: 1 Date: Thu Mar 15 08:28:13 2007 DistroRelease: Ubuntu 7.04 ExecutablePath: /usr/bin/metacity Package: metacity 1:2.18.0-0ubuntu1 ... .
+ Trace 121735
Thread 1 (process 5375)
The crash happens when using desktop effects to run compiz
> The crash happens when using desktop effects to run compiz NOTGNOME
why? it's metacity crashing
You should not be running both Metacity and Compiz at the same time. They're both window managers and you should only have one of them running at a time. Compiz is not currently part of the gnome desktop, so if it's a Compiz bug then it's definitely not gnome. However, the top of the stack trace indicates that the binary that crashed was Metacity. In your Ubuntu bug, it sounds like Metacity is crashing when you're trying to enable visual effects? If that is the case then this might be a crash when compiz --replace is being called. That still leaves the question of whether it's metacity crashing at replacement time or compiz crashing at startup. There isn't really much more to go on in that launchpad bug though :-/
(In reply to comment #2) > why? it's metacity crashing ah, right. Didn't read that closely, did I? I won't easily be able to look at it; until I get better hardware (intel stuff as I hear) I can't duplicate.
(Now marking as needinfo, as per Martin's comments. It looks like we've got a new knowledgeable metacity contributor. Woohoo!)
The backtrace is pretty good here, presumably looking at display.c:1840 for the right metacity version would narrow it down pretty quick. It's definitely a metacity bug if metacity crashes. A simple thing to try is whether metacity --replace (replace metacity with metacity) also crashes, then it would be simple to reproduce sans compiz, for anyone with two screens at least.
FWIW, in trunk at least, 1840 is attempting to activate the default window on the new screen when the mouse has just entered that screen. It looks up meta_display_screen_for_root for the root window taken from the event, and puts the answer in new_screen; we see from the trace that this is null. It then tries to dereference it, hence the segfault. MDSFR returning null is quite reasonable, though: it just means that the root window requested is not the root window of any of the screens of that display. Why *that* should be, I don't know. (It bothers me rather that in almost all the places where meta_display_screen_for_root is called, we don't check whether the result is null before dereferencing it. I will add some checks for this.)
I believe metacity at least originally was intended to be able to manage only some of the screens on a display, which would imply a NULL MetaScreen for some root windows. I'm sure this has been tested only rarely. But e.g. you would do this if you wanted to do some weird thing on one head, you could run fvwm2 on that head with some weird custom config to e.g. just hold a window at fullscreen. Then on the main head you could run metacity. So question 1), I would say figure out why metacity is not managing the screen in question. Question 2), if it's not managing a screen, some events may arrive on that screen anyway, and they should be ignored. I would suggest trying to put this in some global location (e.g. in event_callback) rather than checking for NULL screen everywhere meta_display_screen_for_root is called.
(In reply to comment #6) > The backtrace is pretty good here, presumably looking at display.c:1840 for the > right metacity version would narrow it down pretty quick. > > It's definitely a metacity bug if metacity crashes. A simple thing to try is > whether metacity --replace (replace metacity with metacity) also crashes, then > it would be simple to reproduce sans compiz, for anyone with two screens at > least. > Hello—I am the original reporter of this issue on Launchpad. “metacity --replace” did it’s job when run from a terminal window manually, without a crash. I am not sure where in the process this is crashing—I just know that it happens when I have the dual-head setup running. Without the dual-head configuration, there are no crashes when Desktop Effects is enabled.
With Ubuntu Feisty, dual head (nvidia) display: malcolm@trillian:~$ metacity --replace & [1] 10445 malcolm@trillian:~$ malcolm@trillian:~$ metacity --replace & [2] 10461 malcolm@trillian:~$ [1]- Segmentation fault (core dumped) metacity --replace malcolm@trillian:~$ malcolm@trillian:~$ compiz --replace & [3] 10545 malcolm@trillian:~$ /usr/bin/compiz.real: glXCreateContext failed /usr/bin/compiz.real: Failed to manage screen: 1 /usr/bin/compiz.real: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu /usr/bin/compiz.real: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png [2]- Segmentation fault (core dumped) metacity --replace malcolm@trillian:~$ metacity crashes when being replaced, even by itself.
Havoc, Thomas: A quick check through the code shows that many calls to meta_display_screen_for_root() are indeed followed by checks to see whether the return value is NULL. It turns out that each and every call that isn't followed by such a check, was code written by me. (/me starts flogging himself) Anyway, even with extra checks to handle this, there is the question of why metacity is only managing one of the two screens, so Havoc's suggested list of steps is what we need to do. To figure out why the screen isn't being managed, a verbose debugging log might be helpful. Can anyone who can reproduce this bug provide one?
Created attachment 86076 [details] verbose debugging log Log of metacity crashing when replaced by itself.
Thanks Malcolm! A couple snippets from the log: Window manager: Added screen 0 (':0.0') root 0x328 Window manager: Added screen 1 (':0.1') root 0x32a Window manager: Attempting to manage 0x3a00005 Window manager: Deciding not to manage override_redirect window 0x3a00005 EVENTS: SelectionClear on 0x3a00005 serial 4385 Window manager: Got selection clear for screen 0 on display :0.0 Window manager: Unmanaging screen 0 on display :0.0 Window manager: Grabbing display, grab count now 1 EVENTS: EnterNotify on 0x3000093: win: 0x3000093 root: 0x328 subwindow: 0x3000099 mode: NotifyNormal detail: NotifyNonlinearVirtual focus: 0 x: 19 y: 761 serial 4604 So it seems that something is definitely requesting that metacity stop managing the first screen. And, indeed, the log ends immediately after an EnterNotify event comes showing the mouse has moved to that unmanaged screen. What the log can't really reveal is who/what is requesting metacity to stop managing the first screen and why?
> The crash happens when using desktop effects to run compiz ... > What the log can't really reveal is who/what is requesting metacity to stop > managing the first screen and why? do you think it might possibly be compiz?
I had an idea in my head that it was crashing instantly but the log made me think you started to interact with it a bit and it wasn't until you moved your mouse to a different screen that it crashed. But maybe my mental picture was wrong (maybe EnterNotify events are sent upon launch of a window manager)? Does this crash happen at the moment you launch compiz? Or is it can you interact with the windows for a little while until you move your mouse to a new screen? Does compiz support multiple screens, or is it restricted to a single screen? Unfortunately, I don't have the graphics hardware/drivers to test. :(
My understanding of this bug is that when metacity is managing a dual screen display, and another window manager tries to replace it, metacity crashes. I am not trying to run one window manager on one screen, and a different window manager on the other screen. I have verified that metacity crashes with several different replacing window managers - compiz, fvwm, or another metacity. If I keep the mouse still when launching fvwm, and the mouse is over the terminal window, then metacity doesn't crash and exits normally. metacity crashes immediately when replaced by another metacity. compiz fails to manage the second screen, but that's a compiz bug. Both fvwm and metacity are able to replace metacity on both screens.
Ah, thanks for the explanation. That answers point 1 mentioned by Havoc to my satisfaction (find out why metacity is only managing one screen). Makes sense to me that launching with fvwm without moving the mouse wouldn't crash metacity (fvwm is probably better than metacity about preserving stacking order, preventing EnterNotify events from being generated immediately) while metacity replacing metacity would crash. So, now we just need to add checks around the calls to meta_display_screen_for_root.
https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/134170 is a duplicate on GNOME 2.19.90
Oh, I fixed this in the most recent unstable version. Sorry, I should have closed this. Well done to the Ubuntu packagers who noticed :)