Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234567 - gdm crashes constantly in Parallels F7 install
Summary: gdm crashes constantly in Parallels F7 install
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact:
URL:
Whiteboard:
: 242560 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-30 06:49 UTC by Eric Kerby
Modified: 2018-04-11 11:38 UTC (History)
4 users (show)

Fixed In Version: 1.3.0.0-7.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-06-07 15:59:18 UTC


Attachments (Terms of Use)
display server error (deleted)
2007-04-04 01:04 UTC, Eric Kerby
no flags Details
Xorg.0.log after the display server fails to start (deleted)
2007-04-04 01:06 UTC, Eric Kerby
no flags Details
/var/log/messages after gdm fails to start (deleted)
2007-04-09 20:54 UTC, Eric Kerby
no flags Details
/var/log/messages after gdm fails to start with debug enabled (deleted)
2007-04-15 18:49 UTC, Eric Kerby
no flags Details
/var/log/messages with gdm debug enabled (deleted)
2007-04-18 20:47 UTC, Eric Kerby
no flags Details

Description Eric Kerby 2007-03-30 06:49:07 UTC
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 18:00:26 UTC
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-04 01:04:52 UTC
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-04 01:06:08 UTC
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 20:24:19 UTC
This isn't obvious anywhere, but Fedora 7 test bugs should be filed against the
"devel" version.

Comment 5 Adam Jackson 2007-04-09 15:27:13 UTC
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 20:51:25 UTC
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 20:54:27 UTC
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 16:15:17 UTC
That looks a lot like gdm crashing, so reassigning to gdm.

Comment 9 Ray Strode [halfline] 2007-04-13 16:35:56 UTC
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 18:49:51 UTC
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 13:27:39 UTC
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 20:47:59 UTC
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 21:20:18 UTC
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 21:27:40 UTC
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 21:45:34 UTC
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 19:29:42 UTC
I can confirm that this also happens with a fresh Fedora 7 Test 4 install.

Comment 17 Adam Jackson 2007-05-08 16:39:07 UTC
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 20:25:53 UTC
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 13:41:51 UTC
*** Bug 242560 has been marked as a duplicate of this bug. ***

Comment 20 Brendan Mchugh 2007-06-05 22:48:36 UTC
(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 22:55:08 UTC
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 16:41:30 UTC
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 18:47:30 UTC
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 15:59:14 UTC
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.