It first showed up in 25.0a1/20130627 and is currently #1 top crasher in 25.0a1 on MetroFirefox. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc80aa0c7c13&tochange=3b955f306226 It's likely a regression from bug 866852. Signature nsIFrame::GetNearestWidget() More Reports Search UUID 4aaeed2c-aeb3-42a0-9d7d-c5b2d2130628 Date Processed 2013-06-28 11:29:30.002366 Uptime 21 Install Age 44297 since version was first installed. Install Time 2013-06-27 23:01:32 Product MetroFirefox Version 25.0a1 Build ID 20130627031027 Release Channel nightly OS Windows NT OS Version 6.2.9200 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 42 stepping 7 | None Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x4 User Comments App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x1200, AdapterSubsysID: 00000000, AdapterDriverVersion: 9.18.13.1106 Has dual GPUs. GPU #2: AdapterVendorID2: 0x8086, AdapterDeviceID2: 0x0112, AdapterSubsysID2: 0000000c, AdapterDriverVersion2: 9.17.10.2932D2D! D2D+ DWrite? DWrite+ Processor Notes sp-processor07_phx1_mozilla_com_20693:2012; non-integer value of "SecondsSinceLastCrash"; WARNING: raw_crash missing Add-ons EMCheckCompatibility True Adapter Vendor ID 0x10de Adapter Device ID 0x1200 Total Virtual Memory 4294836224 Available Virtual Memory 3840118784 System Memory Use Percentage 20 Available Page File 11400126464 Available Physical Memory 6745059328 Accessibility Active Frame Module Signature Source 0 xul.dll nsIFrame::GetNearestWidget() layout/generic/nsFrame.cpp 1 xul.dll nsLayoutUtils::PaintFrame(nsRenderingContext *,nsIFrame *,nsRegion const &,unsigned int,unsigned int) layout/base/nsLayoutUtils.cpp 2 xul.dll PresShell::Paint(nsView *,nsRegion const &,unsigned int) layout/base/nsPresShell.cpp 3 xul.dll nsViewManager::ProcessPendingUpdatesForView(nsView *,bool) view/src/nsViewManager.cpp 4 xul.dll nsRefreshDriver::Tick(__int64,mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp 5 xul.dll mozilla::RefreshDriverTimer::Tick() layout/base/nsRefreshDriver.cpp 6 xul.dll nsTimerImpl::Fire() xpcom/threads/nsTimerImpl.cpp 7 nss3.dll nss3.dll@0xa860 8 nss3.dll PR_IntervalNow nsprpub/pr/src/misc/prinrval.c 9 xul.dll nsThread::ProcessNextEvent(bool,bool *) xpcom/threads/nsThread.cpp 10 xul.dll NS_ProcessPendingEvents(nsIThread *,unsigned int) obj-firefox/xpcom/build/nsThreadUtils.cpp 11 xul.dll nsBaseAppShell::NativeEventCallback() widget/xpwidgets/nsBaseAppShell.cpp 12 xul.dll MetroAppShell::NativeCallback() widget/windows/winrt/MetroAppShell.cpp 13 xul.dll MetroAppShell::EventWindowProc(HWND__ *,unsigned int,unsigned int,long) widget/windows/winrt/MetroAppShell.cpp 14 user32.dll InternalCallWinProc 15 user32.dll UserCallWinProcCheckWow 16 user32.dll DispatchMessageWorker 17 user32.dll DispatchMessageW 18 windows.ui.dll Windows::UI::Core::CDispatcher::ProcessMessage(int,int *) d:\\w8rtm\\windows\\advcore\\winrt\\iwindow\\corewindow\\dispatcher.cpp 19 shell32.dll _CIsqrt More reports at: https://crash-stats.mozilla.com/report/list?product=MetroFirefox&signature=nsIFrame%3A%3AGetNearestWidget%28%29 https://crash-stats.mozilla.com/report/list?product=MetroFirefox&signature=nsView%3A%3AGetNearestWidget%28nsPoint*%29

I've seen this locally in release builds. Should block v1.

Bas, could you take a peek?

https://crash-stats.mozilla.com/report/index/7dc29743-0c67-4a51-af6c-3611e2130629 I'm able to reproduce this pretty consistently on my Iconia W3 after I close Metro Firefox by swiping down from the top of the screen.

I suspect this is more of a widget integration problem than any sort of problem with OMTC D3D. I could still look at it but it might take me a little, as I have no idea how this code works and don't have a fast Win8 machine with me in San Francisco.

Probably related: https://crash-stats.mozilla.com/report/index/2c272cd2-2b47-4384-90f5-c92ca2130704 crashes in [@ mozilla::layers::LayerManagerUserDataDestroy ], also on a refresh driver tick.

Based on Bas's comment 6, I went through windows widget and metro widget tear down methods and matched them up call for call. A lot of this code is a no-op in metro with a couple exceptions, NotifyWindowDestroyed which was added last fall while we were still on elm, and nsBaseWidget::OnDestroy() which frees the device context. I can't confirm this addresses this crash, but it insures we go through the same process as win32 widget. Lets land this and see if it has any effect. In testing I don't see any issues with this in release builds. Will also push to try.

debug/release builds with an mc run: https://tbpl.mozilla.org/?tree=Try&showall=0&rev=74e977208f06

Doubt this is fixed by widget shutdown cleanup. I just got one of these with that patch in my queue.

This is caused by our use of WaitForNotify calls in the ipc code. Which explains why this showed up when we turned on omtc. WaitForNotify processes windowing events, including native callbacks generated by the refresh driver, so nine times out of ten we force quit right in the middle of a paint. Which is bad.

This patch does a few things: 1) a little bit of cleanup and namespacing surrounding the app shell gecko message we already defer in WindowsMessageLoop. 2) add deferred message support for the "Windows.UI.Core.CoreWindow" class, which is the main browser window we render to in metro. 3) add support for deferring the system close event, which we often received while layout is talking with the compositor, which fixes the crash this bug is about.

Mostly cleanup plus support for a metro specific window type and message in WindowsMessageLoop logic.

Currently #1 and #2 on our top crash list.

Comment on attachment 779339 [details] [diff] [review] defer msg patch v.1 For whoever can get to this the soonest. Sorry to pester but this crash currently represents 70% of our crashes in metrofx, so we'd like to get it fixed. https://crash-stats.mozilla.com/topcrasher/products/MetroFirefox/versions/25.0a1

Thanks! https://hg.mozilla.org/integration/fx-team/rev/74f983165c02

(In reply to Jim Mathies [:jimm] from comment #16) > Currently #1 and #2 on our top crash list. > Keywords: topcrash Please set the topcrash threshold in https://wiki.mozilla.org/CrashKill/Topcrash.

Top three crashes appear to be fixed, no reports after build 20130807161117.

Went through the following "Defect" for iteration #12 with possibly some issues. Used the following build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-08-13-03-02-05-mozilla-central/ Jim, I am not receiving the above crash anymore, but I do receive this one here and there, could this crash be related to the one in this ticket? https://crash-stats.mozilla.com/report/index/f39307a9-7ca7-41e0-981a-31b5c2130814

(In reply to Kamil Jozwiak [:kjozwiak] from comment #22) > Went through the following "Defect" for iteration #12 with possibly some > issues. Used the following build: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-08-13-03-02-05- > mozilla-central/ > > Jim, I am not receiving the above crash anymore great. crash stats confirms this is fixed too. > but I do receive this one > here and there, could this crash be related to the one in this ticket? > > https://crash-stats.mozilla.com/report/index/f39307a9-7ca7-41e0-981a- > 31b5c2130814 That's already filed as bug 844354.

Went through the following "Defect" for iteration #13 without any issues. Used the following build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-05-03-02-06-mozilla-central/ - Opened several tabs and then quickly closed Firefox Metro while tabs where loading without any crashes or issues - Had at least ten different tabs opened and then closed Firefox Metro without any crashes or issues - Went through the steps in 888532 (duplicate of this) and ensured there was no crashes after Firefox Metro was closed - Closed Firefox Metro by sliding the mouse pointer in the left corner of the desktop without any crashes or issues - Went through the above test cases using filled view without any issues

Went through the following "Defect" for iteration #15 without any issues. Used the following build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-30-03-02-05-mozilla-central/ - Went through the original issue described in comment #0 without any issues - Went through the original steps described in bug 888532 comment #0 without any issues - Went through the test cases added in comment # 24 without any issues