Deleting many imap messages can cause subsequent deletes to fail

VERIFIED FIXED in M16

Status

P1
normal
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: Bienvenu, Assigned: Bienvenu)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

19 years ago
If you delete many imap messages, you can get into a state where deletes stop 
working until you click away to another message or wait or something (hard to 
say). It may have to do with deleting messages quickly, I'm not sure. Cc'ing 
scottip so he can mark any bugs he gets on this dups - similarly for jeff and 
mscott.
(Assignee)

Comment 1

19 years ago
accepting - could be related to 21574
Status: NEW → ASSIGNED
Target Milestone: ---

Comment 2

19 years ago
For me, I notice that whenever I delete spam email which contains attached web 
pages that haven't finished loading yet, I can never delete any other mail 
afterwards.
(Assignee)

Comment 3

19 years ago
OK, what's happening here is that somehow the m_copyState that the 
nsImapMailFolder holds onto during a copy is not getting nulled out when this 
bug happens. Then, nsImapMailFolder::InitCopyState errors out and delete is 
disabled. It doesn't really seem to matter what the messages you delete are; I 
ran into it with bugsplat notifications. I'm not sure what's causing it not to 
get cleaned up, and it'll be tricky to catch it in the act.

Updated

19 years ago
QA Contact: lchiang → laurel
(Assignee)

Comment 4

19 years ago
*** Bug 31389 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

19 years ago
My suspicion is that is related to biff going off while deleting messages. I 
made my biff interval 5 seconds, and ran into this problem within 20 seconds. 
There's something wrong with the connection cache/ url queueing mechanism, I'm 
pretty sure. We start the delete, but biff fires, and the delete url never runs, 
so we don't clear the move/copy state. It's not quite that simple, but I think 
that's roughly the problem.

Comment 6

19 years ago
that is a possibility.  I vaguely remember turning biff off and having this 
still occur.  I think it has to do with displaying messages.  If I close the 
thread pane so that messages don't load, I never see this problem.  If I have 
the thread pane open I run into this within 50 deletes and lately it's been 
within 10 deletes.
(Assignee)

Comment 7

19 years ago
yes, displaying messages does seem to be involved (because it is another url 
that gets run), but biff makes it much much easier to create this, at least for 
me.
(Assignee)

Comment 8

19 years ago
OK, I've found one cause of this - when nsImapProtocol's m_imapMiscellaneousSink 
is NULL at the end of ProcessCurrentUrl, we don't call SetUrlState, which means 
we don't know to clear the copy state on the nsImapMailFolder. In the one case I 
ran into, all the sinks are null. There may be some race condition which causes 
the sinks to get nulled out. Or, less likely, the sinks aren't initialized. 
Neither of these seems possible by inspection, but one of them must be 
happening.
(Assignee)

Comment 9

19 years ago
So I can fix this by adding two lines to the start of 
nsImapProtocol::ProcessCurrentURL():

  if (!m_imapMiscellaneousSink)
    SetupSinkProxy(); // try this again. Evil, but I'm desperate.

This is probably not good, because it'll cause SetupSinkProxy to be called from 
an imap thread, and not the ui thread as it should be. But it does fix the 
problem and seems to work. I'll try to find a better fix.
(Assignee)

Comment 10

19 years ago
marking P1 as one of my hot bugs per Steve's request. I do have a fix in hand.
Priority: P3 → P1
Target Milestone: --- → M16
(Assignee)

Comment 11

19 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 12

19 years ago
This is OK for me using:
2000-04-14-10m16 commercial build NT 4.0
2000-04-14-11m16 commercial build mac OS 9.0
2000-04-14-09m16 commercial build linux rh6.0


Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.