1098597 - startup crash in igd10umd32.dll@0x18f35 from [@ CContext::ID3D11DeviceContext_UpdateSubresource_<2>(ID3D11DeviceContext*, ID3D11Resource*, unsigned int, D3D11_BOX const*, void const*, unsigned int, unsigned int) ]

Status: RESOLVED DUPLICATE of bug 1221348

(Core :: Graphics, defect)

Description

[Mats Palmgren (inactive)]

This bug was filed from the Socorro interface and is 
report bp-c1de3d44-9f16-41de-9806-ff5d42141110.
=============================================================

Comment 1

[Mats Palmgren (inactive)]

Better stack:  bp-bd17cbea-5730-43eb-a961-8c54b2141111

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Milan - this bug is causing 50% of crashed in 35.0b3 and is the #1 topcrash by far, combined with bug 1074378 (which despite being resolved) is #2 causing 25% -- are they connected?  Can we get some attention here?  This is causing 35 to be highly unstable compared to our previous release.

Comment 3

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

So these crashes are on 33 - did it go away in 34 and now it's back in 35?  Or we just had everybody bail in 34 and not come back and now we're doing the same to the beta population?

Nicolas, Bas, this is D3D11; bug 1074378 was D3D10, is there an equivalent fix?  Bas, related to the driver restart you're looking at?

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

It's looking like Kairo might have found the issue over here https://bugzilla.mozilla.org/show_bug.cgi?id=1097321#c26

Comment 5

[Robert Kaiser]

See bug 1097321 comment #26, I think that unblocking patch caused this huge explosion. Given that knowledge, I'm reluctant to sign off pushing 35.b4 to the public with this still in.

Comment 6

[Robert Kaiser]

(In reply to Milan Sreckovic [:milan] from comment #3)
> So these crashes are on 33 - did it go away in 34 and now it's back in 35? 
> Or we just had everybody bail in 34 and not come back and now we're doing
> the same to the beta population?

We did unblock a big swath of drivers, apparently ones affected by this.

> Nicolas, Bas, this is D3D11; bug 1074378 was D3D10, is there an equivalent
> fix?  Bas, related to the driver restart you're looking at?

Both this and bug 1074378 are back in 35.0b3 as well as Aurora 36 starting 12/12, after that unblocking landed.

Comment 7

[Bas Schouten (:bas.schouten)]

(In reply to Lukas Blakk [:lsblakk] use ?needinfo from comment #4)
> It's looking like Kairo might have found the issue over here
> https://bugzilla.mozilla.org/show_bug.cgi?id=1097321#c26

It seems very strange that that patch should cause this problem. But for now it still seems best to, at least for this beta, back that out and see if it brings the crash rate back down. Especially since the user benefit of this patch is relatively limited.

(In reply to Milan Sreckovic [:milan] from comment #3)
> So these crashes are on 33 - did it go away in 34 and now it's back in 35? 
> Or we just had everybody bail in 34 and not come back and now we're doing
> the same to the beta population?
> 
> Nicolas, Bas, this is D3D11; bug 1074378 was D3D10, is there an equivalent
> fix?  Bas, related to the driver restart you're looking at?

Not really, that patch already blocks all features, including D3D11.

Comment 8

[Robert Kaiser]

(In reply to Bas Schouten (:bas.schouten) from comment #7)
> (In reply to Lukas Blakk [:lsblakk] use ?needinfo from comment #4)
> > It's looking like Kairo might have found the issue over here
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1097321#c26
> 
> It seems very strange that that patch should cause this problem.

If you have a better idea of what might have caused this on Aurora on the same day that bug 1097321 landed and on beta in the same build that this landed in, I'm all ears and happy to have been wrong. But for me those correlations seemed too large to be a coincidence - I did not check what else landed in the same regression windows on those branches, though.

Comment 9

[Wayne Mery (:wsmwk)]

#1 crash for TB36.0a2 and 34.0b1

Comment 10

[Robert Kaiser]

I suspect this is the same as bug 1074378 and gone with the backout of bug 1097321 as well.

Comment 11

[Robert Kaiser]

(In reply to Robert Kaiser (:[e-mail]) from comment #10)
> I suspect this is the same as bug 1074378 and gone with the backout of bug
> 1097321 as well.

From all I've seen, this is confirmed. I'm not marking fixed because we did not back out on 36+ yet, only on Beta 35.

Comment 12

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

Bas, can you back this out from Aurora, looks like we may have had our lines crossed on who's doing the actual landing that already happened on Beta.

Comment 13

[Bas Schouten (:bas.schouten)]

(In reply to Milan Sreckovic [:milan] from comment #12)
> Bas, can you back this out from Aurora, looks like we may have had our lines
> crossed on who's doing the actual landing that already happened on Beta.

Jeff has done this I believe.

Comment 14

[u279076]

This no longer shows up at all for Thunderbird. For Firefox I still see significant volume but I'm not sure if those crashes are different than what was investigated here. In combined signatures there's 2479 reports in the last week on Firefox 41 which would make this the #3 topcrash. However more than 65% of these happen after 15 minutes to more than an hour of usage so they're not startup crashes. 

We're probably looking at a separate issue in this case. Please let me know if we should close this bug and reopen a new one.

Comment 15

[Benoit Girard (:BenWa)]

I think this is a dupe of bug 1221348.

When we try to do runtime texture sharing detection we hit an Intel driver bug on startup. Bug 1221348 is addressing this issue.