Closed Bug 590372 Opened 14 years ago Closed 14 years ago

Crash in [@ @0x0 | nsBaseHashtable<nsPtrHashKey<imgIRequest>, unsigned int, unsigned int>::s_EnumReadStub ]

Categories

(Core :: DOM: Core & HTML, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: marcia, Assigned: bholley)

References

()

Details

(Keywords: crash)

Crash Data

Seen while sifting through trunk crash stats and reproduced while running Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100824 Minefield/4.0b5pre. This bug needs a better home than Core | General. Will try to see if this is Mac only or whether it repros on Windows.

STR:
1. Load the site in the URL.
2. Scroll the page down using the mouse.
3. After scrolling down and then back up I crash. You may have to do it a few times to trigger the crash.

https://crash-stats.mozilla.com/report/index/bp-3465a93b-b678-4076-92dd-42c682100824

https://crash-stats.mozilla.com/report/index/bp-14c2b4c9-ec03-4a11-8455-922512100824

Frame  	Module  	Signature [Expand]  	Source
0 		@0x0 	
1 	XUL 	nsBaseHashtable<nsPtrHashKey<imgIRequest>,unsigned int,unsigned int>::s_EnumReadStub 	nsBaseHashtable.h:345
2 	XUL 	PL_DHashTableEnumerate 	pldhash.c:754
3 	XUL 	nsDocument::~nsDocument 	nsBaseHashtable.h:206
4 	XUL 	nsHTMLDocument::~nsHTMLDocument 	content/html/document/src/nsHTMLDocument.h:75
5 	XUL 	nsNodeUtils::LastRelease 	content/base/src/nsNodeUtils.cpp:294
6 	XUL 	nsDocument::Release 	content/base/src/nsDocument.cpp:1631
7 	XUL 	nsXPCOMCycleCollectionParticipant::Unroot 	nsCycleCollectionParticipant.cpp:74
8 	XUL 	nsCycleCollector::CollectWhite 	xpcom/base/nsCycleCollector.cpp:1800
9 	XUL 	nsCycleCollector::Collect 	xpcom/base/nsCycleCollector.cpp:2655
10 	XUL 	nsCycleCollector_collect 	xpcom/base/nsCycleCollector.cpp:3168
11 	XUL 	nsJSContext::CC 	dom/base/nsJSEnvironment.cpp:3635
12 	XUL 	nsJSContext::MaybeCC 	dom/base/nsJSEnvironment.cpp:3723
13 	XUL 	GCTimerFired 	dom/base/nsJSEnvironment.cpp:3711
14 	XUL 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:425
15 	XUL 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:517
16 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:547
17 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:200
18 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/src/xpwidgets/nsBaseAppShell.cpp:126
19 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/src/cocoa/nsAppShell.mm:394
20 	CoreFoundation 	__CFRunLoopDoSources0 	
21 	CoreFoundation 	__CFRunLoopRun 	
22 	CoreFoundation 	CFRunLoopRunSpecific 	
23 	CoreFoundation 	CFRunLoopRunInMode 	
24 	HIToolbox 	RunCurrentEventLoopInMode 	
25 	HIToolbox 	ReceiveNextEventCommon 	
26 	HIToolbox 	BlockUntilNextEventMatchingListInMode 	
27 	AppKit 	_DPSNextEvent 	
28 	AppKit 	-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 	
29 	AppKit 	-[NSApplication run] 	
30 	XUL 	nsAppShell::Run 	widget/src/cocoa/nsAppShell.mm:747
31 	XUL 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:191
32 	XUL 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3662
33 	firefox-bin 	main 	browser/app/nsBrowserApp.cpp:158
34 	firefox-bin 	firefox-bin@0xbf5 	
35 		@0x2
Adding this - the trick seems to be to scroll *rapidly* on that page to trigger the crash.
Component: General → DOM
QA Contact: general → general
Bobby, this seems to be the mImageTracker enumeration in the nsDocument destructor...
blocking2.0: --- → ?
Though it's weird that this would crash.  Really weird.
Unless we're invoking the destructor twice or something?
I believe that this, bug 590395, bug 588681, and bug 589469 are all the same issue. I requested bz's input in bug 589469 comment 6, and thankfully Jesse posted a simplified test-case in bug 590395. I should be able to figure this out shortly.
Blocks: 512260
Depends on: 590395
Blocking, and assigning to Bobby.
Assignee: nobody → bobbyholley+bmo
blocking2.0: ? → final+
I believe this should be fixed by the push in comment 6. Can anyone with more crash-stats-fu than me verify this?
(would also be useful to hear about bug 588681)
I believe this should be fixed by the patch in bug 589469. Resolving fixed, please re-open if you see it again.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
In the last 18 days crash volume has declined, and only one crash  with this singnature this month.

last crashes were seen on  builds from 2010 08 26 & 27

20100829 2 4.0b5pre2010082603 1 4.0b5pre2010082703 1
20100902 1 4.0b5pre2010082603 1
(In reply to comment #11)
> In the last 18 days crash volume has declined, and only one crash  with this
> singnature this month.
> 
> last crashes were seen on  builds from 2010 08 26 & 27
> 
> 20100829 2 4.0b5pre2010082603 1 4.0b5pre2010082703 1
> 20100902 1 4.0b5pre2010082603 1

Awesome - that's exactly when the fix landed!
Crash Signature: [@ @0x0 | nsBaseHashtable<nsPtrHashKey<imgIRequest>, unsigned int, unsigned int>::s_EnumReadStub ]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.