Closed
Bug 454932
Opened 16 years ago
Closed 12 years ago
assertion in nsVoidArray::FastElementAt() trying to find a connection in the cache
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8.1
People
(Reporter: Bienvenu, Assigned: Bienvenu)
Details
Attachments
(2 files)
3.29 KB,
patch
|
Details | Diff | Splinter Review | |
3.32 KB,
patch
|
standard8
:
review+
neil
:
superreview+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•16 years ago
|
||
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)
Updated•16 years ago
|
Attachment #338232 -
Flags: superreview?(neil) → superreview+
Comment 2•16 years ago
|
||
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.
Updated•16 years ago
|
Attachment #338232 -
Flags: review?(bugzilla) → review+
Assignee | ||
Comment 3•16 years ago
|
||
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.
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 4•12 years ago
|
||
(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: 12 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.
Description
•