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 #89 received at 75209 <at> debbugs.gnu.org (full text, mbox):

From: "N. Jackson" <njackson <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>, Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75209 <at> debbugs.gnu.org
Subject: Re: bug#75209: 30.0.93; Emacs reader failed to read data in
 "/home/nlj/.cache/org-persist/gc-lock.eld"
Date: Sun, 26 Jan 2025 00:42:21 +0000

At 10:53 +0200 on Saturday 2025-01-25, Eli Zaretskii wrote:
>
> Ping!  Any progress with this issue?  Any new data?
>
>> From: "N. Jackson" <njackson <at> posteo.net>
>> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,  75209 <at> debbugs.gnu.org
>> Date: Mon, 13 Jan 2025 15:36:04 +0000
>> 
>> This is the change I have made here for testing:
>> 
>> --- Emacs-30.0.93/org-persist.el	2024-12-18 17:30:29.000000000 -0500
>> +++ atomic_write/org-persist.el	2025-01-12 18:58:58.230823402 -0500
>> @@ -475,7 +475,8 @@
>>          (print-escape-nonascii t)
>>          (print-continuous-numbering t)
>>          print-number-table
>> -        (start-time (float-time)))
>> +        (start-time (float-time))
>> +        (tmp-file (make-temp-file "org-persist-")))
>>      (unless (file-exists-p (file-name-directory file))
>>        (make-directory (file-name-directory file) t))
>>      ;; Force writing even when the file happens to be opened by
>> @@ -483,12 +484,19 @@
>>      (cl-letf (((symbol-function #'ask-user-about-lock)
>>                 ;; FIXME: Emacs 27 does not yet have `always'.
>>                 (lambda (&rest _) t)))
>> -      (with-temp-file file
>> +      ;; Do not write to FILE directly.  Another Emacs instance may be
>> +      ;; doing the same at the same time.  Instead, write to new
>> +      ;; temporary file and then rename it (renaming is atomic
>> +      ;; operation that does not create data races).
>> +      ;; See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75209#35
>> +      (with-temp-file tmp-file
>>          (insert ";;   -*- mode: lisp-data; -*-\n")
>>          (if pp
>>              (let ((pp-use-max-width nil)) ; Emacs bug#58687
>>                (pp data (current-buffer)))
>> -          (prin1 data (current-buffer)))))
>> +          (prin1 data (current-buffer))))
>> +      (rename-file tmp-file file 'overwrite))
>> +    
>>      (org-persist--display-time
>>       (- (float-time) start-time)
>>       "Writing to %S" file)))

Hello Eli,

Yes.  Unfortunately I can report that when I woke my system from
suspend this morning I saw the bug -- after about eleven days.  So I
can say that the patch I showed above (that tests doing an atomic
write by renaming a temporary file) is not sufficient.

I'm not sure where to go from here.

[I have now advised the org-persist--refresh-gc-lock timer handler
to log (each time the timer is called and in separate log files,
one for each instance of Emacs) the exact time, the state of the
timer, and whether the handler returned cleanly.  Maybe this will
shed some more light on what is happening -- or at least suggest a
way to trigger the bug more quickly.]

At 17:27 +0000 on Monday 2025-01-13, Ihor Radchenko wrote:
>
> I recommend following https://orgmode.org/manual/Installation.html
> In particular, the part about installing Org from git repository.

If the presence of the bug were something that could be tested in a
few minutes, I would be happy to test with Org mainline.  But the
bug takes several days (or weeks) to manifest.  That would mean I
would have to run the bleeding edge version of Org for my everyday
tasks and I just wouldn't be comfortable not using a version that's
been released and tested, because Org is critical to organising and
scheduling everything in my world.

Also, even if I did run Org mainline and after a suitable period of
testing the bug seemed to be gone, where would that leave us in
Emacs 30?

Previous Next

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