Bug 234567

Can you attach the /var/log/Xorg.0.log from a failed startup please?  That way I
can see why it failed to start.

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.

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.

This isn't obvious anywhere, but Fedora 7 test bugs should be filed against the
"devel" version.

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.

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.

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.

That looks a lot like gdm crashing, so reassigning to gdm.

can you set Enable=true in the [debug] section of /etc/gdm/custom.conf, reboot
and then post /var/log/messages ?

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.

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?

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.

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?

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.

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

I can confirm that this also happens with a fresh Fedora 7 Test 4 install.

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.

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?)

*** Bug 242560 has been marked as a duplicate of this bug. ***

(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?

We have a pretty good idea what's going on now, we think, so you should be all
set for now.

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.

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.

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.