[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52735: 29.0.50; Gnus hangs while getting new news
From: |
Eric Abrahamsen |
Subject: |
bug#52735: 29.0.50; Gnus hangs while getting new news |
Date: |
Wed, 22 Dec 2021 08:23:35 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Stephen Berman <stephen.berman@gmx.net> 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?