1171094 - Startup crash with old DisplayLink drivers in @0x0 | CContext::ID3D11DeviceContext1_SetSamplers_<int, 5>(ID3D11DeviceContext1*, unsigned int, unsigned int, ID3D11SamplerState* const*)

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[(Away)]

+++ This bug was initially created as a clone of Bug #1026893 +++

(In reply to Tyler Downer [:Tyler] from bug 1026893 comment #33)
> [Tracking Requested - why for this release]:
> 
> Have a user reporting that this has resurfaced in 38 Beta
> 
> https://crash-stats.mozilla.com/report/index/0c9cf2f3-98f0-4b68-83fb-
> 73a7e2150429
> 
> https://support.mozilla.org/en-US/questions/1059732

(In reply to philipp from bug 1026893 comment #39)
> next to the sumo question in tyler's comment 33, we also got feedback on irc
> by an affected user that updating the displaylink drivers on the system did
> solve this crash. 
> (reportedly safemode/disabling hwa didn't help, neither did an update to
> firefox 39 beta)

Comment 1

[[:philipp]]

in case it's of help - the crash report by the second referenced user was https://crash-stats.mozilla.com/report/index/757b001b-98a0-4418-9eec-a48922150603

Comment 2

[(Away)]

[Tracking Requested - why for this release]: Based on the flag from the clone's parent bug

Comment 3

[(Away)]

Bug 1026893 added a try/except bandaid to the d3d11CreateDevice call in gfxWindowsPlatform::GetD3D11Device. 

According to the crash reports in comment 0 and comment 1, we can also get a d3d11CreateDevice call from libGLES. Should we add the same bandaid?

Note that this only happens with old DisplayLink drivers, so alternatively maybe we could block something based on that.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

Sounds like this would be good to add to the blocklist if we can figure out the specific drivers causing it. 

Is this crash still happening in 39 at a high volume?

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

I just double checked and the second signature listed has around 250 crashes for 39.0b1.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1026893#c39, some of these crashes were happening in the safemode as well - are those gone, or is there one of those we can tag here?

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

So, we had the bug 1149864 that made sure we don't create any devices while in the safemode, but haven't done it for WebGL as a few have pointed out.  Should be a quick enough fix.

Comment 8

[(Away)]

That sounds like something we should definitely have as a backup, but can we do anything for the non-safemode crashes? I'm wondering if it's as simple as adding another __try/__except.

Comment 9

[[:philipp]]

(In reply to Milan Sreckovic [:milan] from comment #6)
> According to https://bugzilla.mozilla.org/show_bug.cgi?id=1026893#c39, some
> of these crashes were happening in the safemode as well - are those gone, or
> is there one of those we can tag here?

no, i only got that as feedback in writing from the user without an associated id: https://scrollback.io/sumo/all/all-messages?t=1433335959158

searching for the characteristics of that one machine in crash-stats leaves me to believe that the signature of this crash changed to https://crash-stats.mozilla.com/report/list?product=Firefox&signature=%400x0+|+dlumd64.dll%400x23758 once the user tried to run firefox 39 beta though...

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Attachment: Quick and dirty patch

This is a patch for all the trees. I plan on doing a more thorough rearrange of things to make more sane tomorrow.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to David Major [:dmajor] from comment #8)
> That sounds like something we should definitely have as a backup, but can we
> do anything for the non-safemode crashes? I'm wondering if it's as simple as
> adding another __try/__except.

Yes, Jeff's patch on this bug, or something similar, is Windows only and something we'd want as a first aid and simple enough to uplift.  The safe mode patch is bug 1171682, we can have a separate discussion whether we uplift that or not, as it would be multiplatform.

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Disallow D3D11 ANGLE with old DisplayLink drivers. Carry r=bas

Jeff's patch, just updated patch comments.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

Comment on attachment 8616219 [details] [diff] [review]
Disallow D3D11 ANGLE with old DisplayLink drivers.  Carry r=bas

Actually, this shouldn't compile.

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Disallow D3D11 ANGLE with old DisplayLink drivers. Carry r=bas

Ugly, but appropriate for uplift.

Comment 15

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/56e2e974eae2

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Milan or Jeff - If you can request uplift once this looks ok on m-c, we can get it into the Beta 4 build  Monday morning.

Comment 17

[Jeff Muizelaar [:jrmuizel]]

Attachment: Disallow D3D11 ANGLE with old DisplayLink drivers

Approval Request Comment
[Feature/regressing bug #]: D3D11 ANGLE
[User impact if declined]: crashes on WebGL content for people with old DisplayLink drivers
[Describe test coverage new/current, TreeHerder]: Not really tested. I don't think we have the hardware to reproduce this.
[Risks and why]: Should be pretty low risk because it's disabling stuff.

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/56e2e974eae2

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8616518 [details] [diff] [review]
Disallow D3D11 ANGLE with old DisplayLink drivers

Approved for uplift to aurora and beta.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e566a3e330a7

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/da14f82d9caf