IMAP fetch hangs

[Uday Reddy]

For a while now, I have been noticing Emacs/VM hanging in the middle of a body fetch from an IMAP server. It happened today in the midst of an IMAP session. When interrupted, it gave the message:

byte-code: Unable to load message; Args out of range: 280287, 23426700

The IMAP trace buffer shows:

VM NOOP
VM OK NOOP completed.
VM UID FETCH 40354:40354 (RFC822.SIZE)
* 4369 FETCH (RFC822.SIZE 3648 UID 40354)
VM OK Fetch completed.
VM UID FETCH 40354:40354 (BODY.PEEK[])
* 4369 FETCH (UID 40354 BODY[] {3648}
)
VM OK Fetch completed.
VM NOOP
VM OK NOOP completed.
VM UID FETCH 40384:40384 (RFC822.SIZE)
* 4399 FETCH (RFC822.SIZE 3956 UID 40384)
VM OK Fetch completed.

When the operation is repeated (trying to read message), it works fine:

VM NOOP
* 4431 EXISTS
* 1 RECENT
VM OK NOOP completed.
VM UID FETCH 40384:40384 (RFC822.SIZE)
* 4399 FETCH (RFC822.SIZE 3956 UID 40384)
VM OK Fetch completed.
VM UID FETCH 40384:40384 (BODY.PEEK[])
* 4399 FETCH (UID 40384 BODY[] {3956}
)
VM OK Fetch completed.

[Uday Reddy (reddyuday)]

Notes:

vm-imap-log-sessions can be used to monitor the progress of the IMAP processing.

[Uday Reddy (reddyuday)]

Possibly related problem occurred yesterday, where only 3-4 messages needed to be fetched from the department IMAP server, but resulted in the error

  "expected (BODY[] string) in FETCH response"

in the second message. Looking at the trace buffer and `vm-imap-tokens' showed that the entire message body had been parsed as a server response. That means that the actual response line, which looks like:

* 957 FETCH (BODY[] {5540}

wasn't parsed correctly. Is there a bug in the parser, or is this a result of an asynchronous buffer change (old Emacs problem)?

Unfortunately, I didn't save the `vm-imap-tokens' list. So I couldn't investigate further.

[Uday Reddy (reddyuday)]

Similar problem occurred today. vm-imap-tokens shows a log like this:

 retrieve
 response #<marker at 110199 in IMAP mailhost.c 14:43:44>
 object #<buffer IMAP mailhost.c 14:43:44> "*" 110200 (atom 110199 110200)
 object #<buffer IMAP mailhost.c 14:43:44> "1669" 110205 (atom 110201 110205)
 object #<buffer IMAP mailhost.c 14:43:44> "FETCH" 110211 (atom 110206 110211)
 object #<buffer IMAP mailhost.c 14:43:44>
 object #<buffer IMAP mailhost.c 14:43:44> "BODY" 110217 (atom 110213 110217)
 object #<buffer IMAP mailhost.c 14:43:44>
   object #<buffer IMAP mailhost.c 14:43:44> 110219 (close-bracket)
 110219 (vector)
 object #<buffer IMAP mailhost.c 14:43:44> 110221 (open-brace)
 object #<buffer IMAP mailhost.c 14:43:44> "5441" "5441" 110225 (atom 110221 110225)
 object #<buffer IMAP mailhost.c 14:43:44> 110226 (close-brace)
 object #<buffer IMAP mailhost.c 14:43:44> "Return-path:" 110240
 (atom 110228 110240)

The (open-brace) is being recognized as a separate token (even though it is the beginning of a string of octets) because of a check added in revision 835.2.14 to allow non-numeric text in braces which gmail spews out occasionally. (Where is its bug report?) "5441" is obviously numeric, but there is probably a timing problem in recognizing it. Disabling the numeric check allowed the retrieval to proceed fine.

[Uday Reddy (reddyuday)]

The original bug report had nothing to do with the numeric check because the revision 835.2.14 is dated 2011-08-09. So, we will spawn this as a new bug report. (Bug 926210).