Closed Bug 622886 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

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

People

(Reporter: scoobidiver, Assigned: roc)

References

Details

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

Crash Data

Attachments

(2 files)

wallpaper
2.75 KB, patch
bas.schouten
: review+
Details | Diff | Splinter Review
part 2
2.00 KB, patch
bas.schouten
: review+
jrmuizel
: review+
Details | Diff | Splinter Review
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 wallpaper — — Splinter 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 2 — — Splinter 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: 15 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.

Attachment

General

Creator:
Created:
Updated:
Size: