GNOME Bugzilla – Bug 756796
Segfault in libmutter.so when secondary monitor turned off.
Last modified: 2015-10-30 17:17:31 UTC
Not certain which product to file against but journalctl claims: * segfault at 0 ip 00007f46d6ee42c2 sp 00007fff3b6a7070 error 4 in libmutter.so.0.0.0[7f46d6e90000+fc000] AND * segfault at 0 ip 00007f76a66852c2 sp 00007ffebc5a2630 error 4 in libmutter.so.0.0.0[7f76a6631000+fc000] ...simultaneously. Two coredumps are produced. This happens for one user at login to X11 session when secondary monitor was turned off in previous session, producing 'Oh, No!' screen. Wayland session is still possible. Deleting ~/.config/monitors.xml allows me to log into X11 again. This also happens instantly for another user on the same machine when clicking 'Apply' in gnome-control-center display settings after turning off the monitor. Rearranging monitors work as expected and produces a monitors.xml that doesn't result in crash. Wayland session shows no issues. I followed Arch wiki for producing trace from coredumps. Attached are the traces for the first scenario. As well as the monitors.xml file resulting in crash. Running GNOME 3.18.1 on Arch Linux.
Created attachment 313634 [details] Part 1 of crash.
Created attachment 313635 [details] Part 2 of crash.
Created attachment 313636 [details] Deleting this allows logging in again to X11
Is this reproducible? Can you provide a stack trace with debugging symbols (you need to look for how to install those for Arch packages) ? Can you try to apply the patch in https://git.gnome.org/browse/mutter/commit/?id=43a1d43f2b6437173bfdc8db2e936791cffd4149 and report if it prevents the crash?
Additionally, a crash happens when plugging in the secondary monitor (VGA) while having the gnome display settings window open. ('Oh, No!' screen) I am attaching traces from the two coredumps produced from such a crash. I am not certain if this is the same crash as reported but symptoms are the same. I have recompiled mutter with debug symbols. Is this sufficient? Or do I need to compile all other libraries mentioned in the trace with debug symbols for the traces to be useful? Disclaimer: I have not done this before.
Created attachment 313719 [details] Part 1 of crash with debug symbols incl.
Created attachment 313720 [details] Part 2 of crash with debug symbols incl.
With the patch above applied, no change. This is 100% reproducible: -Crash on VGA connect with Display Settings window open. -Crash on clicking 'Apply' when turning off secondary monitor. -Crash on logging in after turning off secondary monitor in previous session (remove monitors.xml to restore login)
Created attachment 313721 [details] Part 1 of crash with 43a1d43f2b6437173bfdc8db2e936791cffd4149 applied.
Created attachment 313722 [details] Part 2 of crash with 43a1d43f2b6437173bfdc8db2e936791cffd4149 applied.
Did you update other components recently? In particular, did you update the kernel, the X server or the DDX (intel, nouveau, radeon) ? Something has changed underneath us because this code, as brittle as it may be, was working fine for several releases, and now I'm seeing crashes left and right. Let me know if the following patch fixes this and if everything still works right.
Created attachment 313748 [details] [review] monitor-manager-xrandr: Ignore outputs without modes In some cases we get outputs without any valid mode. We need to ignore them or we'll crash later.
Review of attachment 313748 [details] [review]: ::: src/backends/x11/meta-monitor-manager-xrandr.c @@ +816,3 @@ + meta_output->preferred_mode = meta_output->modes[0]; + else + continue; Should be: if (meta_output->n_modes == 0) continue; meta_output->preferred_mode = meta_output->modes[0];
Created attachment 313789 [details] [review] Rui's patch modified according to Jasper. Is this what you mean, Jasper? Learning as I'm going along. Applying this patch in addition to https://git.gnome.org/browse/mutter/commit/?id=43a1d43f2b6437173bfdc8db2e936791cffd4149 from before changes things as follows: - No more reproducible segfaults. (Yet...) - Turning off the secondary monitor now removes it completely from the display settings dialog. (No way to use it again until relogin) - Changes are not persistent across logins. (i.e. secondary switched on again) - UNLESS... replacing monitors.xml with the one initially attached to this report.
As for package history... This was a fresh Arch Install from just over a week ago: -- linux 4.2.2 -- xorg-server 1.17.2 -- xf86-video-intel 1:2.99.917+472+gf0fd4d5 -- gnome 3.18.0 Updated once over the weekend: -- linux 4.2.3 -- xf86-video-intel 1:2.99.917+478+gdf72bc5 -- gnome 3.18.1 I have noticed numerous Arch users experiencing the 'Oh No!' screen for X11 sessions but not Wayland sessions after upgrading to 3.18.x. I have suggested deleting monitors.xml to two users on IRC and they claimed it worked.
(In reply to Michael Heyns from comment #14) > - Turning off the secondary monitor now removes it completely from the > display settings dialog. (No way to use it again until relogin) What's the output of 'xrandr' in this case? Does running it make the monitor visible again? How is the monitor connected (VGA, DP, DVI, other)? Can you try connecting the monitor with a different connection type/cable? > - Changes are not persistent across logins. (i.e. secondary switched on > again) Changes are saved in monitors.xml after you press "keep changes" in the modal dialog after you change the configuration. Is that not working? (In reply to Michael Heyns from comment #15) > As for package history... > > This was a fresh Arch Install from just over a week ago: > -- linux 4.2.2 > -- xorg-server 1.17.2 > -- xf86-video-intel 1:2.99.917+472+gf0fd4d5 So it all worked in this configuration? Can you downgrade only the intel DDX to this version and check if things work?
Created attachment 313841 [details] monitors.xml after patches. The new monitors.xml does not contain the secondary monitor (VGA) at all. As represented by the disappearance from Display Settings and explains why the setting does not persist. Running xrandr with no options: refreshes the screens, turns the secondary monitor on again and relists it in Display Settings. It could be worth mentioning that I'm experiencing monitor overlapping (both screens at 0x0) when changing resolutions / turning on and off.
Created attachment 313842 [details] xrandr output xrandr output as requested. HDMI is Primary. VGA is Secondary. LVDS is always shut (lid closed). Unfortunately I don't have other outputs to try. I discovered that if xrandr is run before changing settings, correct monitors.xml is generated and secondary doesn't disappear. Also, to add to my previous comment, I can make the vanished monitor reappear by opening one of the other monitor's dialogs and clicking cancel.
Breakthrough: Downgrading to xf86-video-intel 1:2.99.917+472+gf0fd4d5 does not make a difference. I tested both original 3.18.1 and patched mutter packages. However... I sourced the Intel DDX released on Arch Linux before that one and all problems go away. Both the mutter packages behave as expected with no segfaults, Display Settings vanishings nor overlappings. And sane, persistent monitors.xml. Something happened after xf86-video-intel 1:2.99.917+381+g5772556
Created attachment 313865 [details] [review] monitor-manager-xrandr: Ask for a connector poll after an hotplug After an hotplug we should use XRRGetScreenResources() since XRRGetScreenResourcesCurrent() doesn't ensure that the DDX has fully polled the hardware. -- Does this patch (on top of the others) help? The intel DDX maintainer told me we should be requesting an hardware poll on hotplugs.
Comment on attachment 313748 [details] [review] monitor-manager-xrandr: Ignore outputs without modes Attachment 313748 [details] pushed as 86a913d - monitor-manager-xrandr: Ignore outputs without modes pushing this with comment 13 addressed but leaving the bug open for the requested feedback
Created attachment 314141 [details] [review] monitor-manager-xrandr: Plug a leak introduced in the previous commit Commit 86a913d37aae4c96cb2e4d765b58fb4f60ec9d54 leaks XRROutputInfos if n_modes == 0. Fix this by checking earlier and ensuring we still go through XRRFreeOutputInfo() below. -- sorry about that
Review of attachment 314141 [details] [review]: Hm, this will mean we could do a g_new0 (sizeof (void*), 0);, which I didn't think would work. I do wonder if it's simpler to make it an autoptr.
Created attachment 314239 [details] [review] monitor-manager: Expose a few helpers to clear structs These are useful for child classes to unwind cleanly when constructing their structures.
Created attachment 314240 [details] [review] Revert "monitor-manager-xrandr: Ignore outputs without modes" This reverts commit 86a913d37aae4c96cb2e4d765b58fb4f60ec9d54. It introduced a memory leak, so we'll go for a cleaner approach.
Created attachment 314241 [details] [review] monitor-manager-xrandr: Skip outputs with no modes If we can't find any valid modes for an output we need to unwind and skip the output because trying to use a modeless output later will crash us.
Created attachment 314242 [details] [review] monitor-manager-xrandr: Skip outputs with no crtcs Outputs with no crtcs shouldn't happen, but if it does we should ignore them, instead of possibly crashing later.
Comment on attachment 314141 [details] [review] monitor-manager-xrandr: Plug a leak introduced in the previous commit (In reply to Jasper St. Pierre from comment #23) > Hm, this will mean we could do a g_new0 (sizeof (void*), 0);, which I didn't > think would work. That just returns NULL which should be fine. But I've decided to do this slightly differently
Review of attachment 314239 [details] [review]: OK.
Review of attachment 314240 [details] [review]: OK.
Review of attachment 314241 [details] [review]: LG.
Closing, please re-open if it still crashes for you. Attachment 314239 [details] pushed as bff75b6 - monitor-manager: Expose a few helpers to clear structs Attachment 314240 [details] pushed as 57ae203 - Revert "monitor-manager-xrandr: Ignore outputs without modes" Attachment 314241 [details] pushed as 8b200de - monitor-manager-xrandr: Skip outputs with no modes Attachment 314242 [details] pushed as af2a13d - monitor-manager-xrandr: Skip outputs with no crtcs