GNU bug report logs - #52735
29.0.50; Gnus hangs while getting new news

Previous Next

To reply to this bug, email your comments to 52735 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Gnus hangs while getting new news
Date: Wed, 22 Dec 2021 16:13:39 +0100

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.

To my surprise, these hangs happen with all builds of Emacs I have:
master, 28, 27 and 26, which indicates the problem is not directly due
to a recent code change.  I also haven't knowingly made any changes in
my setup since I began observing this problem (moreover, I also seem to
get a hang when I start Gnus from -Q and open news.gmane.io, though I
haven't tried stepping through the code then to see if it's really the
same issue).  If there were a problem with news.gmane.io, I'd have
expected to see other reports or find some mention on the internet, but
I haven't.  Perhaps some unrelated recent code change somehow causes the
server buffer to become empty at the wrong point.  Or maybe my debugging
is faulty and the problem lies elsewhere.  I'll gladly try any
suggestions.


In GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.29, cairo version 1.17.4)
 of 2021-12-22 built on strobelfs
Repository revision: 70266929c3eb173fae0c64d56f8d402a805ca786
Repository branch: master
Windowing system distributor 'System Description: Linux From Scratch 10.2-rc1

Configured using:
 'configure --with-pgtk 'CFLAGS=-Og -g3''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XIM GTK3
ZLIB

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#52735: 29.0.50; Gnus hangs while getting new news
Date: Wed, 22 Dec 2021 08:23:35 -0800

Stephen Berman <stephen.berman <at> 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?

Message #11 received at 52735 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 52735 <at> debbugs.gnu.org
Subject: Re: bug#52735: 29.0.50; Gnus hangs while getting new news
Date: Wed, 22 Dec 2021 18:42:05 +0100

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.

Steve Berman

Message #14 received at 52735 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 52735 <at> debbugs.gnu.org
Subject: Re: bug#52735: 29.0.50; Gnus hangs while getting new news
Date: Wed, 22 Dec 2021 09:54:32 -0800

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

Message #17 received at 52735 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 52735 <at> debbugs.gnu.org
Subject: Re: bug#52735: 29.0.50; Gnus hangs while getting new news
Date: Thu, 23 Dec 2021 00:13:38 +0100

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?

Steve Berman

Message #20 received at 52735 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 52735 <at> debbugs.gnu.org
Subject: Re: bug#52735: 29.0.50; Gnus hangs while getting new news
Date: Wed, 22 Dec 2021 16:01:25 -0800

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.