From unknown Wed Jun 18 00:26:24 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#53164 <53164@debbugs.gnu.org> To: bug#53164 <53164@debbugs.gnu.org> Subject: Status: After an ELC+ELN build, don't load the source file into a buffer. Reply-To: bug#53164 <53164@debbugs.gnu.org> Date: Wed, 18 Jun 2025 07:26:24 +0000 retitle 53164 After an ELC+ELN build, don't load the source file into a buf= fer. reassign 53164 emacs submitter 53164 Alan Mackenzie severity 53164 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 10 11:51:48 2022 Received: (at submit) by debbugs.gnu.org; 10 Jan 2022 16:51:48 +0000 Received: from localhost ([127.0.0.1]:53155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6xtc-0003Cy-61 for submit@debbugs.gnu.org; Mon, 10 Jan 2022 11:51:48 -0500 Received: from lists.gnu.org ([209.51.188.17]:49938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6xtZ-0003Co-52 for submit@debbugs.gnu.org; Mon, 10 Jan 2022 11:51:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35084) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6xtL-0007Br-OE for bug-gnu-emacs@gnu.org; Mon, 10 Jan 2022 11:51:38 -0500 Received: from colin.muc.de ([193.149.48.1]:17943 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1n6xt9-0005Uc-Au for bug-gnu-emacs@gnu.org; Mon, 10 Jan 2022 11:51:31 -0500 Received: (qmail 36870 invoked by uid 3782); 10 Jan 2022 16:50:56 -0000 Received: from acm.muc.de (p4fe15a8e.dip0.t-ipconnect.de [79.225.90.142]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 10 Jan 2022 17:50:56 +0100 Received: (qmail 12986 invoked by uid 1000); 10 Jan 2022 16:50:56 -0000 Date: Mon, 10 Jan 2022 16:50:56 +0000 To: bug-gnu-emacs@gnu.org Subject: After an ELC+ELN build, don't load the source file into a buffer. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) Hello, Emacs. emacs-28 and master branches. In batch-byte+native-compile (lisp/emacs-lisp/comp.el), the code fails to remove the source file argument from command-line-args-left, thus causing Emacs (or bootstrap-emacs) to regard this argument as a file to be visited after the compilation is complete. This can lead (and has led) to bugs. Remove this element from command-line-args-left at the end of batch-byte+native-compile. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 10 12:15:43 2022 Received: (at 53164-done) by debbugs.gnu.org; 10 Jan 2022 17:15:43 +0000 Received: from localhost ([127.0.0.1]:53201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6yGl-0003rG-98 for submit@debbugs.gnu.org; Mon, 10 Jan 2022 12:15:43 -0500 Received: from colin.muc.de ([193.149.48.1]:18556 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1n6yGk-0003r1-0s for 53164-done@debbugs.gnu.org; Mon, 10 Jan 2022 12:15:42 -0500 Received: (qmail 55803 invoked by uid 3782); 10 Jan 2022 17:15:35 -0000 Received: from acm.muc.de (p4fe15a8e.dip0.t-ipconnect.de [79.225.90.142]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 10 Jan 2022 18:15:34 +0100 Received: (qmail 8644 invoked by uid 1000); 10 Jan 2022 17:15:34 -0000 Date: Mon, 10 Jan 2022 17:15:34 +0000 To: 53164-done@debbugs.gnu.org Subject: Bug#53164 (After an ELC+ELN build, don't load the source file into a buffer.) fixed. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53164-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Bug fixed in the emacs-28 branch. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 10 13:01:23 2022 Received: (at 53164) by debbugs.gnu.org; 10 Jan 2022 18:01:23 +0000 Received: from localhost ([127.0.0.1]:53266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6yyx-00059E-Jp for submit@debbugs.gnu.org; Mon, 10 Jan 2022 13:01:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6yyt-00058y-0r for 53164@debbugs.gnu.org; Mon, 10 Jan 2022 13:01:22 -0500 Received: from [2001:470:142:3::e] (port=52608 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6yyn-0007d9-8P; Mon, 10 Jan 2022 13:01:13 -0500 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=JC3pOsXEATUdmSZ5HzkVE4wGq+zUfoQ3nw8kVe1lwbo=; b=Fr/eUnxndrep 1H5Xvb35KWpGyP5ApWYk2JUsPd83pmslMUe8nK9/KA9lT/XY2kKfYr4a450Yx7W9fAZ1FAM2Os9mA q9DkY1aiOtCGa8Tz3BLLSARfeG5PGcBDp6qqyfG+oXdjYvlp1YoTDxZ/1ZHXlbTQ16f/tHKUVxkpH 0G5h7NgzlnCOMME5byUUyzjZ7JL3iSVWR/wAw+zZIVnrLoPjDqM8w3liQMhN/4Y9O2/OXSMJzLZ+y Ko7WZTr6OPAbAR7RADFo6is7vKRskeInBB/zhM9KB3qJg+LOKUmIWZDNn9z5RcWCzzI3Ha8wqlz3I PhfMjKkQCcxqxNe+uvHIGA==; Received: from [87.69.77.57] (port=4795 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6yyk-0003IS-IZ; Mon, 10 Jan 2022 13:01:11 -0500 Date: Mon, 10 Jan 2022 20:01:01 +0200 Message-Id: <83wnj78o82.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Mon, 10 Jan 2022 16:50:56 +0000) Subject: Re: bug#53164: After an ELC+ELN build, don't load the source file into a buffer. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53164 Cc: 53164@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 10 Jan 2022 16:50:56 +0000 > From: Alan Mackenzie > > emacs-28 and master branches. > > In batch-byte+native-compile (lisp/emacs-lisp/comp.el), the code fails > to remove the source file argument from command-line-args-left, thus > causing Emacs (or bootstrap-emacs) to regard this argument as a file to > be visited after the compilation is complete. > > This can lead (and has led) to bugs. > > Remove this element from command-line-args-left at the end of > batch-byte+native-compile. Please show the smallest recipe to reproduce this. Because I don't think I follow your description, and in particular I saw no such problems when building Emacs. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 10 13:05:40 2022 Received: (at 53164) by debbugs.gnu.org; 10 Jan 2022 18:05:40 +0000 Received: from localhost ([127.0.0.1]:53277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6z36-0005GS-Cs for submit@debbugs.gnu.org; Mon, 10 Jan 2022 13:05:40 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6z34-0005GE-9I for 53164@debbugs.gnu.org; Mon, 10 Jan 2022 13:05:38 -0500 Received: from [2001:470:142:3::e] (port=52702 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6z2x-0008Dr-Sh; Mon, 10 Jan 2022 13:05:32 -0500 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=C2TGocQDPUAqOMOrXxbL4f2OH6cipvONSfuqkPBgV4c=; b=PL2nGdQ1K+3R LaornBvu1joPobWTLL5iE9LNjO8l3UQFF9xJxIf0Qqodi0ZSICuB7PMzZm0PrpGbTWFs/lmES3bJM QDM0Mf+fAO8NdniUHI+Qm49hROZ5MEg3EVFgrIh1jLFPhpDFE2qsfC5wcl5ivc0bVQyGn2Ct08knH eM23KngYvpbKomz9gTatYl+8VxnJEo1v/bGOCV54FokYwhHeM8kBsu21jP8chOFz9LKkDxIVID/0r E4tZRgVtJzTXGrvgc/7NjaPdthgOJeP1ZOoLOQVEbhA7f97QFyQLZMlqW9VQTNUl518yvnyj9znQU N613MXlF9ZIQvBJ/6YCAHg==; Received: from [87.69.77.57] (port=1094 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6z2x-0001d2-Th; Mon, 10 Jan 2022 13:05:32 -0500 Date: Mon, 10 Jan 2022 20:05:22 +0200 Message-Id: <83v8yr8o0t.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Mon, 10 Jan 2022 17:15:34 +0000) Subject: Re: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53164 Cc: 53164@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 10 Jan 2022 17:15:34 +0000 > From: Alan Mackenzie > > Bug fixed in the emacs-28 branch. I reverted that commit. Please don't make any non-trivial changes on the release branch without asking first, and definitely not without explaining the problem and the solution in much more detail than you did. FTR, I didn't see any build problems due to this issue, not even once. So I wonder what exactly did you see and in what scenario. Please elaborate. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 10 14:35:11 2022 Received: (at 53164) by debbugs.gnu.org; 10 Jan 2022 19:35:12 +0000 Received: from localhost ([127.0.0.1]:53331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n70Rj-0007YR-GN for submit@debbugs.gnu.org; Mon, 10 Jan 2022 14:35:11 -0500 Received: from colin.muc.de ([193.149.48.1]:22355 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1n70Re-0007Xk-1R for 53164@debbugs.gnu.org; Mon, 10 Jan 2022 14:35:10 -0500 Received: (qmail 54895 invoked by uid 3782); 10 Jan 2022 19:34:59 -0000 Received: from acm.muc.de (p4fe15a8e.dip0.t-ipconnect.de [79.225.90.142]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 10 Jan 2022 20:34:59 +0100 Received: (qmail 4147 invoked by uid 1000); 10 Jan 2022 19:34:58 -0000 Date: Mon, 10 Jan 2022 19:34:58 +0000 To: Eli Zaretskii Subject: Re: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. Message-ID: References: <83v8yr8o0t.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83v8yr8o0t.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53164 Cc: 53164@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Mon, Jan 10, 2022 at 20:05:22 +0200, Eli Zaretskii wrote: > > Date: Mon, 10 Jan 2022 17:15:34 +0000 > > From: Alan Mackenzie > > Bug fixed in the emacs-28 branch. > I reverted that commit. Please don't make any non-trivial changes on > the release branch without asking first, and definitely not without > explaining the problem and the solution in much more detail than you > did. It seemed to me like such an obvious fix for a non-obvious bug which can cause serious amounts of time to be lost (see below), and with a negligible chance of doing any damage. But after reading the following, please consider putting it back. It will make building Emacs faster, even if only a little bit. > FTR, I didn't see any build problems due to this issue, not even > once. So I wonder what exactly did you see and in what scenario. > Please elaborate. It took me practically three days solid to diagnose this bug. The symptom, whilst bootstrapping the scratch/correct-warning-pos, was the following message on stderr: Error: (invalid-function #) .. I quickly tracked down the source of the `=' symbol to lisp/subr.el, in the code for `zerop'. Further progress was elusive. In the course of debugging it, I ended up writing my own backtrace routine, free of dependencies, which can work early in the bootstrap, unlike the standard backtrace. The course of events which led to that error message is this: 1. During the bootstrap with native compile, ELC+ELN compiles subr.el. It does so by getting the LAP code from bytecomp.el via a side channel. It completes the compilation. 2. bootstrap-emacs now contains the native-compiled version of subr.el. Unfortunately, the macro `zerop--anon-cmacro' a complier macro for `zerop', still contains symbols with position. 3. Having finished the native compilation, ELC+ELN visited subr.el in a buffer, due to this bug. 4. As part of visiting subr.el, Emacs calls after-find-file, which invokes find-file-hook. 5. One of the entries in find-file-hook is vc-refresh-state, which gets called. 6. This causes vc-git.elc to be loaded. Eventually, vc-git--out-ok gets called. 7. vc-git--out-ok invokes `zerop', or more precisely the code generated by the macro `zerop--anon-cmacro'. This contains #. 8. eval signals an error, since symbols-with-pos-enabled is nil and it thus can't handle the symbol with position. This error gets blocked from reaching a backtrace function by an inconsiderate condition-case, which just dumps the message onto stderr. The most obvious cause of the error seems to be at step 3, where bootstrap-emacs spuriously visits the source file. As I said above, please consider putting the fix to this bug back. I do not want anybody else to have to go through what I had to to track the bug down. Leaving stale arguments on the command line, later to be visited, cannot possibly be the Right Thing. I'm pretty sure it was not done deliberately, it was just a minor oversight which didn't seem to matter. Thanks. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 10 14:53:54 2022 Received: (at 53164) by debbugs.gnu.org; 10 Jan 2022 19:53:54 +0000 Received: from localhost ([127.0.0.1]:53353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n70jq-00083c-DO for submit@debbugs.gnu.org; Mon, 10 Jan 2022 14:53:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n70jm-00083I-NA for 53164@debbugs.gnu.org; Mon, 10 Jan 2022 14:53:53 -0500 Received: from [2001:470:142:3::e] (port=55516 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n70jg-0002Hf-Vl; Mon, 10 Jan 2022 14:53:45 -0500 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=FhVzNy/npQTLiS1giFUsgNhUZcgiCC4zBO0rckVw1qM=; b=cRAsvDHdU6gU p/1JC8PD3jIvYEvrh7FeEg0yNQC7il30vTPVYJN1fDLdOdxKsgrzBSYOYjda+ikEDOMwUY7mQAJpz DjdQPdSzD2yCa+Eaqs/iREGsSzlEJSSks8E+O20Dh9QSld8tdJVL3K8o57gj58uvhJkmO0QcF4H9Y /6aGj/iBO1ymgy7UKyfPb/KCKUuozSV+2oMde9dtAj+/z9anyOELP86/izvgDXEj4z3PoZOEwwWFd we2lsPW2T+QtjteJL53stkK/dFe3YN3ocZTUhLn5K7LLDRFNL3GZEGqFCcTn209dUwcsSJD/BgwIt 3LuLS/Y1sLl9d8AWnJ4DzA==; Received: from [87.69.77.57] (port=2310 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n70jh-0008Tj-0a; Mon, 10 Jan 2022 14:53:45 -0500 Date: Mon, 10 Jan 2022 21:53:36 +0200 Message-Id: <83ilur8j0f.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Mon, 10 Jan 2022 19:34:58 +0000) Subject: Re: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. References: <83v8yr8o0t.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53164 Cc: 53164@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 10 Jan 2022 19:34:58 +0000 > Cc: 53164@debbugs.gnu.org > From: Alan Mackenzie > > > FTR, I didn't see any build problems due to this issue, not even > > once. So I wonder what exactly did you see and in what scenario. > > Please elaborate. > > It took me practically three days solid to diagnose this bug. The > symptom, whilst bootstrapping the scratch/correct-warning-pos, was the > following message on stderr: > > Error: (invalid-function #) > > .. I quickly tracked down the source of the `=' symbol to lisp/subr.el, > in the code for `zerop'. Further progress was elusive. In the course > of debugging it, I ended up writing my own backtrace routine, free of > dependencies, which can work early in the bootstrap, unlike the standard > backtrace. > > The course of events which led to that error message is this: > > 1. During the bootstrap with native compile, ELC+ELN compiles subr.el. > It does so by getting the LAP code from bytecomp.el via a side > channel. It completes the compilation. > 2. bootstrap-emacs now contains the native-compiled version of subr.el. > Unfortunately, the macro `zerop--anon-cmacro' a complier macro for > `zerop', still contains symbols with position. > 3. Having finished the native compilation, ELC+ELN visited subr.el in a > buffer, due to this bug. > 4. As part of visiting subr.el, Emacs calls after-find-file, which > invokes find-file-hook. > 5. One of the entries in find-file-hook is vc-refresh-state, which gets > called. > 6. This causes vc-git.elc to be loaded. Eventually, vc-git--out-ok gets > called. > 7. vc-git--out-ok invokes `zerop', or more precisely the code generated > by the macro `zerop--anon-cmacro'. This contains # 18944>. > 8. eval signals an error, since symbols-with-pos-enabled is nil and it > thus can't handle the symbol with position. This error gets blocked > from reaching a backtrace function by an inconsiderate condition-case, > which just dumps the message onto stderr. > > The most obvious cause of the error seems to be at step 3, where > bootstrap-emacs spuriously visits the source file. After reading this, I still don't understand how come you bump into this problem, whereas I don't, and neither does anyone else who builds the release branch with native-compilation. Is this something specific to that branch you are working on? If so, why is it urgent to have the fix on the release branch? The branch on which you ware working will land on master. > As I said above, please consider putting the fix to this bug back. I do > not want anybody else to have to go through what I had to to track the > bug down. Leaving stale arguments on the command line, later to be > visited, cannot possibly be the Right Thing. I'm pretty sure it was not > done deliberately, it was just a minor oversight which didn't seem to > matter. There's always one more bug. When we are so far into the pretest process, problems that take unusual steps to reproduce are not important enough to delay the release. The judgment call I need to make is how important is it to have this in the release branch, and that's only after I understand how to trigger the problem in the first place. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 10 15:21:52 2022 Received: (at 53164) by debbugs.gnu.org; 10 Jan 2022 20:21:52 +0000 Received: from localhost ([127.0.0.1]:53378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n71At-0000Km-Q5 for submit@debbugs.gnu.org; Mon, 10 Jan 2022 15:21:52 -0500 Received: from colin.muc.de ([193.149.48.1]:23619 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1n71Aq-0000KX-2U for 53164@debbugs.gnu.org; Mon, 10 Jan 2022 15:21:50 -0500 Received: (qmail 87401 invoked by uid 3782); 10 Jan 2022 20:21:41 -0000 Received: from acm.muc.de (p4fe15a8e.dip0.t-ipconnect.de [79.225.90.142]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 10 Jan 2022 21:21:41 +0100 Received: (qmail 4305 invoked by uid 1000); 10 Jan 2022 20:21:40 -0000 Date: Mon, 10 Jan 2022 20:21:40 +0000 To: Eli Zaretskii Subject: Re: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. Message-ID: References: <83v8yr8o0t.fsf@gnu.org> <83ilur8j0f.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ilur8j0f.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53164 Cc: 53164@debbugs.gnu.org, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Mon, Jan 10, 2022 at 21:53:36 +0200, Eli Zaretskii wrote: > > Date: Mon, 10 Jan 2022 19:34:58 +0000 > > Cc: 53164@debbugs.gnu.org > > From: Alan Mackenzie > > > FTR, I didn't see any build problems due to this issue, not even > > > once. So I wonder what exactly did you see and in what scenario. > > > Please elaborate. > > It took me practically three days solid to diagnose this bug. The > > symptom, whilst bootstrapping the scratch/correct-warning-pos, was the > > following message on stderr: > > Error: (invalid-function #) > > .. I quickly tracked down the source of the `=' symbol to lisp/subr.el, > > in the code for `zerop'. Further progress was elusive. In the course > > of debugging it, I ended up writing my own backtrace routine, free of > > dependencies, which can work early in the bootstrap, unlike the standard > > backtrace. > > The course of events which led to that error message is this: > > 1. During the bootstrap with native compile, ELC+ELN compiles subr.el. > > It does so by getting the LAP code from bytecomp.el via a side > > channel. It completes the compilation. > > 2. bootstrap-emacs now contains the native-compiled version of subr.el. > > Unfortunately, the macro `zerop--anon-cmacro' a complier macro for > > `zerop', still contains symbols with position. > > 3. Having finished the native compilation, ELC+ELN visited subr.el in a > > buffer, due to this bug. > > 4. As part of visiting subr.el, Emacs calls after-find-file, which > > invokes find-file-hook. > > 5. One of the entries in find-file-hook is vc-refresh-state, which gets > > called. > > 6. This causes vc-git.elc to be loaded. Eventually, vc-git--out-ok gets > > called. > > 7. vc-git--out-ok invokes `zerop', or more precisely the code generated > > by the macro `zerop--anon-cmacro'. This contains # > 18944>. > > 8. eval signals an error, since symbols-with-pos-enabled is nil and it > > thus can't handle the symbol with position. This error gets blocked > > from reaching a backtrace function by an inconsiderate condition-case, > > which just dumps the message onto stderr. > > The most obvious cause of the error seems to be at step 3, where > > bootstrap-emacs spuriously visits the source file. > After reading this, I still don't understand how come you bump into > this problem, whereas I don't, and neither does anyone else who builds > the release branch with native-compilation. Is this something > specific to that branch you are working on? Indeed, yes. It is the symbols with position which escaped from a compiler macro. > If so, why is it urgent to have the fix on the release branch? The > branch on which you ware working will land on master. There was no urgency. I though the convention was for documentation fixes and simple safe code fixes to go onto the release branch. The fix to this bug, a single line, is well understood and certainly comes into the category of simple and safe. > > As I said above, please consider putting the fix to this bug back. I do > > not want anybody else to have to go through what I had to to track the > > bug down. Leaving stale arguments on the command line, later to be > > visited, cannot possibly be the Right Thing. I'm pretty sure it was not > > done deliberately, it was just a minor oversight which didn't seem to > > matter. > There's always one more bug. When we are so far into the pretest > process, problems that take unusual steps to reproduce are not > important enough to delay the release. OK. But can I ask you to consider announcing on emacs-devel when the criteria for making bug fixes on the release branch change? Apologies if you have done, and I missed it. > The judgment call I need to make is how important is it to have this in > the release branch, and that's only after I understand how to trigger > the problem in the first place. It is not particularly important for the release branch. But it is a positive step (making the build faster, and removing a potential bug source). As for triggering it, I cannot give you a recipe except for committing my recent changes to scratch/correct-warning-pos, and asking you to repeat what I did (basically, a make bootstrap). Somebody else may trigger it in some other way, and the debugging effort is potentially unbounded. So, I still think it would be better in the release branch, but can see that it's not very important. There're three ways we could go. Commit it in emacs-28, master, or scratch/correct-warning-pos. I'm willing to commit it again in any of these places. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 11 07:27:29 2022 Received: (at 53164) by debbugs.gnu.org; 11 Jan 2022 12:27:29 +0000 Received: from localhost ([127.0.0.1]:54339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7GFM-0008KC-Na for submit@debbugs.gnu.org; Tue, 11 Jan 2022 07:27:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7GFL-0008Js-2l for 53164@debbugs.gnu.org; Tue, 11 Jan 2022 07:27:28 -0500 Received: from [2001:470:142:3::e] (port=44440 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7GFF-0007an-OY; Tue, 11 Jan 2022 07:27:21 -0500 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=7FmkLuR5zNOc3EAb9iLCU3PAF+2ZYt0pa+BhRCPB+do=; b=OXzoU6DeBRIG e6IKeT8Kz9mBh26by/4/D9yapHvPrsMdtEFHUBs0rAGS+B/sXgfG+a1LgTctFPXsc9h4ULXRTwqVE TMPE7bdF2gk2IjMej7Y2ZoXzlqrZABwNhWb5cj5A30rWatwJLNOHoCSmBKX6U9QKGOJA5WgVGGVaS ednSa2tGGmYAw2h+YxSqtw/rBfz/70Eh9Fz5RkGw/fgAMemmRV/5yfnJ0SN4Zlf5rTJHLQApxzLFa N5bzCXkeIQ02IWh1hVBlhOydUg2Cm6grYvS0Kf1gT4Ev02nKHOf9G/5NLFJmYlyigeZ4bVQ/Cwy95 ABJsdlecenUzTxGoOmMdNw==; Received: from [87.69.77.57] (port=3234 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7GFF-0002dz-PJ; Tue, 11 Jan 2022 07:27:22 -0500 Date: Tue, 11 Jan 2022 14:27:14 +0200 Message-Id: <83bl0i8nkt.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Mon, 10 Jan 2022 20:21:40 +0000) Subject: Re: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. References: <83v8yr8o0t.fsf@gnu.org> <83ilur8j0f.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53164 Cc: 53164@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 10 Jan 2022 20:21:40 +0000 > Cc: 53164@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > After reading this, I still don't understand how come you bump into > > this problem, whereas I don't, and neither does anyone else who builds > > the release branch with native-compilation. Is this something > > specific to that branch you are working on? > > Indeed, yes. It is the symbols with position which escaped from a > compiler macro. > > > If so, why is it urgent to have the fix on the release branch? The > > branch on which you ware working will land on master. > > There was no urgency. I though the convention was for documentation > fixes and simple safe code fixes to go onto the release branch. The fix > to this bug, a single line, is well understood and certainly comes into > the category of simple and safe. The fix is well understood, but its possible effects aren't. We have been using the current code for more than a year with no problems whatsoever. > > There's always one more bug. When we are so far into the pretest > > process, problems that take unusual steps to reproduce are not > > important enough to delay the release. > > OK. But can I ask you to consider announcing on emacs-devel when the > criteria for making bug fixes on the release branch change? Apologies if > you have done, and I missed it. This is in CONTRIBUTE: If you are fixing a bug that exists in the current release, you should generally commit it to the release branch; it will be merged to the master branch later by the gitmerge function. However, when the release branch is for Emacs version NN.2 and later, or when it is for Emacs version NN.1 that is in the very last stages of its pretest, that branch is considered to be in a feature freeze: only bug fixes that are "safe" or are fixing major problems should go to the release branch, the rest should be committed to the master branch. This is so to avoid destabilizing the next Emacs release. If you are unsure whether your bug fix is "safe" enough for the release branch, ask on the emacs-devel mailing list. > There're three ways we could go. Commit it in emacs-28, master, or > scratch/correct-warning-pos. I'm willing to commit it again in any of > these places. Please install this on master (or leave it on your branch), and we will revisit this when time comes for Emacs 28.2. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 11 13:03:25 2022 Received: (at 53164) by debbugs.gnu.org; 11 Jan 2022 18:03:25 +0000 Received: from localhost ([127.0.0.1]:55500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7LUS-0002Nd-KM for submit@debbugs.gnu.org; Tue, 11 Jan 2022 13:03:25 -0500 Received: from colin.muc.de ([193.149.48.1]:58920 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1n7LUO-0002N6-Sa for 53164@debbugs.gnu.org; Tue, 11 Jan 2022 13:03:22 -0500 Received: (qmail 72016 invoked by uid 3782); 11 Jan 2022 18:03:14 -0000 Received: from acm.muc.de (p4fe1582c.dip0.t-ipconnect.de [79.225.88.44]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 11 Jan 2022 19:03:14 +0100 Received: (qmail 30528 invoked by uid 1000); 11 Jan 2022 18:03:14 -0000 Date: Tue, 11 Jan 2022 18:03:14 +0000 To: Eli Zaretskii Subject: Re: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. Message-ID: References: <83v8yr8o0t.fsf@gnu.org> <83ilur8j0f.fsf@gnu.org> <83bl0i8nkt.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83bl0i8nkt.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53164 Cc: 53164@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Tue, Jan 11, 2022 at 14:27:14 +0200, Eli Zaretskii wrote: > > Date: Mon, 10 Jan 2022 20:21:40 +0000 > > Cc: 53164@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > After reading this, I still don't understand how come you bump into > > > this problem, whereas I don't, and neither does anyone else who builds > > > the release branch with native-compilation. Is this something > > > specific to that branch you are working on? > > Indeed, yes. It is the symbols with position which escaped from a > > compiler macro. > > > If so, why is it urgent to have the fix on the release branch? The > > > branch on which you ware working will land on master. > > There was no urgency. I though the convention was for documentation > > fixes and simple safe code fixes to go onto the release branch. The fix > > to this bug, a single line, is well understood and certainly comes into > > the category of simple and safe. > The fix is well understood, but its possible effects aren't. OK, we will just have to disagree on this point. If I wasn't sure about the lack of possible negative effects, I wouldn't have committed the fix to the emacs-28 branch. > We have been using the current code for more than a year with no > problems whatsoever. None on the emacs-28 branch, perhaps. I had severe problems with the same code on a branch branched from master. Incidentally, I timed a bootstrap on the release branch with and without the fix, both starting from a warm file cache. With the fix, the build ran ~7% faster. > > > There's always one more bug. When we are so far into the pretest > > > process, problems that take unusual steps to reproduce are not > > > important enough to delay the release. > > OK. But can I ask you to consider announcing on emacs-devel when the > > criteria for making bug fixes on the release branch change? Apologies if > > you have done, and I missed it. > This is in CONTRIBUTE: > If you are fixing a bug that exists in the current release, you should > generally commit it to the release branch; it will be merged to the > master branch later by the gitmerge function. However, when the > release branch is for Emacs version NN.2 and later, or when it is for > Emacs version NN.1 that is in the very last stages of its pretest, > that branch is considered to be in a feature freeze: only bug fixes > that are "safe" or are fixing major problems should go to the release > branch, the rest should be committed to the master branch. This is so > to avoid destabilizing the next Emacs release. If you are unsure > whether your bug fix is "safe" enough for the release branch, ask on > the emacs-devel mailing list. OK, thanks. I'm not sure I understand any more what "safe" means in this context. > > There're three ways we could go. Commit it in emacs-28, master, or > > scratch/correct-warning-pos. I'm willing to commit it again in any of > > these places. > Please install this on master (or leave it on your branch), and we > will revisit this when time comes for Emacs 28.2. I'll install it on master this evening. Thanks! > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 11 13:46:13 2022 Received: (at 53164) by debbugs.gnu.org; 11 Jan 2022 18:46:13 +0000 Received: from localhost ([127.0.0.1]:55535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7M9s-0004Ml-P3 for submit@debbugs.gnu.org; Tue, 11 Jan 2022 13:46:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7M9r-0004ML-7F for 53164@debbugs.gnu.org; Tue, 11 Jan 2022 13:46:11 -0500 Received: from [2001:470:142:3::e] (port=55724 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7M9l-0006Z7-2T; Tue, 11 Jan 2022 13:46:05 -0500 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=VcX3grvvHDbUH6HNztA6n84LDwGyEtPdqqXjOWhUYPU=; b=ehlQ4tIRTf4v c6PirKXzqk+IMwrITnGS987BH0H7Pv/wJZOt0we9TKaXco/37JLfgPe8fCX8BasBxzmK5LpbFRZNl M9aJuZ4Z4jw27pDVckEhrI4h/a4PBEmbf2hCejP35dxXlYgNSA501Vzvd5zm79SDgssCsWUeikycc LHqBUVp8/b3Mp1vtRuPGc89ioeZoZihJlGi+23Kmt5liVufl/Yah2uBwu+4iFk8iqjMkeymc39a3X V/Y9xjcGq1lfWhTtT1GuT6y9JnXQhqL8uYomSnBlt+QRHjj5tQMxjqQKhnZ48bNSkPxKsvWh+AMQx 4NBexasH2iLNtfAzp6dY3w==; Received: from [87.69.77.57] (port=2905 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7M9k-0000mm-3o; Tue, 11 Jan 2022 13:46:04 -0500 Date: Tue, 11 Jan 2022 20:45:56 +0200 Message-Id: <83h7aa6rh7.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Tue, 11 Jan 2022 18:03:14 +0000) Subject: Re: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. References: <83v8yr8o0t.fsf@gnu.org> <83ilur8j0f.fsf@gnu.org> <83bl0i8nkt.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53164 Cc: 53164@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 11 Jan 2022 18:03:14 +0000 > Cc: 53164@debbugs.gnu.org > From: Alan Mackenzie > > > The fix is well understood, but its possible effects aren't. > > OK, we will just have to disagree on this point. If I wasn't sure about > the lack of possible negative effects, I wouldn't have committed the fix > to the emacs-28 branch. We are mis-communicating. I didn't mean something as silly as saying that the result of removing a command-line argument is not well understood. What I meant to say is that since it's impossible to look at all the possible situations where this code is being used, we cannot know what would happen due to this removal. You basically only tested the fix in one situation, where you discovered the problem, and just assume that it cannot possibly have any adverse effects on the infinity of other cases. But that's just an assumption. The reason we have long pretests is precisely because code we think we understand has unintended consequences that take a lot of time to reveal. This change is no different. > > We have been using the current code for more than a year with no > > problems whatsoever. > > None on the emacs-28 branch, perhaps. I had severe problems with the > same code on a branch branched from master. Incidentally, I timed a > bootstrap on the release branch with and without the fix, both starting > from a warm file cache. With the fix, the build ran ~7% faster. Thanks, but at this point in the pretest I no longer worry about speeding up the build. > > If you are fixing a bug that exists in the current release, you should > > generally commit it to the release branch; it will be merged to the > > master branch later by the gitmerge function. However, when the > > release branch is for Emacs version NN.2 and later, or when it is for > > Emacs version NN.1 that is in the very last stages of its pretest, > > that branch is considered to be in a feature freeze: only bug fixes > > that are "safe" or are fixing major problems should go to the release > > branch, the rest should be committed to the master branch. This is so > > to avoid destabilizing the next Emacs release. If you are unsure > > whether your bug fix is "safe" enough for the release branch, ask on > > the emacs-devel mailing list. > > OK, thanks. I'm not sure I understand any more what "safe" means in > this context. That's right, at this point no change is "safe" a-priori. > > Please install this on master (or leave it on your branch), and we > > will revisit this when time comes for Emacs 28.2. > > I'll install it on master this evening. Thanks! Thanks. From unknown Wed Jun 18 00:26:24 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 09 Feb 2022 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator