65798 - M08 & (trunk) crash: [@ nsCacheManager::NoteDormant]

Status: VERIFIED FIXED

(Core :: Networking: Cache, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

DESCRIPTION:  The current #2 topcrash on the trunk is in
nsCachedNetData::NoteDormant.  This may be the same as bug 52818, but that
bug has gotten confusing enough already, so I'm filing this separately.

Details at ftp://ftp.mozilla.org/pub/data/crash-data/

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hmmm.  The vast majority of these crashes are with the stack:

nsCacheManager::NoteDormant
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCacheManager.cpp line 344]
nsCachedNetData::Release
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp line 264]
nsCOMPtr_base::~nsCOMPtr_base
[d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp line 50]
nsMsgMailNewsUrl::~nsMsgMailNewsUrl
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgMailNewsUrl.cpp line 66]

Comment 2

[neeti]

This is different from bug 52818, because all the stack traces for this bug 
involve mailnews (using the memory cache), whereas the stack traces for bug do 
not involve mailnews.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I can reproduce this bug, or something very similar, reliably.  It's blocking
me from continuing working on leaks with "./mozilla -mail".  All I need to do
to reproduce (with the two patches from bug 56703 in my tree) is start
"./mozilla -mail", click cancel on the password dialog, and close the window.
I crash here:

#5  0x40130a98 in nsTraceRefcnt::LogReleaseCOMPtr (aCOMPtr=0x870d9f4, 
    aObject=0x86ac720)
    at /builds/seamonkey/mozilla/xpcom/base/nsTraceRefcnt.cpp:1988
#6  0x41bdb19d in nsCOMPtr<nsICachedNetData>::~nsCOMPtr (this=0x870d9f4, 
    __in_chrg=2) at ../../../dist/include/nsCOMPtr.h:488
#7  0x41bc19a3 in nsMsgMailNewsUrl::~nsMsgMailNewsUrl (this=0x870d9d4, 
    __in_chrg=0)
    at /builds/seamonkey/mozilla/mailnews/base/util/nsMsgMailNewsUrl.cpp:63
#8  0x4206f94b in nsImapUrl::~nsImapUrl (this=0x870d9d0, __in_chrg=3)
    at /builds/seamonkey/mozilla/mailnews/imap/src/nsImapUrl.cpp:114

And the mRawPtr of the nsCOMPtr is:

$2 = {<nsISupports> = {_vptr. = 0xdadadada}, <No data fields>}

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I can tell from refcount logging that the nsReplacementPolicy has already been
destroyed, so the arena has probably been destroyed as well.  Therefore we're
holding an owning reference to an object that was allocated from an arena and
the arena has been destroyed.  That's no fun.

The one on which we're crashing seems to have a much lower address than the
other 2:

<nsCachedNetData> 0x41EC2EB0 1
<nsCachedNetData> 0x41EC2EF8 2
<nsCachedNetData> 0x0868ABC8 3   <== the crash

I'm not sure how that's related to how they were allocated...

But suddenly I'm having trouble reproducing the crash...

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ignore my guessing about the values of the pointers.  It was different another
time.

Comment 6

[neeti]

This bug should be resolved when the new cache code lands.

Comment 7

[Jay Patel [:jay]]

adding (trunk) and [@ nsCacheManager::NoteDormant] for tracking.

Comment 8

[Daniel Veditz [:dveditz]]

I assume your 1/30 comment means you're not working on this, so I'll take it to 
help out the branch effort.

Comment 9

[Daniel Veditz [:dveditz]]

Attachment: Patch to firewall the problem

Comment 10

[Daniel Veditz [:dveditz]]

The stack traces I looked at were mostly at shutdown, and the global cache 
manager was already gone. This crash doesn't show up (at least in the top 40) 
in N6.01 so something timing-wise has changed, but given the new cache landing 
I think this is a sufficient fix without having to figure out the deeper cause. 
This does not introduce any new links; if gCacheManager is gone so is the 
hashtable holding the ActiveCacheRecords, and the calling routine ignores the 
error return value and will release it's hold on cache record regardless.

Comment 11

[neeti]

r=neeti

Comment 12

[rpotts (gone)]

sr=rpotts.

Comment 13

[Daniel Veditz [:dveditz]]

Fix checked in.

Comment 14

[Jay Patel [:jay]]

Adding M08 to summary for tracking, this was also a topcrash for the Mozilla 0.8 
milestone.

Comment 15

[Keyser Sose]

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

Comment 16

[Daniel Veditz [:dveditz]]

Apparently I forgot to mark this fixed...

Comment 17

[Jay Patel [:jay]]

verifying fixed...i haven't seen this crash in talkback data for along time.