GNU bug report logs - #48141
28.0.50; Files left over by native compiler

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Sat, 1 May 2021 14:37:01 UTC

Severity: normal

Merged with 52912

Found in versions 28.0.50, 29.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48141 in the body.
You can then email your comments to 48141 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#48141; Package emacs. (Sat, 01 May 2021 14:37:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefan Monnier <monnier <at> iro.umontreal.ca>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 01 May 2021 14:37:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Files left over by native compiler
Date: Sat, 01 May 2021 10:36:22 -0400
Package: Emacs
Version: 28.0.50


I have a few files apparently left over from failed native compilations.
They look like `lisp/foo.elcABCDEF` where `ABCDEF` is random
(presumably chosen by `make-temp-file`).

I haven't found a way to reproduce the problem, so I'm not sure exactly
how they got here but maybe we need to take more precautions to remove
them, and maybe we should put them in /tmp?


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48141; Package emacs. (Sat, 01 May 2021 14:45:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 48141 <at> debbugs.gnu.org
Subject: Re: bug#48141: 28.0.50; Files left over by native compiler
Date: Sat, 01 May 2021 17:44:14 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Sat, 01 May 2021 10:36:22 -0400
> 
> I have a few files apparently left over from failed native compilations.
> They look like `lisp/foo.elcABCDEF` where `ABCDEF` is random
> (presumably chosen by `make-temp-file`).
> 
> I haven't found a way to reproduce the problem, so I'm not sure exactly
> how they got here but maybe we need to take more precautions to remove
> them, and maybe we should put them in /tmp?

These are created by byte compiling, they aren't specific to native
compilations.  (AFAIR, we already had them in /tmp at some point, but
moved away of that for some good reasons that I cannot recall?)

I wouldn't be bothered by them, as failed native compilations will
sooner or later pass from the world...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48141; Package emacs. (Sat, 01 May 2021 16:55:01 GMT) Full text and rfc822 format available.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 48141 <at> debbugs.gnu.org
Subject: Re: bug#48141: 28.0.50; Files left over by native compiler
Date: Sat, 01 May 2021 12:54:25 -0400
Stefan Monnier wrote:

> I have a few files apparently left over from failed native compilations.
> They look like `lisp/foo.elcABCDEF` where `ABCDEF` is random
> (presumably chosen by `make-temp-file`).

This is not directly related to native compilation.
This is so creation of .elc files can be atomic (bug#4196).

> I haven't found a way to reproduce the problem, so I'm not sure exactly
> how they got here but maybe we need to take more precautions to remove
> them

I would guess that the only way this can happen is if Emacs dies during
byte-compilation, which is obviously not a normal situation.

> and maybe we should put them in /tmp?

IIUC, the temp files must be on the same partition as the destination
.elc files, else the move would not be atomic.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48141; Package emacs. (Sun, 02 May 2021 07:07:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 48141 <at> debbugs.gnu.org
Subject: Re: bug#48141: 28.0.50; Files left over by native compiler
Date: Sun, 02 May 2021 09:05:58 +0200
Glenn Morris <rgm <at> gnu.org> writes:

>> and maybe we should put them in /tmp?
>
> IIUC, the temp files must be on the same partition as the destination
> .elc files, else the move would not be atomic.

Well, we could create them in /tmp, and then move them to
lisp/foo.elcABCDEF, and then move them to lisp/foo.elc -- and it's
unlikely that things go wrong between the first and the second move,
which should lead to fewer of these files being left behind them Emacs
segfaults and stuff when generating the .elc files.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48141; Package emacs. (Mon, 03 May 2021 08:43:01 GMT) Full text and rfc822 format available.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 48141 <at> debbugs.gnu.org
Subject: Re: bug#48141: 28.0.50; Files left over by native compiler
Date: Mon, 03 May 2021 08:42:08 +0000
>> I have a few files apparently left over from failed native 
>> compilations. They look like `lisp/foo.elcABCDEF` where `ABCDEF` is 
>> random (presumably chosen by `make-temp-file`).
>
> This is not directly related to native compilation. This is so creation 
> of .elc files can be atomic (bug#4196).
>
>> and maybe we should put them in /tmp?
>
> IIUC, the temp files must be on the same partition as the destination 
> .elc files, else the move would not be atomic.
>

Given that requirement (atomicity) and its implication (same partition), 
would it not be better to create these temporary files in a 'tmp' 
subdirectory of their target directory (e.g. 'lisp/tmp' for el files in 
'lisp' and 'lisp/calc/tmp' for el files in 'lisp/calc') instead of using 
random filenames in the target directory itself?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48141; Package emacs. (Mon, 03 May 2021 11:51:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: rgm <at> gnu.org, monnier <at> iro.umontreal.ca, 48141 <at> debbugs.gnu.org
Subject: Re: bug#48141: 28.0.50; Files left over by native compiler
Date: Mon, 03 May 2021 14:49:53 +0300
> Date: Mon, 03 May 2021 08:42:08 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 48141 <at> debbugs.gnu.org
> 
> Given that requirement (atomicity) and its implication (same partition), 
> would it not be better to create these temporary files in a 'tmp' 
> subdirectory of their target directory (e.g. 'lisp/tmp' for el files in 
> 'lisp' and 'lisp/calc/tmp' for el files in 'lisp/calc') instead of using 
> random filenames in the target directory itself?

Since they will be in the tree anyway, why does it matter in what
subdirectory they will be deposited?

Using a subdirectory has a disadvantage: you need to create it and
delete it, which can hamper atomicity, and also cause trouble in
parallel builds.  So if the advantage is unclear, I'd rather not go
there.

There's nothing wrong with what we do now, IMO.  We arrived at that
after several iterations, which did try some of the suggestions in
this thread.  If Magit users are annoyed by their popping up
unexpectedly, adding them to .gitignore is TRT and will solve the
issue cleanly and safely.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48141; Package emacs. (Mon, 03 May 2021 12:12:02 GMT) Full text and rfc822 format available.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, monnier <at> iro.umontreal.ca, 48141 <at> debbugs.gnu.org
Subject: Re: bug#48141: 28.0.50; Files left over by native compiler
Date: Mon, 03 May 2021 12:11:25 +0000
>> Given that requirement (atomicity) and its implication (same 
>> partition), would it not be better to create these temporary files in a 
>> 'tmp' subdirectory of their target directory (e.g. 'lisp/tmp' for el 
>> files in 'lisp' and 'lisp/calc/tmp' for el files in 'lisp/calc') 
>> instead of using random filenames in the target directory itself?
>
> Since they will be in the tree anyway, why does it matter in what 
> subdirectory they will be deposited?
>

IMO it's easier to manage, both in .gitignore and to clean the temporary 
files.  But it's just a suggestion (inspired by the way maildirs work).




Merged 48141 52912. Request was from Glenn Morris <rgm <at> fencepost.gnu.org> to control <at> debbugs.gnu.org. (Fri, 31 Dec 2021 16:07:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 29.1, send any further explanations to 52912 <at> debbugs.gnu.org and Stefan Monnier <monnier <at> iro.umontreal.ca> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 20 Jan 2022 08:21:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 24 Feb 2022 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 34 days ago.

Previous Next


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