From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#56528: 29.0.50; Emacs lucid segfaults when X dies Date: Wed, 13 Jul 2022 22:50:30 +0530 Message-ID: <871qup7wv5.fsf@gmail.com> References: <877d4h1vl9.fsf@astatine.mail-host-address-is-not-set> <87ilo1uw9d.fsf@yahoo.com> <87sfn5l1c9.fsf@gmail.com> <87cze9urzv.fsf@yahoo.com> <877d4hi2lx.fsf@gmail.com> <831qupw3us.fsf@gnu.org> <87r12pgn80.fsf@gmail.com> <83zghdunq1.fsf@gnu.org> <87mtddgkp9.fsf@gmail.com> <83v8s1uecy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39556"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: luangruo@yahoo.com, 56528@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 13 19:21:23 2022 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 1oBg35-0009xd-PJ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Jul 2022 19:21:19 +0200 Original-Received: from localhost ([::1]:50704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oBg34-0000b6-Fg for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Jul 2022 13:21:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBg2o-0000ae-F2 for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2022 13:21:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53769) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oBg2n-0004PI-RS for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2022 13:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oBg2n-000299-Nt for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2022 13:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Jul 2022 17:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56528 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 56528-submit@debbugs.gnu.org id=B56528.16577328548217 (code B ref 56528); Wed, 13 Jul 2022 17:21:01 +0000 Original-Received: (at 56528) by debbugs.gnu.org; 13 Jul 2022 17:20:54 +0000 Original-Received: from localhost ([127.0.0.1]:47666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBg2g-00028T-8Z for submit@debbugs.gnu.org; Wed, 13 Jul 2022 13:20:54 -0400 Original-Received: from mail-pf1-f194.google.com ([209.85.210.194]:45773) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBg2d-00028E-6B for 56528@debbugs.gnu.org; Wed, 13 Jul 2022 13:20:52 -0400 Original-Received: by mail-pf1-f194.google.com with SMTP id y9so10781264pff.12 for <56528@debbugs.gnu.org>; Wed, 13 Jul 2022 10:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=jyaYrGm8RtpAs4LNd8YkEzYWcitxFeG6cZhVLau4gmI=; b=SViIva7amLoY80FvNsI0FrHu8m/gqSVlxHQp0ewsUgMvsZbBzciGSpswdjbrWe0ath mXLWIw8seMnPevaDmUH60gNULoE8I8NyhDJlNhufrW1Ftgy4usvvs2vRK78u0O/l8kyD VAd3g3xL795z4iDntUpS2Wk5y4o5ABoWIYOiq/140c0NIJyVUZEnmSsA8Zq2WUIK27Uf kda9pnEV259U7IRqtPtKtBeuGxbmUtLjg9QkQgDqgbNuf/Re6Va3l4/hALdo/kswrNuH ustNMxecB8BlWzPSzBNlzomnnHNJslbyaG/XELlSE9vlxbttKEGZXmMSBlB2ce3CMc7H dpbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:user-agent:mime-version:content-transfer-encoding; bh=jyaYrGm8RtpAs4LNd8YkEzYWcitxFeG6cZhVLau4gmI=; b=R19jQvrND92au1SLUZZlgRgWN/mLGg+JwrhoSCCK0Qb25zoyeSWAHA/jLfxR2fgYhH sZO9bmCrTzursOcVdVhiTpc1Cya/8jp6sTJKX7NRbkq1eCNIDCWqbDXwfCijisLrLJmY yhatsDhkUpMYEi7Kli5T3RywP8HwliX6tdiraykwXiH+QVJFIBcAEqXYSP9QJzsiOyBw eG3+siMK3fOeBsJKCD/8CnQu3em7A3Pc8106lxzB48lAOrrZt/8uRoTvui3FMisBj6B5 5+0aCwrxAQ5/w8vTgs0S4ygRfwf6LuYVsTDGwcRy0ju94O0YvAROo5AwDqi2vXPSkHcD 9o1A== X-Gm-Message-State: AJIora/v+AsBpFPsP18TBDdOvNtiFhiRu6FdNI4jKZqh8fw9Jy6/lG+4 Ya0GX8k/y2elkec4S9UdS8c= X-Google-Smtp-Source: AGRyM1soJoSbeU0WN1XJIY8utT6biEomv+Ha3eLmBhsMg4XQmuts+L3/iDVSsg0bR/pHpT5ktKL7LQ== X-Received: by 2002:a63:2b84:0:b0:412:5277:99dc with SMTP id r126-20020a632b84000000b00412527799dcmr3733324pgr.208.1657732845112; Wed, 13 Jul 2022 10:20:45 -0700 (PDT) Original-Received: from localhost ([49.204.129.90]) by smtp.gmail.com with ESMTPSA id u188-20020a6260c5000000b0050dc7628183sm9417246pfb.93.2022.07.13.10.20.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Jul 2022 10:20:44 -0700 (PDT) In-Reply-To: <83v8s1uecy.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 Jul 2022 20:11:41 +0300") 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" Xref: news.gmane.io gmane.emacs.bugs:236914 Archived-At: [=E0=AE=AA=E0=AF=81=E0=AE=A4=E0=AE=A9=E0=AF=8D =E0=AE=9C=E0=AF=82=E0=AE=B2= =E0=AF=88 13, 2022] Eli Zaretskii wrote: >> In the past, when I start Emacs daemon by `emacs --daemon' in my >> ~/.xsession file and eventually kill X, Emacs will not die. I can still >> access the Emacs session in the tty or a fresh Xorg session using >> emacsclient. But I seem to recall M-x server-start RET working >> identical to --daemon here. > > That's probably just sheer luck. When you kill the X server, any code > in Emacs that tries to display something will crash and burn, because > there's generally no way for us to display anything in that case. I don't think so. Lucid toolkit has been the suggested method to survive X crashes, and so far, it has worked. If it involved more than sheer luck, then I don't think people would suggest it. >> > Why not close Emacs before that -- this way you get to keep all your >> > edits, instead of relying on error handling to succeed in doing that. >>=20 >> That's not a solution, sorry. Just saving the buffers is not going to >> cut it, I would like to have my shell session, other processes stay >> alive. > > Our solution to this is desktop.el. You can customize it to save and > restore more than it does by default. But expecting Emacs to survive > the killing of X is unreasonable. I know about desktop.el and I do use it, but it is not the same. >> Hmm, trying it with --fg-daemon, sometimes Emacs survives, sometimes it >> dies. Backtrace follows, >>=20 >> (gdb) run -Q --fg-daemon >> Starting program: /home/viz/lib/ports/emacs/src/emacs -Q --fg-daemon >> [Switching to thread 1 (process 7339)](running) >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1= ". >> [New Thread 0x7ffff15fe640 (LWP 7340)] >> [New Thread 0x7ffff0c6d640 (LWP 7356)] >> [New Thread 0x7fffebfff640 (LWP 7357)] >> [Detaching after vfork from child process 7393] >>=20 >> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. >> message3_nolog (m=3D...) at xdisp.c:11770 >> 11770 if (FRAME_TERMINAL (f)->frame_up_to_date_hook) >> (gdb) bt >> #0 message3_nolog (m=3DXIL(0x555556066254)) at xdisp.c:11770 >> #1 0x00005555555f3449 in message3 (m=3DXIL(0x555556066254)) at xdisp.c:= 11698 >> #2 0x0000555555848e28 in Fmessage (nargs=3D2, args=3D0x7ffff15ff250) at= editfns.c:2881 > > Here's an excellent example of what I was trying to say: this says > that Emacs tried to show some message, and crashed because that > requires a valid frame with a terminal connection. What do you expect > Emacs to do here? Ignore it? Or write it to stdout? One can see the message in *Messages* anyway. I killed X the same way I did here last month and Emacs coped just fine; the same way being M-! pkill X RET. > I think we should close this bug as wontfix. It's unreasonable to > expect a GUI program to stay in the air when its GUI infrastructure is > forcibly killed. Please reconsider. I will finally quote etc/PROBLEMS here, ** When Emacs is compiled with Gtk+, closing a display kills Emacs. There is a long-standing bug in GTK that prevents it from recovering from disconnects: https://gitlab.gnome.org/GNOME/gtk/issues/221 Thus, for instance, when Emacs is run as a server on a text terminal, and an X frame is created, and the X server for that frame crashes or exits unexpectedly, Emacs must exit to prevent a GTK error that would result in an endless loop. If you need Emacs to be able to recover from closing displays, compile it with the Lucid toolkit instead of GTK.