Re: Emacs daemon dies at Xorg crash

Re: Emacs daemon dies at Xorg crash

[Ulrich Mueller]

>>>>> 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

Re: Emacs daemon dies at Xorg crash

[dhruva]

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!

Re: Emacs daemon dies at Xorg crash

[Chong Yidong]

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.

Re: Emacs daemon dies at Xorg crash

[Dan Nicolaescu]

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.

Re: Emacs daemon dies at Xorg crash

[Ulrich Mueller]

>>>>> 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

Re: Emacs daemon dies at Xorg crash

[Dan Nicolaescu]

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.  

Re: Emacs daemon dies at Xorg crash

[Ulrich Mueller]

>>>>> 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

Re: Emacs daemon dies at Xorg crash

[Ulrich Mueller]

>>>>> 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

Re: Emacs daemon dies at Xorg crash

[Dan Nicolaescu]

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...

Re: Emacs daemon dies at Xorg crash

[Ulrich Mueller]

>>>>> 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)

Re: Emacs daemon dies at Xorg crash

[Dan Nicolaescu]

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?

Re: Emacs daemon dies at Xorg crash

[Ulrich Mueller]

>>>>> 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

Re: Emacs daemon dies at Xorg crash

[Dan Nicolaescu]

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.

Re: Emacs daemon dies at Xorg crash

[Ulrich Mueller]

>>>>> 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

Re: Emacs daemon dies at Xorg crash

[Dan Nicolaescu]

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.

Re: Emacs daemon dies at Xorg crash

[Ulrich Mueller]

>>>>> 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

Re: Emacs daemon dies at Xorg crash

[Dan Nicolaescu]

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... 

Re: Emacs daemon dies at Xorg crash

[Stefan Monnier]

> 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

Re: Emacs daemon dies at Xorg crash

[Dan Nicolaescu]

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.

Re: Emacs daemon dies at Xorg crash

[Ulrich Mueller]

>>>>> 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