Closed
Bug 1222496
Opened 5 years ago
Closed 5 years ago
startup sanity test crash in @0x0 | CContext::ID3D11DeviceContext1_SetSamplers_<T>
Categories
(Core :: Canvas: WebGL, defect)
Tracking
()
People
(Reporter: milan, Assigned: jrmuizel)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
1.42 KB,
patch
|
ritu
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•5 years ago
|
||
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>
Comment 2•5 years ago
|
||
(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)
Comment 3•5 years ago
|
||
This is on 42 as well, which is really strange. Maybe it's a weird change from Product-land that was uplifted?
Reporter | ||
Comment 4•5 years ago
|
||
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.
Assignee | ||
Comment 5•5 years ago
|
||
I think this is caused by the ANGLE update. I'll try to fix it.
Assignee: nobody → jmuizelaar
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(dvander)
Comment 7•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/09cd7947ffd9
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox45:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
![]() |
||
Comment 8•5 years ago
|
||
[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?
status-firefox42:
--- → affected
status-firefox43:
--- → affected
status-firefox44:
--- → affected
tracking-firefox42:
--- → ?
tracking-firefox43:
--- → ?
tracking-firefox44:
--- → ?
Tracking since this is a startup crash. Happy to take a patch for beta....
![]() |
||
Comment 10•5 years ago
|
||
(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)
Reporter | ||
Comment 11•5 years ago
|
||
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)
Comment 13•5 years ago
|
||
It sounds like jrmuizel had a solution for this, though it looks like no bug got attached here.
Flags: needinfo?(jgilbert)
Assignee | ||
Comment 14•5 years ago
|
||
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)
Assignee | ||
Comment 18•5 years ago
|
||
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•5 years ago
|
||
bugherderuplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/6f4e398c6303
Comment 21•5 years ago
|
||
bugherderuplift |
https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/6f4e398c6303
status-b2g-v2.5:
--- → fixed
Assignee | ||
Comment 22•5 years ago
|
||
(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)
Assignee | ||
Comment 23•5 years ago
|
||
(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.
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•