GNU bug report logs - #68083
30.0.50; Intermittent build failure with native compilation

Previous Next

Full log

Message #29 received at 68083 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68083 <at> debbugs.gnu.org, acorallo <at> gnu.org, jschmidt4gnu <at> vodafonemail.de
Subject: Re: bug#68083: 30.0.50;
 Intermittent build failure with native compilation
Date: Sat, 30 Dec 2023 10:29:16 -0500

On Sat, Dec 30, 2023 at 1:47 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen <at> gmail.com>
> > Date: Fri, 29 Dec 2023 16:07:38 -0500
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 68083 <at> debbugs.gnu.org,
> >       Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> >
> > Just to confirm, adding macroexpand to native-comp-never-optimize-functions allows me to build
> > successfully.
> >
> > It also looks like comp-delete-or-replace-file can be updated to protect rename-file against
> > file-already-exists like it does for Windows. That would also likely solve the problem if you want to be
> > able to optimize macroexpand.
>
> Are you sure?  We do that on Windows because Windows doesn't allow us
> to delete a file that is open by another program.  That shouldn't
> happen on Posix systems, so I think what you see here is due to a race
> between checking whether a file exists and renaming it, which is a
> different problem.
>
> However, feel free to try the same trick we use on Windows and see
> whether it helps.

This fixes it for me:

diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
index 3b2fd25e61c..80088f935a4 100644
--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -3341,7 +3341,11 @@ comp-delete-or-replace-file
         ;; is currently loaded.
         (t (delete-file oldfile)
            (when newfile
-             (rename-file newfile oldfile)))))
+             (condition-case _
+                 (rename-file newfile oldfile)
+               (file-already-exists
+                (delete-file newfile)
+                t))))))

 (defun comp--native-compile (function-or-file &optional with-late-load output)
   "Compile FUNCTION-OR-FILE into native code.

I imagine that this is worth doing just to make this operation
parallel-safe, but I wonder why macroexpand is the only instance of
this happening. I don't know if macroexpand should still be in
native-comp-never-optimize-functions or not (i.e., is there another
reason it was there other than to avoid this crash?)

Aaron

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.