Received: (at 81124) by debbugs.gnu.org; 26 May 2026 13:22:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 09:22:16 2026 Received: from localhost ([127.0.0.1]:60861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wRrjc-0008Fg-3I for submit <at> debbugs.gnu.org; Tue, 26 May 2026 09:22:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35926) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1wRrjZ-0008FA-Gq for 81124 <at> debbugs.gnu.org; Tue, 26 May 2026 09:22:14 -0400 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 <eliz@HIDDEN>) id 1wRrjT-0000LS-Tq; Tue, 26 May 2026 09:22:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=5urlHCPq7HfUOKjXoSLw8KgdXBvkq7M3QeKIjJcMFMk=; b=Qtz0uAKOBB4HKtOIp9Fr krj8LD3tfg/BeQVc6U7T1TVuCli8jFmv6d8+G6Bq0dBj/hLasBkLHL1pVq/lWuo/Or2a1ebjmoK31 Kxt+o/IJRZKQGrZp1EFdlwbhc2cmKizCfbDM8K736cxSu/QMRNIvuZILITwSLFQz/G+Q7K7LU8IoV lXt0C5SS/0Q8QhYkpeG5gGHywDolGBLmHWKzcmox54f8tz8+laNAjZPs63gZb/LTUvQkX40fzFhW7 1ipJFtsEx+eyAVyzQwV2fggzaITHqApRBuhsw7H+cdbrsKhT9eN+SwJ2lnS4zDpiZquNJkik+GQPP 9lQ8aXrOX7MRsA==; Date: Tue, 26 May 2026 16:22:04 +0300 Message-Id: <86zf1mpapv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <c12e2d8b-f88e-437b-ad08-f56c1e8ee3c8@HIDDEN> (message from Dmitry Gutov on Tue, 26 May 2026 15:59:06 +0300) Subject: Re: bug#81124: Making progress with the GTK disconnection bug References: <ac71bd08-bd26-45e3-ab7d-bb0cb5eefcb9@HIDDEN> <86a4tmqra3.fsf@HIDDEN> <c12e2d8b-f88e-437b-ad08-f56c1e8ee3c8@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81124 Cc: 81124 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 26 May 2026 15:59:06 +0300 > Cc: 81124 <at> debbugs.gnu.org > From: Dmitry Gutov <dmitry@HIDDEN> > > On 26/05/2026 15:39, Eli Zaretskii wrote: > > If we can run TTY frames after this event, why cannot we save the > > unsaved buffers instead of shutting down Emacs, then exit? After all, > > the only reason to support text-mode clients is to allow the user to > > save the edits, not to let them keep working in such a "lame duck" > > Emacs, right? > > We could, but I don't know if that's going to be the ideal. > > I could imagine someone who works mostly in terminal Emacs but calls up > GUI emacsclient for certain specific edits (involving images let's say). > They would just continue in their terminal sessions and restart when > it's optimal for them. > > Maybe we could special-case the situation when there are no other > clients connected a trigger a restart? Even then there could be a case > when, unusually, the file on disk contains important unsaved work, > whereas the buffer currently has older or unwanted changes, so saving > would overwrite the former. I have states like that sometimes. > > In any case, I'm happy to let someone else decide the optimal behavior, > but catching X IO Error seems necessary either way. My worry is that by luring users to continue working vis-à-vis the problematic session we will cause them hitting crashes shortly, because the features initialized and set up for GUI frames will not necessarily work when the GUI system is not available. We have a lot of features in Emacs that implicitly assume the frames in a session are of the same type (think all those variables that should really be functions of the frame, and even if there are already such functions, they are called with nil as the frame). Sessions with some GUI frames and some TTY frames are problematic IME, and sessions that used to have GUI frames but no longer can frighten me even more. Of course, if the proposed solution will work reliably, I'll be the first to applaud. But a cautious approach, whereby we start by providing a way to shut down the session in an orderly manner, sounds like a good first step to me, because it will go a long way away of the violent crash we have now. Anyway, my $0.02.
bug-gnu-emacs@HIDDEN:bug#81124; Package emacs.
Full text available.Received: (at 81124) by debbugs.gnu.org; 26 May 2026 12:59:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 08:59:18 2026 Received: from localhost ([127.0.0.1]:60658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wRrNN-00045B-NB for submit <at> debbugs.gnu.org; Tue, 26 May 2026 08:59:18 -0400 Received: from fhigh-a3-smtp.messagingengine.com ([103.168.172.154]:58243) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1wRrNL-00044q-OG for 81124 <at> debbugs.gnu.org; Tue, 26 May 2026 08:59:16 -0400 Received: from phl-compute-08.internal (phl-compute-08.internal [10.202.2.48]) by mailfhigh.phl.internal (Postfix) with ESMTP id 258F714000EA; Tue, 26 May 2026 08:59:10 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-08.internal (MEProxy); Tue, 26 May 2026 08:59:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1779800350; x=1779886750; bh=XJFV2bmyb8ACYnGfBbWS89awQUwfQ8W1ijOru056D0w=; b= p2XFvax5OgiVhjb/Bv7WClEQE8acu2Nl1/J0QsKBoB7SoadQ+j7lfqnurkKlSUb9 bf/FFa6YDXC30NulUZPmes0Jg4S8c6rMTE5wkubZjvTBG7FO3Fbn+LoEmEwVGtOz Dzmu+m70jB2MCSLkZCqjAhDbQ8PonYQM/OsKE3OB5VCWvGw1vJsq/QPFxJQTk8RX mJce961EeEZkL6MaWSim7zEiqfWCz2qojjKnYrwdEX8b8GlZNp7Gkm6xnl2bq3uE gpGv/BtLJrf7ATGUjzwHoNjn/g5lCgfNfndWMybCz4fkV9P5zUpTfYFU5UNAOLSK tYfZZ3J2inSZ7tKNfPctrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1779800350; x= 1779886750; bh=XJFV2bmyb8ACYnGfBbWS89awQUwfQ8W1ijOru056D0w=; b=t ywgZ7q6sgpJACgsHoEVwtVFvugXCY3CUKoxsDfwmCu5kI2MIVWo/94CBXmKmwpez BTd9SaZtS+wBe4O2VhVm9hWOMpeEn//3Nje4+yAUyJL1Aewiw1ZbAxUegWtmDUy3 5Kj3hoRIFMmm+a8xYx5CyMM6owiSuI4lU79Zoz9I1EEnnNPQBjnPDSGz+9Rc1DfK cnM5gxhl5UKz8uhi9HbJqZlTsb7iTEWrdzZ5kr1cXkIoUjrrRvaeyqPdq0ytDAjG JHRPRQSxF52r+y+Gtc9vF/Q78jL5QadZR5zvqqb1Cbe1kdmoXP3z5rX/3RRdOO3A +R8ND23nwtoejxHrbkXsA== X-ME-Sender: <xms:HZkVasRXbs9jDiA_8mVKU_z5Zn9nPgr7KHdVxKzYVwE218wju1lQqg> <xme:HZkVavwVGS7l4MIDmDTQNpdeeO1VHEYo5T2gMJoqP2wRi_6zab3DlEg4q0yj6oA8p JVB7Rm8I2L_gSc-mCHHhoDmNANfuCD72Zp1xSE7Ez8HGzr9ZHXKZA> X-ME-Received: <xmr:HZkVane6ByuMO5Ry-g4_QaCV4l2nEo-GLfoe9uGc4nq9IvgobJ4rsB3D5hO-63N__5R7> X-ME-Proxy-Cause: dmFkZTFvmGlpio6cNd5AhVrkMxMdDvVgpjdLKb/PzOjchm03QaeOa7dZSxe8nph4ZZXRCV PaU+T1qNHM2uex9gpl65Mif1TIShxrXMYsCzqK+vgmUQXvMJjBwKfQRxFhWYjUoRYcjo9D 4Ibfq1475q2k+evTNYR9vGbdDnzQEYNVl/pF/HqTladp7dJ4N7Qkfj30d9msUJoBO5/Fpl jnrHW9VpKC1QccDPVCqAcLuWnNpKQOdf7kGi980v+C1upvRSwjkXD+nY74ztDF360tK5yu gF3UpKwlOSRMRaHoFuVKPvPNRgMgGyA8JgOxT6qVDgg+YJANUAwUDKjha2s8rSaqRLildo GA2bjQE7HcQztfiNLqSMZo7x7X8rf1tZBrmg20JrVruY6pvL5GbShk38WCv8UU4M+j6FKE c41AEI+Xfb+/xoU4uCTdFOWWepq0VUpn9FzhK7PH4L+SyoJXb5EXIgLbxs0ycrfbRKRH1e urE7lkmDilikO10AjSggYTSEuMi3jpK1FgNet9gd53ADk2G1qqRG8pPsC4rnlvUsUhK1VO F0fs/XsL0csWtvcikvd0eUd89AHbC+31HmSUMLqADEyTG0U4a8dnqnOvIHXj0LjZYX6g/k f/FCs3Ezx+7RNntpNkHCK4q3RVEP8afpQF2E7mQfCgWXgO4B2wTcnIWLpCpQ X-ME-Proxy: <xmx:HZkVarKXX4Od6gYCcwAfimJZSt10T5mrSNpr5snK04p2vWzhKX4OZQ> <xmx:HZkVaoEA3O-GFniuYNDPzkfaTQMMc7DVNgAKgt3S4mG_rqK-Yg38TQ> <xmx:HZkValoIpLu66WEgY8xt6emHQ_BBADaVBMfM-xYnicAKhM2IUnCXDg> <xmx:HZkVahQd5d7qqWMykADgiZkZX7TrPWQSPYnJNJ3CaSe2j7g3PLkoWw> <xmx:HpkVagkHuQXlcm58LtKxAIWhruw2kvlh54swqabt5IukAx-jCmL4yYoc> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 May 2026 08:59:08 -0400 (EDT) Message-ID: <c12e2d8b-f88e-437b-ad08-f56c1e8ee3c8@HIDDEN> Date: Tue, 26 May 2026 15:59:06 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#81124: Making progress with the GTK disconnection bug To: Eli Zaretskii <eliz@HIDDEN> References: <ac71bd08-bd26-45e3-ab7d-bb0cb5eefcb9@HIDDEN> <86a4tmqra3.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86a4tmqra3.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 81124 Cc: 81124 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 26/05/2026 15:39, Eli Zaretskii wrote: > If we can run TTY frames after this event, why cannot we save the > unsaved buffers instead of shutting down Emacs, then exit? After all, > the only reason to support text-mode clients is to allow the user to > save the edits, not to let them keep working in such a "lame duck" > Emacs, right? We could, but I don't know if that's going to be the ideal. I could imagine someone who works mostly in terminal Emacs but calls up GUI emacsclient for certain specific edits (involving images let's say). They would just continue in their terminal sessions and restart when it's optimal for them. Maybe we could special-case the situation when there are no other clients connected a trigger a restart? Even then there could be a case when, unusually, the file on disk contains important unsaved work, whereas the buffer currently has older or unwanted changes, so saving would overwrite the former. I have states like that sometimes. In any case, I'm happy to let someone else decide the optimal behavior, but catching X IO Error seems necessary either way.
bug-gnu-emacs@HIDDEN:bug#81124; Package emacs.
Full text available.Received: (at 81124) by debbugs.gnu.org; 26 May 2026 12:50:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 08:50:57 2026 Received: from localhost ([127.0.0.1]:60551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wRrFI-0003dW-JX for submit <at> debbugs.gnu.org; Tue, 26 May 2026 08:50:57 -0400 Received: from fout-b8-smtp.messagingengine.com ([202.12.124.151]:39959 helo=fout-c8-smtp.messagingengine.com) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1wRrFF-0003d4-M9 for 81124 <at> debbugs.gnu.org; Tue, 26 May 2026 08:50:54 -0400 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id D96CC1D0011C; Tue, 26 May 2026 08:50:47 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Tue, 26 May 2026 08:50:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1779799847; x= 1779886247; bh=8JGhphN8Q1wB35lkRNt+djUv6n0Hag9gPhqEdIWNDzE=; b=n 4UMQN8fLpNfvgocDRWi/9vdHNZZV5HQvpRj6tjpMOhnwzV+NqzQ3OutR7C5lfkTh AO3yl1Mo0B/AK4Ifib4HaAPtE9uDNDpKX5hS94DHZdfUo5IaP7Nqu4ewG1ZbO+75 F+pe8AHY4s6TsVNaab1/4clY+VyWhw4IHHSm3Kiy+hpRaFMMf68YktOSF93L1NC9 7FCT9AG9a+b4aWlRXJ3ELyN1oFAwQ8mEfNA87tKGsdalihKKSU8ZTjXcMocMjism Rm4kezKKwf3EAYmlYGQyGluFQccjMwHTH925wnq2t9CxG10HY80mEGHm/WrsveF3 /0UgzFzq+uXZglTWC1vtg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1779799847; x=1779886247; bh=8JGhphN8Q1wB35lkRNt+djUv6n0Hag9gPhq EdIWNDzE=; b=nOrVbQ5M5NNBv6eGwAf3Y4U8JNm8bGp15oWYPWdjAKq+rnZ8/Xy mmIKjsKJL/M++9EyyStky811maxTrgfVMXRFiFyWO+P3xiDxSm+yxwiyOjxOAEs/ hLkxCdZtwTvIPEg1ACeZoktM7kTtHRrSM1art7Mbjlcou6BgnzQoKuZlS3TY2y13 X24X6kFA9HQzG+l3VpVp4McYdHZ20eCfjXHbv6NMQmTtlXAu/4LhdiErMGPc8B6F xEh7lJk5CLLrfo4UgArgaBzUVe06sumRS7ZL3JvccGlczGYpskBXvacwadWwj8pY k5gXGjIySRFdbzInn/VK6J+WtLrCCDpNXXw== X-ME-Sender: <xms:J5cVamdMh8SK01CxunQT_LpY1hIc3APl_Pzu2bMb9TEppZ95TyMI5Q> <xme:J5cVanoJBq-TRP9VoF4DHQ0IABs3tEaWvg9_LUhuFpGnVZvP8JypY0zoc-rnSf4lU IrTilB96Opksr9pjzppx2OdD13XXjzowu5HjGMFcOTA9sct_EfwhOw> X-ME-Received: <xmr:J5cVak6tC6_0ZnKRybbh_H7FYvZ0O4h5ILrU2Lr-G-Uyg3H8rSzzQTO8LViGfdtFGvl-hxU9GQBl> X-ME-Proxy-Cause: dmFkZTFZ9Y4aseINRwqtsh98NJ4/FCOhEvXzMDaJ4IU4TC/e7x+/ZP7JLOetzQlX0J3F6e Q7hf79Ct8LKu9ckKXM4EPe7c3B2hFu0xbKZWrfRbyMbuEMzbGkUD0qRREvv2VjNIuqcJa9 Qt330ZMbaUNUtOuEEzl5tDv2BYSJXQSPoh1Dx67FEDvYN7wtrmEOA+OU9qrI0+wTbhyQnU pGDC6NzJHJs9R7QGhCwAHh1bZuKKlkCjCHnKPsXJo8LACG6zTmNcr9XZviYUvqzTPOJH+6 Wr+AdkWqI1MZ+dX//DNaGxzXq7ibGfg/cBoSXzmXa6b+JipdCuF49/rehOW+QeuThBcvqZ nT1BKmmGzpMr3p/7QjLiD9j2ePMzVSoHlYELE5mLgPjPO3vz1xqhB6KsyicZNZmY7mwBzV GkzW6fsGf4Gv70wV2avGRWvZ3ifbZWiyL385g1soP7BzR/sUusAS1Heq5S1vGs5cP7v+XE RYE9PAouydGUO9gPtJG9G3S/2l8qEUbev1CIeFgrPuGnOSzx2Dv3aaIeJKpfmFwUHo8r6l GFQbQ6UIAdrMuKl16yv1/aZ/r1eJLtDpyqQPxcwklfOJWJMGFnRiXTm7CwRjFX1FGt4Qo4 phcddSoquLi2pqbjmQ5tFgkkQDdTBG2tkg7BDJeNPNapCIzmy64ls//APV4Q X-ME-Proxy: <xmx:J5cVatphX1a0uQqbFs_6p-zXV26H5noa3-fGGl8SI-nmeILgR9caaQ> <xmx:J5cVamgB4COSTZ6dpyg1u46CssacDUrUMeMfgjM5ujYRkXrKNWP1dg> <xmx:J5cVanKKFQ52nuiXtULKhxnmBsomHw1Y7I1fHoIZY-WKANUGmjMkBg> <xmx:J5cVamBoeURGC4lHc_RevrU7I_5USdnlKgks2-NP6dRn4Q6hHkGfNQ> <xmx:J5cVarDMxogngi8HObaU5DhfAkPWCc8m0VVaMgoLBqwM671cE3eJK6Qg> Feedback-ID: i62564b17:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 May 2026 08:50:47 -0400 (EDT) Received: by melete.silentflame.com (Postfix, from userid 1000) id 4B2227EA950; Tue, 26 May 2026 13:50:46 +0100 (BST) From: Sean Whitton <spwhitton@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN>, Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#81124: Making progress with the GTK disconnection bug In-Reply-To: <86a4tmqra3.fsf@HIDDEN> References: <ac71bd08-bd26-45e3-ab7d-bb0cb5eefcb9@HIDDEN> <86a4tmqra3.fsf@HIDDEN> Date: Tue, 26 May 2026 13:50:46 +0100 Message-ID: <87ldd61gih.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 81124 Cc: 81124 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Eli Zaretskii [26/May 3:39pm +03] wrote: >> Date: Tue, 26 May 2026 10:17:21 +0300 >> From: Dmitry Gutov <dmitry@HIDDEN> >> >> So I've tried some experiments in several directions. A good news is one >> seems to be working out reasonably well: being able to forestall the >> daemon crash using XSetIOErrorExitHandler, and then prohibiting more >> graphical clients from connecting, upon which they can gracefully >> degrade to using the terminal (-nw clients continue to work). So even if >> one prefers GUI Emacs, they can connect and save their current work then >> restart the daemon. >> >> The bad news is that the code implementation is LLM assisted, so I'm not >> attaching it here, but I'm hoping to provide anybody interested enough >> information so they can do a cleanroom implementation suitable for >> installation. The total length of my patch is about 25 lines discounting >> the comments, so it shouldn't be too difficult. > > If we can run TTY frames after this event, why cannot we save the > unsaved buffers instead of shutting down Emacs, then exit? After all, > the only reason to support text-mode clients is to allow the user to > save the edits, not to let them keep working in such a "lame duck" > Emacs, right? I think it might be nice to support both. By default we can do some sort of cleanup where we save all buffers, but someone might have cleanup that they can only do manually, in which case being able to connect in text mode would allow it. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#81124; Package emacs.
Full text available.Received: (at 81124) by debbugs.gnu.org; 26 May 2026 12:39:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 08:39:38 2026 Received: from localhost ([127.0.0.1]:60438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wRr4M-0002rQ-23 for submit <at> debbugs.gnu.org; Tue, 26 May 2026 08:39:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43792) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1wRr4I-0002qn-0X for 81124 <at> debbugs.gnu.org; Tue, 26 May 2026 08:39:34 -0400 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 <eliz@HIDDEN>) id 1wRr4B-0003sa-LG; Tue, 26 May 2026 08:39:27 -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=uDhmlkkEhPamvN0owW0JzGsU3hFcbboWnqOJhq5+U+8=; b=SrI8Id56/VAM CgHm7IAy4OGVWJqZjeI6ivcLw1TiKescD6TNJgKvAeSaXuCYdd82GVvKDM/ttO4RaE7bNH+Y1J+X4 1AJXzlxlx1oINaVo9Sl5OUXpZnaDYaQ+vsAdoaWYFs0ay57uJoo5J9smG7RdJ2stwbecY7xFV5hoJ ytMzfWwkcI8lPWkMDSmLObfZ/NJQnvovDw4Hhb27SVFGwpCMiIJ3w3fKvJqT0JZ94VSgZFTpMQohr 05Hge7kwIlHlmMaNCzXlUqk1g2+qQD0Cf7ylqAkMGgNCLwDLHxWWLtN7hYbYBshVgmWfHS8YCF02a LFV6ES4HkfpULhYcH56LMw==; Date: Tue, 26 May 2026 15:39:00 +0300 Message-Id: <86a4tmqra3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <ac71bd08-bd26-45e3-ab7d-bb0cb5eefcb9@HIDDEN> (message from Dmitry Gutov on Tue, 26 May 2026 10:17:21 +0300) Subject: Re: bug#81124: Making progress with the GTK disconnection bug References: <ac71bd08-bd26-45e3-ab7d-bb0cb5eefcb9@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81124 Cc: 81124 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 26 May 2026 10:17:21 +0300 > From: Dmitry Gutov <dmitry@HIDDEN> > > So I've tried some experiments in several directions. A good news is one > seems to be working out reasonably well: being able to forestall the > daemon crash using XSetIOErrorExitHandler, and then prohibiting more > graphical clients from connecting, upon which they can gracefully > degrade to using the terminal (-nw clients continue to work). So even if > one prefers GUI Emacs, they can connect and save their current work then > restart the daemon. > > The bad news is that the code implementation is LLM assisted, so I'm not > attaching it here, but I'm hoping to provide anybody interested enough > information so they can do a cleanroom implementation suitable for > installation. The total length of my patch is about 25 lines discounting > the comments, so it shouldn't be too difficult. If we can run TTY frames after this event, why cannot we save the unsaved buffers instead of shutting down Emacs, then exit? After all, the only reason to support text-mode clients is to allow the user to save the edits, not to let them keep working in such a "lame duck" Emacs, right?
bug-gnu-emacs@HIDDEN:bug#81124; Package emacs.
Full text available.Received: (at 81124) by debbugs.gnu.org; 26 May 2026 08:52:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 04:52:36 2026 Received: from localhost ([127.0.0.1]:58552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wRnWc-0003SS-Vp for submit <at> debbugs.gnu.org; Tue, 26 May 2026 04:52:36 -0400 Received: from fout-a7-smtp.messagingengine.com ([103.168.172.150]:56049) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1wRnWY-0003R6-1P for 81124 <at> debbugs.gnu.org; Tue, 26 May 2026 04:52:33 -0400 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 94944EC00D2; Tue, 26 May 2026 04:52:24 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Tue, 26 May 2026 04:52:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1779785544; x=1779871944; bh=7rMxxHxVX+ 1tP/e7aIeC7crdM3TnS3UGq3OnrFYDj7Y=; b=km9nW2FWF4HdQ0OBfjehoCAN2L bHsYSAk6RlTftgL1yYFPvipk3b8Sy6ZZOZsNJ4KX/W5i58ZqztY/TpA/51bNO9Mn xmj7u3KAFFK3+SHLc5wnB5Q76WZrpv01XbqNx2WQiFLHp0M2X8SwTEZuSj4z2Ajm 15tHZBNLlo7ozztQltOXPbxn6p+v1DU9aNIxKfWxDD073r1cFQXjZDnJ/IvxQleb AraH4Z+qfXxUrxddWDCM+lOgb50YXNif0fpUR43dRrWXJIg+yPPY8lLo9urHfUE1 gia2k6HxLbMyScnt/lQWzQHITcveB1jpXhA/cyJU4V7Ezk3jSBRNGnE8A/dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1779785544; x=1779871944; bh=7rMxxHxVX+1tP/e7aIeC7crdM3TnS3UGq3O nrFYDj7Y=; b=Hu0AfLLLnNeU6X/sYjiRViZ4zPX/RiirHkNnLl3wAIOEczFX1ip E3SqWT9+FPXR+xEgfEuFOvQVfF4xC/SO0+PnNuTiVnOgGO0aVVSjQ+PpQS3rav+i Wo/aVj3FwkBWV0IrZRNqxx3VAuMN+IvuhY10j5KtTgRwXKwcbAkDsQG8UkRpchS3 hyOmuznEw961kWoZtlUEQsQi6SyfvM/SxP19LBY5snV5wT5ACbDoA/+nY1nEm7um L3YpSAMvc1Y23HhmSqINvpgzpdzMCZh2gVTwpWMvzUW1I+MS+hVG9cEBw4CnGfam eAZF3b1yuSQPuXyvLAwkbaZVBol2j+sqxPA== X-ME-Sender: <xms:R18VajsriHTJ0wJ5hHbsPQ49PdMQ7YwL-LUVGhQYdMmY3taCRqoBGw> <xme:R18VaqcJydEPwKpwfhmG4_JiJQNwTWkk28zYlbme4_rElo9uewg4Nu6PsZ-sY0X5d DtrVCwlajYbD2nEuqWTf_BCx5irUOBAqPM4Cd7C9YNbmF8tgR8p2Ew> X-ME-Received: <xmr:R18VakYcgt1ELreZHA5R_yDvI3bNzjw5LgAW44TLMFFCW7WQsRos0uRxUHH0dRGkepmrd0FOaygf> X-ME-Proxy-Cause: dmFkZTFS0hW+rqB6KKGm3LzuXC38U7qXJtFWYKsABONn0WZegRWGyji31BYWf0Px2HEZgf 05WQwz7Ist9AWUh0i5yPrYiAr9ZOWDQMTgQbadoO/mK/HY4FyjlufUU8UbNJ4sYPloVA4E CZzJmr1ECHsPobKDxUiirGnKXo2QxhE0q1jcInUG+NeKsyZpaGZzOzYMF+6t1EvwG0PBIQ TqPW3c7pnF4VoHVv8EU0R8GleSfSJT9YHtSjCfHj5p0ua3sQpFkgLmNPnIg1IB16kaiF36 AnGDA1xsayDuFQjirK/exPMJamwwCJyrPKD6zm/Pa52YEipUlQJwvx+BcdG+SDSJgoWUJI UtUb/VDCjD5QJKBzospfcOG4OYjQKi7DbiHFDnDvg5z089pFj6myj3J90LBzhc1AvVph8+ gXoMmN4EgNMKkc6v+Ly+OpQV766aRCxv9Lewb5DiqLUhvPGktx3I8dASq/8FKt3u3WLiSA mFj4OrVut+Qu9g16pG7143KKNtiA1DBz1EVkwve4s1NRSkx3gJslqtzo0l0jBIqvbJsDjC K+lttOZOvCNE8+VcS+whsn4YCPA6wcbgwDNg1CglOw32oirLomSy0dSM1AZ9s/ls1dweh1 VXtVd7dG1oQNUXHPTACnyPX55VlpCW49HoV3d+BVkg6+sxqLKilVSn1ZPXJQ X-ME-Proxy: <xmx:R18VatU2LyLyH5aq9IvuYSoH-HlqhCLw05Ip8FH0QkifvYrHeoR6Hg> <xmx:SF8Vamg0gCUT_dw3ThLWlViJ_-6AqS6rA-b5XhO0myZn_v47oWuahQ> <xmx:SF8VarWrI0RyFAmIRLX40AsbtIpEag-SU638D0Cjg1o_w9i8Ld57AA> <xmx:SF8VatNs5SuguE2kzw2YgpF84FjUSWHZdlj9nfNoL8JnVbSLlVGoLw> <xmx:SF8VanRLkXvqyICrP6XM8NPiT8kuTZxY_jSgsoangr55XwvYlrxvjnDj> Feedback-ID: i62564b17:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 May 2026 04:52:23 -0400 (EDT) Received: by melete.silentflame.com (Postfix, from userid 1000) id 067FD7E7288; Tue, 26 May 2026 09:52:23 +0100 (BST) From: Sean Whitton <spwhitton@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN>, 81124 <at> debbugs.gnu.org Subject: Re: bug#81124: Making progress with the GTK disconnection bug In-Reply-To: <ac71bd08-bd26-45e3-ab7d-bb0cb5eefcb9@HIDDEN> References: <ac71bd08-bd26-45e3-ab7d-bb0cb5eefcb9@HIDDEN> Date: Tue, 26 May 2026 09:52:23 +0100 Message-ID: <8733ze3648.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 81124 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Dmitry Gutov [26/May 10:17am +03] wrote: > Having gotten into the toolkit code lately, I've wanted to see whether > the core problem (daemon dying, clients not connecting) could be solved > using one or the other approach mentioned by GTK developers in the > corresponding issue threads. > > So I've tried some experiments in several directions. A good news is one > seems to be working out reasonably well: being able to forestall the > daemon crash using XSetIOErrorExitHandler, and then prohibiting more > graphical clients from connecting, upon which they can gracefully > degrade to using the terminal (-nw clients continue to work). So even if > one prefers GUI Emacs, they can connect and save their current work then > restart the daemon. > > The bad news is that the code implementation is LLM assisted, so I'm not > attaching it here, but I'm hoping to provide anybody interested enough > information so they can do a cleanroom implementation suitable for > installation. The total length of my patch is about 25 lines discounting > the comments, so it shouldn't be too difficult. > > If someone wants to test and verify that it works, I can send them a > patch in private, with the understanding that they won't be the one > implementing the upstreamable change. > > And now for your attention, the free-form description of the > problem/tradeoffs and the solution's details. There is more (other > things that have been tried, for instance), but I'd prefer not to > overload this thread right away. Thank you so much for this, and for taking care to ensure that it's possible for someone to write an upstreamable patch. It would be a big step forward on this issue to keep terminal Emacs working, and who knows, this being implemented might help someone figure out the whole bug somehow. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#81124; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 26 May 2026 07:17:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 03:17:48 2026
Received: from localhost ([127.0.0.1]:57979 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wRm2p-0004US-C2
for submit <at> debbugs.gnu.org; Tue, 26 May 2026 03:17:47 -0400
Received: from lists1p.gnu.org ([2001:470:142::17]:51276)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1wRm2g-0004Si-Tx
for submit <at> debbugs.gnu.org; Tue, 26 May 2026 03:17:40 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <dmitry@HIDDEN>) id 1wRm2b-0002Jp-5J
for bug-gnu-emacs@HIDDEN; Tue, 26 May 2026 03:17:29 -0400
Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]
helo=fhigh-c8-smtp.messagingengine.com)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <dmitry@HIDDEN>) id 1wRm2Z-0008P7-1p
for bug-gnu-emacs@HIDDEN; Tue, 26 May 2026 03:17:28 -0400
Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42])
by mailfhigh.stl.internal (Postfix) with ESMTP id 910347A0157
for <bug-gnu-emacs@HIDDEN>; Tue, 26 May 2026 03:17:24 -0400 (EDT)
Received: from phl-frontend-04 ([10.202.2.163])
by phl-compute-02.internal (MEProxy); Tue, 26 May 2026 03:17:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:content-transfer-encoding:content-type:content-type:date:date
:from:from:in-reply-to:message-id:mime-version:reply-to:subject
:subject:to:to; s=fm2; t=1779779844; x=1779866244; bh=byCMYqqVD1
KoK7DU/cdaWuGDNgfOVFPgCQBG92XcGww=; b=YXs0k5pnj4zWpXgeW+pmP5sZIM
ipLngYDrfoLA8S3FbZmYlXS1fqwQBKrZRN9XFTGLP0o/iPQ3QnC4EsKj7R8K7MHF
EZol0UAr+BrPOWJMNCz1X/j9Nox8ZKlKw95ECBWw1HyfQLtqAwmP+4fT5HWjA88k
eUf58QWw+8sCDjiCmdJHkwjHimohuOmCVCLi6uiBWR8M2k3N+YG6tvtl8hAUc3dR
D9FAfXNOnm6nOwsZ3f/PHat6crHjSvtvkdargk3lxUjNfKB4CRbPA7v4tFkS+fzo
tLeUcwtvWWhhPH6ChsRdpYZ0cAn/83JDddnZgd/TTf47LhfUiCmB3z60LTAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:content-type:date:date:feedback-id:feedback-id:from:from
:in-reply-to:message-id:mime-version:reply-to:subject:subject:to
:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
1779779844; x=1779866244; bh=byCMYqqVD1KoK7DU/cdaWuGDNgfOVFPgCQB
G92XcGww=; b=TwLWnuaofgyuZjs2i0ItdAhGvNDWUqCIpZR6bZD9hl98IkXxENn
OfJMd6t/W5iskw0smbfbDEnPd5ramMDWfh57yAccRLEeQaRTjXn8RIxA5cy99tae
rHrsJlXNJjNTEhIAZ0AAN892UEPoE2iPEjENt5h++85lSmC+QJZBmjFLZj/pYxL9
BAG2P/jGwR0MwMXMMDfv8A93KzjuLqXWjEWXUkW2mSxwRDTPRWjvSBCCsvHLtndh
IiKpgcpWSPCRptzwqNlzL1YEnUZ/pu3QWwTQV7kUjj64Zv4csLJ53O4GTAu5EBor
q1OOtMaIiDCEdeEYce1kJcFVTbb06xwb8CA==
X-ME-Sender: <xms:BEkVarR7uN5G0oH0CyEsp3X64GIyzAzyRKv2A-KVDcMNW8vbQKhXMA>
<xme:BEkVair1PSgU7CRNI-hZa_KnIndDrop9MMzU2lQ5k7lrYhbQqcJ5ozbLiPi-1eOGm
DVjd0Ty0vBwx8IZsWyeT13DlpVMHMQMRzQwpLaTPCjkcmqJDZ8YoMc>
X-ME-Received: <xmr:BEkVar7rDUTMqlo_QDne0T5z7WdD5BUO83z__tS45ENTki_1vdyyRuPy1byOokepq2JW>
X-ME-Proxy-Cause: dmFkZTGyAXdR0qNxDKaHA4uPozTSXrlIDzN6VNOddAGRVh8cemjPWJlAIYP01/QMfrtvpX
0nvbE72fbOWqUKXgeKlT1XxnRdxfzpgrXhs9Htl6WsQgxvJuS+p3p3la0DubjFewitd2EE
tp9FygV/1hLmtvM/STKharNptv1xeg1KGeBQvbuqTbVFCnPjA060rGsfTiMjHE6dEOhQQX
b4/f2g+4aqHBNC5i0TlIztkJQhCDJjC90JufW3l0gjWjnfnDg1HFkjcbhnKW5mMiGffrUs
wlod2ajQrSaMEiY0cd7WpfkGWk3BMJLu90Mol1cbgC7BT4cyRoTfr5CyaK+OOdMkE/LAbH
804JAqzhObvPD49NfKP1ADHOZWuk5vnS1jLBIC6yYE/M77jU/26jvqjJSwQPwAE07DlLsB
XEL4oSLwAWR8hiOyeFKaG6uNjXQ//ImjritynFmYn0l5wyoSggoHqC/GG/B34WUlvzFRGc
AKlIQD/3XcIDuPBprU1Lt4lHV5Wdy8Rkt7/RE3z8sgT7Kte5FvwasLEjMc4ZsaiBkVEKA6
Stpkop1ZarugiOPATQ6ddL36bWztwy7k0zHLIu6iU20LJzyNfNwruXSEHdJ61oUDIf/F6s
VLKDpzazLDHiPjyE3Okirkrpq6eV7713nvg1chGlDqsT63KIj02qkF1VMFSw
X-ME-Proxy: <xmx:BEkVan0ogjm42UOPDu34_i_dIn90cQZacUVb-mUR640iVIRC7j-GUA>
<xmx:BEkVaoH2KaKdT8ZWo3IIAklJZcT3LiOOtOO0UBWa6phRYF2Z3YJwXQ>
<xmx:BEkVahRct0RA9Zq8n1okAdkcxVl6RVHcZcCLvNEZ8jnuQj6KGhgFAg>
<xmx:BEkVavAhYdpeQ41ih7Sjh9yUWtEF3Tgkzxww8hgm8tt-W2Ly4LNwsg>
<xmx:BEkVagiUWTFXklMLApokQcwZ-sAubJHzY5EUpPDE9MQDaRqc7F5juJgG>
Feedback-ID: i07de48aa:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<bug-gnu-emacs@HIDDEN>; Tue, 26 May 2026 03:17:23 -0400 (EDT)
Message-ID: <ac71bd08-bd26-45e3-ab7d-bb0cb5eefcb9@HIDDEN>
Date: Tue, 26 May 2026 10:17:21 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: bug-gnu-emacs@HIDDEN
From: Dmitry Gutov <dmitry@HIDDEN>
Subject: Making progress with the GTK disconnection bug
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=202.12.124.159; envelope-from=dmitry@HIDDEN;
helo=fhigh-c8-smtp.messagingengine.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.3 (/)
Hi all,
Having gotten into the toolkit code lately, I've wanted to see whether
the core problem (daemon dying, clients not connecting) could be solved
using one or the other approach mentioned by GTK developers in the
corresponding issue threads.
So I've tried some experiments in several directions. A good news is one
seems to be working out reasonably well: being able to forestall the
daemon crash using XSetIOErrorExitHandler, and then prohibiting more
graphical clients from connecting, upon which they can gracefully
degrade to using the terminal (-nw clients continue to work). So even if
one prefers GUI Emacs, they can connect and save their current work then
restart the daemon.
The bad news is that the code implementation is LLM assisted, so I'm not
attaching it here, but I'm hoping to provide anybody interested enough
information so they can do a cleanroom implementation suitable for
installation. The total length of my patch is about 25 lines discounting
the comments, so it shouldn't be too difficult.
If someone wants to test and verify that it works, I can send them a
patch in private, with the understanding that they won't be the one
implementing the upstreamable change.
And now for your attention, the free-form description of the
problem/tradeoffs and the solution's details. There is more (other
things that have been tried, for instance), but I'd prefer not to
overload this thread right away.
== Goal ==
Survive X disconnect under GTK; degrade to terminal-only
When the X server connection dies (xkill, server exit, network drop)
on a GTK-built Emacs daemon, the process used to abort unconditionally
(shut_down_emacs + emacs_abort) because longjmping out of the IO
error handler corrupts GTK's GMainContext. This patch lets the
daemon survive the disconnect and keep serving terminal (emacsclient
-nw / -t) clients. Attempting `emacsclient -c` after the disconnect
falls back gracefully to a terminal frame with a one-line warning to
stderr; the daemon must be restarted to open new graphical frames.
== Background ==
Under GTK, the IO error fires from inside g_main_context_prepare
(GDK's display source prepare unconditionally calls XPending). By
that point GLib has incremented context->in_check_or_prepare on
entry. A longjmp out of our IO error handler skips the matching
decrement at prepare's normal exit; the recursion guard then stays
> 0 forever, and every subsequent prepare/check call hits the guard,
refuses to dispatch, and spins emitting "GLib-WARNING **:
g_main_context_prepare() called recursively..." -- effectively a
dead daemon at 100% CPU.
== Design ==
- Register XSetIOErrorExitHandler on display creation (libX11 1.7+;
configure.ac adds the AC_CHECK_FUNCS test that defines
HAVE_XSETIOERROREXITHANDLER).
- In x_connection_closed: when ioerror is set, call
suppress_xg_select() and set the file-scope flag
x_disconnect_recovery_mode. Do not call the matching
release_xg_select; the suppression stays on permanently. Once
suppressed, xg_select bypasses GLib and uses plain pselect on the
fds passed in, so the dead X fd that still sits in GDK's GPollFD
list is never fed to pselect. No EBADF abort.
- Under HAVE_XSETIOERROREXITHANDLER, do not call the legacy
in-place error() at the end of x_connection_closed. Just return,
so libX11 reaches the exit handler. x_io_error_exit_handler
itself longjmps via error("Connection lost ..."); the longjmp
happens from inside g_main_context_prepare and corrupts
in_check_or_prepare, but the corruption never matters because
nothing in the surviving daemon will call prepare again:
* Daemon has no X terminal in terminal_list after
Fdelete_terminal runs, so gobble_input never invokes
XTread_socket, which means gtk_main_iteration and
gtk_events_pending are never called.
* xg_select is permanently suppressed, so its own
g_main_context_pending / g_main_context_query calls never
run.
* Terminal clients use read_tty_input over plain pselect;
no GLib involvement.
- x_term_init checks x_disconnect_recovery_mode at entry and
signals an error if set, refusing to open a new X display. This
prevents any new GdkDisplay setup from driving
g_main_context_prepare and tripping the poisoned recursion guard.
- emacsclient prints a one-line warning to stderr when it receives
-window-system-unsupported from the server and is about to fall
back to opening a tty frame. This makes the failover visible to
the user instead of silent.
Dmitry Gutov <dmitry@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#81124; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.