Closed Bug 622886 Opened 9 years ago Closed 9 years ago

spike in crashes [@ gfxContext::gfxContext(gfxASurface*) ]

Categories

(Core :: Graphics, defect, critical)

x86
Windows 7
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla2.0b9
Tracking Status
blocking2.0 --- beta9+

People

(Reporter: scoobidiver, Assigned: roc)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: [hardblocker])

Crash Data

Attachments

(2 files)

It is a residual crash signature that exists in 3.6 and trunk builds.
There is a spike in crashes from 4.0b9pre/20110103.
It is #1 top crasher in this build.

Signature	gfxContext::gfxContext(gfxASurface*)
UUID	0b92041d-45e1-4048-ae54-332162110104
Time 	2011-01-04 09:46:20.322134
Uptime	566
Last Crash	573 seconds (9.6 minutes) before submission
Install Age	649 seconds (10.8 minutes) since version was first installed.
Product	Firefox
Version	4.0b9pre
Build ID	20110103030359
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 14 stepping 12
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x4
User Comments	
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 01d7

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	gfxContext::gfxContext 	gfx/thebes/gfxContext.cpp:64
1 	xul.dll 	mozilla::layers::ThebesLayerD3D9::DrawRegion 	gfx/layers/d3d9/ThebesLayerD3D9.cpp:498
2 	xul.dll 	mozilla::layers::ThebesLayerD3D9::RenderLayer 	gfx/layers/d3d9/ThebesLayerD3D9.cpp:224
3 	xul.dll 	mozilla::layers::ContainerLayerD3D9::RenderLayer 	gfx/layers/d3d9/ContainerLayerD3D9.cpp:317
4 	xul.dll 	mozilla::layers::ContainerLayerD3D9::RenderLayer 	gfx/layers/d3d9/ContainerLayerD3D9.cpp:317
5 	xul.dll 	mozilla::layers::LayerManagerD3D9::Render 	gfx/layers/d3d9/LayerManagerD3D9.cpp:300
6 	xul.dll 	mozilla::layers::LayerManagerD3D9::EndTransaction 	gfx/layers/d3d9/LayerManagerD3D9.cpp:157
7 	xul.dll 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:480
8 	xul.dll 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1463
9 	xul.dll 	PresShell::Paint 	layout/base/nsPresShell.cpp:6108

The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a05e91710adb&tochange=c20f34eefa5d

More reports at:
http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=gfxContext%3A%3AgfxContext%28gfxASurface*%29
blocking2.0: --- → ?
Attached patch wallpaperSplinter Review
I'm mildly disturbed that destinationSurface can be null, but I guess the Windows API calls in OpaqueRenderer::Begin could be failing for mysterious reasons. This should prevent a crash.
Attachment #501114 - Flags: review?(bas.schouten)
Blocks: 593604
This is the #1 crash on the trunk right now - regression of some kind caused this spike. Shouldn't this be a candidate for beta9?
The number of crashes increased to over 500 yesterday. It's probably worth trying to investigate what triggered this even if we don't block beta9. It could potentially explode up.
Marking beta9 for now.
blocking2.0: ? → beta9+
One (not always reliable) way to reproduce this bug is to open many new tabs in a SeaMonkey(!) trunk build with about:blank to display in a new tab. I just hold Ctrl+T for one or two seconds and then release that shortcut, a second later it crashes.
Whiteboard: [hardblocker]
Assignee: nobody → roc
Assignee: roc → bas.schouten
Comment on attachment 501114 [details] [diff] [review]
wallpaper

I'm concerned that due to the increased memory usage if we've got several large component alpha layers actively working we're running into OO VRAM situations.
Attachment #501114 - Flags: review?(bas.schouten) → review+
On my laptop, I can reproduce this bug when I surf to http://www.guilhermebarbosa.com/AUSTRALIA/Aussie-Pelican/13943281_NHcWB and just hover above the big picture. Normally some menu appears within the picture, but I get an instant crash.
checking needed?
Is there something we have ready to checkin for this? It's still our top crasher and it's rising. I really don't think we want to ship beta9 without trying to get rid of this. What's the status?
Keywords: checkin-needed
Pushed "wallpaper" patch: http://hg.mozilla.org/mozilla-central/rev/906f834203ff

Not sure if the intention was to investigate this further and come up with a non-wallpaper patch, so I'm leaving this open.

Bas/roc: please close if we're done here.
Keywords: checkin-needed
Target Milestone: --- → mozilla2.0b9
Crashes are still happening in 4.0b9pre/20110108 so it is not fully fixed.
(In reply to comment #14)
> Crashes are still happening in 4.0b9pre/20110108 so it is not fully fixed.

I can confirm: My crash ID's

bp-308ad776-fe40-46b4-8a11-e21a92110108
bp-b68fa935-0524-4fbe-99f1-74aff2110108
Depends on: 624170
Keywords: topcrash
Attached patch part 2Splinter Review
Assignee: bas.schouten → roc
Attachment #502327 - Flags: review?(bas.schouten)
(In reply to comment #7)
> I'm concerned that due to the increased memory usage if we've got several large
> component alpha layers actively working we're running into OO VRAM situations.

I doubt it. We might be running out of VRAM, and component alpha might make it worse, but we'd definitely see a lot of OOVRAM crashes without component alpha as well if that was the case.
Whiteboard: [hardblocker] → [hardblocker][needs review]
Comment on attachment 502327 [details] [diff] [review]
part 2

This looks fine to me.
Attachment #502327 - Flags: review+
Attachment #502327 - Flags: review?(bas.schouten) → review+
Let's try to shoehorn this simple null check into beta9
Whiteboard: [hardblocker][needs review] → [hardblocker]
Should be fixed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Do we understand what was the root cause of these crashes?
No. It looks like D3D surface creation failed, but we don't know why.
(In reply to comment #23)
> No. It looks like D3D surface creation failed, but we don't know why.

Ok. I've filed a follow up (bug 624801) to figure out why.
(In reply to comment #21)
> Should be fixed.

yup. last build with crashes is 2011011000
Status: RESOLVED → VERIFIED
Crash Signature: [@ gfxContext::gfxContext(gfxASurface*) ]
You need to log in before you can comment on or make changes to this bug.