From: Austin <austiny.cn@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: emacs --daemon and GDK default display
Date: Mon, 23 Mar 2009 21:11:04 -0400 [thread overview]
Message-ID: <84y6uviv28.fsf@gmail.com> (raw)
In-Reply-To: 49C7C250.9030505@swipnet.se
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
prev parent reply other threads:[~2009-03-24 1:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-17 11:14 emacs --daemon and GDK default display Ulrich Mueller
2009-03-17 11:47 ` Jason Rumney
2009-03-23 9:28 ` Ulrich Mueller
2009-03-23 17:09 ` Jan Djärv
2009-03-23 21:33 ` Ulrich Mueller
2009-03-25 19:21 ` Jan Djärv
2009-03-28 15:49 ` Jan Djärv
2009-03-28 18:09 ` Ulrich Mueller
2009-03-24 1:11 ` Austin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84y6uviv28.fsf@gmail.com \
--to=austiny.cn@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.