bug#52735: 29.0.50; Gnus hangs while getting new news

[Eric Abrahamsen]

On 12/22/21 18:42 PM, Stephen Berman wrote:
> On Wed, 22 Dec 2021 08:23:35 -0800 Eric Abrahamsen <eric@ericabrahamsen.net> 
> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> The hang appears to happen in nntp-finish-retrieve-group-infos: stepping
>>> through the code with Edebug, I see an infinite loop here:
>>>
>>>           (while (and (gnus-buffer-live-p buf)
>>>                   (progn
>>>                     (goto-char last-point)
>>>                     ;; Count replies.
>>>                     (while (re-search-forward
>>>                             (if nntp-server-list-active-group
>>>                                 "^[.]"
>>>                               "^[0-9]")
>>>                             nil t)
>>>                       (cl-incf received))
>>>                     (setq last-point (point))
>>>                     (< received count)))
>>>         (nntp-accept-response))
>>>
>>> when the server buffer (e.g. " *server news.gmane.io nntp *nntpd**") is
>>> empty.  Since this code clearly does not expect an empty buffer, the bug
>>> is presumably making this buffer empty when this code is executed.  But
>>> I haven't managed to figure out how this happens.  (I have seen that
>>> this buffer can become empty in other situations, e.g. on opening an
>>> article in Gnus, and that doesn't cause any problems.)  I've also
>>> observed that when I wait long enough for the server process to close
>>> (the buffer then shows "Process nntpd connection broken by remote
>>> peer"), then there is no hang on typing `g' in the *Group* buffer.
>>
>> The only thing I can suggest now is more debugging on
>> `nntp-finish-retrieve-group-infos', and try to get a backtrace for both
>> the buggy empty-buffer situation, and the normal, non-empty-buffer
>> situation. Perhaps comparing the two backtraces will provide a clue as
>> to how we ended up with an empty buffer?
>
> So far, I determined that problem isn't the empty buffer per se, but
> that it remains empty after (nntp-accept-response) returns, that's why
> the while-loop keeps looping.  I'll try to dig into nntp-accept-response.

This is probably a total red herring, but... look for `copy-to-buffer'
calls that are pointing at the wrong buffer (ie, the process output is
supposed to go to nntp-server-buffer, but it goes elsewhere).