* Re: Emacs daemon dies at Xorg crash [not found] <1229454957.21129.0.camel@localhost> @ 2008-12-17 11:10 ` Ulrich Mueller 2008-12-17 11:37 ` dhruva 2008-12-17 16:03 ` Chong Yidong 0 siblings, 2 replies; 20+ messages in thread From: Ulrich Mueller @ 2008-12-17 11:10 UTC (permalink / raw) To: Diego E. 'Flameeyes' Pettenò; +Cc: emacs-devel >>>>> On Tue, 16 Dec 2008, Diego E 'Flameeyes' wrote: > Why on earth when Xorg dies, my emacs daemon dies as well? Isn't it > the point of using the daemon to NOT die when X dies and preserve > the workspace between X restarts? [CCing emacs-devel list] AFAICS Emacs only dies if there's no other connection open. I've tested it with another client open on a tty, and Emacs survived. The last thing it outputs is "Connection lost to X server `:0.0'", so it passes through x_io_error_quitter, which in turn will call x_connection_closed. In x_connection_closed there are two tests for the last terminal, where shut_down_emacs is called. Probably this should be modified for the daemon case? Ulrich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-17 11:10 ` Emacs daemon dies at Xorg crash Ulrich Mueller @ 2008-12-17 11:37 ` dhruva 2008-12-17 16:03 ` Chong Yidong 1 sibling, 0 replies; 20+ messages in thread From: dhruva @ 2008-12-17 11:37 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Diego E. 'Flameeyes' Pettenò, emacs-devel Hi, On Wed, Dec 17, 2008 at 4:40 PM, Ulrich Mueller <ulm@gentoo.org> wrote: >>>>>> On Tue, 16 Dec 2008, Diego E 'Flameeyes' wrote: > >> Why on earth when Xorg dies, my emacs daemon dies as well? Isn't it >> the point of using the daemon to NOT die when X dies and preserve >> the workspace between X restarts? > > In x_connection_closed there are two tests for the last terminal, > where shut_down_emacs is called. Probably this should be modified for > the daemon case? I completely agree. My use case is something like this. I run an X server on WXP and have emacs frame running on a remote GNU/Linux box. When I put my laptop in standby mode with the emacs frame on my local X server on WXP and wake up my system, the emacs process on the remote GNU/Linux machine is killed. I now make sure I close all emacs frames before putting my laptop on standby/hibernate. If I forget, it is gone! -dhruva -- Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-17 11:10 ` Emacs daemon dies at Xorg crash Ulrich Mueller 2008-12-17 11:37 ` dhruva @ 2008-12-17 16:03 ` Chong Yidong 2008-12-17 17:08 ` Dan Nicolaescu 1 sibling, 1 reply; 20+ messages in thread From: Chong Yidong @ 2008-12-17 16:03 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Diego E. 'Flameeyes' Pettenò, emacs-devel Ulrich Mueller <ulm@gentoo.org> writes: > AFAICS Emacs only dies if there's no other connection open. I've > tested it with another client open on a tty, and Emacs survived. > > The last thing it outputs is "Connection lost to X server `:0.0'", so > it passes through x_io_error_quitter, which in turn will call > x_connection_closed. > > In x_connection_closed there are two tests for the last terminal, > where shut_down_emacs is called. Probably this should be modified for > the daemon case? I'm not sure this is the problem. The two tests you mention are if (terminal_list->next_terminal == NULL) where terminal_list points to the X terminal about to be deleted, and if (terminal_list == 0) after the deletion of the terminal. Unless the code has changed since the last time I looked at it, Emacs uses an initial terminal, which neither sends nor receives anything, when it is run as a daemon; the existence of this initial terminal should prevent shut_down_emacs from being called. I suspect that closing X also closes the initial terminal, somehow. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-17 16:03 ` Chong Yidong @ 2008-12-17 17:08 ` Dan Nicolaescu 2008-12-17 19:25 ` Ulrich Mueller 0 siblings, 1 reply; 20+ messages in thread From: Dan Nicolaescu @ 2008-12-17 17:08 UTC (permalink / raw) To: Chong Yidong Cc: Ulrich Mueller, Diego E. 'Flameeyes' Pettenò, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Ulrich Mueller <ulm@gentoo.org> writes: > > > AFAICS Emacs only dies if there's no other connection open. I've > > tested it with another client open on a tty, and Emacs survived. > > > > The last thing it outputs is "Connection lost to X server `:0.0'", so > > it passes through x_io_error_quitter, which in turn will call > > x_connection_closed. > > > > In x_connection_closed there are two tests for the last terminal, > > where shut_down_emacs is called. Probably this should be modified for > > the daemon case? > > I'm not sure this is the problem. The two tests you mention are > > if (terminal_list->next_terminal == NULL) > > where terminal_list points to the X terminal about to be deleted, and > > if (terminal_list == 0) > > after the deletion of the terminal. Unless the code has changed since > the last time I looked at it, Emacs uses an initial terminal, which > neither sends nor receives anything, when it is run as a daemon; the > existence of this initial terminal should prevent shut_down_emacs from > being called. Agreed. There wasn't enough context in the initial mail, but I suspect this is an emacs compiled with Gtk+. It works (and it has always done so) perfectly well for me when using Lucid. There's a long standing Gtk+ bug: http://bugzilla.gnome.org/show_bug.cgi?id=85715 that creates problems with closing the display for Emacs from time to time. Jan has put in a few workarounds, but the bug in Gtk+ still exists. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-17 17:08 ` Dan Nicolaescu @ 2008-12-17 19:25 ` Ulrich Mueller 2008-12-17 22:51 ` Dan Nicolaescu 0 siblings, 1 reply; 20+ messages in thread From: Ulrich Mueller @ 2008-12-17 19:25 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Chong Yidong, Diego Petteno, emacs-devel >>>>> On Wed, 17 Dec 2008, Dan Nicolaescu wrote: > Chong Yidong <cyd@stupidchicken.com> writes: >> I'm not sure this is the problem. The two tests you mention are >> >> if (terminal_list->next_terminal == NULL) >> >> where terminal_list points to the X terminal about to be deleted, and >> >> if (terminal_list == 0) >> >> after the deletion of the terminal. Unless the code has changed since >> the last time I looked at it, Emacs uses an initial terminal, which >> neither sends nor receives anything, when it is run as a daemon; the >> existence of this initial terminal should prevent shut_down_emacs from >> being called. Right. Further debugging shows that neither of the two tests is true, but "error" is called at the very end of x_connection_closed. > Agreed. > There wasn't enough context in the initial mail, but I suspect this is > an emacs compiled with Gtk+. It works (and it has always done so) > perfectly well for me when using Lucid. I could reproduce the issue with the following configuration. No GTK+. In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, X toolkit) of 2008-12-17 on a1iulm2 Windowing system distributor `The X.Org Foundation', version 11.0.10502000 configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-23' '--with-sound' '--with-x' '--without-toolkit-scroll-bars' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xpm' '--with-freetype' '--with-xft' '--without-libotf' '--without-m17n-flt' '--with-x-toolkit=athena' '--without-hesiod' '--without-kerberos' '--without-kerberos5' '--with-gpm' '--with-dbus' '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-march=pentium-m -O2 -pipe' 'LDFLAGS=-Wl,-O1'' Ulrich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-17 19:25 ` Ulrich Mueller @ 2008-12-17 22:51 ` Dan Nicolaescu 2008-12-18 12:03 ` Ulrich Mueller 0 siblings, 1 reply; 20+ messages in thread From: Dan Nicolaescu @ 2008-12-17 22:51 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Chong Yidong, Diego Petteno, emacs-devel Ulrich Mueller <ulm@gentoo.org> writes: > >>>>> On Wed, 17 Dec 2008, Dan Nicolaescu wrote: > > > Agreed. > > There wasn't enough context in the initial mail, but I suspect this is > > an emacs compiled with Gtk+. It works (and it has always done so) > > perfectly well for me when using Lucid. > > I could reproduce the issue with the following configuration. No GTK+. > In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, X toolkit) > of 2008-12-17 on a1iulm2 > Windowing system distributor `The X.Org Foundation', version 11.0.10502000 > configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu' > '--mandir=/usr/share/man' '--infodir=/usr/share/info' > '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' > '--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-23' > '--with-sound' '--with-x' '--without-toolkit-scroll-bars' '--with-gif' > '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xpm' > '--with-freetype' '--with-xft' '--without-libotf' '--without-m17n-flt' > '--with-x-toolkit=athena' '--without-hesiod' '--without-kerberos' > '--without-kerberos5' '--with-gpm' '--with-dbus' > '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu' > 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-march=pentium-m -O2 -pipe' > 'LDFLAGS=-Wl,-O1'' It works fine for me on a Fedora 10 machine when configuring with --with-x-toolkit=athena. Killing X does not kill the daemon when either no frames are open, tty frames are open, X11 frames or tty and X11 frames are open. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-17 22:51 ` Dan Nicolaescu @ 2008-12-18 12:03 ` Ulrich Mueller 2008-12-18 12:14 ` Ulrich Mueller 2008-12-18 19:14 ` Dan Nicolaescu 0 siblings, 2 replies; 20+ messages in thread From: Ulrich Mueller @ 2008-12-18 12:03 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Chong Yidong, Diego Petteno, emacs-devel >>>>> On Wed, 17 Dec 2008, Dan Nicolaescu wrote: > It works fine for me on a Fedora 10 machine when configuring with > --with-x-toolkit=athena. Killing X does not kill the daemon when > either no frames are open, tty frames are open, X11 frames or tty > and X11 frames are open. I also depends on the desktop / window manager. Here it dies when Gnome or Xfce4 are terminated (only in the "no frames" case). No problem with IceWM though. Below I include a gdb backtrace. I can provide further information if necessary. cmd_error_internal in frame #25 is called with the first argument: (error "Connection lost to X server `:0.0'") Since FRAME_INITIAL_P (sf) is true at that point, it then calls kill-emacs: /* If the window system or terminal frame hasn't been initialized yet, or we're not interactive, write the message to stderr and exit. */ else if (!sf->glyphs_initialized_p || FRAME_INITIAL_P (sf) || noninteractive) { print_error_message (data, Qexternal_debugging_output, context, Vsignaling_function); Fterpri (Qexternal_debugging_output); Fkill_emacs (make_number (-1)); } #0 Fsignal (error_symbol=0x84863b9, data=0x874fcfd) at eval.c:1640 #1 0x0824c780 in xsignal (error_symbol=0x84863b9, data=0x874fcfd) at eval.c:1772 #2 0x081f8844 in report_file_error (string=0x82e8afa "make client process failed", data=0x874fd45) at fileio.c:277 #3 0x0829a4bd in Fmake_network_process (nargs=0xa, args=0x7fdb5f58) at process.c:3632 #4 0x0824e5b7 in Ffuncall (nargs=0xb, args=0x7fdb5f54) at eval.c:3050 #5 0x0829201e in Fbyte_code (bytestr=0x84c8f5b, vector=0x9b5bea4, maxdepth=0x70) at bytecode.c:678 #6 0x0824d885 in Feval (form=0x8731c55) at eval.c:2406 #7 0x0824be4b in internal_lisp_condition_case (var=0x84778c9, bodyform=0x8731c55, handlers=0x8731f9d) at eval.c:1456 #8 0x08292cf0 in Fbyte_code (bytestr=0x84c8fdb, vector=0x9b5bf44, maxdepth=0x18) at bytecode.c:868 #9 0x0824ee8a in funcall_lambda (fun=0x9b5bfcc, nargs=0x1, arg_vector=0x7fdb66b4) at eval.c:3256 #10 0x0824e93b in Ffuncall (nargs=0x2, args=0x7fdb66b0) at eval.c:3115 #11 0x0829201e in Fbyte_code (bytestr=0x84f7f63, vector=0x9b5baa4, maxdepth=0xb8) at bytecode.c:678 #12 0x0824ee8a in funcall_lambda (fun=0x9b5bc9c, nargs=0x1, arg_vector=0x7fdb6a04) at eval.c:3256 #13 0x0824e93b in Ffuncall (nargs=0x2, args=0x7fdb6a00) at eval.c:3115 #14 0x0829201e in Fbyte_code (bytestr=0x84cd9f3, vector=0x9b5c034, maxdepth=0x18) at bytecode.c:678 #15 0x0824ee8a in funcall_lambda (fun=0x9b5c104, nargs=0x1, arg_vector=0x7fdb6d04) at eval.c:3256 #16 0x0824e93b in Ffuncall (nargs=0x2, args=0x7fdb6d00) at eval.c:3115 #17 0x0829201e in Fbyte_code (bytestr=0x84f6b03, vector=0x9b5b9b4, maxdepth=0x10) at bytecode.c:678 #18 0x0824ee8a in funcall_lambda (fun=0x9b5ba2c, nargs=0x0, arg_vector=0x7fdb7078) at eval.c:3256 #19 0x0824e93b in Ffuncall (nargs=0x1, args=0x7fdb7074) at eval.c:3115 #20 0x0824e0a0 in run_hook_with_args (nargs=0x1, args=0x7fdb7074, cond=to_completion) at eval.c:2728 #21 0x0824debd in Frun_hooks (nargs=0x1, args=0x7fdb7134) at eval.c:2591 #22 0x0824e5b7 in Ffuncall (nargs=0x2, args=0x7fdb7130) at eval.c:3050 #23 0x0824e280 in call1 (fn=0x8499a61, arg1=0x84a5729) at eval.c:2854 #24 0x081c1a14 in Fkill_emacs (arg=0xfffffff8) at emacs.c:2087 #25 0x081c3219 in cmd_error_internal (data=0x874fe4d, context=0x7fdb71ae "") at keyboard.c:1274 #26 0x081c30b4 in cmd_error (data=0x874fe4d) at keyboard.c:1222 #27 0x0824bf18 in internal_condition_case (bfun=0x81c35ee <command_loop_1>, handlers=0x84821b1, hfun=0x81c2fc9 <cmd_error>) at eval.c:1501 #28 0x081c3340 in command_loop_2 () at keyboard.c:1338 #29 0x0824ba31 in internal_catch (tag=0x84811f9, func=0x81c331b <command_loop_2>, arg=0x84778c9) at eval.c:1247 #30 0x081c32f9 in command_loop () at keyboard.c:1317 #31 0x081c2bd9 in recursive_edit_1 () at keyboard.c:942 #32 0x081c2d46 in Frecursive_edit () at keyboard.c:1004 #33 0x081c14c6 in main (argc=0x3, argv=0x7fdb78b4) at emacs.c:1788 Lisp Backtrace: "make-network-process" (0x7fdb5f58) "byte-code" (0x7fdb6200) "server-running-p" (0x7fdb66b4) "server-start" (0x7fdb6a04) "server-mode" (0x7fdb6d04) 0x9b5ba2c PVEC_COMPILED "run-hooks" (0x7fdb7134) Ulrich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-18 12:03 ` Ulrich Mueller @ 2008-12-18 12:14 ` Ulrich Mueller 2008-12-18 19:14 ` Dan Nicolaescu 1 sibling, 0 replies; 20+ messages in thread From: Ulrich Mueller @ 2008-12-18 12:14 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Chong Yidong, Diego Petteno, emacs-devel >>>>> On Thu, 18 Dec 2008, Ulrich Mueller wrote: > Here it dies when Gnome or Xfce4 are terminated (only in the "no > frames" case). This might be misleading. I meant that there was one X11 frame open before, and no frames after killing X. Of course it doesn't die if there are no frames before X is killed. Ulrich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-18 12:03 ` Ulrich Mueller 2008-12-18 12:14 ` Ulrich Mueller @ 2008-12-18 19:14 ` Dan Nicolaescu 2008-12-18 22:03 ` Ulrich Mueller 1 sibling, 1 reply; 20+ messages in thread From: Dan Nicolaescu @ 2008-12-18 19:14 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Chong Yidong, Diego Petteno, emacs-devel Ulrich Mueller <ulm@gentoo.org> writes: > >>>>> On Wed, 17 Dec 2008, Dan Nicolaescu wrote: > > > It works fine for me on a Fedora 10 machine when configuring with > > --with-x-toolkit=athena. Killing X does not kill the daemon when > > either no frames are open, tty frames are open, X11 frames or tty > > and X11 frames are open. > > I also depends on the desktop / window manager. Here it dies when > Gnome or Xfce4 are terminated (only in the "no frames" case). > No problem with IceWM though. Of those environments, I only have Gnome, and I don't see any problems with it. > Below I include a gdb backtrace. I can provide further information if > necessary. Can you try the patch at: http://permalink.gmane.org/gmane.emacs.bugs/22201 > #0 Fsignal (error_symbol=0x84863b9, data=0x874fcfd) at eval.c:1640 Can you do M-x load-library RET server.el RET before producing the backtrace? > #1 0x0824c780 in xsignal (error_symbol=0x84863b9, data=0x874fcfd) at eval.c:1772 > #2 0x081f8844 in report_file_error (string=0x82e8afa "make client process failed", data=0x874fd45) at fileio.c:277 This is strange, this error seems to occur when something tries to connect to the server. Hmmm... ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-18 19:14 ` Dan Nicolaescu @ 2008-12-18 22:03 ` Ulrich Mueller 2008-12-18 22:49 ` Dan Nicolaescu 0 siblings, 1 reply; 20+ messages in thread From: Ulrich Mueller @ 2008-12-18 22:03 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Chong Yidong, Diego Petteno, emacs-devel >>>>> On Thu, 18 Dec 2008, Dan Nicolaescu wrote: > Can you try the patch at: > http://permalink.gmane.org/gmane.emacs.bugs/22201 Tested and Emacs doesn't die anymore. I find the "Connection lost ..." message in the *Messages* buffer after reconnecting. > Can you do > M-x load-library RET server.el RET > before producing the backtrace? Sure. New backtrace is appended. >> #1 0x0824c780 in xsignal (error_symbol=0x84863b9, data=0x874fcfd) at eval.c:1772 >> #2 0x081f8844 in report_file_error (string=0x82e8afa "make client process failed", data=0x874fd45) at fileio.c:277 > This is strange, this error seems to occur when something tries to > connect to the server. Hmmm... #0 Fsignal (error_symbol=0x84863b9, data=0x874d62d) at eval.c:1640 #1 0x0824c780 in xsignal (error_symbol=0x84863b9, data=0x874d62d) at eval.c:1772 #2 0x081f8844 in report_file_error (string=0x82e8afa "make client process failed", data=0x874d675) at fileio.c:277 #3 0x0829a4bd in Fmake_network_process (nargs=0xa, args=0x7f877cd0) at process.c:3632 #4 0x0824d75e in Feval (form=0x875469d) at eval.c:2373 #5 0x0824d7ab in Feval (form=0x87546a5) at eval.c:2385 #6 0x0824a551 in Fprogn (args=0x8754615) at eval.c:449 #7 0x0824a4a8 in Fif (args=0x8754c2d) at eval.c:398 #8 0x0824d674 in Feval (form=0x8754c35) at eval.c:2347 #9 0x0824be4b in internal_lisp_condition_case (var=0x84778c9, bodyform=0x8754c35, handlers=0x87545ed) at eval.c:1456 #10 0x0824bc78 in Fcondition_case (args=0x8754c3d) at eval.c:1397 #11 0x0824d674 in Feval (form=0x8754c45) at eval.c:2347 #12 0x0824a551 in Fprogn (args=0x87545e5) at eval.c:449 #13 0x0824ee3e in funcall_lambda (fun=0x87545dd, nargs=0x1, arg_vector=0x7f8782a0) at eval.c:3249 #14 0x0824eb55 in apply_lambda (fun=0x87545dd, args=0x874f615, eval_flag=0x1) at eval.c:3180 #15 0x0824db57 in Feval (form=0x874f61d) at eval.c:2460 #16 0x0824d7ab in Feval (form=0x874f62d) at eval.c:2385 #17 0x0824d7ab in Feval (form=0x874f635) at eval.c:2385 #18 0x0824a462 in Fif (args=0x874f5fd) at eval.c:393 #19 0x0824d674 in Feval (form=0x874f63d) at eval.c:2347 #20 0x0824a551 in Fprogn (args=0x874f48d) at eval.c:449 #21 0x0824b447 in FletX (args=0x874f685) at eval.c:1033 #22 0x0824d674 in Feval (form=0x874f705) at eval.c:2347 #23 0x0824a551 in Fprogn (args=0x8746175) at eval.c:449 #24 0x0824d674 in Feval (form=0x874616d) at eval.c:2347 #25 0x0824a488 in Fif (args=0x874614d) at eval.c:397 #26 0x0824d674 in Feval (form=0x874613d) at eval.c:2347 #27 0x0824db2e in Feval (form=0x874f7ad) at eval.c:2458 #28 0x0824a551 in Fprogn (args=0x87551e5) at eval.c:449 #29 0x0824ee3e in funcall_lambda (fun=0x87551dd, nargs=0x1, arg_vector=0x7f878bd0) at eval.c:3249 #30 0x0824eb55 in apply_lambda (fun=0x87551dd, args=0x8754555, eval_flag=0x1) at eval.c:3180 #31 0x0824db57 in Feval (form=0x875456d) at eval.c:2460 #32 0x0824a551 in Fprogn (args=0x875bf45) at eval.c:449 #33 0x0824b699 in Flet (args=0x875bf35) at eval.c:1089 #34 0x0824d674 in Feval (form=0x875bf2d) at eval.c:2347 #35 0x0824a551 in Fprogn (args=0x875bf15) at eval.c:449 #36 0x0824ee3e in funcall_lambda (fun=0x875bca5, nargs=0x1, arg_vector=0x7f878fc4) at eval.c:3249 #37 0x0824e9d3 in Ffuncall (nargs=0x2, args=0x7f878fc0) at eval.c:3126 #38 0x0829201e in Fbyte_code (bytestr=0x84f6b03, vector=0x8c199b4, maxdepth=0x10) at bytecode.c:678 #39 0x0824ee8a in funcall_lambda (fun=0x8c19a2c, nargs=0x0, arg_vector=0x7f879338) at eval.c:3256 #40 0x0824e93b in Ffuncall (nargs=0x1, args=0x7f879334) at eval.c:3115 #41 0x0824e0a0 in run_hook_with_args (nargs=0x1, args=0x7f879334, cond=to_completion) at eval.c:2728 #42 0x0824debd in Frun_hooks (nargs=0x1, args=0x7f8793f4) at eval.c:2591 #43 0x0824e5b7 in Ffuncall (nargs=0x2, args=0x7f8793f0) at eval.c:3050 #44 0x0824e280 in call1 (fn=0x8499a61, arg1=0x84a5729) at eval.c:2854 #45 0x081c1a14 in Fkill_emacs (arg=0xfffffff8) at emacs.c:2087 #46 0x081c3219 in cmd_error_internal (data=0x874618d, context=0x7f87946e "") at keyboard.c:1274 #47 0x081c30b4 in cmd_error (data=0x874618d) at keyboard.c:1222 #48 0x0824bf18 in internal_condition_case (bfun=0x81c35ee <command_loop_1>, handlers=0x84821b1, hfun=0x81c2fc9 <cmd_error>) at eval.c:1501 #49 0x081c3340 in command_loop_2 () at keyboard.c:1338 #50 0x0824ba31 in internal_catch (tag=0x84811f9, func=0x81c331b <command_loop_2>, arg=0x84778c9) at eval.c:1247 #51 0x081c32f9 in command_loop () at keyboard.c:1317 #52 0x081c2bd9 in recursive_edit_1 () at keyboard.c:942 #53 0x081c2d46 in Frecursive_edit () at keyboard.c:1004 #54 0x081c14c6 in main (argc=0x3, argv=0x7f879b74) at emacs.c:1788 Lisp Backtrace: "make-network-process" (0x7f877cd0) "delete-process" (0x7f877e98) "if" (0x7f877fc8) "condition-case" (0x7f8781f8) "server-running-p" (0x7f8782a0) "eq" (0x7f8784b8) "not" (0x7f8785a8) "if" (0x7f8786b8) "let*" (0x7f878818) "progn" (0x7f878928) "if" (0x7f878a38) "when" (0x7f878b28) "server-start" (0x7f878bd0) "let" (0x7f878e88) "server-mode" (0x7f878fc4) 0x8c19a2c PVEC_COMPILED "run-hooks" (0x7f8793f4) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-18 22:03 ` Ulrich Mueller @ 2008-12-18 22:49 ` Dan Nicolaescu 2008-12-19 0:04 ` Ulrich Mueller 2008-12-20 18:35 ` Ulrich Mueller 0 siblings, 2 replies; 20+ messages in thread From: Dan Nicolaescu @ 2008-12-18 22:49 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Chong Yidong, Diego Petteno, emacs-devel Ulrich Mueller <ulm@gentoo.org> writes: > >>>>> On Thu, 18 Dec 2008, Dan Nicolaescu wrote: > > > Can you try the patch at: > > http://permalink.gmane.org/gmane.emacs.bugs/22201 > > Tested and Emacs doesn't die anymore. I find the "Connection lost ..." > message in the *Messages* buffer after reconnecting. IMO that patch is good, but it fixes the effect in this case, not the cause. Given where we are in the release process I'd like an OK from one of the maintainers to check it in. > > Can you do > > M-x load-library RET server.el RET > > before producing the backtrace? > > Sure. New backtrace is appended. > > >> #1 0x0824c780 in xsignal (error_symbol=0x84863b9, data=0x874fcfd) at eval.c:1772 > >> #2 0x081f8844 in report_file_error (string=0x82e8afa "make client process failed", data=0x874fd45) at fileio.c:277 > > > This is strange, this error seems to occur when something tries to > > connect to the server. Hmmm... > > > #0 Fsignal (error_symbol=0x84863b9, data=0x874d62d) at eval.c:1640 > #1 0x0824c780 in xsignal (error_symbol=0x84863b9, data=0x874d62d) at eval.c:1772 > #2 0x081f8844 in report_file_error (string=0x82e8afa "make client process failed", data=0x874d675) at fileio.c:277 > #3 0x0829a4bd in Fmake_network_process (nargs=0xa, args=0x7f877cd0) at process.c:3632 Can you please check why the above function fails? Can you also revert server.el to version 1.175 and see if that still causes problems? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-18 22:49 ` Dan Nicolaescu @ 2008-12-19 0:04 ` Ulrich Mueller 2008-12-19 0:46 ` Dan Nicolaescu 2008-12-20 18:35 ` Ulrich Mueller 1 sibling, 1 reply; 20+ messages in thread From: Ulrich Mueller @ 2008-12-19 0:04 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Chong Yidong, Diego Petteno, emacs-devel >>>>> On Thu, 18 Dec 2008, Dan Nicolaescu wrote: >> > Can you try the patch at: >> > http://permalink.gmane.org/gmane.emacs.bugs/22201 >> >> Tested and Emacs doesn't die anymore. I find the "Connection lost ..." >> message in the *Messages* buffer after reconnecting. > IMO that patch is good, but it fixes the effect in this case, not the > cause. Hm, could you please elaborate what you mean by "effect" and "cause" here? >> #0 Fsignal (error_symbol=0x84863b9, data=0x874d62d) at eval.c:1640 >> #1 0x0824c780 in xsignal (error_symbol=0x84863b9, data=0x874d62d) at eval.c:1772 >> #2 0x081f8844 in report_file_error (string=0x82e8afa "make client process failed", data=0x874d675) at fileio.c:277 >> #3 0x0829a4bd in Fmake_network_process (nargs=0xa, args=0x7f877cd0) at process.c:3632 This error has nothing to do with the X connection problem, right? > Can you please check why the above function fails? server-start gets called from kill-emacs-hook. It first deletes the server-process, and then calls server-running-p, which unsuccessfully tries to connect to the server's socket (server.el, revision 1.177): (when server-process ;; kill it dead! (ignore-errors (delete-process server-process))) ;; Delete the socket files made by previous server invocations. (if (not (eq t (server-running-p server-name))) However, please note that make-network-process in server-running-p is inside a condition-case. (Which doesn't prevent it from hitting my gdb breakpoint in Fsignal.) > Can you also revert server.el to version 1.175 and see if that still > causes problems? With 1.175 it doesn't hit Fsignal. But I'm not sure if there really is a problem in 1.177. Ulrich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-19 0:04 ` Ulrich Mueller @ 2008-12-19 0:46 ` Dan Nicolaescu 2008-12-19 8:00 ` Ulrich Mueller 2008-12-19 13:56 ` Stefan Monnier 0 siblings, 2 replies; 20+ messages in thread From: Dan Nicolaescu @ 2008-12-19 0:46 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Chong Yidong, Diego Petteno, emacs-devel Ulrich Mueller <ulm@gentoo.org> writes: > >>>>> On Thu, 18 Dec 2008, Dan Nicolaescu wrote: > > >> > Can you try the patch at: > >> > http://permalink.gmane.org/gmane.emacs.bugs/22201 > >> > >> Tested and Emacs doesn't die anymore. I find the "Connection lost ..." > >> message in the *Messages* buffer after reconnecting. > > > IMO that patch is good, but it fixes the effect in this case, not the > > cause. > > Hm, could you please elaborate what you mean by "effect" and "cause" > here? Emacs dies because something tries to call message while no frame is open. This is the "effect". The "cause" is whatever causes that message to be written, it probably should not happen. And indeed, even for you, it happens only for some specific window managers. > > >> #0 Fsignal (error_symbol=0x84863b9, data=0x874d62d) at eval.c:1640 > >> #1 0x0824c780 in xsignal (error_symbol=0x84863b9, data=0x874d62d) at eval.c:1772 > >> #2 0x081f8844 in report_file_error (string=0x82e8afa "make client process failed", data=0x874d675) at fileio.c:277 > >> #3 0x0829a4bd in Fmake_network_process (nargs=0xa, args=0x7f877cd0) at process.c:3632 > > This error has nothing to do with the X connection problem, right? I don't know, you need to find out why we get here sometimes, but not when using other WMs. > > Can you please check why the above function fails? > > server-start gets called from kill-emacs-hook. It first deletes the > server-process, and then calls server-running-p, which unsuccessfully This sounds strange... > tries to connect to the server's socket (server.el, revision 1.177): > > (when server-process > ;; kill it dead! > (ignore-errors (delete-process server-process))) > ;; Delete the socket files made by previous server invocations. > (if (not (eq t (server-running-p server-name))) > > However, please note that make-network-process in server-running-p is > inside a condition-case. (Which doesn't prevent it from hitting my > gdb breakpoint in Fsignal.) > > > Can you also revert server.el to version 1.175 and see if that still > > causes problems? > > With 1.175 it doesn't hit Fsignal. But I'm not sure if there really is > a problem in 1.177. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-19 0:46 ` Dan Nicolaescu @ 2008-12-19 8:00 ` Ulrich Mueller 2008-12-19 17:00 ` Dan Nicolaescu 2008-12-19 13:56 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: Ulrich Mueller @ 2008-12-19 8:00 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Chong Yidong, Diego Petteno, emacs-devel >>>>> On Thu, 18 Dec 2008, Dan Nicolaescu wrote: >> >> > Can you try the patch at: >> >> > http://permalink.gmane.org/gmane.emacs.bugs/22201 >> >> >> >> Tested and Emacs doesn't die anymore. I find the "Connection lost ..." >> >> message in the *Messages* buffer after reconnecting. >> >> > IMO that patch is good, but it fixes the effect in this case, not the >> > cause. >> >> Hm, could you please elaborate what you mean by "effect" and "cause" >> here? > Emacs dies because something tries to call message while no frame is > open. This is the "effect". The "cause" is whatever causes that > message to be written, it probably should not happen. But "X connection lost" is precisely what happens. What could Emacs do to prevent this, if there is suddenly no X server anymore? > And indeed, even for you, it happens only for some specific window > managers. Looks like IceWM sends a WM_DELETE_WINDOW message to the X clients before it exits, while Xfce4 doesn't do this. What happens if you kill -9 your X server? Does Emacs die? Ulrich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-19 8:00 ` Ulrich Mueller @ 2008-12-19 17:00 ` Dan Nicolaescu 2008-12-19 17:27 ` Ulrich Mueller 0 siblings, 1 reply; 20+ messages in thread From: Dan Nicolaescu @ 2008-12-19 17:00 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Chong Yidong, Diego Petteno, emacs-devel Ulrich Mueller <ulm@gentoo.org> writes: > >>>>> On Thu, 18 Dec 2008, Dan Nicolaescu wrote: > > >> >> > Can you try the patch at: > >> >> > http://permalink.gmane.org/gmane.emacs.bugs/22201 > >> >> > >> >> Tested and Emacs doesn't die anymore. I find the "Connection lost ..." > >> >> message in the *Messages* buffer after reconnecting. > >> > >> > IMO that patch is good, but it fixes the effect in this case, not the > >> > cause. > >> > >> Hm, could you please elaborate what you mean by "effect" and "cause" > >> here? > > > Emacs dies because something tries to call message while no frame is > > open. This is the "effect". The "cause" is whatever causes that > > message to be written, it probably should not happen. > > But "X connection lost" is precisely what happens. What could Emacs do > to prevent this, if there is suddenly no X server anymore? Kill the frames on the display that was closed and continue running? Your backtrace seems to show that the problem happens because of Fmake_network_process... > > And indeed, even for you, it happens only for some specific window > > managers. > > Looks like IceWM sends a WM_DELETE_WINDOW message to the X clients > before it exits, while Xfce4 doesn't do this. > > What happens if you kill -9 your X server? Does Emacs die? I won't try kill -9 X because I've seen that lock the machine in the past. But C-A-backspace does not kill emacs, and I doubt it gives the WM a chance to send any message. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-19 17:00 ` Dan Nicolaescu @ 2008-12-19 17:27 ` Ulrich Mueller 2008-12-19 17:47 ` Dan Nicolaescu 0 siblings, 1 reply; 20+ messages in thread From: Ulrich Mueller @ 2008-12-19 17:27 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Chong Yidong, Diego Petteno, emacs-devel >>>>> On Fri, 19 Dec 2008, Dan Nicolaescu wrote: >> But "X connection lost" is precisely what happens. What could Emacs do >> to prevent this, if there is suddenly no X server anymore? > Kill the frames on the display that was closed and continue running? But it does that? The error occurs _after_ deleting these frames. Or am I missing something here? > Your backtrace seems to show that the problem happens because of > Fmake_network_process... I think that this is an unrelated problem. (In fact, I'd better set a breakpoint in Fkill_emacs, and you wouldn't have seen that part of the backtrace at all.) Here are the relevant frames of the backtrace again: #2 0x081f8844 in report_file_error (string=0x82e8afa "make client process failed", data=0x874d675) at fileio.c:277 #3 0x0829a4bd in Fmake_network_process (nargs=0xa, args=0x7f877cd0) at process.c:3632 [...] #42 0x0824debd in Frun_hooks (nargs=0x1, args=0x7f8793f4) at eval.c:2591 [...] #45 0x081c1a14 in Fkill_emacs (arg=0xfffffff8) at emacs.c:2087 #46 0x081c3219 in cmd_error_internal (data=0x874618d, context=0x7f87946e "") at keyboard.c:1274 Fkill_emacs is called because cmd_error_internal doesn't like to output the error message ("Connection lost ...") to the initial frame. Fmake_network_process is called later, while running kill-emacs-hook. This is unrelated to the original error. Ulrich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-19 17:27 ` Ulrich Mueller @ 2008-12-19 17:47 ` Dan Nicolaescu 0 siblings, 0 replies; 20+ messages in thread From: Dan Nicolaescu @ 2008-12-19 17:47 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Chong Yidong, Diego Petteno, emacs-devel Ulrich Mueller <ulm@gentoo.org> writes: > >>>>> On Fri, 19 Dec 2008, Dan Nicolaescu wrote: > > >> But "X connection lost" is precisely what happens. What could Emacs do > >> to prevent this, if there is suddenly no X server anymore? > > > Kill the frames on the display that was closed and continue running? > > But it does that? The error occurs _after_ deleting these frames. > Or am I missing something here? It works fine for me. You said it works fine for you with some window managers. It works fine for you with and older version of server.el... ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-19 0:46 ` Dan Nicolaescu 2008-12-19 8:00 ` Ulrich Mueller @ 2008-12-19 13:56 ` Stefan Monnier 2008-12-19 16:45 ` Dan Nicolaescu 1 sibling, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2008-12-19 13:56 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Ulrich Mueller, Diego Petteno, Chong Yidong, emacs-devel > Emacs dies because something tries to call message while no frame is > open. This is the "effect". The "cause" is whatever causes that > message to be written, it probably should not happen. And indeed, even > for you, it happens only for some specific window managers. Is it really because of a "message"? Isn't it because of an "error" instead? I'm thinking it might be related to the fact that emacs --batch --eval '(error "toto")' --eval '(message "tata")' will not show the message "tata" because Emacs has already exited after the error. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-19 13:56 ` Stefan Monnier @ 2008-12-19 16:45 ` Dan Nicolaescu 0 siblings, 0 replies; 20+ messages in thread From: Dan Nicolaescu @ 2008-12-19 16:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: Ulrich Mueller, Diego Petteno, Chong Yidong, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > > Emacs dies because something tries to call message while no frame is > > open. This is the "effect". The "cause" is whatever causes that > > message to be written, it probably should not happen. And indeed, even > > for you, it happens only for some specific window managers. > > Is it really because of a "message"? Isn't it because of an "error" instead? It's actually because of cmd_error_internal getting called with Vcommand_error_function set to nil. If you can trigger this with emacsclient --eval, it will kill the daemon. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Emacs daemon dies at Xorg crash 2008-12-18 22:49 ` Dan Nicolaescu 2008-12-19 0:04 ` Ulrich Mueller @ 2008-12-20 18:35 ` Ulrich Mueller 1 sibling, 0 replies; 20+ messages in thread From: Ulrich Mueller @ 2008-12-20 18:35 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Chong Yidong, Diego Petteno, emacs-devel >>>>> On Thu, 18 Dec 2008, Dan Nicolaescu wrote: >> > Can you try the patch at: >> > http://permalink.gmane.org/gmane.emacs.bugs/22201 >> >> Tested and Emacs doesn't die anymore. I find the "Connection lost ..." >> message in the *Messages* buffer after reconnecting. > IMO that patch is good, but it fixes the effect in this case, not the > cause. Given where we are in the release process I'd like an OK from > one of the maintainers to check it in. The intention of that test in cmd_error_internal is clear from the comment before it, namely to exit if there's an error during initialisation or in batch mode (both not the case here): /* If the window system or terminal frame hasn't been initialized yet, or we're not interactive, write the message to stderr and exit. */ So, any reason why above patch cannot be checked in? Ulrich ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2008-12-20 18:35 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <1229454957.21129.0.camel@localhost> 2008-12-17 11:10 ` Emacs daemon dies at Xorg crash Ulrich Mueller 2008-12-17 11:37 ` dhruva 2008-12-17 16:03 ` Chong Yidong 2008-12-17 17:08 ` Dan Nicolaescu 2008-12-17 19:25 ` Ulrich Mueller 2008-12-17 22:51 ` Dan Nicolaescu 2008-12-18 12:03 ` Ulrich Mueller 2008-12-18 12:14 ` Ulrich Mueller 2008-12-18 19:14 ` Dan Nicolaescu 2008-12-18 22:03 ` Ulrich Mueller 2008-12-18 22:49 ` Dan Nicolaescu 2008-12-19 0:04 ` Ulrich Mueller 2008-12-19 0:46 ` Dan Nicolaescu 2008-12-19 8:00 ` Ulrich Mueller 2008-12-19 17:00 ` Dan Nicolaescu 2008-12-19 17:27 ` Ulrich Mueller 2008-12-19 17:47 ` Dan Nicolaescu 2008-12-19 13:56 ` Stefan Monnier 2008-12-19 16:45 ` Dan Nicolaescu 2008-12-20 18:35 ` Ulrich Mueller
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).