[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs --daemon and GDK default display
From: |
Austin |
Subject: |
Re: emacs --daemon and GDK default display |
Date: |
Mon, 23 Mar 2009 21:11:04 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (windows-nt) |
Jan Djärv <address@hidden> 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
- emacs --daemon and GDK default display, Ulrich Mueller, 2009/03/17
- Re: emacs --daemon and GDK default display, Jason Rumney, 2009/03/17
- Re: emacs --daemon and GDK default display, Ulrich Mueller, 2009/03/23
- Re: emacs --daemon and GDK default display, Jan Djärv, 2009/03/23
- Re: emacs --daemon and GDK default display, Ulrich Mueller, 2009/03/23
- Re: emacs --daemon and GDK default display, Jan Djärv, 2009/03/25
- Re: emacs --daemon and GDK default display, Jan Djärv, 2009/03/28
- Re: emacs --daemon and GDK default display, Ulrich Mueller, 2009/03/28
- Re: emacs --daemon and GDK default display,
Austin <=