Bug 123421 - Endless SELECT/FETCH loop.
Endless SELECT/FETCH loop.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dovecot (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-18 09:23 EDT by David Woodhouse
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-22 15:49:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2004-05-18 09:23:29 EDT
Description of problem:
When selecting a certain folder, Evolution goes into an endless loop
repeating the same IMAP actions.

Version-Release number of selected component (if applicable):
1.4.6-2

sending : B02155 SELECT rhlists.kernel-team
received: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
received: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen
\Draft \*)] Fl
ags permitted.
received: * 357 EXISTS
received: * 7 RECENT
received: * OK [UNSEEN 23] First unseen.
received: * OK [UIDVALIDITY 1081503301] UIDs valid
received: * OK [UIDNEXT 358] Predicted next UID
received: B02155 OK [READ-WRITE] Select completed.
sending : B02156 FETCH 356 UID
received: * 356 FETCH (UID 356)
received: B02156 OK Fetch completed.
sending : B02157 UID FETCH 357:* (FLAGS RFC822.SIZE INTERNALDATE
BODY.PEEK[HEADE
R.FIELDS.NOT (RECEIVED)])
received: * 351 FETCH (UID 357 FLAGS (\Recent) INTERNALDATE
"18-May-2004 13:36:1
5 +0100" RFC822.SIZE 6376 BODY[HEADER.FIELDS.NOT (RECEIVED)] {1381}
received: )
received: B02157 OK Fetch completed.
sending : B02158 SELECT rhlists.kernel-team
received: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
received: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen
\Draft \*)] Fl
ags permitted.
received: * 357 EXISTS
received: * 7 RECENT
received: * OK [UNSEEN 23] First unseen.
received: * OK [UIDVALIDITY 1081503301] UIDs valid
received: * OK [UIDNEXT 358] Predicted next UID
received: B02158 OK [READ-WRITE] Select completed.
sending : B02159 FETCH 356 UID
received: * 356 FETCH (UID 356)
received: B02159 OK Fetch completed.
sending : B02160 UID FETCH 357:* (FLAGS RFC822.SIZE INTERNALDATE
BODY.PEEK[HEADE
R.FIELDS.NOT (RECEIVED)])
received: * 351 FETCH (UID 357 FLAGS (\Recent) INTERNALDATE
"18-May-2004 13:36:1
5 +0100" RFC822.SIZE 6376 BODY[HEADER.FIELDS.NOT (RECEIVED)] {1381}
received: )
received: B02160 OK Fetch completed.
sending : B02161 SELECT rhlists.kernel-team
received: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
received: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen
\Draft \*)] Fl
ags permitted.
received: * 357 EXISTS
received: * 7 RECENT
received: * OK [UNSEEN 23] First unseen.
received: * OK [UIDVALIDITY 1081503301] UIDs valid
received: * OK [UIDNEXT 358] Predicted next UID
received: B02161 OK [READ-WRITE] Select completed.
sending : B02162 FETCH 356 UID
received: * 356 FETCH (UID 356)
... etc...
Comment 2 David Woodhouse 2004-05-18 09:36:55 EDT
This happens with evo 1.5.7 too.
Comment 3 David Woodhouse 2004-05-18 09:47:45 EDT
It isn't the offending mail. After using pine to move the mail to an
alternative folder, Evo doesn't have the same problem on the new folder.

Removing Evo's cache directory for the folder in question made it
happy again -- but I'd done that once already this morning before it
happened again and I reported the bug. I suspect the problem will
recur, possibly when new mail next arrives in the offending folder.
Comment 4 David Woodhouse 2004-05-18 11:34:17 EDT
This is a known Evolution bug. It is, however, triggered by an as yet
unknown (AFAICT) bug in Dovecot. Note the sequence number 351 in the
first comment, for the mail with UID 357. This is despite the fact
that no mails have ever been deleted from this folder. We have a 1:1
mapping from sequence number to uid number. In fact....

000 fetch 352,358 uid
* 352 FETCH (UID 352)
* 358 FETCH (UID 358)
000 OK Fetch completed.
000 uid fetch 358 uid
* 352 FETCH (UID 358)
000 OK Fetch completed.


Reassigning to dovecot.
Comment 5 David Woodhouse 2004-05-18 11:46:47 EDT
More research shows...

000 uid fetch 302 uid
* 302 FETCH (UID 302)
000 OK Fetch completed.
000 uid fetch 303 uid
000 OK Fetch completed.
000 uid fetch 304 uid
000 OK Fetch completed.
000 uid fetch 305 uid
000 OK Fetch completed.
000 uid fetch 306 uid
000 OK Fetch completed.
000 uid fetch 307 uid
000 OK Fetch completed.
000 uid fetch 308 uid
000 OK Fetch completed.
000 uid fetch 309 uid
* 303 FETCH (UID 309)
000 OK Fetch completed.

Removing .dovecot-uidlist didn't help. Removing .imap.index* seems to
fix it.
Comment 6 Warren Togami 2004-05-19 06:28:28 EDT
Timo, just FYI.
Comment 7 John Dennis 2005-01-05 15:03:50 EST
Any reason to believe this still occurrs in 0.99.11?
Comment 8 John Dennis 2005-07-22 15:49:40 EDT
Haven't heard anything, we're up to 0.99.14, there were a number of index fixes
since this was first reported, closing this out...

Note You need to log in before you can comment on or make changes to this bug.