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: Stephen Berman
Subject: bug#52735: 29.0.50; Gnus hangs while getting new news
Date: Wed, 22 Dec 2021 18:42:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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.

Steve Berman





reply via email to

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