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: Thu, 23 Dec 2021 00:13:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

On Wed, 22 Dec 2021 09:54:32 -0800 Eric Abrahamsen <eric@ericabrahamsen.net> 
wrote:

 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).

I haven't succeeded in following the nntp-accept-response call that
leaves the server buffer empty to any code calling copy-to-buffer.  The
pattern I see is that there are two calls of nntp-accept-response in the
while-loop that leave the buffer empty, and on the third iteration,
either the buffer is filled with data, or it remains empty, causing the
hang.  I added a counter to the loop and when it reaches 3 a call to
nntp-kill-buffer to kill the server buffer: this results in a bunch of
"Warning - invalid active" messages but doesn't hang.  When I then type
`g' in the *Group* buffer, fetching new news successfully completes.  So
this just mimics the effect of `C-g' followed by `g' as I reported
above.  But I'm no closer to the reason for the hang or how to track it
down.  Since no one else seems to be having this problem, that suggests
a problem with my connection to news.gmane.io; is there anything I can
do to investigate that?

Steve Berman





reply via email to

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