Closed Bug 806346 Opened 7 years ago Closed 5 years ago

crash in _d2d_clear_surface @ RenderTargetStateHolder::operator

Categories

(Core :: Graphics, defect, critical)

16 Branch
x86
Windows 8
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox17 + wontfix
firefox18 - ---

People

(Reporter: scoobidiver, Assigned: bas.schouten)

Details

(Keywords: crash, Whiteboard: [Win8][startupcrash])

Crash Data

Attachments

(1 file)

It's #139 top browser crasher in 16.0.2 and #84 in 17.0b3 and happens mainly on startup.
It's #3 top crasher in 16.0.2 and #2 in 17.0b3 for Windows 8 only.

Every GPUs are affected: AMD, NVIDIA, Intel.

Signature 	RenderTargetStateHolder::operator=(CD3DSurface*) More Reports Search
UUID	f726cd00-56c7-4748-9494-b79ea2121029
Date Processed	2012-10-29 02:41:41
Uptime	1
Last Crash	3.5 minutes before submission
Install Age	6.6 hours since version was first installed.
Install Time	2012-10-28 20:02:48
Product	Firefox
Version	16.0.2
Build ID	20121024073032
Release Channel	release
OS	Windows NT
OS Version	6.2.9200
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 16 model 6 stepping 3
Crash Reason	EXCEPTION_ACCESS_VIOLATION_EXEC
Crash Address	0xffffffffc76c1929
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x68f9, AdapterSubsysID: 03ca1043, AdapterDriverVersion: 8.982.10.8000
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x68f9
Total Virtual Memory	4294836224
Available Virtual Memory	4061765632
System Memory Use Percentage	29
Available Page File	6677372928
Available Physical Memory	3021373440

Frame 	Module 	Signature 	Source
0 		@0xc76c1929 	
1 	d2d1.dll 	RenderTargetStateHolder::operator= 	
2 	d2d1.dll 	DrawingContext::Flush 	
3 	d2d1.dll 	DrawingContext::EndDraw 	
4 	d2d1.dll 	D2DDeviceContextBase<ID2D1HwndRenderTarget,ID2D1HwndRenderTarget,ID2D1DeviceCont 	
5 	gkmedias.dll 	_d2d_clear_surface 	gfx/cairo/cairo/src/cairo-d2d-surface.cpp:719
6 	gkmedias.dll 	cairo_d2d_surface_create 	gfx/cairo/cairo/src/cairo-d2d-surface.cpp:4489
7 	xul.dll 	gfxD2DSurface::gfxD2DSurface 	gfx/thebes/gfxD2DSurface.cpp:46
8 	xul.dll 	gfxWindowsPlatform::CreateOffscreenSurface 	gfx/thebes/gfxWindowsPlatform.cpp:704
9 	xul.dll 	gfxPlatform::Init 	gfx/thebes/gfxPlatform.cpp:329
10 	xul.dll 	gfxPlatform::GetPlatform 	gfx/thebes/gfxPlatform.cpp:237
11 	xul.dll 	mozilla::dom::AzureCanvasEnabledOnPlatform 	content/canvas/src/nsCanvasRenderingContext2DAzure.cpp:558
12 	xul.dll 	mozilla::dom::AzureCanvasEnabled 	content/canvas/src/nsCanvasRenderingContext2DAzure.cpp:582
13 	xul.dll 	nsDOMClassInfo::Init 	dom/base/nsDOMClassInfo.cpp:4604
14 	xul.dll 	NS_GetDOMClassInfoInstance 	dom/base/nsDOMClassInfo.cpp:5183

More reports at:
https://crash-stats.mozilla.com/report/list?signature=RenderTargetStateHolder%3A%3Aoperator%3D%28CD3DSurface*%29
This isn't very high overall but our top crash on Win 8. We should probably have someone take a look. Maybe Joe can help find the right person.
Assignee: nobody → jpr
Assignee: jpr → bas
Hrm, it's clear that this is a serious problem, particularly since it's a startup crash. I can't reproduce it locally though and I'm not sure what's causing this, I don't think it's a regression, it would be good if QA could find a machine that reproduces the problem. The stack itself is virtually useless.
(In reply to Bas Schouten (:bas.schouten) from comment #2)
> Hrm, it's clear that this is a serious problem, particularly since it's a
> startup crash. I can't reproduce it locally though and I'm not sure what's
> causing this, I don't think it's a regression, it would be good if QA could
> find a machine that reproduces the problem. The stack itself is virtually
> useless.

We've done significant Win8 testing and QA hasn't run into this. They'll need direction to do a new round of testing. Do you have a recommendation on a configuration we should order (gpu/driver versions)?

Also including Matt/Tyler to see if we've got any related Win8 startup crash leads on SUMO.
I'm in the process of installing Win8 final on my desktop at the Vancouver office. I have an AMD HD6450 and NVidia 8800GT on hand. Please let me know how I can help test this.
QA Contact: anthony.s.hughes
Many of the comments say that this started happening after upgrading from Win7 to Win8. I've emailed a couple of people asking for more information.
Lukas filed bug 808900 to see if there are any specific driver/version correlations that we can ask QA to pursue.
selenamarie (on #breakpad) has some queries in place to get graphics vendor, driver, channel, date, # of reports for Win8(WindowsNT, 6.2.9200) for the period last week of October - 1st of november. This will take an hours of time. I'll take a look at the data and post findings here.
Bas - bug 808900 suggests that there may not be a correlation between device/driver and this crash. Is there anything that we can add to Firefox that'll send better info to crash-stats? Or is there any other QA direction that you can provide?
Alex, i think i mentioned that "It appears the presence of NVIDIA significant increases changes of RenderTargetStateHolder report." so NVIDIA vendor might be  a place to start ...
I've not seen any startup crashes with Windows 8 Pro 64-bit and an NVidia 8600GT using the latest drivers. I've been dogfooding Firefox Beta, Aurora, and Nightly for at least a week now in this environment. 

I believe Juan was looking into testing the Win7-Win8 upgrade path. Juan, any update in that regard?

It should be noted that anyone with an NVidia card on Windows 8 that is not using the latest driver is using software that isn't even supported by NVidia on Win8. Is there any way we can reach out to users and ask them to make sure they are updated?
(In reply to juan becerra [:juanb] from comment #5)
> Many of the comments say that this started happening after upgrading from
> Win7 to Win8. I've emailed a couple of people asking for more information.

Juan, have you had a chance to try the Win 7 -> Win 8 update investigation for this? Also, now that we have some correlations in bug 808900 perhaps you might have the ability to try doing that update with the most correlated drivers?
(In reply to Saptarshi Guha from comment #9)
> Alex, i think i mentioned that "It appears the presence of NVIDIA
> significant increases changes of RenderTargetStateHolder report." so NVIDIA
> vendor might be  a place to start ...

Thanks for pointing that out, I misread comment 9 to mean that there were no correlations, when in fact we should focus on NVIDIA. We'll want to test with NVIDIA driver v9.18.13.697 going from Win7->Win8 in that case.
At this point testing Win7->Win8 is the only sensible suggestion I have.
(In reply to Alex Keybl [:akeybl] from comment #12)
> We'll want to test with NVIDIA driver v9.18.13.697 going from Win7->Win8 in that case.

Do we have any idea what NVidia GeForce version this applies to? NVidia posts versions in VVV.vv format on their website. For example, GeForce 302.67.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #14)
> Do we have any idea what NVidia GeForce version this applies to? NVidia
> posts versions in VVV.vv format on their website. For example, GeForce
> 302.67.
The last 4 or 5 digits of the driver version give the NVIDIA version. In that case, it's 306.97 (you need to add a zero).
Thanks Scoobidiver.

Juan, will you be able to attempt this today? If not, I'll have to see if I can buy an upgrade edition of Windows 8.
Anthony, you should go ahead and try as well. I have been trying in between other testing stuff today, but it is still in progress.
Okay, thanks Juan. I'll go ahead and file a ticket to get an upgrade license for Win8.
We're too close to the 17 final beta now to be able to do much on this, if it turns out to be an upgrading-specific issue from Win 7 -> Win 8 then we can continue the work for 18.
I have been able to test the upgrade scenario from Win7 to Win8 on a machine with an nVidia GeForce GT 520 with the latest drivers (9.18.13.697). I've tested using Aurora in multiple scenarios, with admin and non-admin accounts, with updates pending, with WebGL enabled for Google Maps, upgrading Aurora, toggling default browser between IE metro and Aurora, and no luck crashing.

Some of the latest comments mention crashes on new Win8 systems right after installing Firefox. So the OS upgrade scenario may not matter.

I don't know what else to try.
Can we take a look at the WinQual data and see if there's something of use?
I've tried to reproduce this on Windows 7 64-bit and Windows 8 64-bit but with no luck so far. I hit a couple of crashes (mostly Flash crashes) and  even a start up crash but with a different signature (Bug 675260 Comment 41).

I've tested using Firefox 17 beta 6 and Firefox 16.0.2 (due to the high number of crashed on this version) on multiple scenarios with new profiles (even clean Firefox installs) or dirty ones (opened several tabs with plug-ins content -flash, java, WebGL - switched groups and windows, restarted Firefox after add-on/plug-ins installs, changed preferences and started Firefox in all the ways that I could think  of.
I've tried to reproduce this crash for Windows 7 x86. I have installed the latest AMD Beta driver for my GPU. For Firefox 16.0.2 and 17.0 Beta 3 I loaded the profile with lots of bookmarks, history, pinned tabs and 4k videos on youtube and put them in panorama groups. I restarted for several times the Firefox, and the OS trying to catch the crash on first use. I installed an graphic card benchmark software to load the GPU at full usage and meanwhile close and restart Firefox, but no crashes it was just working jerky.

On Windows 8 x86 I installed the Firefox 16.0.2, downloaded as normal user. I performed the same actions as for Windows 7. Then my Windows 8 Pro asked me for an update. I installed the update, restarted the system and started Firefox 16.0.2, witch acted very weird because after a double click on the shortcut, from my desktop, it minimized an icon on taskbar, but on hover there was no tab opened and on click on the icon on taskbar, it took no action. I continued with several double clicks on the FF 16.0.2 shortcut on my desktop, and it opened some little windows in the corners but I could not use them as normal, I could just close them clicking on X button. Unfortunately I could not reproduce this because I needed another upgrade of my system. See attachment for the behavioral on Windows 8 x86.
(In reply to Virgil Dicu [:virgil] [QA] from comment #24)
> Created attachment 682005 [details]
> First use of 16.0.2 after an update of Windows 8 Pro

I suggest filing that in a new bug.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #25)
> (In reply to Virgil Dicu [:virgil] [QA] from comment #24)
> > Created attachment 682005 [details]
> > First use of 16.0.2 after an update of Windows 8 Pro
> 
> I suggest filing that in a new bug.

This is now bug 812519.
Given the fact that we've exhausted our QA leads and engineering has no further plans for investigation, tracking for future releases will do little to resolve this issue.
In Win8 topcrash reports, this continues to be the highest-ranked Win8-specific issue in Firefox 18.0.1.
For firefox 34.0.5 This signature barely exists anymore.
WFM?
Flags: needinfo?(kairo)
I guess so. Just mark stuff like this that way, no need to take my time on that, really.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(kairo)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.