From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66151: 29.1.50; daemon crashing after X forwarding disconnects Date: Fri, 22 Sep 2023 18:07:49 +0300 Message-ID: <83msxe5jqy.fsf@gnu.org> References: <83fs3675zc.fsf@gnu.org> <87ediqpd0u.fsf@yahoo.com> <83ttrm5ovz.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35630"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 66151@debbugs.gnu.org To: Benjamin Schwehn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 22 17:08:07 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qjhlG-00092L-SF for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Sep 2023 17:08:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjhl2-0005Og-R7; Fri, 22 Sep 2023 11:07:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjhl1-0005OR-Lh for bug-gnu-emacs@gnu.org; Fri, 22 Sep 2023 11:07:51 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qjhl1-00041y-D2 for bug-gnu-emacs@gnu.org; Fri, 22 Sep 2023 11:07:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qjhlB-0003j8-Mq for bug-gnu-emacs@gnu.org; Fri, 22 Sep 2023 11:08:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Sep 2023 15:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66151 X-GNU-PR-Package: emacs Original-Received: via spool by 66151-submit@debbugs.gnu.org id=B66151.169539528014319 (code B ref 66151); Fri, 22 Sep 2023 15:08:01 +0000 Original-Received: (at 66151) by debbugs.gnu.org; 22 Sep 2023 15:08:00 +0000 Original-Received: from localhost ([127.0.0.1]:37096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjhl9-0003is-UO for submit@debbugs.gnu.org; Fri, 22 Sep 2023 11:08:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjhl5-0003iU-Jo for 66151@debbugs.gnu.org; Fri, 22 Sep 2023 11:07:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjhkp-00040f-Ej; Fri, 22 Sep 2023 11:07:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6gM/HT8DRZYnX1Cl+D8YAXQBZVMkrGEtI8+F5/1LiG4=; b=P0s3hM8F4Cuj fN5avbJO9Mq2KaDtLH4wb66f9gdl4tcFGMkcn8pktv1mjEXyYMj5EDPUP0PFHgWUP3G+7tTmW56MF m7qCO+Hbhx93HDptvmXj7qUX3GTyrTAp3/N0x5K/8TmsaoRlEG1/Gbu+jlyPwTm+aNeT2m+V/7wAK eYr1D0H/NeQp9pF3OW9FfDEU6BvrvYOtLf2v2NTuDGmUHwEO6NzxHgsMP0RdTt1p6am93zLRZfdbG Tja5QjU5iy/53Ceh+hUPH80IAPmXkjjGmuatbKBNtOME7cpnRarHjEtAx35xj690605ErSi+WZXDl tT7fduZU3b3+ueVeuoFlyQ==; In-Reply-To: (message from Benjamin Schwehn on Fri, 22 Sep 2023 16:28:40 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271110 Archived-At: > From: Benjamin Schwehn > Date: Fri, 22 Sep 2023 16:28:40 +0200 > Cc: Po Lu , 66151@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?