Bug 1250128

Summary: segfault in libmutter.so.0.0.0
Product: Red Hat Enterprise Linux 7 Reporter: Vladimir Benes <vbenes>
Component: gnome-shellAssignee: Florian Müllner <fmuellner>
Status: CLOSED DUPLICATE QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 7.2CC: ayadav, joe.lawrence, mclasen, rstrode
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-09-15 16:38:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
backtrace
none
journalctl logs none

Description Vladimir Benes 2015-08-04 14:59:11 UTC
Description of problem:
when starting gdm, gnome-shell crashes with following issue:
[ 2124.142268] gnome-shell[15995]: segfault at 0 ip 00007f5f1f4e84ec sp 00007ffe76951640 error 4 in libmutter.so.0.0.0[7f5f1f46c000+e8000] 

gdb backtrace will be attached

Version-Release number of selected component (if applicable):
mutter-3.14.4-10.el7.x86_64
gnome-shell-3.14.4-24.el7.x86_64
gdm-3.14.2-10.el7.x86_64
kernel-3.10.0-302.el7.x86_64

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 08)

I would say no monitor (remote machine)

How reproducible:
randomly

Steps to Reproduce:
1.start gdm service

Actual results:
gnome-shell --mode=gdm running for a while -> crash

Expected results:


Additional info:

Comment 1 Vladimir Benes 2015-08-04 15:00:43 UTC
Created attachment 1059120 [details]
backtrace

Comment 2 Florian Müllner 2015-08-04 16:28:17 UTC
(In reply to Vladimir Benes from comment #0)
> I would say no monitor (remote machine)

Is this a duplicate of bug 1212702 then? In any case, the backtrace is helpful ...

Comment 3 Matthias Clasen 2015-08-18 13:18:06 UTC
Florian, did you have any insight in this ?

Comment 4 Florian Müllner 2015-09-04 11:49:08 UTC
(In reply to Matthias Clasen from comment #3)
> Florian, did you have any insight in this ?

Not anymore than in comment #2 - if this is indeed on a headless machine, this is a duplicate of bug 1212702 (which is known not to be fully fixed yet, but progress on that is slow as I don't actually have access to hardware that allows booting without monitors)

Comment 5 amit yadav 2015-09-08 18:57:48 UTC
Facing similar issue on my test system. I have configured Xdmcp on RHEL7.2 Beta.
System console is working fine, but when I try to connect this system from other RHEL/fedora system using "Xnest/Xephyr", I am getting black screen. If I try to connect from Windows system using Cygwin/MobaXterm/Xming,  I am getting following error:

   "Oh no! Something has gone wrong."


  "journalctl -b -a" output file : journalctl.logs attached to the bug.

Comment 6 amit yadav 2015-09-08 18:59:09 UTC
Created attachment 1071454 [details]
journalctl logs

Comment 7 Joe Lawrence 2015-09-09 19:54:34 UTC
Hi Amit, et al -- I noticed a similar segfault when starting gdm on 7.2 Alpha and Beta.  We run with a /etc/X11/xorg.conf.d/00-ftserver.conf file that contains:

  Section "ServerFlags"
          Option          "RandR" "false"
  EndSection

which X appears to honor:

  % grep -i randr /var/log/Xorg.0.log
  [  3544.109] (**) Option "RandR" "false"
  [  3544.408] (**) RandR disabled

but then there are several "Xlib:  extension "RANDR" missing on display ":0" complaints out of gdm and gnome-session before gnome-shell eventually segfaults.

If I comment out the 'Option "RandR" "false"' line from the config file, gdm starts successfully.

I happened to notice similar complaints in your journalctl logs so I thought I would chime in.

Do you know if the randr extension is a *requirement* for gnome in 7.2?

Thanks,

-- Joe

Comment 8 Ray Strode [halfline] 2015-09-15 16:38:30 UTC
let's dupe this on to bug 1212702 since they're essentially the same problem.

*** This bug has been marked as a duplicate of bug 1212702 ***