Re: emacs --daemon and GDK default display

[Austin <austiny.cn@gmail.com>]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Ulrich Mueller skrev:
>>>>>>> On Tue, 17 Mar 2009, Jason Rumney wrote:
>>>> While I think that the blame is with libcanberra, I'm confused
>>>> about the fact that the segfault only happens during the second
>>>> request from a client. Does it mean that there is a GDK default
>>>> display at the time of the first request, but not for the second
>>>> one? Why?
>>
>>> Just a guess without looking at libcanberra, but could the bug be
>>> that libcanberra remembers the default display created during the
>>> first request and tries to reuse it after it is closed?
>>
>> It doesn't remember it. libcanberra just calls a GTK function, which
>> in turn asks the GDK display manager for the default display. And that
>> returns a valid display for the first request, but a null pointer for
>> the second one.
>>
>
> If I remember correctly, the display manager does not set a new
> default display when the old is closed.  There is some code for that
> case i gtkutil.c.
>
> But there was a bug in it.  I don't know if that fixes anything, but
> please try again.  Note that closing displays under Gtk+ is generally
> buggy in itself.  If you can capture a stack trace in the debugger we
> should be able to tell if it is Gtk+ or Emacs that is doing the wrong
> thing.
>
> 	Jan D.

This is the stack trace that I got when following Ulrich's procedure.

Program received signal SIGSEGV, Segmentation fault.
0x0000000006a10e8a in gtk_module_init () from
/usr/lib64/gtk-2.0/modules/libcanberra-gtk-module.so
(gdb) bt
#0  0x0000000006a10e8a in gtk_module_init () from
 /usr/lib64/gtk-2.0/modules/libcanberra-gtk-module.so
#1  0x000000357e93c36f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#2  0x000000357e93c428 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#3  0x000000357e93c4f7 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#4  0x000000357f20b7dd in g_closure_invoke () from
 /lib64/libgobject-2.0.so.0
#5  0x000000357f2214bd in ?? () from /lib64/libgobject-2.0.so.0
#6  0x000000357f222b68 in g_signal_emit_valist () from
 /lib64/libgobject-2.0.so.0
#7  0x000000357f222ee7 in g_signal_emit_by_name () from
 /lib64/libgobject-2.0.so.0
#8  0x000000357cc41906 in gdk_display_open () from
 /usr/lib64/libgdk-x11-2.0.so.0
#9  0x00000000004d24eb in xg_display_open (display_name=0x0,
 dpy=0x6a12897) at emacs/src/gtkutil.c:121
#10 0x00000000004a10ac in x_term_init (display_name=15258819,
 xrm_option=0x0, resource_name=0x10a51c0 "emacs") at
 emacs/src/xterm.c:10018
#11 0x00000000004adbcc in x_display_info_for_name (name=15258819) at
 emacs/src/xfns.c:4108
#12 0x00000000004b305d in Fx_create_frame (parms=12003973) at
 emacs/src/xfns.c:3155
#13 0x000000000055f31c in Ffuncall (nargs=2, args=<value optimized out>)
 at emacs/src/eval.c:3044
#14 0x0000000000595f85 in Fbyte_code (bytestr=<value optimized out>,
 vector=11655313, maxdepth=<value optimized out>)
    at emacs/src/bytecode.c:678
...

It is the latest CVS code and the system is FC10 x86_64, kernel
2.6.27.19, with NVidia dual-head. My observation is that this seg fault
won't happen if the first frame is not closed when creating the second
one.

Hope this helps,

Austin