Bug 234567 - gdm crashes constantly in Parallels F7 install
gdm crashes constantly in Parallels F7 install
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
:
: 242560 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-30 02:49 EDT by Eric Kerby
Modified: 2007-11-30 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version: 1.3.0.0-7.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-07 11:59:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
display server error (4.00 KB, image/png)
2007-04-03 21:04 EDT, Eric Kerby
no flags Details
Xorg.0.log after the display server fails to start (83.01 KB, text/plain)
2007-04-03 21:06 EDT, Eric Kerby
no flags Details
/var/log/messages after gdm fails to start (142.04 KB, text/plain)
2007-04-09 16:54 EDT, Eric Kerby
no flags Details
/var/log/messages after gdm fails to start with debug enabled (226.01 KB, text/plain)
2007-04-15 14:49 EDT, Eric Kerby
no flags Details
/var/log/messages with gdm debug enabled (783.71 KB, text/plain)
2007-04-18 16:47 EDT, Eric Kerby
no flags Details

  None (edit)
Description Eric Kerby 2007-03-30 02:49:07 EDT
Description of problem:
pyxf86config creates a bad xorg.conf file during a clean install of Fedora 7
Test 3 in Parallels Desktop for Mac build 3188.

Version-Release number of selected component (if applicable):
Fedora 7 Test 3 Prime i386 DVD
pyxf86config 0.3.33
Parallels Desktop for Mac build 3188

Steps to Reproduce:
1. Perform a clean install of Fedora 7 Test 3 in a Parallels Desktop for Mac
virtual machine.
2. Boot up and run through the firstboot
3. When gdm tries to start, it restarts 6 times and gives up with an error.
  
Actual results:
xorg.conf file is generated incorrectly without a Monitor section and without a
Modes line in the Display subsection of the Screen section.

Expected results:
The xorg.conf file is generated correctly so that X windows and gdm works after
a clean install of Fedora 7.

Additional info:
File as created by pyxf86config:
---------START xorg.conf-----------
# Xorg configuration created by pyxf86config

Section "ServerLayout"
	Identifier     "Default Layout"
	Screen      0  "Screen0" 0 0
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "us"
EndSection

Section "Device"
	Identifier  "Videocard0"
	Driver      "vesa"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Videocard0"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

---------END xorg.conf-----------


Altered file that works properly:
------START xorg-fixed.conf------
# Xorg configuration created by pyxf86config

Section "ServerLayout"
	Identifier     "Default Layout"
	Screen      0  "Screen0" 0 0
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "us"
EndSection

Section "Monitor"
	Identifier   "Monitor0"
	HorizSync    30.0 - 70.0
	VertRefresh  50.0 - 140.0
EndSection

Section "Device"
	Identifier  "Videocard0"
	Driver      "vesa"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Videocard0"
	Monitor    "Monitor0"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     24
		Modes     "1024x768" "800x600"
	EndSubSection
EndSection

------END xorg-fixed.conf------
Comment 1 Adam Jackson 2007-04-02 14:00:26 EDT
Can you attach the /var/log/Xorg.0.log from a failed startup please?  That way I
can see why it failed to start.
Comment 2 Eric Kerby 2007-04-03 21:04:52 EDT
Created attachment 151633 [details]
display server error

After the clean f7test3 install, the firstboot configuration walkthrough works
fine.  After finishing firstboot, the display server fails to start several
times and the error in the attached image is displayed.
Comment 3 Eric Kerby 2007-04-03 21:06:08 EDT
Created attachment 151634 [details]
Xorg.0.log after the display server fails to start

I ssh-ed into the virtual machine and copied this Xorg.0.log after the display
server failed to start after the clean f7test3 install.
Comment 4 Matthew Miller 2007-04-06 16:24:19 EDT
This isn't obvious anywhere, but Fedora 7 test bugs should be filed against the
"devel" version.
Comment 5 Adam Jackson 2007-04-09 11:27:13 EDT
That certainly looks like a successful X server startup.  If you boot the
virtual machine into runlevel 3, and then launch X manually with 'X :0', does
the X server stay running?  If so, then the session crashing is not X's fault,
but the fault of some other application down the line.
Comment 6 Eric Kerby 2007-04-09 16:51:25 EDT
If I start the virtual machine in runlevel 3 and launch X with 'X :0' it loads
the gray background with an X cursor and does not crash.  The Xorg.0.log file is
generated fresh, but has the same output as the one I attached to this bug earlier.
Comment 7 Eric Kerby 2007-04-09 16:54:27 EDT
Created attachment 152026 [details]
/var/log/messages after gdm fails to start

After a normal runlevel 5 start when the X server seems to crash, if I look at
the contents of /var/log/messages the last entries look as follows:

Apr  9 16:41:59 kerbsvm gdm[2148]: (null): cannot open shared object file: No
such file or directory
Apr  9 16:42:02 kerbsvm gdm[2148]: gdm_cleanup_children: child 2174 crashed of
signal 11
Apr  9 16:42:02 kerbsvm gdm[2148]: gdm_cleanup_children: Slave crashed, killing
its children
Apr  9 16:42:07 kerbsvm gdm[2148]: gdm_cleanup_children: child 2188 crashed of
signal 11
Apr  9 16:42:07 kerbsvm gdm[2148]: gdm_cleanup_children: Slave crashed, killing
its children
Apr  9 16:42:12 kerbsvm gdm[2148]: gdm_cleanup_children: child 2201 crashed of
signal 11
Apr  9 16:42:12 kerbsvm gdm[2148]: gdm_cleanup_children: Slave crashed, killing
its children
Apr  9 16:42:18 kerbsvm gdm[2148]: gdm_cleanup_children: child 2214 crashed of
signal 11
Apr  9 16:42:18 kerbsvm gdm[2148]: gdm_cleanup_children: Slave crashed, killing
its children
Apr  9 16:42:30 kerbsvm gdm[2148]: gdm_cleanup_children: child 2227 crashed of
signal 11
Apr  9 16:42:30 kerbsvm gdm[2148]: gdm_cleanup_children: Slave crashed, killing
its children
Apr  9 16:42:45 kerbsvm gdm[2148]: gdm_cleanup_children: child 2242 crashed of
signal 11
Apr  9 16:42:45 kerbsvm gdm[2148]: gdm_cleanup_children: Slave crashed, killing
its children
Apr  9 16:46:45 kerbsvm gdm[2148]: The display server has been shut down about
6 times in the last 90 seconds. It is likely that something bad is going on. 
Waiting for 2 minutes before trying again on display :0.


I will attach the full messages log in case it will help.
Comment 8 Adam Jackson 2007-04-13 12:15:17 EDT
That looks a lot like gdm crashing, so reassigning to gdm.
Comment 9 Ray Strode [halfline] 2007-04-13 12:35:56 EDT
can you set Enable=true in the [debug] section of /etc/gdm/custom.conf, reboot
and then post /var/log/messages ?
Comment 10 Eric Kerby 2007-04-15 14:49:51 EDT
Created attachment 152653 [details]
/var/log/messages after gdm fails to start with debug enabled

As requested, here is /var/log/messages after starting up with gdm debug
enabled.  Let me know if you need anything else.
Comment 11 Ray Strode [halfline] 2007-04-17 09:27:39 EDT
Unfortunately, there isn't enough debug spew to really see where the crash is
happening.  I'm going to build a more verbose version of gdm into rawhide
tonight.  Would you mind getting the logs again with tomorrow's gdm?
Comment 12 Eric Kerby 2007-04-18 16:47:59 EDT
Created attachment 152953 [details]
/var/log/messages with gdm debug enabled

After updating from gdm 2.18.0-10 to 2.18.0-11 in the F7 install, gdm still
fails and produced the /var/log/messages that is attached here.
Comment 13 Ray Strode [halfline] 2007-04-18 17:20:18 EDT
hmm...

pr 18 16:38:27 kerbsvm gdm[2228]: gdm_screen_init: display :0 has 25 screens

X is reporting that it is configured to have 25 xinerama heads.  That seems
quite large.  Do you have some sort of virtual 5x5 matrix set up or is it
returning a bogus value?

If you do have some sort of virtual 5x5 matrix set up, if you configure it for
just 1 head, do things work?
Comment 14 Eric Kerby 2007-04-18 17:27:40 EDT
Nothing crazy, unless it is in Parallels.  I am running a Mac Pro with two
monitors connected to an Nvidia card.  As far as I know, Parallels only supports
single display virtualization, so that must be a bogus value.

I have not really changed any of the defaults that Parallels gives other than to
select that this is a Fedora installation, disabling the virtual floppy drive,
configuring the networking settings, etc.
Comment 15 Ray Strode [halfline] 2007-04-18 17:45:34 EDT
okay, so gdm does:

                XineramaScreenInfo *xscreens =
                        XineramaQueryScreens (display->dsp,
                                              &screen_num);

and screen_num is incorrectly returned by the X server as 25.  Reassigning back
to xorg-x11-server
Comment 16 Eric Kerby 2007-04-28 15:29:42 EDT
I can confirm that this also happens with a fresh Fedora 7 Test 4 install.
Comment 17 Adam Jackson 2007-05-08 12:39:07 EDT
So I'm looking at the code and not seeing any possible way we could be returning
25 screens.  I really wish we had a copy of Parallels to work with.
Comment 18 Ray Strode [halfline] 2007-05-10 16:25:53 EDT
well to give a little bigger snippet of the code:

#ifdef HAVE_XFREE_XINERAMA
        gboolean have_xinerama = FALSE;

        gdk_flush ();
        gdk_error_trap_push ();
        have_xinerama = XineramaIsActive (GDK_DISPLAY ());
        gdk_flush ();
        if (gdk_error_trap_pop () != 0)
                have_xinerama = FALSE;

        if (have_xinerama) {
                int screen_num, i;
                XineramaScreenInfo *xscreens =
                        XineramaQueryScreens (GDK_DISPLAY (),
                                              &screen_num);


                if (screen_num <= 0) {

so XineramaIsActive () is returning to true in his setup, even those there is
only one head at play.  If XineramaQueryScreens isn't initializing screen_num
then the 25 could just be random memory since we don't initialize it before hand.

maybe IsActive() is returning true, but QueryScreens is returning NULL (and
screen_num isn't getting set?)
Comment 19 Adam Jackson 2007-06-05 09:41:51 EDT
*** Bug 242560 has been marked as a duplicate of this bug. ***
Comment 20 Brendan Mchugh 2007-06-05 18:48:36 EDT
(In reply to comment #19)
> *** Bug 242560 has been marked as a duplicate of this bug. ***

Should i update gdm from rawhide also to get the debug output or is the source
of the problem now known?
Comment 21 Ray Strode [halfline] 2007-06-05 18:55:08 EDT
We have a pretty good idea what's going on now, we think, so you should be all
set for now.
Comment 24 Fedora Update System 2007-06-06 12:41:30 EDT
xorg-x11-server-1.3.0.0-7.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 25 Brendan Mchugh 2007-06-06 14:47:30 EDT
I have updated to xorg-x11-server-1.3.0.0-7.fc7 and now gdm, gedit etc. are
working as they should be. Thank you.
Comment 26 Fedora Update System 2007-06-07 11:59:14 EDT
xorg-x11-server-1.3.0.0-7.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.