Defect - Crash in nsIFrame::GetNearestWidget

VERIFIED FIXED in mozilla26

Status

()

defect
P1
critical
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: scoobidiver, Assigned: jimm)

Tracking

({crash, regression, topcrash})

25 Branch
mozilla26
All
Windows 8.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox24 unaffected, firefox25 affected)

Details

(Whiteboard: [metro-crash][omtc-crash][topcrash] feature=defect c=graphic_display_features u=metro_firefox_user p=1, crash signature)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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
(Assignee)

Comment 1

6 years ago
I've seen this locally in release builds. Should block v1.
Summary: crash in nsIFrame::GetNearestWidget → Defect - Crash in nsIFrame::GetNearestWidget
Whiteboard: [metro-crash] → [metro-crash] feature=defect c=tbd u=tbd p=0
(Assignee)

Comment 2

6 years ago
Bas, could you take a peek?
Flags: needinfo?(bas)
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.
(Reporter)

Updated

6 years ago
Duplicate of this bug: 888532
Priority: -- → P1
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.
Flags: needinfo?(bas)
(Assignee)

Comment 7

6 years ago
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.
(Assignee)

Updated

6 years ago
Whiteboard: [metro-crash] feature=defect c=tbd u=tbd p=0 → [metro-crash][omtc-crash] feature=defect c=tbd u=tbd p=0
(Assignee)

Comment 8

6 years ago
Posted patch patch v.1Splinter Review
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.
Assignee: nobody → jmathies
Attachment #777061 - Flags: review?(netzen)
(Assignee)

Updated

6 years ago
Blocks: metrov1it11
(Assignee)

Updated

6 years ago
Whiteboard: [metro-crash][omtc-crash] feature=defect c=tbd u=tbd p=0 → [metro-crash][omtc-crash] feature=defect c=tbd u=tbd p=1
No longer blocks: metrov1defect&change
Status: NEW → ASSIGNED
QA Contact: jbecerra
Whiteboard: [metro-crash][omtc-crash] feature=defect c=tbd u=tbd p=1 → [metro-crash][omtc-crash] feature=defect c=graphic_display_features u=metro_firefox_user p=1
Attachment #777061 - Flags: review?(netzen) → review+
(Assignee)

Comment 9

6 years ago
debug/release builds with an mc run:

https://tbpl.mozilla.org/?tree=Try&showall=0&rev=74e977208f06
(Assignee)

Comment 11

6 years ago
Doubt this is fixed by widget shutdown cleanup. I just got one of these with that patch in my queue.
Whiteboard: [metro-crash][omtc-crash] feature=defect c=graphic_display_features u=metro_firefox_user p=1 → [metro-crash][omtc-crash][leave-open] feature=defect c=graphic_display_features u=metro_firefox_user p=1
(Assignee)

Comment 13

6 years ago
Posted file omtc wfn stack
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.
(Assignee)

Comment 14

6 years ago
Posted patch patch (obsolete) — Splinter Review
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.
(Assignee)

Comment 15

6 years ago
Mostly cleanup plus support for a metro specific window type and message in WindowsMessageLoop logic.
Attachment #779334 - Attachment is obsolete: true
Attachment #779339 - Flags: review?(bent.mozilla)
(Assignee)

Updated

6 years ago
Whiteboard: [metro-crash][omtc-crash][leave-open] feature=defect c=graphic_display_features u=metro_firefox_user p=1 → [metro-crash][omtc-crash] feature=defect c=graphic_display_features u=metro_firefox_user p=1
(Assignee)

Comment 16

6 years ago
Currently #1 and #2 on our top crash list.
Keywords: topcrash
Whiteboard: [metro-crash][omtc-crash] feature=defect c=graphic_display_features u=metro_firefox_user p=1 → [metro-crash][omtc-crash][topcrash] feature=defect c=graphic_display_features u=metro_firefox_user p=1
Blocks: metrov1it12
No longer blocks: metrov1it11
(Assignee)

Updated

6 years ago
Blocks: 900127
(Assignee)

Comment 17

6 years ago
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
Attachment #779339 - Flags: review?(benjamin)

Updated

6 years ago
Attachment #779339 - Flags: review?(benjamin) → review+
(Assignee)

Updated

6 years ago
Attachment #779339 - Flags: review?(bent.mozilla)
https://hg.mozilla.org/mozilla-central/rev/74f983165c02
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
(Reporter)

Comment 20

6 years ago
(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.
(Assignee)

Comment 21

6 years ago
Top three crashes appear to be fixed, no reports after build 20130807161117.
Status: RESOLVED → VERIFIED
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
Flags: needinfo?(jmathies)
(Assignee)

Comment 23

6 years ago
(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.
Flags: needinfo?(jmathies)
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
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.