Closed Bug 65798 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: Networking: Cache, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: dbaron, Assigned: dveditz)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(1 file)

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/
OS: Linux → All
Hardware: PC → All
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]
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.
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>}
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...
Ignore my guessing about the values of the pointers. It was different another time.
This bug should be resolved when the new cache code lands.
Target Milestone: --- → mozilla0.9
adding (trunk) and [@ nsCacheManager::NoteDormant] for tracking.
Summary: trunk #2 crash: [@ nsCacheManager::NoteDormant] → (trunk) #2 crash: [@ nsCacheManager::NoteDormant]
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
Attached patch Patch to firewall the problem (deleted) — Splinter Review
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.
r=neeti
sr=rpotts.
Fix checked in.
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]
*** Bug 70468 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.8.1
Keywords: mozilla0.8
Apparently I forgot to mark this fixed...
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: