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

VERIFIED FIXED in mozilla0.9

Status

()

Core
Networking: Cache
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: dbaron, Assigned: dveditz)

Tracking

({crash, topcrash})

Trunk
mozilla0.9
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

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/
(Reporter)

Updated

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

Comment 1

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

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.
(Reporter)

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, 
    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>}
(Reporter)

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...
(Reporter)

Comment 5

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

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]
(Assignee)

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
(Assignee)

Comment 9

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

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
r=neeti

Comment 12

18 years ago
sr=rpotts.
(Assignee)

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 
milestone.
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. ***

Updated

18 years ago
Keywords: mozilla0.8.1

Updated

18 years ago
Keywords: mozilla0.8
(Assignee)

Comment 16

18 years ago
Apparently I forgot to mark this fixed...
Status: NEW → RESOLVED
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.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsCacheManager::NoteDormant]
You need to log in before you can comment on or make changes to this bug.