115475 - disk cache of size 0 causes crash

Status: RESOLVED DUPLICATE of bug 114292

(Core :: Networking: Cache, defect)

Description

[Bill Nottingham]

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.

Comment 1

[Bill Nottingham]

Attachment: gdb backtrace of segfault.

Comment 2

[Karl Johan Kleist]

Build ID: 2001 12 15 08. Windows 2000.

WFM, carefully using reporter's recipe.

Comment 3

[Boris Zbarsky [:bzbarsky]]

status to new since we have a nice stack trace of a real crash here...

Comment 4

[Christopher Blizzard (:blizzard)]

Would be nice to have fixed in 0.9.7 if it's simple to find and fix.

Comment 5

[Brendan Eich [:brendan]]

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

Comment 6

[Bill Nottingham]

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.

Comment 7

[Darin Fisher]

FWIW the stack trace corresponds to either a 300, 301, 302, or 307 http redirect.

Comment 8

[Bill Nottingham]

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.

Comment 9

[Bill Nottingham]

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).)

Comment 10

[Bill Nottingham]

Attachment: prefs.js in use on test system.

Comment 11

[Tom Everingham]

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..

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[Tom Everingham]

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.

Comment 14

[David G King]

FWIW, I can't reproduce this using build 2001121803 (trunk) on Win98SE.

Comment 15

[Boris Zbarsky [:bzbarsky]]

stack looks like bug 114292

Comment 16

[Tom Everingham]

*** This bug has been marked as a duplicate of 114292 ***