GNU bug report logs - #62845
29.0.90; nntp-with-open-group-function kills current buffer on timeout

Previous Next

Full log

View this message in rfc822 format

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> linux-m68k.org, 62845 <at> debbugs.gnu.org
Subject: bug#62845: 29.0.90; nntp-with-open-group-function kills current buffer on timeout
Date: Wed, 10 May 2023 11:21:42 -0700

On 05/10/23 18:53 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  62845 <at> debbugs.gnu.org
>> Date: Sat, 06 May 2023 22:52:17 -0700
>> 
>> 
>> On 05/06/23 19:43 PM, Andreas Schwab wrote:
>> > On Mai 06 2023, Eric Abrahamsen wrote:
>> >
>> > You cannot recreate a buffer once it is killed.  You can create a new
>> > buffer, but it will always be a different buffer.
>> 
>> But `nntp-possibly-change-group' re-initializes `nntp-server-buffer' to
>> a new buffer, and the `nntp-find-connection-buffer' inside
>> `nntp-retrieve-group-data-early' uses the value of `nntp-server-buffer'
>> to find its process. My reading is that each time the with-open-group
>> function runs, its `bodyfun' lambda should get a new opportunity to find
>> a live `nntp-server-buffer'.
>> 
>> Plus, if the buffer were already dead the second time through,
>> `nntp-retrieve-group-data-early' has sufficient guards to simply bail
>> before doing anything.
>> 
>> I'm not trying to be stubborn here, I assume your analysis is
>> essentially right, I'm just trying to make sure I actually understand
>> what's happening in the code.
>> 
>> Even if it does require two timeouts in a row, I get that plenty often
>> with a `nntp-connection-timeout' value of 6.
>
> Eric, any progress here?
>
> If no better ideas are ready to be implemented, I think we should
> revert that commit on emacs-29 and leave it on master, where work on
> fixing this fallout should continue.  OK?

Yeah, I haven't made much progress in the time I've had to look at this
(and I still don't completely understand the current error!).

I think the commit should be reverted on both emacs-29 and master. It
was there to fix an inconvenience (an nntp failure would halt a Gnus
refresh at the top level), but it caused an actual bug (Gnus messes with
the contents of random buffers). Better to go back to the inconvenience
until a fuller solution is found.

Thanks,
Eric

Previous Next

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