This bug was filed from the Socorro interface and is report bp-12689298-f92f-4cad-a528-6baf62150731. ============================================================= Encountered while testing 40.0b9 (Build ID: 20150730171029), under Windows 8 32-bit - loaded some WebGL content (animations, games) [1], a YouTube playlist and Google Maps. Before the crash occurred, various black artifacts were displayed. Please note that it was a *1 time occurrence* crash. More reports: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=gfxContext%3A%3AgfxContext%28mozilla%3A%3Agfx%3A%3ADrawTarget%2A%2C+mozilla%3A%3Agfx%3A%3APointTyped%3CT%3E+const%26%29 [1] http://www.3dsitelinks.com/webgl-games/; http://dl.dropboxusercontent.com/u/6983010/wserv/gexp_pulpo/index.html; http://madebyevan.com/webgl-water/; http://webglsamples.googlecode.com/hg/aquarium/aquarium.html; http://goo.gl/zz1rox

gfxContext, so let's ask jrmuizel.

At least some of these have D2DERR_RECREATE_TARGET (0x8899000C) error in the log.

I just got a similar crash in Nightly today using Workday. Any attempt to open workday for me in nightly (OS X) crashes immediately: https://crash-stats.mozilla.com/report/index/d5132cb7-1346-4030-b109-20f8c2151113

Any chance for a regression range?

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc473fe5dc512c450634506f68cbacfb40a06a23&tochange=3cc3b1968524248450c465c4ea2ee5596ffa65f2 https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1e5f3d1151d60a1edd6424a35a2e38b5ab17adad&tochange=af5c9cf6898b0e2931a809774387cad5953363c3 Bug 1210560.

[GFX2-]: Failed to Init() DrawTargetCG because of bad size. Assertion failure: aTarget (Don't create a gfxContext without a DrawTarget), at /Users/msreckovic/Repos/mozilla-central/gfx/thebes/gfxContext.cpp:78 #01: gfxContext::gfxContext(mozilla::gfx::DrawTarget*, mozilla::gfx::PointTyped<mozilla::gfx::UnknownUnits, float> const&)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1a283c4] #02: gfxContext::gfxContext(mozilla::gfx::DrawTarget*, mozilla::gfx::PointTyped<mozilla::gfx::UnknownUnits, float> const&)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1a241b5] #03: nsSVGClipPathFrame::GetClipMask(gfxContext&, nsIFrame*, gfxMatrix const&, mozilla::gfx::Matrix*, mozilla::gfx::SourceSurface*, mozilla::gfx::Matrix const&)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x49c176b] #04: nsSVGIntegrationUtils::PaintFramesWithEffects(gfxContext&, nsIFrame*, nsRect const&, nsDisplayListBuilder*, mozilla::layers::LayerManager*)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x49dfd13] #05: nsDisplaySVGEffects::PaintAsLayer(nsDisplayListBuilder*, nsRenderingContext*, mozilla::layers::LayerManager*)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x46e6503] #06: mozilla::PaintInactiveLayer(nsDisplayListBuilder*, mozilla::layers::LayerManager*, nsDisplayItem*, gfxContext*, nsRenderingContext*)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4630ef9] #07: mozilla::FrameLayerBuilder::PaintItems(nsTArray<mozilla::FrameLayerBuilder::ClippedDisplayItem>&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, gfxContext*, nsRenderingContext*, nsDisplayListBuilder*, nsPresContext*, mozilla::gfx::IntPoin[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4630b36] #08: mozilla::FrameLayerBuilder::DrawPaintedLayer(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mo[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4631d17]

roc claims my issue is probably different, so I will open a new bug. However for the regression range, I definitely upgrade to new nightlies every day and I was last using Workday successfully on Tuesday and/or Wednesday. So it's very recent.

(In reply to Milan Sreckovic [:milan] from comment #5) > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=cc473fe5dc512c450634506f68cbacfb40a06a23&tochange=3cc3 > b1968524248450c465c4ea2ee5596ffa65f2 > > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=1e5f3d1151d60a1edd6424a35a2e38b5ab17adad&tochange=af5c > 9cf6898b0e2931a809774387cad5953363c3 > > Bug 1210560. Wait, this bug is -waaay- older than the landing of 1210560, I believe what you're seeing there is actually bug 1224798. I've assigned that to myself, let's keep this one around for the original bug it was filed for.

(In reply to Milan Sreckovic [:milan] from comment #6) > [GFX2-]: Failed to Init() DrawTargetCG because of bad size. > Assertion failure: aTarget (Don't create a gfxContext without a DrawTarget), > at /Users/msreckovic/Repos/mozilla-central/gfx/thebes/gfxContext.cpp:78 > > > > #01: gfxContext::gfxContext(mozilla::gfx::DrawTarget*, > mozilla::gfx::PointTyped<mozilla::gfx::UnknownUnits, float> > const&)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0. > 0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1a283c4] > #02: gfxContext::gfxContext(mozilla::gfx::DrawTarget*, > mozilla::gfx::PointTyped<mozilla::gfx::UnknownUnits, float> > const&)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0. > 0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1a241b5] > #03: nsSVGClipPathFrame::GetClipMask(gfxContext&, nsIFrame*, gfxMatrix > const&, mozilla::gfx::Matrix*, mozilla::gfx::SourceSurface*, > mozilla::gfx::Matrix > const&)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0. > 0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x49c176b] > #04: nsSVGIntegrationUtils::PaintFramesWithEffects(gfxContext&, nsIFrame*, > nsRect const&, nsDisplayListBuilder*, > mozilla::layers::LayerManager*)[/Users/msreckovic/Repos/mozilla-central/obj- > x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL > +0x49dfd13] > #05: nsDisplaySVGEffects::PaintAsLayer(nsDisplayListBuilder*, > nsRenderingContext*, > mozilla::layers::LayerManager*)[/Users/msreckovic/Repos/mozilla-central/obj- > x86_64-apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL > +0x46e6503] > #06: mozilla::PaintInactiveLayer(nsDisplayListBuilder*, > mozilla::layers::LayerManager*, nsDisplayItem*, gfxContext*, > nsRenderingContext*)[/Users/msreckovic/Repos/mozilla-central/obj-x86_64- > apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4630ef9] > #07: > mozilla::FrameLayerBuilder::PaintItems(nsTArray<mozilla::FrameLayerBuilder:: > ClippedDisplayItem>&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> > const&, gfxContext*, nsRenderingContext*, nsDisplayListBuilder*, > nsPresContext*, > mozilla::gfx::IntPoin[/Users/msreckovic/Repos/mozilla-central/obj-x86_64- > apple-darwin15.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4630b36] > #08: > mozilla::FrameLayerBuilder::DrawPaintedLayer(mozilla::layers::PaintedLayer*, > gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> > const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, > mozilla::layers::DrawRegionClip, > mo[/Users/msreckovic/Repos/mozilla-central/obj-x86_64-apple-darwin15.0.0/ > dist/NightlyDebug.app/Contents/MacOS/XUL +0x4631d17] Anything specific you're doing in workday that makes this happen? I don't seem to be getting any odd sizes there. Also, could you tell me what the size is that it's attempting to create the DrawTarget for? I -suspect- it's 0x0 but I'd like to know for sure.

Continued the conversation in bug 1224798 comment 1 (but, yes, the size is 0x0)

Nightly constantly crashes when I try to open workday.

Yes, we're covering the fix in bug 1224798.

Seems there are a few places where we don't check if we're passing an invalid draw target to gfxContext, so we crash. Here is one more from pres shell: https://crash-stats.mozilla.com/report/index/d04cee66-3319-4a61-b917-178cc2160310

[Tracking Requested - why for this release]: the crash signature is significantly rising in 46 beta builds, currently it's the #9 crash signature in 46.0b2 with 1.3% off all crashes

This is a topcrash in 46 beta 4 (in early results from today) I see this is noted already by the graphics team but I want to keep an eye on this for 46. Tracking. Milan can you find someone to investigate a bit more?

Review commit: https://reviewboard.mozilla.org/r/42233/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/42233/

Working on it.

We're going to need more information, Lee will land a patch in nightly to get that for us. The big patch above is something we'll eventually do, the small one, probably not, as the trouble happens much earlier than the crash signature would suggest - in ::UpdateRenderMode when we fail to create screen reference draw target.

This matches the abort we are already doing in normal gfxPlatform creation here: https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPlatform.cpp#699 Our code uses the implicit contract that gfxPlatform::ScreenReferenceDrawTarget() should never be null, so if it ever does actually happen to be null, which could only really occur here after a device reset, many other places in our code end up crashing on null pointer deferences. This will restore the implicit contract and also give us more information about what the status of D2D/D3D/backends is to let us diagnose the actual cause. Without this, the crashing happens too far downstream due to above-mentioned null pointer dereferences to show the reason the actual reference DT creation failed. This crash should not introduce more crashes into the Firefox (since we already crash downstream), but rather it will give us a specific known point of failure and log the information until we can actually fix the cause.

Comment on attachment 8734469 [details] [diff] [review] verify that reference draw target is created after device reset and log failure in gfxWindowsPlatform::UpdateRenderMode Review of attachment 8734469 [details] [diff] [review]: ----------------------------------------------------------------- Good stuff. Let's watch what crashes come in.

(In reply to Lee Salzman [:lsalzman] from comment #20) > Created attachment 8734469 [details] [diff] [review] > verify that reference draw target is created after device reset and log > failure in gfxWindowsPlatform::UpdateRenderMode > ... Note, this is not a fix, we are trying to get more information at the time the bad things happen. Which should help us with a fix. We should be able to get a crash or two on nightly to help with this, but if that fails, we may ask for the uplift to Aurora. Note that the total number of crashes shouldn't change, it would just happen in a different place.

This will search for the crashes with this info: https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=~Failed+to+update+reference+draw+target+after+device+reset&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Comment on attachment 8734428 [details] MozReview Request: Bug 1189715: Wallpaper over the crash by making sure the draw target is valid. r?lsalzman https://reviewboard.mozilla.org/r/42233/#review39225 We have decided for now to take another approach to this problem, and that it didn't make sense to address the issue here in this way.

Got a crash with the extra info: https://crash-stats.mozilla.com/report/index/b0dc7b45-072e-4770-954e-049522160328 Here's the info we were looking for: Failed to update reference draw target after device reset, D3D11 device:2BCE754C, D3D11 status:available, D2D1 device:00000000, D2D1 status:available, content:7, compositor:4 (t=2527.09)

(In reply to Milan Sreckovic [:milan] from comment #25) > Got a crash with the extra info: > https://crash-stats.mozilla.com/report/index/b0dc7b45-072e-4770-954e- > 049522160328 > Here's the info we were looking for: > Failed to update reference draw target after device reset, > D3D11 device:2BCE754C, > D3D11 status:available, > D2D1 device:00000000, > D2D1 status:available, > content:7, > compositor:4 > (t=2527.09) So at least this particular mousetrap has caught what we expected, that the D2D1 device creation failed, but it tried to continue on with D2D1 anyway. The patch that's in inbound for bug 1259810 should address this, and depending if it seems safe and addresses the primary cause will probably want to uplift that one. But we should see if we still get any other crashes pointing back to the gfxContext constructor just to make sure it's not something else as well.

I'm guessing comment 27 and comment 28 are for another bug.

Yeah, looks like those were for bug 1229946.

hi, although the presumptive fix from bug 1259810 has made it into 46.0b8, some very very early crash reports from this version show that the signature is still occurring there: https://crash-stats.mozilla.com/report/index/2aa91d5e-0e9f-4511-9150-4ec9c2160405 https://crash-stats.mozilla.com/report/index/2aa91d5e-0e9f-4511-9150-4ec9c2160405

(In reply to philipp from comment #31) > hi, although the presumptive fix from bug 1259810 has made it into 46.0b8, > some very very early crash reports from this version show that the signature > is still occurring there: > https://crash-stats.mozilla.com/report/index/2aa91d5e-0e9f-4511-9150- > 4ec9c2160405 > https://crash-stats.mozilla.com/report/index/2aa91d5e-0e9f-4511-9150- > 4ec9c2160405 That looks like a build from before the patch was incorporated.

Same signature in the previous comment for both crashes, but there are others I've seen. Just want to confirm - the stamp on the build is 46.0b8 stamped 20160404120533, and the beta uplift https://hg.mozilla.org/releases/mozilla-beta/rev/6b34b6fb1b62 with "push date 2016-04-04 18:31 +0000". Wes, could you confirm for us that the 46.0b8 does contain the patch mentioned in bug 1259810 comment 13?

My understanding is that everything that has landed on the beta branch at this point is in the beta 8 build.

Yes, https://hg.mozilla.org/releases/mozilla-beta/graph/820fbb29dcf6 confirms that 6b34b6fb1b62 is part of 0334bcac4033, which is tagged FIREFOX_46_0b8_RELEASE now.

This was only going to fix the crashes that have PresShell::CreateReferenceRenderingContext as the next item in the stack, so here are a few more of those in addition to the one in comment 31: https://crash-stats.mozilla.com/report/index/d7d5cd0b-83b4-4331-bb63-da99c2160405 https://crash-stats.mozilla.com/report/index/dcc02779-1e74-46ff-b2a1-e82f42160405 https://crash-stats.mozilla.com/report/index/b33f454d-013d-4589-aa6d-cf59d2160405 Nothing on nightly yet, so it's possible there are uplifts missing.

None of these are hitting https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp#542, so this does look like a different cause, even for the same signatures.

(In reply to Milan Sreckovic [:milan] from comment #37) > None of these are hitting > https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform. > cpp#542, so this does look like a different cause, even for the same > signatures. Never mind, we never uplifted the change with extra information.

Lee, let's get a beta patch for the gfxCriticalNote we added, but without the MOZ_CRASH. Just want to confirm.

(In reply to Milan Sreckovic [:milan] from comment #39) > Lee, let's get a beta patch for the gfxCriticalNote we added, but without > the MOZ_CRASH. Just want to confirm. The patch should work against beta as-is.

I was somewhat nervous about adding a MOZ_CRASH in there and was thinking just with the critical note. But, I'll ask for the uplift as is.

Comment on attachment 8734469 [details] [diff] [review] verify that reference draw target is created after device reset and log failure in gfxWindowsPlatform::UpdateRenderMode Approval Request Comment We have crashes still getting through, we need to verify if it's still the original problem we went after with the bug 1259810, or something similar, but not quite the same. This additional information will help with that. Note that it will introduce a MOZ_CRASH that will replace the crash in this signature, but otherwise it's the same cause.

(In reply to Milan Sreckovic [:milan] from comment #42) > Note that it will introduce a MOZ_CRASH that will replace the crash in this > signature, but otherwise it's the same cause. So those crashes will move to gfxWindowsPlatform::UpdateRenderMode() - do I understand this right? (Just so I know how to associate those)

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #43) > (In reply to Milan Sreckovic [:milan] from comment #42) > > Note that it will introduce a MOZ_CRASH that will replace the crash in this > > signature, but otherwise it's the same cause. > > So those crashes will move to gfxWindowsPlatform::UpdateRenderMode() - do I > understand this right? (Just so I know how to associate those) Yes.

Comment on attachment 8734469 [details] [diff] [review] verify that reference draw target is created after device reset and log failure in gfxWindowsPlatform::UpdateRenderMode Diagnostic help for a topcrash. This should land with beta 9, this Friday. #moz_crash #yolo

https://hg.mozilla.org/releases/mozilla-aurora/rev/6adef622c36b https://hg.mozilla.org/releases/mozilla-beta/rev/b007110e9005

Sorry, forgot the "leave-open" part.

Here are a couple of crashes in Beta 9 with the extra information: https://crash-stats.mozilla.com/report/index/2f4811f7-dd88-4aa0-8cb8-df7eb2160409 https://crash-stats.mozilla.com/report/index/b29fb45b-0fd9-4755-a657-ceec42160409 Both D3D11 and D2D1 devices are null, and the status is "available".

FYI, as expected, https://crash-stats.mozilla.com/report/list?signature=gfxWindowsPlatform%3A%3AUpdateRenderMode is rising now in beta crash data while gfxContext::gfxContext is going down.

Review commit: https://reviewboard.mozilla.org/r/45809/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/45809/

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #49) > FYI, as expected, > https://crash-stats.mozilla.com/report/ > list?signature=gfxWindowsPlatform%3A%3AUpdateRenderMode is rising now in > beta crash data while gfxContext::gfxContext is going down. This is good news - it suggests that the problem is starting in the new crash location; that was what we were "hoping" for, but wasn't necessarily provable.

Comment on attachment 8740496 [details] MozReview Request: Bug 1189715: Make sure we don't try to use D2D 1.1 when D2D 1.0 init has failed. r=dvander https://reviewboard.mozilla.org/r/45809/#review42389

Lee and I like the patch as well :)

Comment on attachment 8740496 [details] MozReview Request: Bug 1189715: Make sure we don't try to use D2D 1.1 when D2D 1.0 init has failed. r=dvander Review request updated; see interdiff: https://reviewboard.mozilla.org/r/45809/diff/1-2/

Approval Request Comment [Feature/regressing bug #]: Been around for a while [User impact if declined]: Top crasher [Describe test coverage new/current, TreeHerder]: None [Risks and why]: Very low, just updates some flags [String/UUID change made/needed]: None

Some colour here - the reasons we weren't seeing some of these crashes in 47 is because we don't have D2D 1.0 code in 47 (just D2D 1.1), so we removed the bug, rather than fixed it, so to speak.

Even safer.

Comment on attachment 8740519 [details] [diff] [review] Make sure we don't try to use D2D 1.1 when D2D 1.0 init has failed. v2 Review of attachment 8740519 [details] [diff] [review]: ----------------------------------------------------------------- r=me

Are we just landing the beta patch, or do we also want the (original) central/aurora patch?

(In reply to Milan Sreckovic [:milan] from comment #59) > Are we just landing the beta patch, or do we also want the (original) > central/aurora patch? The original one we can land, if we want, it doesn't really have immediate value except making things a little clearer.

Comment on attachment 8740519 [details] [diff] [review] Make sure we don't try to use D2D 1.1 when D2D 1.0 init has failed. v2 Fix for topcrash, I like the words "even safer". Let's try this for beta 11.

failed to apply to beta: applying 2d6e76f25aeb patching file gfx/thebes/gfxWindowsPlatform.cpp Hunk #1 FAILED at 2628 1 out of 1 hunks FAILED -- saving rejects to file gfx/thebes/gfxWindowsPlatform.cpp.rej patch failed to apply abort: fix up the working directory and run hg transplant --continue can you take a look, thanks!

This is just be being sloppy and forgetting to post the link, I'd already landed it: https://hg.mozilla.org/releases/mozilla-beta/rev/6cd21936571d

I also don't think 47 is affected, adjusting accordingly.

seems fixed according to crash stats for 46.0b11.

I would expect these to reduce 48, after bug 1259513 and go away in 50 after the follow up bug 1276128.