Closed
Bug 65798
Opened 24 years ago
Closed 24 years ago
M08 & (trunk) crash: [@ nsCacheManager::NoteDormant]
Categories
(Core :: Networking: Cache, defect)
Core
Networking: Cache
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: dbaron, Assigned: dveditz)
References
Details
(Keywords: crash, topcrash)
Crash Data
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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•24 years ago
|
Reporter | ||
Comment 1•24 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]
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•24 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•24 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•24 years ago
|
||
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
Comment 7•24 years ago
|
||
adding (trunk) and [@ nsCacheManager::NoteDormant] for tracking.
Summary: trunk #2 crash: [@ nsCacheManager::NoteDormant] → (trunk) #2 crash: [@ nsCacheManager::NoteDormant]
Assignee | ||
Comment 8•24 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•24 years ago
|
||
Assignee | ||
Comment 10•24 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•24 years ago
|
||
r=neeti
Comment 12•24 years ago
|
||
sr=rpotts.
Assignee | ||
Comment 13•24 years ago
|
||
Fix checked in.
Comment 14•24 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•24 years ago
|
||
*** Bug 70468 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Keywords: mozilla0.8.1
Updated•24 years ago
|
Keywords: mozilla0.8
Assignee | ||
Comment 16•24 years ago
|
||
Apparently I forgot to mark this fixed...
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 17•23 years ago
|
||
verifying fixed...i haven't seen this crash in talkback data for along time.
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Crash Signature: [@ nsCacheManager::NoteDormant]
You need to log in
before you can comment on or make changes to this bug.
Description
•