Closed Bug 454932 Opened 16 years ago Closed 11 years ago

assertion in nsVoidArray::FastElementAt() trying to find a connection in the cache

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8.1

People

(Reporter: Bienvenu, Assigned: Bienvenu)

Details

Attachments

(2 files)

spun off from bug 436615

Here's the stack trace:

xpcom_core.dll!nsVoidArray::FastElementAt(int aIndex=4)  Line 73	C++
xpcom_core.dll!nsCOMArray_base::ObjectAt(int aIndex=4)  Line 101	C++
msgimap.dll!nsCOMArray<nsIImapProtocol>::ObjectAt(int aIndex=4)  Line 161	C++
msgimap.dll!nsCOMArray<nsIImapProtocol>::operator[](int aIndex=4)  Line 171	C++
msgimap.dll!nsImapIncomingServer::GetImapConnection(nsIEventTarget * aEventTarget=0x00cd3358, nsIImapUrl * aImapUrl=0x05c27de8, nsIImapProtocol * * aImapConnection=0x0012eabc)  Line 696 + 0x15 bytes	C++
msgimap.dll!nsImapIncomingServer::GetImapConnectionAndLoadUrl(nsIEventTarget * aClientEventTarget=0x00cd3358, nsIImapUrl * aImapUrl=0x05c27de8, nsISupports * aConsumer=0x00000000)  Line 416 + 0x2e bytes	C++
msgimap.dll!nsImapService::GetImapConnectionAndLoadUrl(nsIEventTarget * aClientEventTarget=0x00cd3358, nsIImapUrl * aImapUrl=0x05c27de8, nsISupports * aConsumer=0x00000000, nsIURI * * aURL=0x0012ecdc)  Line 2136 + 0x28 bytes	C++
msgimap.dll!nsImapService::SelectFolder(nsIEventTarget * aClientEventTarget=0x00cd3358, nsIMsgFolder * aImapMailFolder=0x051a622c, nsIUrlListener * aUrlListener=0x00000000, nsIMsgWindow * aMsgWindow=0x00000000, nsIURI * * aURL=0x0012ecdc)  Line 259 + 0x1b bytes	C++
msgimap.dll!nsImapMailFolder::UpdateFolder(nsIMsgWindow * msgWindow=0x00000000, nsIUrlListener * aUrlListener=0x00000000)  Line 771 + 0x85 bytes	C++
msgimap.dll!nsImapMailFolder::UpdateFolder(nsIMsgWindow * inMsgWindow=0x00000000)  Line 674	C++

The problem is that CanHandleUrl sometimes will actually remove the connection from the connection cache, while we're iterating through it. A simple fix is to check for this. I'll attach a patch. I could also the loop to start looking from the end; I think I'll try that as well.
I removed the ConnectionTimeout stuff after the loop - we should have already checked that inside the loop, unless I'm missing something...
Attachment #338232 - Flags: superreview?(neil)
Attachment #338232 - Flags: review?(bugzilla)
Attachment #338232 - Flags: superreview?(neil) → superreview+
Comment on attachment 338232 [details] [diff] [review]
iterate in reverse

Another approach for the long term would be to convert m_connectionCache into an nsTObserverArray.
Attachment #338232 - Flags: review?(bugzilla) → review+
fix checked in, changeset:   319:b9996ad44f8d

maybe an nsTObserverArray would work, but I'm not sure that the actual protocol object goes away immediately, since we have to deal with cleaning up the imap thread as well.
Product: Core → MailNews Core
(In reply to David :Bienvenu from comment #3)
> fix checked in, changeset:   319:b9996ad44f8d
> 
> maybe an nsTObserverArray would work, but I'm not sure that the actual
> protocol object goes away immediately, since we have to deal with cleaning
> up the imap thread as well.

I don't seen mention of followup needed, so closing Fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: