Closed Bug 114292 Opened 23 years ago Closed 23 years ago

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

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: u38342, Assigned: gordon)

References

(
URL
)

Details

(Keywords: crash, topcrash, Whiteboard: [driver:dbaron])

Crash Data

Attachments

(2 files)

The page that crashes the browser
28.60 KB, text/html
Details
proposed fix
1002 bytes, patch
brendan
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review 
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.
confirmed on winxp 2001120808
Status: UNCONFIRMED → NEW
Ever confirmed: true
hmm... this bug only happend once to me - when i tried this again after the
crash mozilla didn't crash again!! 
Hmm.....On my RH7.2, it always crash.
WFME on win2k build 2001120808
Keywords: crash
wfm using build 2001120821 on Linux (glibc 2.1.3).
Checked with Windows Me and Build 2001112009, and it didn't crashed. Maybe only
in Linux.
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...)
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.
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.
There seems to be no other similar pages....so I will not complain...:)
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.
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.
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 tetsuji@rai.sytes.net
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)
Assignee: asa → gordon
Component: Browser-General → Networking: Cache
QA Contact: doronr → tever
*** Bug 117420 has been marked as a duplicate of this bug. ***
*** Bug 116318 has been marked as a duplicate of this bug. ***
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 ;-)
Keywords: nsbeta1
OS: Linux → All
Hardware: PC → All
*** Bug 117336 has been marked as a duplicate of this bug. ***
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.
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....
*** Bug 117826 has been marked as a duplicate of this bug. ***
*** Bug 117779 has been marked as a duplicate of this bug. ***
*** Bug 118176 has been marked as a duplicate of this bug. ***
*** Bug 115475 has been marked as a duplicate of this bug. ***
*** Bug 118325 has been marked as a duplicate of this bug. ***
*** Bug 118716 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.8
*** Bug 115672 has been marked as a duplicate of this bug. ***
Keywords: topcrash
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)
Summary: Mozilla crashes on this page → Mozilla crashes on this page - Trunk [@ 0x00000000 - nsCacheMetaData::HashKey | PL_DHashTableOperate]
Summary: Mozilla crashes on this page - Trunk [@ 0x00000000 - nsCacheMetaData::HashKey | PL_DHashTableOperate] → Mozilla crashes on this page - Trunk [@ 0x00000000 - nsCacheMetaData::HashKey | PL_DHashTableOperate | 0x00000008]
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
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.
*** Bug 119685 has been marked as a duplicate of this bug. ***
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*
*** Bug 119822 has been marked as a duplicate of this bug. ***
*** Bug 119962 has been marked as a duplicate of this bug. ***
*** Bug 114820 has been marked as a duplicate of this bug. ***
*** Bug 113139 has been marked as a duplicate of this bug. ***
*** Bug 117889 has been marked as a duplicate of this bug. ***
*** Bug 119308 has been marked as a duplicate of this bug. ***
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!
Summary: Mozilla crashes on this page - Trunk [@ 0x00000000 - nsCacheMetaData::HashKey | PL_DHashTableOperate | 0x00000008] → Mozilla crashes on this page - Trunk M097 [@ 0x00000000 | 0x00000008 - nsCacheMetaData::HashKey | PL_DHashTableOperate]
Target Milestone: --- → mozilla0.9.8
*** Bug 120340 has been marked as a duplicate of this bug. ***
Why is the nsCacheMetaData::HashKey callback being called for an
nsCacheEntryHashTable table?
*** Bug 120649 has been marked as a duplicate of this bug. ***
*** Bug 120663 has been marked as a duplicate of this bug. ***
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.
Attached patch proposed fix — — Splinter Review 
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 on attachment 65549 [details] [diff] [review]
proposed fix

r/sr=brendan@mozilla.org -- darin can sr= I hope.

/be
Attachment #65549 - Flags: review+
Whiteboard: [driver:dbaron]
Comment on attachment 65549 [details] [diff] [review]
proposed fix

sr=darin
Attachment #65549 - Flags: superreview+
a=blizzard on behalf of drivers for 0.9.8
Keywords: mozilla0.9.8 → mozilla0.9.8+
Patch checked in.  Marking fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 120862 has been marked as a duplicate of this bug. ***
*** Bug 120765 has been marked as a duplicate of this bug. ***
verified - net2phone and other sites are not crashing anymore.

01/25/02 trunk builds - linux rh6, mac osX, win NT4
Status: RESOLVED → VERIFIED
*** Bug 120231 has been marked as a duplicate of this bug. ***
*** Bug 121492 has been marked as a duplicate of this bug. ***
right, works on my.advance.de in between...but now bug # 69833 is the limiting
factor....
*** Bug 122738 has been marked as a duplicate of this bug. ***
Crash Signature: [@ 0x00000000 | 0x00000008 - nsCacheMetaData::HashKey | PL_DHashTableOperate]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: