bug-gnu-emacs
[Top][All Lists]
Advanced

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]