Closed Bug 115475 Opened 23 years ago Closed 23 years ago

disk cache of size 0 causes crash

Categories

(Core :: Networking: Cache, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 114292

People

(Reporter: notting, Assigned: gordon)

References

()

Details

(Keywords: crash)

Attachments

(2 files)

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
Keywords: crash
Would be nice to have fixed in 0.9.7 if it's simple to find and fix.
Blocks: 114455
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.
No longer blocks: 114455
stack looks like bug 114292

*** This bug has been marked as a duplicate of 114292 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: