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

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 75209 <at> debbugs.gnu.org, njackson <at> posteo.net
Subject: 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 21:09:24 +0000

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

>> Date: Wed, 01 Jan 2025 17:41:57 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: "N. Jackson" <njackson <at> posteo.net>, yantar92 <at> posteo.net, 75209 <at> debbugs.gnu.org
>>
>> 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?
>
> The .elc file is supposed to be created only when the compilation is
> complete and successful.  If you look at byte-compile-file, you will

You're right.  Sorry for the noise.  The most likely explanation is I
missed a "Pure Lisp storage overflowed" message which "explained" it,
because I just tried and that's what happened.

There's a bug in pin_string which assumes no purespace overflow, and
corrupts bytecode after one, so it's entirely possible that an .elc file
was truncated.  Probably not worth fixing at this point.

I'll try interrupting a few more builds when no-purespace is merged.

Pip

Previous Next

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