Bug#681830: Reproduced

[Neil Williams]

found 681830 3.4.1-5
thanks

I made a fresh Wheezy GNOME3 install on a desktop machine (so that the
display could be disconnected more easily) and had the GDM3 welcome
screen on display. 

First test was simply to disconnect the display, without problems on
this setup.

The second test kept the display connected. I generated an Xorg failure
by moving /usr/sbin/Xorg aside and replacing it with a shell script
which simply exits with non-zero.

Restarting gdm3 via invoke-rc.d causes htop to show a huge number of
gdm processes.

gdm3 was stopped over an SSH connection using invoke-rc.d. Then I
started gdm3 from the command line (on a directly connected keyboard)
to generate endless lists of:

gdm3[17041]: WARNING: GdmDisplay: display lasted 1.681562 seconds
gdm3[17041]: WARNING: GdmDisplay: display lasted 1.687131 seconds
gdm3[17041]: WARNING: GdmDisplay: display lasted 1.693576 seconds

 daemon/gdm-display.c : 725
       g_warning ("GdmDisplay: display lasted %lf seconds",elapsed);

I changed the shell script to avoid the 3 second timeout (which makes
this much more manageable) and gdm3 just keeps respawning using
gdm-simple-slave, incrementing the --display-id each time.

More investigation will follow but at least this provides what should
be a reproducible method and a hint as to a starting point in the
codebase. 

To avoid spinning the CPU at 100%, it could be trivial to add an
explicit sleep if the elapsed time in gdm-display.c is less than a few
seconds - the conditional already exists in the codebase.

daemon/gdm-display.c : 723
        elapsed = g_timer_elapsed (display->priv->slave_timer, NULL);
        if (elapsed < 3) {
                g_warning ("GdmDisplay: display lasted %lf seconds", elapsed);
                _gdm_display_set_status (display, GDM_DISPLAY_FAILED);
                sleep (2);
        } else {
                _gdm_display_set_status (display, GDM_DISPLAY_UNMANAGED);
        }

(hypothetically)

Whilst this change does nothing to prevent the re-spawning, (which may
be entirely justifiable in some use cases), it does at least ensure
that the system remains usable.

A much better fix (which previous versions of gdm appeared to
implement) would be a counter in the same loop which only let the
server become un-managed a certain number of times (e.g. 10) before
failing utterly and exiting gdm3 with a sane error message and a
non-zero exit code.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20130127/ddd864f2/attachment.pgp>