gnus hangs on entry to group

gnus hangs on entry to group

[Laura Conrad]

I have reported a problem similar to this, but I don't remember this
particular backtrace, so I mention it again.

I'm getting news from leafnode on localhost.  This morning, pgnus 0.97 hangs 
when I try to enter the group rec.music.early.  

The debug-on-quit backtrace is:


Signaling: (quit)
  accept-process-output(#<network connection "nntpd" ("nntp" . "localhost") state:run> 1)
  nntp-accept-process-output(#<network connection "nntpd" ("nntp" . "localhost") state:run>)
  nntp-send-command-nodelete("\r?\n\\.\r?\n" "XOVER" "123-123")
  nntp-send-xover-command(123 123)
  nntp-retrieve-headers-with-xover((123 152 231 268 270 1043 1303 1359 1360 1361) nil)
  nntp-retrieve-headers((123 152 231 268 270 1043 1303 1359 1360 1361) "rec.music.early" "localhost" nil)
  gnus-retrieve-headers((123 152 231 268 270 1043 1303 1359 1360 1361) "rec.music.early" nil)
  gnus-cache-retrieve-headers((123 152 231 268 270 1043 1303 1359 1360 1361) "rec.music.early" nil)
  gnus-retrieve-headers((123 152 231 268 270 1043 1303 1359 1360 1361) "rec.music.early" nil)
  gnus-select-newsgroup("rec.music.early" nil nil)
  gnus-summary-read-group-1("rec.music.early" nil nil nil nil nil)
  gnus-summary-read-group("rec.music.early" nil nil nil nil nil nil)
  gnus-group-read-group(nil)
  call-interactively(gnus-group-read-group)

And telneting gives:

[lconrad@serpent november]$ telnet localhost 119
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
200 Leafnode NNTP Daemon, version 1.9.4 running at serpent.local
group rec.music.early
211 1244 118 1361 rec.music.early group selected
xover 123-123
420 No articles in specified range.


-- 
Laura (mailto:lconrad@world.std.com , http://www.world.std.com/~lconrad/ )
(617) 661-8097	fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

Re: gnus hangs on entry to group

[Shenghuo ZHU]

>>>>> "LC" == Laura Conrad <lconrad@world.std.com> writes:

LC> I have reported a problem similar to this, but I don't remember this
LC> particular backtrace, so I mention it again.

LC> I'm getting news from leafnode on localhost.  This morning, pgnus 0.97 hangs 
LC> when I try to enter the group rec.music.early.  

LC> The debug-on-quit backtrace is:


LC> Signaling: (quit)
LC>   accept-process-output(#<network connection "nntpd" ("nntp" . "localhost") state:run> 1)
LC>   nntp-accept-process-output(#<network connection "nntpd" ("nntp" . "localhost") state:run>)
LC>   nntp-send-command-nodelete("\r?\n\\.\r?\n" "XOVER" "123-123")
LC>   nntp-send-xover-command(123 123)
LC>   nntp-retrieve-headers-with-xover((123 152 231 268 270 1043 1303 1359 1360 1361) nil)
LC>   nntp-retrieve-headers((123 152 231 268 270 1043 1303 1359 1360 1361) "rec.music.early" "localhost" nil)
LC>   gnus-retrieve-headers((123 152 231 268 270 1043 1303 1359 1360 1361) "rec.music.early" nil)
LC>   gnus-cache-retrieve-headers((123 152 231 268 270 1043 1303 1359 1360 1361) "rec.music.early" nil)
LC>   gnus-retrieve-headers((123 152 231 268 270 1043 1303 1359 1360 1361) "rec.music.early" nil)
LC>   gnus-select-newsgroup("rec.music.early" nil nil)
LC>   gnus-summary-read-group-1("rec.music.early" nil nil nil nil nil)
LC>   gnus-summary-read-group("rec.music.early" nil nil nil nil nil nil)
LC>   gnus-group-read-group(nil)
LC>   call-interactively(gnus-group-read-group)

LC> And telneting gives:

LC> [lconrad@serpent november]$ telnet localhost 119
LC> Trying 127.0.0.1...
LC> Connected to localhost.
LC> Escape character is '^]'.
LC> 200 Leafnode NNTP Daemon, version 1.9.4 running at serpent.local
LC> group rec.music.early
LC> 211 1244 118 1361 rec.music.early group selected
LC> xover 123-123
LC> 420 No articles in specified range.


420 is really bad. In some NNTPD, it is supposed to return "\n.\n"
followed by a "2xx" when there is no articles in specified
range. Although I can not find bug in `nntp-send-command-nodelete'
(actually in `nntp-wait-for'), I fixed a bug in
`nntp-send-xover-command'.  I've committed it to CVS a few weeks ago.

In your backtrace, `nntp-send-xover-command' only got two arguments
(third argument `wait-for-reply' is nil), so we don't suppose it will
wait for something (unless it is a first (`try') action). The bug
cause gnus wait. Though, gnus wouldn't be hanging if `nntp-wait-for'
worked properly, I guess.

In addition, I also suggest you set `nntp-server-xover' to "XOVER",
the "420" response may mislead gnus to disable XOVER.

[...]

-- 
Shenghuo ZHU