From: Stephen Berman <stephen.berman@gmx.net>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: 52735@debbugs.gnu.org
Subject: bug#52735: 29.0.50; Gnus hangs while getting new news
Date: Wed, 22 Dec 2021 18:42:05 +0100 [thread overview]
Message-ID: <87o858edua.fsf@gmx.net> (raw)
In-Reply-To: <87a6gsa9rs.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Wed, 22 Dec 2021 08:23:35 -0800")
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
next prev parent reply other threads:[~2021-12-22 17:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-22 15:13 bug#52735: 29.0.50; Gnus hangs while getting new news Stephen Berman
2021-12-22 16:23 ` Eric Abrahamsen
2021-12-22 17:42 ` Stephen Berman [this message]
2021-12-22 17:54 ` Eric Abrahamsen
2021-12-22 23:13 ` Stephen Berman
2021-12-23 0:01 ` Eric Abrahamsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o858edua.fsf@gmx.net \
--to=stephen.berman@gmx.net \
--cc=52735@debbugs.gnu.org \
--cc=eric@ericabrahamsen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.