This bug was filed from the Socorro interface and is report bp-b4efe734-a3e6-4847-96e6-da6152160310. ============================================================= These are one of the top crashes on nightly, and started being common in the 20160302030209 nightly build, though there were occasional crashes before then. See query: https://crash-stats.mozilla.com/signature/?product=Firefox&release_channel=nightly&platform=Windows&date=%3E%3D2016-02-15&signature=mozilla%3A%3Alayers%3A%3ASyncObjectD3D11%3A%3AFinalizeFrame&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&page=1#aggregations

Hrm, interesting, in these crash reports a device reset is certainly occurring, but we seem to 'forget' it has occurred and incorrectly conclude we shouldn't act as if we're in a device reset situation, I suspect this is a regression from some of the recent device reset behavior changes.

The regression range between that nightly and the previous is: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8ef94be995a4&tochange=eb25b90a05c1 which does include bug 1245765.

(In reply to Bas Schouten (:bas.schouten) from comment #1) > Hrm, interesting, in these crash reports a device reset is certainly > occurring, but we seem to 'forget' it has occurred and incorrectly conclude > we shouldn't act as if we're in a device reset situation, I suspect this is > a regression from some of the recent device reset behavior changes. This crash is under e10s, where the previous behavior for a device reset was not handling it all and rendering as a black rectangle. We're now taking the device away, and it looks like this trips a bunch of (prerelease?) asserts in TextureD3D11.cpp. A few things could cause this, but what seems most likely is re-using a stale SyncObject in the shadow forwarder. I don't see that we ever update it - whoops.

(In reply to David Anderson [:dvander] from comment #3) > (In reply to Bas Schouten (:bas.schouten) from comment #1) > > Hrm, interesting, in these crash reports a device reset is certainly > > occurring, but we seem to 'forget' it has occurred and incorrectly conclude > > we shouldn't act as if we're in a device reset situation, I suspect this is > > a regression from some of the recent device reset behavior changes. > > This crash is under e10s, where the previous behavior for a device reset was > not handling it all and rendering as a black rectangle. We're now taking the > device away, and it looks like this trips a bunch of (prerelease?) asserts > in TextureD3D11.cpp. > > A few things could cause this, but what seems most likely is re-using a > stale SyncObject in the shadow forwarder. I don't see that we ever update it > - whoops. Yep. This is definitely the cause.

Tracked for 47 and 48 since it's a top crasher.

Would this also explain the increase in crashes in mozilla::layers::BasicCompositor::DrawQuad regressing on the same date: https://crash-stats.mozilla.com/signature/?product=Firefox&release_channel=nightly&platform=Windows&date=%3E%3D2016-01-01&signature=mozilla%3A%3Alayers%3A%3AAsyncPanZoomController%3A%3AOnLongPress&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&page=1#aggregations or should that be a separate bug?

(In reply to David Baron [:dbaron] ⌚️UTC-7 from comment #8) > Would this also explain the increase in crashes in > mozilla::layers::BasicCompositor::DrawQuad regressing on the same date: > https://crash-stats.mozilla.com/signature/ > ?product=Firefox&release_channel=nightly&platform=Windows&date=%3E%3D2016-01- > 01&signature=mozilla%3A%3Alayers%3A%3AAsyncPanZoomController%3A%3AOnLongPress > &_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=p > latform&_columns=reason&_columns=address&page=1#aggregations > or should that be a separate bug? Is that link right? It looks like APZ crashes. I did a search for BasicCompositor::DrawQuad though, and from what I can tell, those crashes are also related to device resets but should be a separate bug. I don't think this bug will fix those crashes.

OK, filed bug 1256517 with a correct link.

Comment on attachment 8730098 [details] [diff] [review] bug1255711.patch Approval Request Comment [Feature/regressing bug #]: bug 1245765 [User impact if declined]: Potential crashes when video card resets [Describe test coverage new/current, TreeHerder]: Nightly; verified no crashes since landing [Risks and why]: No risk [String/UUID change made/needed]:

Hi David, when I look at the crash-stats for the attached signature, I can still see reports on 48.0a1 with build ID 20160320030409, 20160319030558, 20160322030417. Am I reading the data wrong? Please let me know. https://crash-stats.mozilla.com/report/index/d40baebf-62fa-4f32-8d8c-e43b82160321 https://crash-stats.mozilla.com/report/index/6b55214b-890c-4969-b717-e46712160319 https://crash-stats.mozilla.com/report/index/fcff1936-d913-4f46-95e2-8c1f52160322

(In reply to Ritu Kothari (:ritu) from comment #13) > Hi David, when I look at the crash-stats for the attached signature, I can > still see reports on 48.0a1 with build ID 20160320030409, 20160319030558, > 20160322030417. Am I reading the data wrong? Please let me know. > > https://crash-stats.mozilla.com/report/index/d40baebf-62fa-4f32-8d8c- > e43b82160321 > https://crash-stats.mozilla.com/report/index/6b55214b-890c-4969-b717- > e46712160319 > https://crash-stats.mozilla.com/report/index/fcff1936-d913-4f46-95e2- > 8c1f52160322 We didn't expect to eliminate this crash; you should see it occurring at the same rate it did before 2016-03-02. If that's the case, we'd want a new bug for these occurrences.

(In reply to David Anderson [:dvander] from comment #14) > (In reply to Ritu Kothari (:ritu) from comment #13) > > Hi David, when I look at the crash-stats for the attached signature, I can > > still see reports on 48.0a1 with build ID 20160320030409, 20160319030558, > > 20160322030417. Am I reading the data wrong? Please let me know. > > > > https://crash-stats.mozilla.com/report/index/d40baebf-62fa-4f32-8d8c- > > e43b82160321 > > https://crash-stats.mozilla.com/report/index/6b55214b-890c-4969-b717- > > e46712160319 > > https://crash-stats.mozilla.com/report/index/fcff1936-d913-4f46-95e2- > > 8c1f52160322 > > We didn't expect to eliminate this crash; you should see it occurring at the > same rate it did before 2016-03-02. If that's the case, we'd want a new bug > for these occurrences. Ok. I think comment 12 threw me off as you wrote "Verified no crashes since landing".

Comment on attachment 8730098 [details] [diff] [review] bug1255711.patch Even though this crash signature is not completely gone even after landing in Nightly, David feels we should uplift. Aurora47+