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

VERIFIED FIXED in mozilla0.9



Networking: Cache
18 years ago
17 years ago


(Reporter: dbaron, Assigned: dveditz)


({crash, topcrash})

crash, topcrash

Firefox Tracking Flags

(Not tracked)


(crash signature)


(1 attachment)



18 years ago
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/


18 years ago
Keywords: crash, mozilla0.8, topcrash
OS: Linux → All
Hardware: PC → All

Comment 1

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

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

Comment 2

18 years ago
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

18 years ago
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, 
    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, 
    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

18 years ago
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

18 years ago
Ignore my guessing about the values of the pointers.  It was different another

Comment 6

18 years ago
This bug should be resolved when the new cache code lands.
Target Milestone: --- → mozilla0.9

Comment 7

18 years ago
adding (trunk) and [@ nsCacheManager::NoteDormant] for tracking.
Summary: trunk #2 crash: [@ nsCacheManager::NoteDormant] → (trunk) #2 crash: [@ nsCacheManager::NoteDormant]

Comment 8

18 years ago
I assume your 1/30 comment means you're not working on this, so I'll take it to 
help out the branch effort.
Assignee: neeti → dveditz

Comment 9

18 years ago
Created attachment 26170 [details] [diff] [review]
Patch to firewall the problem

Comment 10

18 years ago
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

18 years ago

Comment 12

18 years ago

Comment 13

18 years ago
Fix checked in.

Comment 14

18 years ago
Adding M08 to summary for tracking, this was also a topcrash for the Mozilla 0.8 
Summary: (trunk) #2 crash: [@ nsCacheManager::NoteDormant] → M08 & (trunk) crash: [@ nsCacheManager::NoteDormant]

Comment 15

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


18 years ago
Keywords: mozilla0.8.1


18 years ago
Keywords: mozilla0.8

Comment 16

18 years ago
Apparently I forgot to mark this fixed...
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 17

17 years ago
verifying fixed...i haven't seen this crash in talkback data for along time.
Crash Signature: [@ nsCacheManager::NoteDormant]
You need to log in before you can comment on or make changes to this bug.