114292 - Mozilla crashes on this page - Trunk M097 [@ 0x00000000 | 0x00000008 - nsCacheMetaData::HashKey | PL_DHashTableOperate]

Status: VERIFIED FIXED

(Core :: Networking: Cache, defect)

Description

[u38342]

From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.17-pre6 i686)
BuildID:    2001120821

With this new build, Mozilla crashes on this page.

Reproducible: Always
Steps to Reproduce:
1.access http://www.net2phone.com  If you are asked your location, click "within
US"  Otherwise go to step 2
2.click "My account" menu on the top of this page.  It doesn't matter whether
you have your account or not.
3.Click "My rates" in the left menu.  You don't have to enter your account.

Actual Results:  Mozilla crashes.


Expected Results:  Proceeding to the next step without crash.

I have my account, and if I enter my account info in this page and click "My
Rates", it crashes.
  This doesn't happen with Mozilla0.9.6.  Yesterday's build was also fine, I
think(but I'm not sure.)  Anyway new build has this problem.

Comment 1

[Harald Glatt]

confirmed on winxp 2001120808

Comment 2

[Harald Glatt]

hmm... this bug only happend once to me - when i tried this again after the
crash mozilla didn't crash again!! 

Comment 3

[u38342]

Hmm.....On my RH7.2, it always crash.

Comment 4

[Markus Hübner]

WFME on win2k build 2001120808

Comment 5

[Olivier Cahagne]

wfm using build 2001120821 on Linux (glibc 2.1.3).

Comment 6

[joakim_46]

Checked with Windows Me and Build 2001112009, and it didn't crashed. Maybe only
in Linux.

Comment 7

[u38342]

hmmm.....build 2001120906 also crashes on my RH Linux7.2.
But thinking of net2phone, it works on Window$, so it doesn't matter so much. 
But other pages may be affected.  That's the problem (not to me so far...)

Comment 8

[Gaby Schilders]

Attachment: The page that crashes the browser

This (generated) page is an example of the ones that reliably crash my mozilla
0.9.6 on Linux. It contains Javascript. More information in my other comment.

Comment 9

[Gaby Schilders]

I'm adding my comment here because I only tested this on 0.9.6, linux, i386.
However, bug 89891 seems to be in the same ballpark.

My 2 cents:

I have reliably reproducable crashes on one site I visit when I try to use a
'reply' button. My talkback agent has sent some 6 or 7 reports back because I'm
stubborn.

Reproducable: Always
Steps to Reproduce:
1) Go to www.broekpolderbewoners.nl
2) From the menu on the left choose one of the 'forum' options
3) Open a message
4) press the 'reply' button.

Boom. All windows are closed. Silent crash (when mozilla is executed from the
command-line it just exits, no information whatsoever.) Talkback _is_ launched
though and has sent back at least the following reports on this:

TB38504385W
TB38504495K
TB275790M
TB275879Q
TB276000X
TB276152W

Example links:
to a message on the forum:
http://www.broekpolderbewoners.nl/forums/message.asp?MessageID=2445
the link that hangs from the reply button in that message:
http://www.broekpolderbewoners.nl/forums/post.asp?InReplyTo=2445

Attached you'll find a wget of that last link.

Comment 10

[u38342]

There seems to be no other similar pages....so I will not complain...:)

Comment 11

[Asa Dotzler [:asa]]

Teetsuji,  if you are crashing in Mozilla the best thing you can do to help the
developers fix your bug is to attach a stacktrace. If you're not building
yourself you are not out of luck.  Mozilla (thanks to a very cool donation from
Netscape) releases nightly and milestone builds with Full Circle's Talkback.
Talkback should catch most crashes and offer to send in a crash report. I can
retrieve that crash report and attach it to your bug report if you provide
either the Incident ID (you can get it by running the talkback program from
/components/talkback/) or you can let me know the email address you used to
submit the report and the time of sending. Thanks for your help in testing
Mozilla and reporting bugs.

Comment 12

[u38342]

Sure, thanks.  This bug still exists in build 20011227 on RH7.2.  I sent crash
report by talkback just now, and the Incident ID is TB979073M.
  I don't encounter this problem with any other pages.

Comment 13

[Asa Dotzler [:asa]]

Thanks for the quick reply Tetsuji! Looks from your talkback report like a crash
in the cache code. I'm updating the component to Networking:cache where the
appropriate developers will see the report. Thanks again for your help in
testing MOzilla and reporting bugs.

Stack Signature  0x00000000 3ae51fd1
Trigger Time 2001-12-28 02:35:53
Email Address [e-mail]
URL visited www.net2phone.com
User Comments I described this bug in
http://bugzilla.mozilla.org/show_bug.cgi?id=114292
Build ID 2001122708
Product ID MozillaTrunk
Platform
Operating System LinuxIntel
Module
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
0x00000000
PL_DHashTableOperate()
nsCacheEntryHashTable::GetEntry()
nsMemoryCacheDevice::DeactivateEntry()
nsCacheService::DeactivateEntry()
nsCacheService::CloseDescriptor()
nsCacheEntryDescriptor::Close()
nsCacheEntryDescriptor::~nsCacheEntryDescriptor()
nsCacheEntryDescriptor::Release()
nsCOMPtr_base::assign_with_AddRef()
nsHttpChannel::CloseCacheEntry()
nsHttpChannel::ProcessResponse()
nsHttpChannel::OnStartRequest()
nsOnStartRequestEvent::HandleEvent()
nsARequestObserverEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xea7a (0x4037fa7a)
libglib-1.2.so.0 + 0x10055 (0x40381055)
libglib-1.2.so.0 + 0x10659 (0x40381659)
libglib-1.2.so.0 + 0x107e8 (0x403817e8)
libgtk-1.2.so.0 + 0x9127b (0x4029d27b)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1c627 (0x404c6627) 

Comment 14

[Blake Ross]

*** Bug 117420 has been marked as a duplicate of this bug. ***

Comment 15

[Blake Ross]

*** Bug 116318 has been marked as a duplicate of this bug. ***

Comment 16

[Blake Ross]

Nominating for machv since a bunch of people are seeing this crash at a bunch 
of urls, randomly (and hey, look at where the reporter of this bug managed to 
crash ;-)

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 117336 has been marked as a duplicate of this bug. ***

Comment 18

[Matt McClure]

On Win2K, with Mozilla 0.9.7, I'm able to reproduce the crash I reported in Bug 
117336 (dup of this one).  Talkback ID TB1083520Q.

Comment 19

[u38342]

Hey Blake!  I didn't *manage* to crash!!   Mozilla simply crashed ;-)   Actually
I tried it again and again to make sure...   Funny thing is that release0.9.6
doesn't crash.  But I made a minor mistake in describing the original report. 
With Mozilla0.9.6, Mozilla doesn't crash but *not* proceeds to the next step. 
Just stay the same page(asking your account info.)   Anyway, Mozilla0.9.6 works
fine.   So I didn't think it should have been difficult for developpers to fix
it, if diff were taken between nightly at that time and 0.9.6.   But time has
passed, and now it has become more difficult...  I wish I had known how to use
talkback....

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 117826 has been marked as a duplicate of this bug. ***

Comment 21

[Tom Everingham]

*** Bug 117779 has been marked as a duplicate of this bug. ***

Comment 22

[R.K.Aa.]

*** Bug 118176 has been marked as a duplicate of this bug. ***

Comment 23

[Tom Everingham]

*** Bug 115475 has been marked as a duplicate of this bug. ***

Comment 24

[Olav Vitters]

*** Bug 118325 has been marked as a duplicate of this bug. ***

Comment 25

[Tom Everingham]

*** Bug 118716 has been marked as a duplicate of this bug. ***

Comment 26

[Tom Everingham]

*** Bug 115672 has been marked as a duplicate of this bug. ***

Comment 27

[Jay Patel [:jay]]

Adding Trunk [@ 0x00000000 - nsCacheMetaData::HashKey | PL_DHashTableOperate] to
summary, since this is occurring under both those stack signature in Talkback
data.  Here's the Windows stack trace if anyone's interested:

Stack trace(Frame) 

	 0x00000000  
	 nsCacheMetaData::HashKey
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheMetaData.cpp  line 225] 
	 PL_DHashTableOperate
[d:\builds\seamonkey\mozilla\xpcom\ds\pldhash.c  line 482] 
	 nsCacheEntryHashTable::GetEntry
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheEntry.cpp  line 505] 
	 nsMemoryCacheDevice::DeactivateEntry
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsMemoryCacheDevice.cpp  line 161] 
	 nsCacheService::DeactivateEntry
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp  line 1290] 
	 nsCacheService::CloseDescriptor
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp  line 1244] 
	 nsCacheEntryDescriptor::Close
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheEntryDescriptor.cpp  line
340] 
	 nsCacheEntryDescriptor::~nsCacheEntryDescriptor
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheEntryDescriptor.cpp  line 49] 
	 nsCacheEntryDescriptor::`scalar deleting destructor'  
	 nsCacheEntryDescriptor::Release
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheEntryDescriptor.cpp  line 32] 
	 nsCOMPtr_base::assign_with_AddRef
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp  line 74] 
	 nsHttpChannel::ProcessResponse
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line 515] 
	 nsHttpChannel::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line
2352] 
	 nsOnStartRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp  line 162] 
	 PL_HandleEvent
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 591] 
	 PL_ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 524] 
	 _md_EventReceiverProc
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1072] 
	 nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp  line 303] 
	 main1
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1280] 
	 main
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1597] 
	 WinMain
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1615] 
	 WinMainCRTStartup()  
	 KERNEL32.DLL + 0x17d08 (0x77e97d08)   

Comment 28

[Yanko Kaneti]

there is a wierd but reliable way of reproducing this bug described in this
galeon bug http://bugzilla.gnome.org/show_bug.cgi?id=68245

i've tried it with 0.9.7 and cvs from a few days back

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Any progress on this?  It's one of the top crashers on the current trunk and it
would be really good to get a fix in to 0.9.8.

Comment 30

[Olav Vitters]

*** Bug 119685 has been marked as a duplicate of this bug. ***

Comment 31

[Ben Tremblay]

Running 2001122106 on Win95 I have both a) gotten through the steps and posted a
reply, and b) crashed. (Talkback from ab006@chebucto w/trace sent ummmm 45
minutes ago)
URLs used were:
http://www.broekpolderbewoners.nl/
http://www.broekpolderbewoners.nl/forums/default.asp
http://www.broekpolderbewoners.nl/forums/forum.asp?ForumID=10
and moz crashed with windows open when selecting a message from that forum.

The identical route succeeded just now, with no negative consequence when
replying to http://www.broekpolderbewoners.nl/forums/message.asp?MessageID=795
(M$ .asp compained that I had left "PostedBy" blank, quite properly).

*wonders if he should duck*

Comment 32

[Olav Vitters]

*** Bug 119822 has been marked as a duplicate of this bug. ***

Comment 33

[Olav Vitters]

*** Bug 119962 has been marked as a duplicate of this bug. ***

Comment 34

[gordon]

*** Bug 114820 has been marked as a duplicate of this bug. ***

Comment 35

[gordon]

*** Bug 113139 has been marked as a duplicate of this bug. ***

Comment 36

[gordon]

*** Bug 117889 has been marked as a duplicate of this bug. ***

Comment 37

[gordon]

*** Bug 119308 has been marked as a duplicate of this bug. ***

Comment 38

[Jay Patel [:jay]]

Adding M097 to the summary since this is also major topcrasher for Mozilla
0.9.7...it would great to have a fix in for M098!

Comment 39

[Olav Vitters]

*** Bug 120340 has been marked as a duplicate of this bug. ***

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Why is the nsCacheMetaData::HashKey callback being called for an
nsCacheEntryHashTable table?

Comment 41

[Matthias Versen [:Matti]]

*** Bug 120649 has been marked as a duplicate of this bug. ***

Comment 42

[Matthias Versen [:Matti]]

*** Bug 120663 has been marked as a duplicate of this bug. ***

Comment 43

[gordon]

darin and I are now able to reproduce this crash and are in the process of
debugging it.  The nsCString in the cache entry is getting corrupted
mysteriously.  Further bulletins as events warrant.

Comment 44

[gordon]

Attachment: proposed fix

This crash is due to a change to the cache to bind entries even if they have no
data (meta-data only) that went in last October and wasn't used until HTTP
started using it early December.

In very rare cases, it was possible for a cache entry with no data to get
unexpectedly evicted from the memory cache while it was in the process of being
bound.	Further attempts to use the cache entry made bad things happen.  This
patch prevent cache entries that are being bound from eviction consideration.

Thanks to Darin for helping track this down.

Comment 45

[Brendan Eich [:brendan]]

Comment on attachment 65549 [details] [diff] [review]
proposed fix

r/sr=[e-mail] -- darin can sr= I hope.

/be

Comment 46

[Darin Fisher]

Comment on attachment 65549 [details] [diff] [review]
proposed fix

sr=darin

Comment 47

[Christopher Blizzard (:blizzard)]

a=blizzard on behalf of drivers for 0.9.8

Comment 48

[gordon]

Patch checked in.  Marking fixed.

Comment 49

[Olav Vitters]

*** Bug 120862 has been marked as a duplicate of this bug. ***

Comment 50

[Olav Vitters]

*** Bug 120765 has been marked as a duplicate of this bug. ***

Comment 51

[Tom Everingham]

verified - net2phone and other sites are not crashing anymore.

01/25/02 trunk builds - linux rh6, mac osX, win NT4

Comment 52

[gordon]

*** Bug 120231 has been marked as a duplicate of this bug. ***

Comment 53

[gordon]

*** Bug 121492 has been marked as a duplicate of this bug. ***

Comment 54

[Axel Braun]

right, works on my.advance.de in between...but now bug # 69833 is the limiting
factor....

Comment 55

[Olav Vitters]

*** Bug 122738 has been marked as a duplicate of this bug. ***