Closed Bug 52818 Opened 24 years ago Closed 24 years ago

N601, M08 & Trunk crash [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete]

Categories

(Core :: Networking: Cache, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: dbaron, Assigned: gordon)

References

Details

(Keywords: crash, topcrash, Whiteboard: [rtm need info][nsbeta3++])

Crash Data

Attachments

(4 files)

Splitting this off as new bug per comments in bug 48292. There are still a number of talkback reports pointing to crashes in nsCachedNetData. The line numbers for both stacks shown seem (on very quick examination) to point to things dealing with mRecord. Perhaps it is: * uninitialized? * being used when mRecordID should be used? I'll attach the relevant excerpts from http://www.mozilla.org/projects/seamonkey/reports/ns6analysis.html
On the principle that the windows stack traces give a line number of what would be executed after the crash, the locations of the crash look like they are here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNetData.cpp&rev=1.27&mark=278#268 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNetData.cpp&rev=1.26&mark=1049#1039 (or equivalent in rev. 1.25)
Keywords: nsbeta3, topcrash
I think I understand this. mRecord need not be valid when we hit nsCachedNetData::Release() Worse if it is corrupted... +ing this. Damn. We thought we fixed it ugh. Wish we had a reproducible case.
Whiteboard: [nsbeta3+]
As of today, the talkback data only shows [@ nsCachedNetData::Delete] in the list of topcrashers...and it's #2! nsCachedNetData::Release crashes have dropped off the radar. I have not yet tried to reproduce, but are some recent entries that might help: nsCachedNetData::Delete c85162d3 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000091821 CrashDate: 2000-09-19 UptimeMinutes: 235 Total: 235 OS: Windows NT 5.0 build 2195 URL: slashdot.org Comment: Window wasn't in focus Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17654128 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17654128 nsCachedNetData::Delete() fd52335b line Build: 2000091908 CrashDate: 2000-09-19 UptimeMinutes: 36 Total: 36 OS: Linux 2.2.16-3 URL: www.rasterman.com/gfx.html Comment: Page was opening Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17690492 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17690492 nsCachedNetData::Delete 1413710e http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000091821 CrashDate: 2000-09-19 UptimeMinutes: 44 Total: 44 OS: Windows NT 4.0 build 1381 URL: http://www.wapland.no Comment: Pressing the "back" button Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17661812 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17661812 nsCachedNetData::Delete 367fdb37 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000091909 CrashDate: 2000-09-19 UptimeMinutes: 18 Total: 18 OS: Windows NT 4.0 build 1381 URL: www.winfiles.com Comment: I was running your komono "buster" script. it cacked out on the 22nd (of 25?) page. Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17685215 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17685215 nsCachedNetData::Delete 2447d797 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000091806 CrashDate: 2000-09-20 UptimeMinutes: 525 Total: 662 OS: Windows NT 4.0 build 1381 URL: http://www.us.rasterman.com/photos.html Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17702219 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17702219 nsCachedNetData::Delete f7dea13b http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000092009 CrashDate: 2000-09-20 UptimeMinutes: 248 Total: 248 OS: Windows 98 4.10 build 67766446 URL: Comment: nothing - i was reading slashdot Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17758337 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17758337 nsCachedNetData::Delete e6919702 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000091909 CrashDate: 2000-09-20 UptimeMinutes: 102 Total: 665 OS: Windows 98 4.10 build 67766446 URL: Comment: Absolutely nothing. I didn't even have mozilla focused when it suddenly crashed for no apparent reason; I was chatting in IRC with mozilla just sitting minimized. Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17759184 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17759184 nsCachedNetData::Delete c85162d3 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000091806 CrashDate: 2000-09-20 UptimeMinutes: 133 Total: 148 OS: Windows NT 4.0 build 1381 URL: www.linuxplanet.com Comment: Browser had already rendered page. There was no keyboard or mouse activity when it crashed. Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17720410 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17720410 nsCachedNetData::Delete 5c59f8af http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000092009 CrashDate: 2000-09-20 UptimeMinutes: 79 Total: 123 OS: Windows 98 4.10 build 67766222 URL: http://www.macosplanet.com/index.shtml#osxfirst Comment: loading page Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17762166 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17762166 nsCachedNetData::Delete 9e3dae97 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000091909 CrashDate: 2000-09-20 UptimeMinutes: 1032 Total: 1032 OS: Windows NT 5.0 build 2195 URL: http://www.swbell.com/ContactUs/1 Comment: 1044 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17722514 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17722514 nsCachedNetData::Delete 6e575078 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000092009 CrashDate: 2000-09-20 UptimeMinutes: 29 Total: 29 OS: Windows NT 4.0 build 1381 URL: running browser buster - don't know what page Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17762432 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17762432 nsCachedNetData::Delete e6919702 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000091806 CrashDate: 2000-09-20 UptimeMinutes: 178 Total: 348 OS: Windows NT 4.0 build 1381 URL: www.linuxplanet.com Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17743883 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17743883 nsCachedNetData::Delete 7ab7f2c5 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 1056 Build: 2000092009 CrashDate: 2000-09-20 UptimeMinutes: 21 Total: 21 OS: Windows 98 4.10 build 67766222 URL: Comment: I was testing Mozilla using the browser buster. URL 29 crashed the browser. Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17746740 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17746740
Summary: crashes related to nsCachedNetData::mRecord → crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete
I just crashed here and it was due to rv = GetRecord(getter_AddRefs(record)); if (NS_SUCCEEDED(rv)) { // Delete the record if we can get a record. record->Delete(); where record was null, not deleted already.
This bug is pretty easy for me to recreate on my machine at home. I just have to browse around for about 10 minutes. Here's what happens leading up tp record being null. nsNetDiskCache::GetCachedNetDataByID calls rv = mDB->Get(RecordID, &info, &info_size); this calls status = (*mDB->get)(mDB, &db_key, &db_data, 0) ; and comes back with status = 1. Because of that it returns NS_OK, but doesn't fill in "info". this causes if(NS_SUCCEEDED(rv) && info) in nsNetDiskCache::GetCachedNetDataByID to fail and return rv which is NS_OK. which causes nsCachedNetData::GetRecord(nsINetDataCacheRecord* *aRecord) to return aRecord of nsnull and a return value of NS_OK. which then leads to the crash accessing a null ptr. I'm just playing around in this code, but one thing I do see is that in nsReplacementPolicy::DeleteAtleastOneEntry(nsINetDataCache *aCache, PRUint32 targetNumEntries, PRUint32* numEntriesDeleted) the first one or 2 calls to rv = LoadAllRecordsInAllCacheDatabases(); return failure. When it finally succeeds I crash trying to get the first record. Also, when it fails it seems to reset my cache to have 0 entries.
LoadAllRecordsInAllCacheDatabases fails for me because at one point: // set mMetaDataLength COPY_INT32(&mMetaDataLength, cur_ptr) ; cur_ptr += sizeof(PRUint32) ; // poor man's attempt to detect corruption if (mMetaDataLength > aInfoLength) return NS_ERROR_FAILURE; mMetaDataLength is much bigger (i.e. 840986229 vs 450)
Today, I've crashed twice before I even get to the crash in this bug. In nsReplacementPolicy::AddAllRecordsInCache, AssociateCacheEntryWithRecord is called. In this function, it can't find a cache entry for the record for some reason. When this happens, it tries to allocate a large cache. Unfortunately, the current size is the same as the max size which means that a new cache doesn't get reallocated. Eventually: // Recycle the record after the last in-use record in the array nsCachedNetData *entry = mRankedEntries[mNumEntries]; is called. Unfortunately, mNumEntries is equal to the capacity since a larger array wasn't allocated and this entry is now being taken from outside of allocated memory and a crash occurs the minute entry is accessed. I think this function needs to be protected against this case. Either an error needs to be returned earlier so that we don't get here, or the array needs to be allowed to be reallocated to a larger size. And of course, it would be interesting to find out why there's no cache entry associated with the record.
Some more data. I decided to remove my cache and start over again and it didn't crash when it went through all of the code mentioned in my last few entries.
*spam* adding crash keyword...
Keywords: crash
Here's a patch that will stop the crash. The cache may not work correctly but at least it shouldn't crash (I haven't been able to verify it doesn't crash later because one I can't get past 54072 and the patch I have for that bug prevents this crash from happening). I'm wondering if there was a cache bug that corrupted a bunch of our caches? I can't get into this state once I remove my old cache but as soon as I put it back I crash. Index: mgr/nsCachedNetData.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/cache/mgr/nsCachedNetData.cpp,v retrieving revision 1.28 diff -c -r1.28 nsCachedNetData.cpp *** nsCachedNetData.cpp 2000/09/22 04:12:42 1.28 --- nsCachedNetData.cpp 2000/09/26 06:56:26 *************** *** 1044,1050 **** nsCOMPtr<nsINetDataCacheRecord> record; rv = GetRecord(getter_AddRefs(record)); ! if (NS_SUCCEEDED(rv)) { // Delete the record if we can get a record. record->Delete(); --- 1044,1050 ---- nsCOMPtr<nsINetDataCacheRecord> record; rv = GetRecord(getter_AddRefs(record)); ! if (NS_SUCCEEDED(rv) && record) { // Delete the record if we can get a record. record->Delete();
Scott, I think in addition to the fix you attached, we also need to return an error from nsNetDiskCache::GetCachedNetDataByID(..), when info is null. This will make nsCachedNetData::GetRecord(..)return an error, when we do not get a record. There have been a number of cases in the in the cache code, which have corrupted the cache. Most of these have been fixed in the last couple of weeks. I have been trying to reproduce this crash, to figure out why we get into this corrupted state, but have been unable to do so. Index: nsNetDiskCache.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/cache/filecache/nsNetDiskCache.cpp,v retrieving revision 1.29 diff -c -r1.29 nsNetDiskCache.cpp *** nsNetDiskCache.cpp 2000/09/14 19:12:01 1.29 --- nsNetDiskCache.cpp 2000/09/26 16:06:48 *************** *** 431,436 **** --- 431,438 ---- printf("CACHE: GetCachedNetDataByID(id=%d) created nsDiskCacheRecord %p\n", RecordID, *_retval); #endif /* DEBUG_dp */ return rv; + } else if(NS_SUCCEEDED(rv)) { + rv = NS_ERROR_FAILURE; } #ifdef DEBUG_dp
Attached patch created an attachement (deleted) — Splinter Review
I will try that out. I think by applying your patch to 54072 I should be able to get into a state where I can reproduce this bug again.
BTW, in order to reproduce this more easily I've changed my pref so that it checks each page every time I visit it. This makes it so I start using the disk cache right away.
*** Bug 54375 has been marked as a duplicate of this bug. ***
Attached patch latest patch (deleted) — Splinter Review
Scott, the cache code as of 2 weeks ago could have been corrupting caches. We bumped the version number so those caches will get deleted automatically. I hope when you put back the cache, you just operate at the Cache/ directory level rather than anything inside of it as the version is a separate file inside the Cache/ directory. Neeti, maybe it is time to bump the version again after the last round of 2 week fixes.
dp, Another problem which Scott and I noticed yesterday is are leaking nsNetDiskCache sometime. So we don't always call nsNetDiskCache::~nsNetDiskCache()on exit. So, we do not call SetSizeEntry(..) all the time. So the number of entries is all messed up. Neeti
Should we be considering this for PR3? This bug is P3 right now so it hasn't been on PDT's radar, but since this is the #2 talkback crasher, maybe it should be? Is this the right fix? Any reason not to take it?
I have a fix in hand, which dp has just reviewed. Now I need a nsbeta++ and a super review to check it in. Neeti
Given the tiny (ultra-reviewable) size of the patch, and the status (#2 crasher), I'm willing to follow Phil's suggestion and go for a beta3-double-plus. Please get this landed on the branch asap (tree open and super-review intact). We're trying to finaliza our build, so at some point, we'd have to give up even on this easy and big win. In case you can't get this landed, I'm also adding an RTM nomination.
Keywords: rtm
Whiteboard: [nsbeta3+] → [nsbeta3++]
fix checked in
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Was the fix checked in to the trunk, or just the branch?
The fix was checked into the branch. I still need to check it into the trunk.
Checked in fix into the trunk
This was easy to reproduce on 9/27 but I haven't seen this happen on today's build. Marking verified. WinNT 20000092808
Status: RESOLVED → VERIFIED
*** Bug 53611 has been marked as a duplicate of this bug. ***
*** Bug 54304 has been marked as a duplicate of this bug. ***
Reopening. This is still showing up in talkback reports: nsCachedNetData::Release() 78429ff9 line Build: 2000100309 CrashDate: 2000-10-03 UptimeMinutes: 98 Total: 295 OS: Linux 2.2.17 URL: www.slashdot.org Comment: I was logging in... and it crashed. Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18485927 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18485927 nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100409 CrashDate: 2000-10-05 UptimeMinutes: 164 Total: 164 OS: Windows NT 4.0 build 1381 URL: Comment: I hit Ctrl-R - the page refreshed Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18608412 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18608412 nsCachedNetData::Release dff214c4 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100509 CrashDate: 2000-10-06 UptimeMinutes: 69 Total: 416 OS: Windows NT 5.0 build 2195 URL: http://climate/main/qfa.cfm Comment: Using the form at http://climate/main/qfa.cfm -- entered one ID Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18652885 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18652885 nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100409 CrashDate: 2000-10-06 UptimeMinutes: 109 Total: 668 OS: Windows NT 4.0 build 1381 URL: http://www.voyetra-turtle-beach.com/site/products/santacru/indetail.asp Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18655219 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18655219 nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100509 CrashDate: 2000-10-06 UptimeMinutes: 36 Total: 57 OS: Windows NT 4.0 build 1381 URL: Comment: Activating mail window while browser was busy Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18655927 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18655927 nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100409 CrashDate: 2000-10-04 UptimeMinutes: 37 Total: 37 OS: Windows NT 4.0 build 1381 URL: www.globeandmail.com Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18534642 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18534642 nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100509 CrashDate: 2000-10-07 UptimeMinutes: 1258 Total: 1286 OS: Windows NT 4.0 build 1381 URL: www.savecents.com Comment: minding my own business!! Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18674571 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18674571 nsCachedNetData::Release 1f7cb15f http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100309 CrashDate: 2000-10-04 UptimeMinutes: 332 Total: 332 OS: Windows 98 4.10 build 67766446 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18538726 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18538726 nsCachedNetData::Release e7629da8 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100421 CrashDate: 2000-10-05 UptimeMinutes: 10 Total: 25 OS: Windows NT 5.0 build 2183 URL: www.mozillazine.org Comment: clicking the back button Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18574175 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18574175 nsCachedNetData::Release() 4af25059 line Build: 2000100706 CrashDate: 2000-10-07 UptimeMinutes: 32 Total: 32 OS: Linux 2.2.12-20 URL: http://www.oreillynet.com/meerkat/ Comment: Crashed after it had mostly loaded page. Not repeatable. Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18680183 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18680183 nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100409 CrashDate: 2000-10-05 UptimeMinutes: 0 Total: 135 OS: Windows NT 4.0 build 1381 URL: http://intranet.netsilicon.com Comment: Launching Mozilla; it crashed trying to load my company's intranet page which worked just ten minutes ago Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18578782 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18578782 nsCachedNetData::Release 4568f1db http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100509 CrashDate: 2000-10-05 UptimeMinutes: 22 Total: 22 OS: Windows NT 5.0 build 2195 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18582989 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18582989 nsCachedNetData::Release 4025bead http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100709 CrashDate: 2000-10-07 UptimeMinutes: 20 Total: 20 OS: Windows 98 4.10 build 67766222 URL: Comment: I left it idle as the only app running for several hours. Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18703967 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18703967 nsCachedNetData::Release 1f7cb15f http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100509 CrashDate: 2000-10-06 UptimeMinutes: 227 Total: 254 OS: Windows 98 4.10 build 67766446 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18616411 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18616411 nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100509 CrashDate: 2000-10-08 UptimeMinutes: 1534 Total: 3516 OS: Windows NT 4.0 build 1381 URL: www.cnnsi.com Comment: minding my own business Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18738926 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18738926 nsCachedNetData::Release 3acc477d http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000100809 CrashDate: 2000-10-08 UptimeMinutes: 19 Total: 102 OS: Windows NT 5.0 build 2195 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18742911 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18742911
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
To add to dbaron's comments, this has been a topcrash for the PR3 release build 2000092909 also. Below are some entries from PR3 talkback data and a stack trace: nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000092909 CrashDate: 2000-10-05 UptimeMinutes: 78 Total: 87 OS: Windows NT 4.0 build 1381 URL: http://www.washingtonpost.com/ Comment: I clicked the Home button. Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=18586581 nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000092909 CrashDate: 2000-10-05 UptimeMinutes: 37 Total: 37 OS: Windows NT 4.0 build 1381 URL: www.intel.com\ Comment: I clicked the back button from www.intel.com\channel Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=18590456 nsCachedNetData::Release 1f7cb15f http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000092909 CrashDate: 2000-10-06 UptimeMinutes: 19 Total: 19 OS: Windows 98 4.10 build 67766446 URL: www.morningstarministries.org Comment: rolling the mouse wheel Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=18633408 nsCachedNetData::Release d73ad7a9 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000092909 CrashDate: 2000-10-06 UptimeMinutes: 165 Total: 165 OS: Windows NT 4.0 build 1381 URL: home.netscape.com Comment: sitting idle Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=18648851 nsCachedNetData::Release 987a801c http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/cache/mgr/nsCachedNe tData.cpp line 279 Build: 2000092909 CrashDate: 2000-10-05 UptimeMinutes: 273 Total: 273 OS: Windows NT 5.0 build 2195 URL: www.espn.com Comment: I was hitting the back button when it crashed. Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=18649125 Incident ID 18649125 nsCachedNetData::Release [d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 279] nsCOMPtr_base::assign_with_AddRef [d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 59] nsHTTPChannel::ResponseCompleted [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPChannel.cpp, line 1832] nsHTTPServerListener::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 729] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 302] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 576] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 512] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1046] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 408] netscp6.exe + 0x1711 (0x00401711) netscp6.exe + 0x1230 (0x00401230) netscp6.exe + 0x2aae (0x00402aae) KERNEL32.DLL + 0x192a6 (0x77e992a6)
Summary: crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete → crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete] [@ nsCachedNetData::Release]
marking [rtm need info]. Who can help with this topcrash?
Whiteboard: [nsbeta3++] → [rtm need info][nsbeta3++]
This is the #7 topcrasher in the official RTM build for Windows (i haven't checked linux or mac talkback data yet). The stack is pretty much the same (a few different line #s): Incident ID 21982139 nsCachedNetData::Release [d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 279] nsCOMPtr_base::assign_with_AddRef [d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 59] nsHTTPChannel::ResponseCompleted [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPChannel.cpp, line 1877] nsHTTPServerListener::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cpp, line 730] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 302] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 581] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 517] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1051] KERNEL32.DLL + 0x24407 (0xbff94407) 0x00658b52 This bug is already huge because of talkback entry info, so I will not add to that. Since this is a cache bug, i dougt a list of URLs would help. I will add user comments if I find anything useful.
Summary: crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete] [@ nsCachedNetData::Release] → RTM crash #6 [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete]
This is also a topcrasher for RTM on Linux and Mac. Someone needs to take a look at this crash.
Gordon's looking at the cache, right? cc'ing him.
I haven't been able to reproduce this yet. Taking a look at the code, it seems we might be crashing on mRecord->GetRecordID(&recordID); ...perhaps mRecord is null. I've put an assert in my tree to check but I haven't hit it yet. Neeti, have you looked at this?
This bug was marked to be fixed in a previous milestone but it didn't get fixed properly. Nominated for beta1.
Keywords: nsbeta1
This is now (excluding crashes suspected to be fixed) the #7 topcrash on the trunk. Nominating for mozilla0.8.
Keywords: mozilla0.8
This bug should be resolved when the new cache code lands.
Target Milestone: --- → mozilla0.9
when will this happen?
changing summary to N601 and adding (trunk) for tracking. this is the #9 topcrasher for N601 and is also a topcrasher for the latest trunk builds.
Summary: RTM crash #6 [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete] → N601 crash #9 and (trunk) [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete]
Summary: N601 crash #9 and (trunk) [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete] → N601 Linux #9 and (trunk) [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete]
removed "Linux" from summary since this is occurring on all platforms.
Summary: N601 Linux #9 and (trunk) [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete] → N601 & (trunk) crash [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete]
Adding M08, this is also a topcrash for the Mozilla 0.8 build
Summary: N601 & (trunk) crash [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete] → N601, M08 & (trunk) crash [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete]
Keywords: mozilla0.8.1
Keywords: mozilla0.8
Cache bugs to Gordon
Assignee: neeti → gordon
Status: REOPENED → NEW
Adding qawanted keyword, since we have not been able to get steps to reproduce from just the Talkback data.
Keywords: qawanted
This bug has been around for a LONG time and noone can reproduce it...so just adding more user submitted info in case someone gets around to trying to reproduce: nsCachedNetData::Release 15 First BBID :28318852 Last BBID :28517996 Min Runtime :12 Max Runtime :111265 First Appearance Date : 2001-03-27 Last Appearance Date : 2001-04-01 First BuildID : 2001032614 Last BuildID : 2001032615 Stack Trace: nsCachedNetData::Release() nsCOMPtr_base::assign_with_AddRef() nsHTTPChannel::CacheAbort() nsHTTPChannel::ResponseCompleted() nsHTTPServerListener::OnStopRequest() nsOnStopRequestEvent::HandleEvent() nsStreamObserverEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xeda8 (0x406e7da8) libglib-1.2.so.0 + 0x103d5 (0x406e93d5) libglib-1.2.so.0 + 0x109d0 (0x406e99d0) libglib-1.2.so.0 + 0x10b68 (0x406e9b68) libgtk-1.2.so.0 + 0x8d73b (0x4060c73b) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x1bf31 (0x40257f31) Source File : line : (28337027) Comments: Closed main Messenger window (28346845) Comments: Same deal: I think Mozilla 8.0.1 does not like Netscape's plugin page (28363800) URL: http://www.linuxgames.com (28363800) Comments: Hard to say. When the crash happened (28453374) URL: www.hannovermesse.de (28493684) URL: http://yp.yahoo.com (28493684) Comments: submitting a query (28517996) Comments: Hitting the back button.
Summary: N601, M08 & (trunk) crash [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete] → N601, M08 & Trunk crash [@ nsCachedNetData::Release] - crashes related to nsCachedNetData::mRecord [@ nsCachedNetData::Delete]
this should be gone now that the new cache has been implemented - marking fixed
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
Keywords: qawanted, rtmnsrtm
Crash Signature: [@ nsCachedNetData::Release] [@ nsCachedNetData::Delete]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: