VM

IMAP fetch hangs

Bug #735833 reported by Uday Reddy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
VM
Triaged
Medium
Uday Reddy
VM 8.3.90a

Bug Description

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.

Revision history for this message
Uday Reddy (reddyuday) wrote :

Notes:

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

Revision history for this message
Uday Reddy (reddyuday) wrote :

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.

Revision history for this message
Uday Reddy (reddyuday) wrote :

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.

Changed in vm:
status: Triaged → In Progress
milestone: 8.2.90a → 8.2.89a
Revision history for this message
Uday Reddy (reddyuday) wrote :

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

no longer affects: vm/8.2.x
Changed in vm:
milestone: 8.2.89a → 8.2.90a
status: In Progress → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.