From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. Date: Mon, 10 Jan 2022 21:53:36 +0200 Message-ID: <83ilur8j0f.fsf@gnu.org> References: <83v8yr8o0t.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38507"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53164@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 10 20:54:22 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 1n70kI-0009qc-0j for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Jan 2022 20:54:22 +0100 Original-Received: from localhost ([::1]:60998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n70kG-00040R-VV for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Jan 2022 14:54:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53498) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n70jz-0003z0-Hw for bug-gnu-emacs@gnu.org; Mon, 10 Jan 2022 14:54:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60454) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n70jy-0002Jv-31 for bug-gnu-emacs@gnu.org; Mon, 10 Jan 2022 14:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n70jy-00084J-2G for bug-gnu-emacs@gnu.org; Mon, 10 Jan 2022 14:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Jan 2022 19:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53164 X-GNU-PR-Package: emacs Original-Received: via spool by 53164-submit@debbugs.gnu.org id=B53164.164184443430980 (code B ref 53164); Mon, 10 Jan 2022 19:54:02 +0000 Original-Received: (at 53164) by debbugs.gnu.org; 10 Jan 2022 19:53:54 +0000 Original-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 Original-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 Original-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==; Original-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 In-Reply-To: (message from Alan Mackenzie on Mon, 10 Jan 2022 19:34:58 +0000) 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:223898 Archived-At: > 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.