Closed Bug 1222496 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: Canvas: WebGL, defect, critical)

43 Branch
x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
firefox42 - wontfix
firefox43 + wontfix
firefox44 + fixed
firefox45 + fixed
b2g-v2.5 --- fixed

People

(Reporter: milan, Assigned: jrmuizel)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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.
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?
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(jgilbert)
Flags: needinfo?(dvander)
Summary: crash in @0x0 | CContext::ID3D11DeviceContext1_SetSamplers_<T> → startup sanity test crash in @0x0 | CContext::ID3D11DeviceContext1_SetSamplers_<T>
(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.
Flags: needinfo?(jgilbert)
This is on 42 as well, which is really strange. Maybe it's a weird change from Product-land that was uplifted?
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.
I think this is caused by the ANGLE update. I'll try to fix it.
Assignee: nobody → jmuizelaar
Flags: needinfo?(jmuizelaar)
https://hg.mozilla.org/mozilla-central/rev/09cd7947ffd9
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
[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?
Tracking since this is a startup crash.  Happy to take a patch for beta....
(In reply to Robert Kaiser (:kairo@mozilla.com) 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?
Flags: needinfo?(jmuizelaar)
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?
Flags: needinfo?(jgilbert)
Milan, I was trying to follow up on 44+ tracked bugs. Do we have need to uplift this fix to Aurora?
Flags: needinfo?(milan)
It sounds like jrmuizel had a solution for this, though it looks like no bug got attached here.
Flags: needinfo?(jgilbert)
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.
Flags: needinfo?(jmuizelaar)
Attachment #8695511 - Flags: approval-mozilla-aurora?
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.
Attachment #8695511 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
Flags: needinfo?(milan) → needinfo?(lhenry)
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.
Flags: needinfo?(lhenry) → needinfo?(jmuizelaar)
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.
Duplicate of this bug: 1226085
(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.
Flags: needinfo?(jmuizelaar)
(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.
See Also: → 1262427
You need to log in before you can comment on or make changes to this bug.