From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs 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 17:41:57 +0000 Message-ID: <87a5camnyu.fsf@protonmail.com> References: <878qrxgg74.fsf@Phoenix> <864j2lnf1j.fsf@gnu.org> <87zfkddk1l.fsf@Phoenix> <86zfkdlz39.fsf@gnu.org> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24540"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, 75209@debbugs.gnu.org, "N. Jackson" To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 01 18:43:28 2025 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 1tT2ki-0006Ed-2n for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 Jan 2025 18:43:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tT2kM-0006ys-3V; Wed, 01 Jan 2025 12:43:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tT2kI-0006yV-HI for bug-gnu-emacs@gnu.org; Wed, 01 Jan 2025 12:43:04 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tT2kI-0002B1-9A for bug-gnu-emacs@gnu.org; Wed, 01 Jan 2025 12:43:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:From:Date:To:Subject; bh=9LV14EyuA+S5gkHV+lc2U94n3lG0pI7UBjxFbuvq8Cs=; b=sv9q8QlQ917hQNimW8gdxLwz4B+/gOa8PB1TdwpdWk26pckAmECn9TYUJ65ree+E0NqQ7Rd2gKPgGbwBjuTQZ+9bDBFWwiatUaEei3XX0tnRayccniLgp5g6ALwRElDb4mfwBSYeGG7Fg51RShFuXsfWU7FgKkjgiOWj3+BvKoYa/kcxyc9F0w73H79Cwsbb9/d+iROYiQwP/aMwbXbhe7SbIQ/UguFXS3mDthalWHM8m4Cl1ekAR09UnxI+3ED2/AZWiPO3YRidlKyTPlorm0KM1RurjcEVKO6lw1hURYUI87zNDBSOVnsdy+/e5ezexIHfuTD5wWPDB0qfW9o2ig==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tT2kH-0002oZ-RI for bug-gnu-emacs@gnu.org; Wed, 01 Jan 2025 12:43:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Jan 2025 17:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75209 X-GNU-PR-Package: emacs Original-Received: via spool by 75209-submit@debbugs.gnu.org id=B75209.173575333310686 (code B ref 75209); Wed, 01 Jan 2025 17:43:01 +0000 Original-Received: (at 75209) by debbugs.gnu.org; 1 Jan 2025 17:42:13 +0000 Original-Received: from localhost ([127.0.0.1]:39699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tT2jV-0002mG-0r for submit@debbugs.gnu.org; Wed, 01 Jan 2025 12:42:13 -0500 Original-Received: from mail-10631.protonmail.ch ([79.135.106.31]:28495) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tT2jR-0002li-J7 for 75209@debbugs.gnu.org; Wed, 01 Jan 2025 12:42:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735753321; x=1736012521; bh=9LV14EyuA+S5gkHV+lc2U94n3lG0pI7UBjxFbuvq8Cs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=c5b+UF+P6e7nVrIckQUgpAnVI8o4F4E+D88i13CGVycwFkQVnNGTYAHH81ASoLbXA Vt1v133oRsO6v2vXyvegEgu0jDxc8FHSkH9NFdD+ORyU3DrIXdM5FKUuU1WeqxlI6d OOnnkmxOqzXB7JbzveMMGZMzCNmNBYejx8p+Weg120n/ocECA3jhy/I6PK0t4zRB5q ULVOhZv1cjCE9HirJXvkCWgFljvSd95z316Z00wMV/HTY7SRAk2A3RFZKxIEg31UNA J78BpPUBCCbOn7wCt5DDzFaVLmyFaLZHBoOz8rjHsS4ROVgis5UDB3+uku2fBMdifo BoPWL7G2cunCA== In-Reply-To: <86zfkdlz39.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e0af420c2aa1576e32d2d7bd1b938438874b0d44 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298066 Archived-At: "Eli Zaretskii" writes: >> From: "N. Jackson" >> Cc: Ihor Radchenko , 75209@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" >> >> 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