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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 06 Jan 2025 15:49:37 +0200

> From: "N. Jackson" <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Mon, 06 Jan 2025 00:58:21 +0000
> 
> 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.

I think you are right.  I think the mechanisms involved in this
scenario should be audited to find possible problems and solutions.
For example, if the timer function could signal an error, it should
catch the error and handle it instead of leading to the timer being
disabled.

> [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.

Because the data for investigating it was not available.