GNU bug report logs -
#52735
29.0.50; Gnus hangs while getting new news
Previous Next
Full log
View this message in rfc822 format
On 12/23/21 00:13 AM, Stephen Berman wrote:
> On Wed, 22 Dec 2021 09:54:32 -0800 Eric Abrahamsen <eric <at> 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 <at> ericabrahamsen.net> wrote:
>>>
>>>> Stephen Berman <stephen.berman <at> 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?
Okay, we're probably looking at different issues, sorry for the
distraction. Unfortunately, I don't have any bright ideas for the
problem you're facing...
This bug report was last modified 3 years and 233 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.