32742 - Deleting many imap messages can cause subsequent deletes to fail

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P1)

Description

[David :Bienvenu]

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.

Comment 1

[David :Bienvenu]

accepting - could be related to 21574

Comment 2

[lchiang]

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.

Comment 3

[David :Bienvenu]

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.

Comment 4

[David :Bienvenu]

*** Bug 31389 has been marked as a duplicate of this bug. ***

Comment 5

[David :Bienvenu]

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

[scottputterman]

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.

Comment 7

[David :Bienvenu]

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.

Comment 8

[David :Bienvenu]

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.

Comment 9

[David :Bienvenu]

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.

Comment 10

[David :Bienvenu]

marking P1 as one of my hot bugs per Steve's request. I do have a fix in hand.

Comment 11

[David :Bienvenu]

fix checked in.

Comment 12

[laurel]

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