Comment 13 for bug 228324

On a netbook running hardy, I've encountered this issue when quickly triggering a restart in gdm's login window (to quickly trigger the reboot, I simply press Alt+T, R, then Alt+R when the login window appears). The greeter disappears and I am left in the console with the last boot message that was output (Running local boot scripts (/etc/rc.local) [OK]). The device is still very much alive as I can interact fully with it from a virtual terminal. The greeter process and X server process have been stopped but the main gdm process as well as the slave process are still around. The issue seems to be a race condition as I cannot reproduce it with gdm debugging or valgrind on (they seem to slow down gdm enough to avoid the bug).

I am not positive this is the same issue that occurs when XDMCP login is selected but the resulting behavior is the same and the bug comments do mention that this does happen occassionally on shutdown.

When gdm starts, it creates a slave process which in turn creates a gdmgreeter process and an X server process. When restart is selected from the login menu, the gdmgreeter process should exit with status 8 (status 8 = DISPLAY_REBOOT). When the gdmgreeter process exits, the slave process should stop the X server process and then also exit with status 8. When the slave process exits with status 8, the main gdm process should get a SIGCHLD signal, query the exit status, detect that the slave process exited with status 8, and then perform the reboot command (shutdown -r now). When I encounter the bug, it seems that the gdmgreeter process is exiting with status 8, the server process is stopped, but the slave process never exits. Because the slave process never exits, the main gdm process never gets a SIGCHLD signal and therefore never runs the reboot command. The slave process, strangely, is not exiting because it is stuck in a g_free call (deadlock?). With g_free removed, the bug does not seem to happen. The following is gdb info for the slave process that does not exit:

BACKTRACE:

#0 0xb7f25410 in __kernel_vsyscall ()
#1 0xb778a953 in __lll_lock_wait_private () from /lib/libc.so.6
#2 0xb771922b in _L_lock_15807 () from /lib/libc.so.6
#3 0xb77187b0 in free () from /lib/libc.so.6
#4 0xb783772c in g_free () from /usr/lib/libglib-2.0.so.0
#5 0x08069850 in gdm_server_wipe_cookies (disp=0x80ba100) at server.c:110
#6 0x0806ab9a in gdm_server_stop (disp=0x80ba100) at server.c:336
#7 0x0805c629 in gdm_slave_quick_exit (status=8) at slave.c:5747
#8 0x080689e4 in gdm_slave_start (display=0x80ba100) at slave.c:735
#9 0x0805b84f in gdm_display_manage (d=0x80ba100) at display.c:414
#10 0x08051c22 in gdm_start_first_unborn_local (delay=0) at gdm.c:268
#11 0x08052588 in main (argc=Cannot access memory at address 0xfffffe00

RELEVANT SOURCE CODE (daemon/server.c):

/* Wipe cookie files */
void
gdm_server_wipe_cookies (GdmDisplay *disp)
{
 if ( ! ve_string_empty (disp->authfile)) {
  VE_IGNORE_EINTR (g_unlink (disp->authfile));
 }
=> g_free (disp->authfile);
 disp->authfile = NULL;

VARIABLE VALUE:

gdb> p disp->authfile
$14 = (gchar *) 0x80bc6f8 "/var/lib/gdm/:0.Xauth"