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

From: Eric Abrahamsen <[email-masked]>
Date: Wed, 22 Dec 2021 08:23:35 -0800

Stephen Berman <[email-masked]> writes:

> Since more than a week (I think it started on December 11), I've been
> regularly experiencing a hang when I type `g' in the Gnus *Group*
> buffer: the mouse pointer spins, and Emacs is locked up.  Typing `C-g'
> releases the hang and then typing `g' again succeeds in fetching new
> news.  I can also get a hang when typing RET on an article line in the
> Gnus *Summary* buffer, and also here typing `C-g' releases the hang and
> typing RET again opens the article.  These hangs happen reliably when I
> don't provide any input to Gnus (e.g., opening a group or an article, or
> just check again for new news) within several minutes (I haven't
> determined a more precise amount of time).  They only involve the
> news.gmane.io server, not any of the mail servers I fetch mail from (I
> haven't tried any other news server).
>
> 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?