hang on login after gnome-session has left a socket in /tmp/.ICE-unix

Bug #45122 reported by Brian Brunswick
14
Affects Status Importance Assigned to Milestone
at-spi (Ubuntu)
Invalid
Medium
Ubuntu Desktop Bugs

Bug Description

After I kill the X server using ctrl-alt backspace, logging back on usually hangs partway through the gnome setup progress with the centre splash still up, sometimes showing update-notifier.

Launching gnome terminal just hangs - no window appears. firefox will start tho.

XXX Manually killing gconfd from outside X can make things work again. XXX

I now think that was a red herring.

Things are hung trying to talk to a gnome-session that isn't replying.

Revision history for this message
Phil Bull (philbull) wrote :

Thanks for the report.

What version of the gconf2 package do you have installed? Can you see any gconfd-related output in the .xsession-errors file in your home directory? (Only a guess that it should output into this file).

Revision history for this message
Laurent Bigonville (bigon) wrote :

I think this is related to bug #45002

Revision history for this message
Brian Brunswick (brian-ithil) wrote :

Oooh, interesting.

In the hung state, gnome-terminal launched from a panel icon or the gnome menu fails to appear.

But gnome-terminal run from the command line (from an xterm launched from a text console login) actually works.

The non-working gnome-terminal hasn't got as far as running gnome-pty-helper.

In fact, here's the end of a strace of a hung gnome-terminal:

munmap(0xb6ded000, 4096) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL) = 1147818268
mkdir("/home/brian/.gnome2", 0700) = -1 EEXIST (File exists)
mkdir("/home/brian/.gnome2_private", 0700) = -1 EEXIST (File exists)
chmod("/home/brian/.gnome2_private/", 0700) = 0
mkdir("/home/brian/.gnome2/accels", 0700) = -1 EEXIST (File exists)
socket(PF_FILE, SOCK_STREAM, 0) = 14
uname({sys="Linux", node="ecthelion", ...}) = 0
connect(14, {sa_family=AF_FILE, path="/tmp/.ICE-unix/9262"}, 21) = 0
fcntl64(14, F_SETFD, FD_CLOEXEC) = 0
write(14, "\0\1\0\0\0\0\0\0", 8) = 8
read(14,

root@ecthelion:/usr/bin# ps 9262
  PID TTY STAT TIME COMMAND
 9262 ? Ss 0:01 /usr/bin/gnome-session

So its trying to talk to gnome-sessions and getting no reply...

Revision history for this message
Brian Brunswick (brian-ithil) wrote :

The above all happened in a hang that didn't start with an extra gconfd running. [details in a reply by email that hasn't made it here yet]

Revision history for this message
Brian Brunswick (brian-ithil) wrote :

Ok, I reckon the hang on startup happens if a dead gnome-session has a left-over socket in /tmp/.ICE-unix. I've just done a successful logon after cleaning that up, even with a left-over gconfd.

Since I was really reporting the hang on login, it would be worth renaming this bug and assigning it to gnome-session, IMHO.

Revision history for this message
Brian Brunswick (brian-ithil) wrote :

Moving to gnome-session - I think gconfd is blameless.

description: updated
Changed in gconf2:
status: Needs Info → Unconfirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

I'm not sure you can blame gnome-session for people using ctrl-alt-backspace to log out of the session. Do you get the issue if you use normally your session and exit it by the menu item?

Revision history for this message
Brian Brunswick (brian-ithil) wrote :

Yes, I've seen it a few times now, and just reproduced it on demand again.

If I log out normally and then immediately log in again, I get the same sort of hang - gnome session seeming unresponsive, stuck splash, and gnome terminal and eg gedit not opening. Note that the splash redraws with no text on it.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Do you still have that issue with dapper or edgy? Do you have a way to force gnome-session to let a socket to /tmp/.ICE-unix?

Changed in gnome-session:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Revision history for this message
Sebastien Bacher (seb128) wrote :

Could you get a gnome-session backtrace when you get the issue?
- gdb -p $(pidof gnome-session)
(gdb) thread apply all bt

Revision history for this message
Brian Brunswick (brian-ithil) wrote :

Just got around to trying to reproduce this one again. With an uptodate dapper, it seems harder to get than it used to be.

But I managed to get it, though only using ctrl-alt-backspace. (I've seen it without that before)

A gnome session backtrace indeed looks quite suggestive - its stuck in a nested event handler inside gnome_accessibility_module_shutdown.

(gdb) thread apply all bt

Thread 1 (Thread -1223522624 (LWP 1957)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb780988d in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb789f7d8 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#3 0xb789fe0e in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#4 0xb797f56a in link_main_iteration () from /usr/lib/libORBit-2.so.0
#5 0xb7964515 in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
#6 0xb7967cc5 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#7 0xb7967e96 in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
#8 0xb79796be in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#9 0xb6f8c5e8 in Accessibility_EventListener_notifyEvent () from /usr/lib/libspi.so.0
#10 0xb6fd34e5 in gnome_accessibility_module_shutdown () from /usr/lib/gtk-2.0/modules/libatk-bridge.so
#11 0xb6fd44fb in gnome_accessibility_module_shutdown () from /usr/lib/gtk-2.0/modules/libatk-bridge.so
#12 0xb792810f in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0
#13 0xb7929b19 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#14 0xb7929e89 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#15 0xb6f38e4b in gail_util_get_type () from /usr/lib/gtk-2.0/modules/libgail.so
#16 0xb7925e54 in g_cclosure_marshal_VOID__UINT_POINTER () from /usr/lib/libgobject-2.0.so.0
#17 0xb791979f in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#18 0xb79282ea in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0
#19 0xb7929b19 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#20 0xb792d030 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#21 0xb6f312a2 in gail_toplevel_new () from /usr/lib/gtk-2.0/modules/libgail.so
#22 0xb6f3132d in gail_toplevel_new () from /usr/lib/gtk-2.0/modules/libgail.so
#23 0xb792810f in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0
#24 0xb7929b19 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#25 0xb7929e89 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#26 0xb7e0a9da in gtk_widget_hide () from /usr/lib/libgtk-x11-2.0.so.0
#27 0x0805ad50 in ?? ()
#28 0x08109070 in ?? ()
#29 0x080c7db0 in ?? ()
#30 0x08105e50 in ?? ()
#31 0xb78b35ca in g_slist_remove () from /usr/lib/libglib-2.0.so.0
#32 0x08050afb in ?? ()
#33 0x00000000 in ?? ()
#0 0xffffe410 in __kernel_vsyscall ()
(gdb) thread apply all bt

Hope this is useful - good luck!

Revision history for this message
Daniel Holbach (dholbach) wrote :

Looks like an at-spi problem. Do you have accessibility technologies enabled? Does it happen without it? Does it still happen?

Revision history for this message
Daniel Holbach (dholbach) wrote :

Thanks for reporting this bug! Unfortunately your report lacks information we would need to investigate the problem further. We are now going to close the bug - please reopen if you have more information at hand.

Changed in at-spi:
status: Needs Info → Rejected
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.