GNU bug report logs - #66151
29.1.50; daemon crashing after X forwarding disconnects

Previous Next

Full log

Message #20 received at 66151 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Benjamin Schwehn <bschwehn <at> gmail.com>
Cc: luangruo <at> yahoo.com, 66151 <at> debbugs.gnu.org
Subject: Re: bug#66151: 29.1.50; daemon crashing after X forwarding disconnects
Date: Fri, 22 Sep 2023 18:07:49 +0300

> From: Benjamin Schwehn <bschwehn <at> gmail.com>
> Date: Fri, 22 Sep 2023 16:28:40 +0200
> Cc: Po Lu <luangruo <at> yahoo.com>, 66151 <at> debbugs.gnu.org
> 
> > Does this happen with any emacsclient command in this situation?  What
> > if you don't use -c, for example, or use -t instead?
> 
> emacsclient -t also causes the crash, with this backtrace (looks the same to me)
> 
> emacs_backtrace at /home/ben/install/emacs/emacs/src/sysdep.c:2304
> terminate_due_to_signal at /home/ben/install/emacs/emacs/src/emacs.c:458
> deliver_process_signal at /home/ben/install/emacs/emacs/src/sysdep.c:1741
>  (inlined by) deliver_fatal_signal at
> /home/ben/install/emacs/emacs/src/sysdep.c:1789
> deliver_thread_signal.constprop.0 at
> /home/ben/install/emacs/emacs/src/sysdep.c:1765
> ?? ??:0
> make_lisp_ptr at /home/ben/install/emacs/emacs/src/lisp.h:1364
>  (inlined by) realize_default_face at
> /home/ben/install/emacs/emacs/src/xfaces.c:5802

So this means we are somehow handling the original GUI frame.

> The crash is triggered when a live frame was connected when the network
> connection was cut, but the crash happens only later, the next time I open a
> frame. But I am not fully sure I correctly understand the question. Let me try
> to explain better the circumstances:
> 
> I have emacs running in server mode on a VM. I have a windows machine running an
> X server. Both machines are connected via a VPN which somtimes loses connection.
> The issues comes after this connection loss. To reproduce I do this:
> 
> 1. ssh -X into the machine and run emacsclient -nc. Emacs frame opens on the
>    client (windows) machine.
> 2. While the frame is open, I disconnect (C-d, C-c in the terminal that has the
>    ssh -X connection).
> 3. I reconnect to the server via ssh. At this point, the emacs server process
>    has not yet crashed.
> 4. I run emacsclient -nc
> 5. On the client machine, an emacs frame opens and does some initial draw, then
>    the server process crashes
> 
> If in step 4, I run emacclient -t instead, the server process also crashes. I
> can't see an initial draw happening in this case.
> 
> If in step 2, I first close the frame, then disconnect, the crash in step 5 does
> not happen (neither for -nc nor -t) and opening a frame works fine.

I think this confirms what Po Lu was saying: Emacs cannot recover when
you close the connection while some frame using that connection is
still on display.  You should close all such frames before
disconnecting.

> It's not a terrible issue for me, but annoyingly happens every time the VPN
> connection is lost (~twice a day) and I have emacs open (~all the time :)).

Why is the VPN connection lost so frequently?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.