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

["N. Jackson" <njackson@posteo.net>]

At 19:21 +0200 on Sunday 2025-01-05, Eli Zaretskii wrote:

>> From: "N. Jackson" <njackson@posteo.net>
>> 
>> Running list-timers shows:
>> 
>> Idle                Next  Repeat Function
>>        -1d 15h 43m 30.2s      1h org-persist--refresh-gc-lock
>
> This timer is disabled.  See bug#39824 for some related discussions,
> in particular
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39824#53

I have now read that bug report and I admit I don't fully understand
it[1].

IIUC, the user's timer had encountered an error, a backtrace had
been produced, and the user had said `q' to the debugger, leaving
the timer in a broken state.

Here, like in that bug report, the broken timer has `t' in the first
element:

  [t 26490 7240 117604 3600 org-persist--refresh-gc-lock nil nil 17000 nil]

However, I have seen no error.  (If I were presented with a
backtrace, I would almost certainly make a copy of the buffer and
then hit `c' rather than `q', but in fact I haven't seen a backtrace
in a long time.  Indeed, debug-on-error is nil.  I have seen no
error messages in this run of Emacs and there are no errors (or
anything else unexpected in Messages).)

I'm guessing (wildly) that what happened is this:

1.  I woke my system from suspend.

2.  All timers in both my instances of Emacs ran roughly
    simultaneously.

3.  Org Mode's locking mechanisms are not working properly when two
    copies of org-persist--refresh-gc-lock run at essentially the 
    same time, and it failed in one instance of Emacs.

4.  Org Mode (or something else) caught the failure and reported

      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"

    and the running of the timer was aborted, leaving it in a broken
    state.

I think this wild conjecture would explain why sometimes (but by no
means always) I see this warning when I resume from suspend; why I
rarely see the warning at other times; and why sometimes I see the
warning in my regular Emacs session and sometimes in the instance in
which I'm running Gnus.


(One other observation: IIUC, it says in bug#39824 that the broken
timer moves farther into the past, but here my broken timer is
counting forward (it is now due in negative 1 day and 5 hours) so
presumably in a day or so it will no longer be negative.  Will it
then start running again I wonder?  If this behaviour is expected,
perhaps it should be mentioned in the documentation.  It seems a bit
peculiar to me.)

[1] I don't understand why bug#39824 was closed as Not A Bug when
the mystery of how the timers got in an incoherent state wasn't
fully clarified.  (But maybe it was well understood and the
mechanism was too trivial to record.) [And I don't think, just
because a timer fails once, that one necessarily wants that timer
disabled (because the problem might be transient).  Also it seems to
me that if a timer is going to be disabled then that should be done
explicitly rather than as a side-effect of an abort.]  But that is
all irrelevant here.