From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.bugs Subject: bug#68799: 30.0.50; emacs --fg-daemon fails silently if server-start fails Date: Sat, 10 Feb 2024 23:23:19 +0000 (UTC) Message-ID: <8734tzq4y6.fsf@catern.com> References: <86y1c82hfb.fsf@gnu.org> <86wmrs2h41.fsf@gnu.org> <86v87c2fw4.fsf@gnu.org> <86sf2g2btj.fsf@gnu.org> <86r0hz2fcz.fsf@gnu.org> <875xywp08p.fsf@catern.com> <868r3st789.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31348"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 68799@debbugs.gnu.org, sbaugh@janestreet.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 11 00:24:10 2024 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 1rYwhd-0007xK-07 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Feb 2024 00:24:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rYwhI-00070W-1x; Sat, 10 Feb 2024 18:23:48 -0500 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 1rYwhG-00070E-Cy for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2024 18:23:46 -0500 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 1rYwhG-0006jo-4I for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2024 18:23:46 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rYwhV-00026y-LM for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2024 18:24:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Feb 2024 23:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68799 X-GNU-PR-Package: emacs Original-Received: via spool by 68799-submit@debbugs.gnu.org id=B68799.17076074258069 (code B ref 68799); Sat, 10 Feb 2024 23:24:01 +0000 Original-Received: (at 68799) by debbugs.gnu.org; 10 Feb 2024 23:23:45 +0000 Original-Received: from localhost ([127.0.0.1]:51364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rYwhF-000262-5X for submit@debbugs.gnu.org; Sat, 10 Feb 2024 18:23:45 -0500 Original-Received: from s.wfbtzhsv.outbound-mail.sendgrid.net ([159.183.224.104]:3486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rYwhB-00025W-VE for 68799@debbugs.gnu.org; Sat, 10 Feb 2024 18:23:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=2dkwgEJIc1JKogXgf9kljwa2ATKoXNF4fskZC60aenA=; b=Ms6fl8WFL612j1AbuzqDnjeEqAqLfcYStA3OAJw8xqWUvvfX3kURzL30OwQND0f3+7jK ROZNLobNXB6/dRXJq4RU1XJfNPDBal1LeyuGU/ripYGPqhrX2rbNehMXzfNt9I6HxbF5zg npUWbSDpjVUK7JiUiMI3IfGqyPUNgesmvZYdsKh2vQtKCu3NiwqU0LJih09PpWbvgNsA78 pRaGAnvlHjB7oCj6v2t+P2rTK9mgfM0k/Tjtm0p+6BybQiAnn1BXXPD9pACQnTcHyghtFH xkANsfH/VbCN5NMhi9wQuGQ1Vxs/D19gMj5ztwwv2Bmmf46R5BP9YI/rvmSmvlCg== Original-Received: by filterdrecv-58bfc74dd6-grnpr with SMTP id filterdrecv-58bfc74dd6-grnpr-1-65C80567-9 2024-02-10 23:23:19.572244206 +0000 UTC m=+1415182.492062421 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-5 (SG) with ESMTP id l-VivqfmTNSnUjmJbh3nwA Sat, 10 Feb 2024 23:23:19.505 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.101.51.129; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Original-Received: from localhost (unknown [74.101.51.129]) by earth.catern.com (Postfix) with ESMTPSA id B97DB62534; Sat, 10 Feb 2024 23:23:29 +0000 (UTC) In-Reply-To: <868r3st789.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 10 Feb 2024 22:05:58 +0200") X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbJCW+oxwTBGtV9Zic6d8vPOU3N+vCh993uQf1owIM5c25fDSOHJMDehTyzObWRvsbTHBIhd9gh+zqgOFr95EhkC8ISyRW3S/jdy7uwUUI9YUBMjUWbruOO6xhu9QpSynIaKsJSX4C+8z1jlI4MgyvGOWgtmYhX6wsuxCeLgtede7A== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== 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:279803 Archived-At: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Sat, 10 Feb 2024 19:50:20 +0000 (UTC) >> Cc: Spencer Baugh , 68799@debbugs.gnu.org >> >> Eli Zaretskii writes: >> >> >> > Thanks, this needs a comment explaining why we need condition-case and >> >> > where does error-message-string come from. >> >> >> >> Actually, on second thought, we could fail anywhere in startup.el, not >> >> just in server-start. So should we actually have a wrapper around all >> >> of normal-top-level which detects an error at startup in a daemon? >> > >> > I'd prefer to handle each specific problem specially, to make sure the >> > error message is self-explanatory. Also, if the error happens after >> > the server has been started, there's no reason to forcibly exit. >> > >> > So I think we should for now solve this particular issue, and not try >> > generalizing too much. >> >> To be clear, right now any error anywhere in command-line causes "emacs >> --fg-daemon" and "emacs --bg-daemon" to hang indefinitely, without >> printing an error, with no way to ever interact with the Emacs process. > > That's not what you said before: you said "anywhere in startup.el", > which is much more general. Now you are saying something different. > > What exactly is meant by "anywhere in command-line"? the function > command-line in startup.el? or something else? The function command-line in startup.el. Or, more specifically: anywhere during the evaluation of the form in the variable top-level, which by default is (normal-top-level). (which calls (command-line)) >> This error can come from any code, so if we have *any* bugs anywhere in >> code called from command-line, it will cause Emacs to enter this state. > > Why would we assume that *any code* there will signal an error? > That's like saying that Emacs is a useless program that always signals > errors in random places. That's a non-starter here. We aren't assuming this code in particular will signal an error. We are just make this code behave equivalently to other Emacs code, which, when it throws an error due to a bug, logs that error. >> We can add good error messages for individual classes of error, but we >> should also have a catch-all check to make sure that Emacs doesn't enter >> this broken state if we (or the user) write code which contains a bug. > > There's no reason to have a catch-all check where no error is > expected. Do you always wrap all of your code in condition-case and > the likes? If not, why not? The reason to have a catch-all is what I just said: if there's an error in this code, either caused by the user or from a bug in the code, it causes Emacs to silently hang without logging an error, providing absolutely no way for the user to know what's going wrong. You might as well ask why we have a condition-case wrapped around command_loop_1 which calls cmd_error, instead of just discarding the error and continuing. >> I have concrete reasons to want this: I think there's a bug in >> command-line in trunk which some of my users using emacs --daemon have >> run into. But I have zero information about what caused the bug, >> because Emacs just hangs without printing any error message in this >> case. > > Then please debug that, and let's talk when you do have concrete data. I can't debug that because I can't reproduce it and the failure case leaves no information behind. That's part of the point of why we should log on error. Your argument here justifies silencing all errors in Emacs and never writing them to *Messages*. That's obviously absurd...