It's a residual crash but there is a spike starting in 13.0a1/20120201. The regression window is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f26b7bee352&tochange=e18c7bc2c28e Signature nsGfxScrollFrameInner::ScrollToImpl(nsPoint) More Reports Search UUID de6a23df-7093-4b76-9a8b-6dfd72120201 Date Processed 2012-02-01 15:37:55 Uptime 158 Last Crash 2.8 minutes before submission Install Age 46.4 minutes since version was first installed. Install Time 2012-02-01 14:50:30 Product Firefox Version 13.0a1 Build ID 20120201031146 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 15 stepping 13 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x6e0061 App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0x2a02, AdapterSubsysID: 022f1028, AdapterDriverVersion: 126.96.36.1990 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers+ Processor Notes INFO: This record is a replacement for a previous record with the same uuid EMCheckCompatibility False Frame Module Signature [Expand] Source 0 xul.dll nsGfxScrollFrameInner::ScrollToImpl 1 xul.dll nsGfxScrollFrameInner::AsyncScrollCallback layout/generic/nsGfxScrollFrame.cpp:1527 2 xul.dll nsGfxScrollFrameInner::AsyncScrollCallback layout/generic/nsGfxScrollFrame.cpp:1537 3 xul.dll nsDOMWindowUtils::ComputeAnimationDistance dom/base/nsDOMWindowUtils.cpp:1822 4 xul.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:428 5 xul.dll nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:524 6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:657 7 nspr4.dll PR_Unlock nsprpub/pr/src/threads/combined/prulock.c:347 8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:201 9 xul.dll _SEH_epilog4 10 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:175 11 xul.dll mozilla::storage::AsyncStatement::QueryInterface storage/src/mozStorageAsyncStatement.cpp:311 12 xul.dll nsBaseAppShell::Run widget/xpwidgets/nsBaseAppShell.cpp:189 13 @0x8ac73f More reports at: https://crash-stats.mozilla.com/report/list?signature=nsGfxScrollFrameInner%3A%3AScrollToImpl%28nsPoint%29
It's #1 top crasher in 13.0a1 with 6 crashes an hour. It might be a regression from bug 90268.
Some comments from the reports: *wow a mouse scroll crashed... *Every Lifehacker page I go to crashes when I scroll or click on the page *Google images > switch to result page
This is 100% reproducible for me on http://hg.mozilla.org/mozilla-central/rev/e777c939a3f9. STR: 1. Load lifehacker.com 2. Once the page has fully loaded, attempt to scroll. 3. Crash https://crash-stats.mozilla.com/report/index/bp-6755afc1-3f93-41e7-863f-35c072120204 https://crash-stats.mozilla.com/report/index/bp-ecd5e7cb-9df9-4e54-9a46-48bb52120204
(In reply to Kyle Huey [:khuey] (email@example.com) from comment #3) > This is 100% reproducible for me I can't reproduce with a fresh profile or with Adblock Plus installed.
Yes, this is absolutely a dead nsPluginInstanceOwner being called through nsIScrollPositionListener. Is this flashblock/adblock-only, or does this happen in stock Firefox?
I haven't tried to reproduce without Adblock.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #6) > Is this flashblock/adblock-only, or does this happen in stock Firefox? + Greasemonkey + NoScript: There are crash reports without extension: bp-ede4c075-4417-4c8a-83a1-1ae1e2120209 bp-1edce8a9-8557-423f-85b4-659df2120208
This happens 100% of time in jalopnik.com and gizmodo.com With NoScript enabled this crash does not happen. My about:support info http://pastebin.com/gYAHwYW9
I don't use Greasmonkey, Noscript or AdBlock - on FlashBlock and I've yet to get this crash on the listed sites in comment #9 and #3
Is this something we can fix? Can we assign it to someone?
I had the same crash after opening http://lifehacker.com/5884941/browser-speed-tests-chrome-17-firefox-10-internet-explorer-9-and-opera-1161 Mozilla/5.0 (Windows NT 6.1; rv:13.0a1) Gecko/20120214 Firefox/13.0a1 SeaMonkey/2.10a1, Flash 11.1 r102 and Adblock+ (easylist filterlist)
If Steven is right in this comment on another bug: https://bugzilla.mozilla.org/show_bug.cgi?id=724717#c2 That explanation could be the cause of this.
Created attachment 598371 [details] [diff] [review] fix v1.0 (limit to Mac Carbon) The code that is crashing is only used for Carbon plugin on Mac OS X, which are quite rare. Firefox will only run them by default on Mac OS X 10.5. This patch skips scroll listener registration except for 32-bit Mac OS X builds and Carbon plugins. This crash possibility will actually remain there, we can open a new bug on that though.
Try server run: https://tbpl.mozilla.org/?tree=Try&rev=880edc058f7b
Comment on attachment 598371 [details] [diff] [review] fix v1.0 (limit to Mac Carbon) This looks fine to me, at least as a stopgap. I'll take your word for it that this stuff isn't needed at all on other platforms than OS X.
I've definitely seen this crash on Windows.
(In reply to Kyle Huey [:khuey] (firstname.lastname@example.org) from comment #17) > I've definitely seen this crash on Windows. I meant that the code is only necessary for Mac OS X Carbon plugins, even though we're running it on all platforms for all plugins. My patch will fix this crash for the vast majority of users by stopping the code from running on Windows entirely, and limiting it to Carbon plugins in 32-bit Firefox on Mac OS X 10.5.
Ah, ok. Carry on :-)
pushed to mozilla-inbound http://hg.mozilla.org/integration/mozilla-inbound/rev/19d7edbf60bc
Created attachment 598565 [details] [diff] [review] real fix for Mac Carbon plugins, v1.0 I can't reproduce this crash but this is my best guess as to the problem. We should unregister as a scroll listener when the object frame changes or goes away instead of just when it goes away.
(In reply to Josh Aas (Mozilla Corporation) from comment #22) > Created attachment 598565 [details] [diff] [review] > real fix for Mac Carbon plugins, v1.0 Try server run: https://tbpl.mozilla.org/?tree=Try&rev=bc6f5aad71dc
Comment on attachment 598565 [details] [diff] [review] real fix for Mac Carbon plugins, v1.0 I haven't tested this either, but it sounds reasonable. And definitely better than just leaving carbon plugins to crash on OS X.
Pushed carbon plugin fix to mozilla-inbound. We can close this bug once that hits m-c, no crashes reported since the last fix made it into a nightly. http://hg.mozilla.org/integration/mozilla-inbound/rev/428d0a52f855
[Triage Comment] No need to track this now that it's resolved and will be riding the train.