GNU bug report logs - #30022
gnus nnimap-sequence vs yahoo hang

Previous Next

Packages: gnus, emacs;

Reported by: Kevin Ryde <user42_kevin <at> yahoo.com.au>

Date: Mon, 8 Jan 2018 06:03:02 UTC

Severity: normal

Found in version 5.13

Fixed in version 27.1

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30022 in the body.
You can then email your comments to 30022 AT debbugs.gnu.org in the normal way.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bugs <at> gnus.org:
bug#30022; Package gnus. (Mon, 08 Jan 2018 06:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kevin Ryde <user42_kevin <at> yahoo.com.au>:
New bug report received and forwarded. Copy sent to bugs <at> gnus.org. (Mon, 08 Jan 2018 06:03:02 GMT) Full text and rfc822 format available.

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

From: Kevin Ryde <user42_kevin <at> yahoo.com.au>
To: submit <at> debbugs.gnu.org
Subject: gnus nnimap-sequence vs yahoo hang
Date: Mon, 08 Jan 2018 17:01:40 +1100
[Message part 1 (text/plain, inline)]
With the gnus included in recent debian packaged i386 emacs 25.2, in the
Group buffer, an M-g to get count of messages of a foreign imap group at
imap.mail.yahoo.com hangs.  If C-g to stop then a second M-g succeeds.

Sticking in some protocol trace showed

    out >> 1 CAPABILITY
    out >> 1 LOGIN "username" "password"

    in  << 1 OK CAPABILITY completed
    out >> 2 SELECT "mailboxname"
    
    in  << 1 OK LOGIN completed
    hang ...

I suspect nnimap.el interprets "1 OK CAPABILITY" response as being login
completion, and issues the SELECT.  Could that be right?

I don't know if a server is supposed to allow pipelined SELECT before
login completes.  It seems recent imap.mail.yahoo.com doesn't like it.
I see nnimap-login uses nnimap-command so I take it the intention in
gnus is not to attempt such a thing anyway, but wait for login success.

I get some joy from the diff below setting nnimap-sequence so it starts
"2 LOGIN".  The first M-g then succeeds for me as hoped.

I think the reason a second M-g on the group succeeds is that
nnimap-sequence is left incremented after the first attempt, so it goes
"3 LOGIN" or whatever bigger number.

I have this on a rather lagged connection, if that might make a
difference.  I see the login taking a noticeable second or so, but don't
know if that's by the server or the connection.

-------------------
Gnus v5.13
GNU Emacs 25.2.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2017-09-12, modified by Debian

[0001-nnimap-sequence-initial-value-1-so-first-command-is-.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#30022; Package emacs,gnus. (Wed, 11 Apr 2018 21:02:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Ryde <user42_kevin <at> yahoo.com.au>
Cc: 30022 <at> debbugs.gnu.org
Subject: Re: bug#30022: gnus nnimap-sequence vs yahoo hang
Date: Wed, 11 Apr 2018 23:01:21 +0200
Kevin Ryde <user42_kevin <at> yahoo.com.au> writes:

> With the gnus included in recent debian packaged i386 emacs 25.2, in the
> Group buffer, an M-g to get count of messages of a foreign imap group at
> imap.mail.yahoo.com hangs.  If C-g to stop then a second M-g succeeds.
>
> Sticking in some protocol trace showed
>
>     out >> 1 CAPABILITY
>     out >> 1 LOGIN "username" "password"

Hm, that looks wrong.  nnimap should be increasing the sequence
number...

When I switch nnimap tracing on (by setting `nnimap-record-commands' to
t and looking in the " *imap log*" (note leading space) buffer, then I
get

1 LOGIN
2 CAPABILITY

which is what I'd expect.

Could you include the data from the logging buffer?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 11 Apr 2018 21:02:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#30022; Package emacs,gnus. (Fri, 13 Apr 2018 08:53:01 GMT) Full text and rfc822 format available.

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

From: Kevin Ryde <user42_kevin <at> yahoo.com.au>
To: 30022 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#30022: gnus nnimap-sequence vs yahoo hang
Date: Fri, 13 Apr 2018 18:50:22 +1000
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> When I switch nnimap tracing on (by setting `nnimap-record-commands' to
> t and looking in the " *imap log*" (note leading space) buffer, then I
> get
>
> 1 LOGIN
> 2 CAPABILITY

Yes, I see similar

    18:16:44 [imap.mail.yahoo.com] (inhibited)
    18:16:44 [imap.mail.yahoo.com] 2 CAPABILITY^M
    18:16:50 [imap.mail.yahoo.com] 3 SELECT "INBOX"^M

But I think this does not include output of open-protocol-stream
:capability-command "1 CAPABILITY" (in nnimap-open-connection-1).

I saw my trace by putting a front-end on gnutls-cli to print data sent
and received.

Could show :capability-command in *imap log* for completeness, since
it's a command sent.  That plus less inhibiting the login command could
have hinted at the problem.




Information forwarded to bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#30022; Package emacs,gnus. (Fri, 13 Apr 2018 11:42:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Ryde <user42_kevin <at> yahoo.com.au>
Cc: 30022 <at> debbugs.gnu.org
Subject: Re: bug#30022: gnus nnimap-sequence vs yahoo hang
Date: Fri, 13 Apr 2018 13:41:08 +0200
Kevin Ryde <user42_kevin <at> yahoo.com.au> writes:

> Yes, I see similar
>
>     18:16:44 [imap.mail.yahoo.com] (inhibited)
>     18:16:44 [imap.mail.yahoo.com] 2 CAPABILITY^M
>     18:16:50 [imap.mail.yahoo.com] 3 SELECT "INBOX"^M
>
> But I think this does not include output of open-protocol-stream
> :capability-command "1 CAPABILITY" (in nnimap-open-connection-1).

Oh, I see.  Well spotted.  I think the simplest solution here is to
start off the nnimap sequence at a higher number so that these things
don't get in each others way.

Does the following patch (pushed to Emacs master now) fix the problem
for you?

diff --git a/lisp/gnus/nnimap.el b/lisp/gnus/nnimap.el
index 01d7948afb..65d40eba69 100644
--- a/lisp/gnus/nnimap.el
+++ b/lisp/gnus/nnimap.el
@@ -1865,7 +1865,7 @@ nnimap-find-connection
 	(setq nnimap-connection-alist (delq entry nnimap-connection-alist))
 	nil))))
 
-(defvar nnimap-sequence 0)
+(defvar nnimap-sequence 5)
 
 (defun nnimap-send-command (&rest args)
   (setf (nnimap-last-command-time nnimap-object) (current-time))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#30022; Package emacs,gnus. (Sat, 14 Apr 2018 01:55:01 GMT) Full text and rfc822 format available.

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

From: Kevin Ryde <user42_kevin <at> yahoo.com.au>
To: 30022 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#30022: gnus nnimap-sequence vs yahoo hang
Date: Sat, 14 Apr 2018 11:51:50 +1000
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> Does the following patch (pushed to Emacs master now) fix the problem
> for you?
>
> -(defvar nnimap-sequence 0)
> +(defvar nnimap-sequence 5)

Yes.  Per my original report it's enough to set 1 if you like.
It's pre-incremented so the first command sent is sequence 2 which is
after 1 CAPABILITY.




Removed tag(s) moreinfo. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 08 Jan 2019 21:13:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 27.1, send any further explanations to 30022 <at> debbugs.gnu.org and Kevin Ryde <user42_kevin <at> yahoo.com.au> Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 08 Jan 2019 21:13:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 06 Feb 2019 12:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 52 days ago.

Previous Next


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