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)
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
Reporter | ||
Comment 1•14 years ago
|
||
Adding this - the trick seems to be to scroll *rapidly* on that page to trigger the crash.
Comment 2•14 years ago
|
||
Bobby, this seems to be the mImageTracker enumeration in the nsDocument destructor...
blocking2.0: --- → ?
Comment 3•14 years ago
|
||
Though it's weird that this would crash. Really weird.
Comment 4•14 years ago
|
||
Unless we're invoking the destructor twice or something?
Assignee | ||
Comment 5•14 years ago
|
||
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.
Updated•14 years ago
|
Assignee | ||
Comment 6•14 years ago
|
||
Pushed a likely fix to this: http://hg.mozilla.org/mozilla-central/rev/cf4d7946e2e0
Comment 7•14 years ago
|
||
Blocking, and assigning to Bobby.
Assignee: nobody → bobbyholley+bmo
blocking2.0: ? → final+
Assignee | ||
Comment 8•14 years ago
|
||
I believe this should be fixed by the push in comment 6. Can anyone with more crash-stats-fu than me verify this?
Assignee | ||
Comment 9•14 years ago
|
||
(would also be useful to hear about bug 588681)
Assignee | ||
Comment 10•14 years ago
|
||
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
Comment 11•14 years ago
|
||
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
Assignee | ||
Comment 12•14 years ago
|
||
(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!
Updated•13 years ago
|
Crash Signature: [@ @0x0 | nsBaseHashtable<nsPtrHashKey<imgIRequest>, unsigned int, unsigned int>::s_EnumReadStub ]
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•