From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Austin Newsgroups: gmane.emacs.devel Subject: Re: emacs --daemon and GDK default display Date: Mon, 23 Mar 2009 21:11:04 -0400 Message-ID: <84y6uviv28.fsf@gmail.com> References: <18879.34340.349741.391197@a1ihome1.kph.uni-mainz.de> <49BF8DD5.2030502@gnu.org> <18887.22064.669003.766051@a1i15.kph.uni-mainz.de> <49C7C250.9030505@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1237857327 24859 80.91.229.12 (24 Mar 2009 01:15:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Mar 2009 01:15:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 24 02:16:45 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LlvFz-00084R-JI for ged-emacs-devel@m.gmane.org; Tue, 24 Mar 2009 02:16:43 +0100 Original-Received: from localhost ([127.0.0.1]:38769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlvEc-0006si-F2 for ged-emacs-devel@m.gmane.org; Mon, 23 Mar 2009 21:15:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LlvEX-0006sT-Kl for emacs-devel@gnu.org; Mon, 23 Mar 2009 21:15:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LlvES-0006sC-4Q for emacs-devel@gnu.org; Mon, 23 Mar 2009 21:15:12 -0400 Original-Received: from [199.232.76.173] (port=48467 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlvER-0006s9-Um for emacs-devel@gnu.org; Mon, 23 Mar 2009 21:15:07 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:47019 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LlvER-0003XH-Gq for emacs-devel@gnu.org; Mon, 23 Mar 2009 21:15:07 -0400 Original-Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LlvEM-0007uF-Be for emacs-devel@gnu.org; Tue, 24 Mar 2009 01:15:02 +0000 Original-Received: from 130.127.255.239 ([130.127.255.239]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Mar 2009 01:15:02 +0000 Original-Received: from austiny.cn by 130.127.255.239 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Mar 2009 01:15:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 76 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 130.127.255.239 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwEAIAAACI8LKTAAAACXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAwAAAAMADO7oxXAAABSklEQVRo3u2avQ3CMBBGURZhAxagZgBq6uzABIgdGIWaBdiAKdKkoHBDETid7z98r3AZXZ6/c6KTh/kyHacT1m/rsAE/gSACtqDXdXffj9zV7gWs62EL2p6fh8et7zUs1FjXjxYj6BQUmyOf7IgE/Q8iQXnOI4s6G8US5C9XQZBkf6yR1xaWIP8s9FGmxaKEqgnK1mha9ZRJUBTBgvKfRMqCsjWanAItxk2Z7iYVEBQLBBEsCOobQUnGY55P49aPBBFAEAEEEUAQAQQRQBABBBEsCGq/6pKVW4Tn07j1I0EEKxSkO0IpICh2hFJAUCzKgmJnNxasNkFaJ1EZQVFZUxOUf/zeR1iCfBIh3zYFQZ7Z8W+0MmeQBMkWBgjK/2n/RCQo6mD2vLjlmqBa2Wl0CsrwUffJkVOCKmanIboGbDdCs6sEF8mVgSCCN/ZFUb91k1ZTAAAALnpUWHRjcmVhdGUtZGF0ZQAAeNozMjCw0DUw1TU0CjEysDIxtDI00TUwsTIwAABBhgUMIAoyDgAAABp6VFh0anBlZzpjb2xvcnNwYWNlAAB42jMCAAAzADOJOCM1AAAAKXpUWHRqcGVnOnNhbXBsaW5nLWZhY3RvcgAAeNozqjDSMaww1DGsMAQAEYMC6XOv90MAAAAuelRYdG1vZGlmeS1kYXRlAAB42jMyMLDQNT DVNTQKMTKwMjGwMjXXNTCxMjAAAEGxBRIhzhKBAAAAAElFTkSuQmCC User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (windows-nt) Cancel-Lock: sha1:GPz0L4N0QPMgs9Ys+yOM6e7QT3g= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:109797 Archived-At: Jan Djärv 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=) at emacs/src/eval.c:3044 #14 0x0000000000595f85 in Fbyte_code (bytestr=, vector=11655313, maxdepth=) 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