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"
--
Black screen hang on XDMCP login.
https://bugs.launchpad.net/bugs/228324
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
