1222496 - startup sanity test crash in @0x0 | CContext::ID3D11DeviceContext1_SetSamplers_<T>

Status: RESOLVED FIXED

(Core :: Canvas: WebGL, defect)

Description

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

This bug was filed from the Socorro interface and is 
report bp-b7c20165-bdf8-45af-892c-b7b542151104.
=============================================================

Not sure if this is really startup, but the uptime is short.  On the other hand, we're initializing WebGL, and I wouldn't expect that on a regular startup.

Comment 1

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

Never mind, we are doing this during start up testing, so we'd expect this to drop these to safe mode.  David, any way to verify this?

Jeff & Jeff - are these newly relaxed driver/device combinations, or is this the type of crash that we'd only see in WebGL, and maybe these people didn't try and run WebGL before.

Are we now creating WebGL context on startup sanity test?

Comment 2

[Jeff Gilbert [:jgilbert]]

(In reply to Milan Sreckovic [:milan] from comment #1)
> Never mind, we are doing this during start up testing, so we'd expect this
> to drop these to safe mode.  David, any way to verify this?
> 
> Jeff & Jeff - are these newly relaxed driver/device combinations, or is this
> the type of crash that we'd only see in WebGL, and maybe these people didn't
> try and run WebGL before.
> 
> Are we now creating WebGL context on startup sanity test?

I found something like this while testing WebGL 2 with the new texture code. It appeared that we're starting a webgl context for some reason on startup. I don't know what would be causing this.

Comment 3

[Jeff Gilbert [:jgilbert]]

This is on 42 as well, which is really strange. Maybe it's a weird change from Product-land that was uplifted?

Comment 4

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

If it's on startup, it should only happen "once" when you update to the new version or change the driver, not each time we run it.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

I think this is caused by the ANGLE update. I'll try to fix it.

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/09cd7947ffd9

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/09cd7947ffd9

Comment 8

[Robert Kaiser]

[Tracking Requested - why for this release]:
This is a startup crash on 42 and higher, and it's 1.3% of the total startup crashes in 42.0 release, with >500 crashes in the last week of that new release.

It's not a driver for a dot release, but could be a nice ridealong. It's also affecting 43 beta and 44 Dev Edition, so requesting tracking across the board.

Jeff, from what I understand, only the moz.build change is actually affecting the build, is that right? If it really fixes the crashes, can you request uplift to aurora and beta?

Comment 9

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

Tracking since this is a startup crash.  Happy to take a patch for beta....

Comment 10

[Robert Kaiser]

(In reply to Robert Kaiser (:[e-mail]) from comment #8)
> Jeff, from what I understand, only the moz.build change is actually
> affecting the build, is that right? If it really fixes the crashes, can you
> request uplift to aurora and beta?

Comment 11

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

It would be strange if this was effecting Beta 43 or earlier, because that's still using the old ANGLE, though it does apply to Aurora 44.  Which clashes with comment 8.  Jeff M is on PTO for another week, Jeff G, your take on this?  Instead of updating the whole ANGLE on Aurora, can we just set that config value?  Or do we need to update to the same ANGLE that nightly is using?

Comment 12

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Milan, I was trying to follow up on 44+ tracked bugs. Do we have need to uplift this fix to Aurora?

Comment 13

[Jeff Gilbert [:jgilbert]]

It sounds like jrmuizel had a solution for this, though it looks like no bug got attached here.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

Attachment: Allow not using D3D11

Approval Request Comment
[Feature/regressing bug #]: 1211774
[User impact if declined]: Instability when using WebGL
[Describe test coverage new/current, TreeHerder]: Has been in 45 for a while.
[Risks and why]: Very low risk. This reverts us to our previous behaviour.

Comment 15

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8695511 [details] [diff] [review]
Allow not using D3D11

Crash fixes are good, and this patch has been on Nightly for a few weeks now, seems safe to uplift to Aurora44.

Comment 16

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Liz, the crash signature shows a few instances of hits on 43.0b6 and 43.0b7. In case you want to consider taking this fix, if deemed safe.

Comment 17

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

Hmm. If the regressing bug is really bug 1211774 then that only landed on 44, so I'm inclined to think this may not be a useful solution. 

Jeff, do you have time to look at some of the reported crashes from 43.0b7 or b6? If not, I'll wontfix  this for 43.

Comment 18

[Jeff Muizelaar [:jrmuizel]]

The crashes on in 43 seem like they might be related to blacklisting being broken somehow. e.g. This crash https://crash-stats.mozilla.com/report/index/3d21c259-37bd-459d-b63e-ac2662151203 should not being taking this path. I'll investigate tomorrow.

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6f4e398c6303

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/6f4e398c6303

Comment 22

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #18)
> The crashes on in 43 seem like they might be related to blacklisting being
> broken somehow. e.g. This crash
> https://crash-stats.mozilla.com/report/index/3d21c259-37bd-459d-b63e-
> ac2662151203 should not being taking this path. I'll investigate tomorrow.

In this crash the user seems to be forcing D3D11.

Comment 23

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #22)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #18)
> > The crashes on in 43 seem like they might be related to blacklisting being
> > broken somehow. e.g. This crash
> > https://crash-stats.mozilla.com/report/index/3d21c259-37bd-459d-b63e-
> > ac2662151203 should not being taking this path. I'll investigate tomorrow.
> 
> In this crash the user seems to be forcing D3D11.

All of the crashes that I looked at seemed to have this property.