GNU bug report logs - #75209
30.0.93; Emacs reader failed to read data in "/home/nlj/.cache/org-persist/gc-lock.eld"

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 75209 <at> debbugs.gnu.org,
 "N. Jackson" <njackson <at> posteo.net>
Subject: Re: bug#75209: 30.0.93; Emacs reader failed to read data in
 "/home/nlj/.cache/org-persist/gc-lock.eld"
Date: Wed, 01 Jan 2025 17:41:57 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> From: "N. Jackson" <njackson <at> posteo.net>
>> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,  75209 <at> debbugs.gnu.org
>> Date: Mon, 30 Dec 2024 19:53:42 +0000
>>
>> At 21:31 +0200 on Monday 2024-12-30, Eli Zaretskii wrote:
>>
>> >> From: "N. Jackson" <njackson <at> posteo.net>
>> >> Date: Mon, 30 Dec 2024 18:48:31 +0000
>> >>
>> >>   Warning (emacs): Emacs reader failed to read data in
>> >>   "/home/nlj/.cache/org-persist/gc-lock.eld". The error was: "End
>> >>   of file during parsing"
>>
>> > Does the file exist?  If so, what is its content (assuming you can
>> > post it here)?
>>
>> It exists and currently has the following contents:
>>
>>   ;;   -*- mode: lisp-data; -*-
>>   (((26482 57035 301257 992000) 26482 60639 74163 973000) ((26482 62694 821331 522000) 26482 62698 583212 450000))
>
> This one seems okay.  I guess we need to wait for the warning and see
> then?

I'm assuming that the resolution was that the file was read before we
finished writing it.  I've run into the same issue a number of times
(interrupting and resuming Emacs builds leads to build failures, "make
bootstrap" makes them go away).

Can we consider modifying the .elc format to have a footer indicating
that the file is complete?  Ideally, it would also indicate the checksum
of the file as well as the fact that it is complete, but this would have
a performance impact which might be significant in some cases (very
large .elc files; of course, we could simply modify the footer to
indicate a "too large to checksum" condition has occurred, if the file
is large).

It's tempting to put this information in the header, the way we do for
pdumps (they are first written to start with "!UMPEDGNUEMACS", then the
last thing pdumper does is to rewrite the first character to be "D"),
but using a footer is more reliable: it detects truncation (or
modification) for whatever reason, and makes fewer assumptions about
data atomicity.

While we're in there, let's indicate in the ELC header whether the
special circumstances of native compilation applied to the compilation
process of this file.  This is particularly important if we use
benchmarks defined in .elc files: using the wrong compiled version would
lead to unreliable benchmark results, and be somewhat difficult to
detect otherwise.  (I'm assuming it is still the case that
native-compiling a Lisp file leaves behind user-visible .elc artifacts.
If that has been fixed, please ignore this paragraph).

But, please, no timestamp.  Let's keep things reproducible where we can,
and not leak sensitive information by accident.

It may be necessary to bump the produced ELC version code for this.

The equivalent issues are less urgent, but ultimately identical, for
pdumper files (apparently, we don't detect truncation or modification)
and object files produced during the build (it's the job of the make
implementation and the compiler to avoid truncated .o files, but if they
don't do that, we might want to write x.o.tmp first, then rename it, in
the usual fashion of Makefiles).

Note that it is, of course, possible to usefully modify .elc (and .pdmp)
files after creation, so we shouldn't make detected modifications an
unconditional error.

Pip

Previous Next

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