Closed Bug 115475 Opened 22 years ago Closed 22 years ago
disk cache of size 0 causes crash
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011215 BuildID: 2001121600 (This build is off the 0.9.7 branch) Opening lots of stuff in tabs leading off this page caused a mozilla crash. It's pretty much reproducible every time for me, but wasn't reproducible for blizzard when he tried. Reproducible: Always Steps to Reproduce: 1. go to http://developer.gnome.org/dotplan/ 2. open the six screenshots, the schedule, and the 'module release engineering list' in new tabs 3. go to the module tab, scroll down, and open 'meat-grinder' and 'stripchart' in new tabs (Yes, I know this is a little silly). Actual Results: It crashed (segfault) in PL_DHashTableOperate, called from nsCacheEntryHashTable::GetEntry Expected Results: Not crashed. :) I'm using a Squid proxy server, and I have the disk cache disabled. I'll attach the stack trace once I get a bug id. Could possibly be related to bug 113139, I suppose; it was the most related one I found when searching.
Build ID: 2001 12 15 08. Windows 2000. WFM, carefully using reporter's recipe.
status to new since we have a nice stack trace of a real crash here...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Would be nice to have fixed in 0.9.7 if it's simple to find and fix.
table->ops->hashKey was nearly null (0x00000059 or so). So how come table was dead or corrupt? Gordon, please speculate freely. Can anyone reproduce this? /be
FWIW, I have reproduced it when not using the squid proxy and when using the disk cache, so it's not related to that quirk of my configuration. I've also seen the same crash occur at other various times during browsing.
FWIW the stack trace corresponds to either a 300, 301, 302, or 307 http redirect.
I have managed to not reproduce it by starting with a clean profile; copying in my prefs.js from my old profile then led to a configuration which I should crash. So, now to figure out which pref it doesn't like.
OK, I've reliably reproduced it here on a clean setup (i.e., not my prefs), by doing the following: Start with a clean setup. Set disk cache size to zero, and disable disk cache. (in debugging) Exit mozilla. (Apparently, this doesn't take effect unless you restart?) Restart, and follow the URL sequence outlined before. It doesn't matter if you use tabs or new windows, at least when I just tried it here. (This was with a 2001121812 build (0.9.7 branch, FWIW).)
Summary: various combinations of tabs cause crash in cache code. → disabling disk cache causes crash in cache code.
I can reproduce this consistantly with the 12/18 trunk build on Linux rh6. I'm not sure if this means anything but in the Talkback report (645422) the first line is a different routine than that in the backtrace. Also, it was not necessary to disable the disk cache in the debug menu. It crashed either way. AtomTableMatchKey() nsCacheEntryHashTable::GetEntry() nsMemoryCacheDevice::DeactivateEntry() nsCacheService::DeactivateEntry() nsCacheService::CloseDescriptor() etc..
If this can be reproduced, it can be debugged. Gordon, can you get tever to show you how? I'll help debug as needed. Is the summary wrong, in light of comment #11? /be
yes, the summary is slightly off. Changing from 'disabling disk cache causes crash in cache code' to 'disk cache of size 0 causes crash'. Not much more descriptive but a bit more accurate. Also, I can now reproduce this on winNT4. see talkback incident 686569. (internal link http://climate/reports/SingleIncidentInfo.cfm?dynamicBBID=686569 ) no luck reproducing with the mac.
Summary: disabling disk cache causes crash in cache code. → disk cache of size 0 causes crash
FWIW, I can't reproduce this using build 2001121803 (trunk) on Win98SE.
stack looks like bug 114292
*** This bug has been marked as a duplicate of 114292 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.