1195844 - DisplayLink (dlumd10.dll, dlumd11.dll) Startup crash in @0x0 | CContext::UMQueryHS_ConstBuf_(D3D10DDI_HRTCORELAYER, unsigned int, unsigned int)

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

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

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

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

Sample crash (see https://bugzilla.mozilla.org/show_bug.cgi?id=1160295#c27)
https://crash-stats.mozilla.com/report/index/64931a12-486a-491d-9eca-62c6a2150817
=============================================================

We want to also look for "dlumd10.dll" and "dlumd11.dll", not just "dlumd32.dll".

Bug 1160295 ended up fixing the regression in the original checking of dlumd32.dll, and to simplify things, we'll open this one to go for the original purpose of that bug.

Comment 1

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

Attachment: DisplayLink version problems may come from a few different DLLs. r=jrmuizel

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8649361 [details] [diff] [review]
DisplayLink version problems may come from a few different DLLs. r=jrmuizel

Review of attachment 8649361 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/thebes/gfxWindowsPlatform.cpp
@@ +1671,5 @@
> +  if (GetModuleHandleW(L"igd10umd32.dll")) {
> +    const wchar_t* checkModules[] = {L"dlumd32.dll",
> +                                     L"dlumd11.dll",
> +                                     L"dlumd10.dll"};
> +    for (int i=0; i<(sizeof(checkModules)/sizeof(wchar_t*)); i+=1) {

for (int i=0; i<PR_ARRAY_SIZE(checkModules); i+=1) {

Comment 3

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

Attachment: DisplayLink version problems may come from a few different DLLs. Carry r=jrmuizel

https://treeherder.mozilla.org/#/jobs?repo=try&revision=7164d8263c22 and
https://treeherder.mozilla.org/#/jobs?repo=try&revision=902942f4d6c2

Comment 4

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

The try failures with test_CrossSiteXHR_origin.html don't seem to be related.

Comment 5

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

[Tracking Requested - why for this release]: KaiRo mentioned that this could be a ride along for FF40.

Comment 6

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

Once this lands, I'll ask for an uplift.

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0e7da11edc90

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0e7da11edc90

Comment 9

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

Comment on attachment 8649593 [details] [diff] [review]
DisplayLink version problems may come from a few different DLLs.  Carry r=jrmuizel

Approval Request Comment
Bug 1160295 (uplifted through release) landed on August 12/13th; this bug landed on central on August 23rd.  We know there are crashes that survived the fixing of bug 1160295 (e.g., https://crash-stats.mozilla.com/report/index/64931a12-486a-491d-9eca-62c6a2150817).  The number is smaller, but it is a startup crash, so we need to decide if it's important enough to uplift, and how far?

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Milan, we will be doing a dot release this week. As it is a startup crash, we could take it, agree?

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8649593 [details] [diff] [review]
DisplayLink version problems may come from a few different DLLs.  Carry r=jrmuizel

Fix a startup crash, taking it.

Comment 12

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

(In reply to Sylvestre Ledru [:sylvestre] from comment #10)
> Milan, we will be doing a dot release this week. As it is a startup crash,
> we could take it, agree?

Agreed.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8649593 [details] [diff] [review]
DisplayLink version problems may come from a few different DLLs.  Carry r=jrmuizel

[Triage Comment]
Thanks, taking it then!

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1a373581e42c

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1d12ec0bd163

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/cc282d7fdcfc

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Added to the release notes:
"Fix a startup crash when using DisplayLink (Windows Only) (1195844)"

Comment 18

[[:philipp]]

sorry to spoil it again, but the crashes continue in 40.0.3:
https://crash-stats.mozilla.com/search/?signature=~UMQueryHS&signature=%3D%400x0+|+CContext%3A%3AUMQueryHS_ConstBuf_(D3D10DDI_HRTCORELAYER%2C+unsigned+int%2C+unsigned+int)&version=40.0.3&_facets=signature#crash-reports

Comment 19

[(Away)]

Could be the force-enable prefs.

We might want to make a note in the crash report whenever force prefs are used.

Comment 20

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

Did the crash volume go down at all?  There are different versions of the DLLs we're investigating, but all of them are below 8.6.1.36484, so this should have caught them - it did not.

If the volume went down, it's probably the forcing of the acceleration as David mentioned.  If the volume didn't go down, then there is a bug somewhere.

Comment 21

[[:philipp]]

it may be a bit too early to tell for sure, but the relative volume looks like it is in the same range in 40.0.2 and 40.0.3 at around 0.2% of all browser crashes.

Comment 22

[(Away)]

I would look at counts/day in the first few days after each release. (Might need to wait a bit for 40.0.3 data to fill out)

Comment 23

[[:philipp]]

in absolute numbers, within 5 days of the 40.0.2 release there have been 308 crashes & in the same timespan after 40.0.3 it have been 278 crashes. that doesn't look like a significant change.

Comment 24

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

No, that looks like this patch isn't doing much if anything.

Comment 25

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

(In reply to Milan Sreckovic [:milan] from comment #24)
> No, that looks like this patch isn't doing much if anything.

Actually, it may have made things worse - https://crash-stats.mozilla.com/report/index/33d48c2e-8ad8-45ee-b962-8215b2150902 now crashes with dlumd32.dll which was covered before.

Comment 26

[(Away)]

(In reply to Milan Sreckovic [:milan] from comment #25)
> (In reply to Milan Sreckovic [:milan] from comment #24)
> > No, that looks like this patch isn't doing much if anything.
> 
> Actually, it may have made things worse -
> https://crash-stats.mozilla.com/report/index/33d48c2e-8ad8-45ee-b962-
> 8215b2150902 now crashes with dlumd32.dll which was covered before.

I'm not so sure about the "worse" part. There were dlumd32 crashes on 40.0.2 before this patch, presumably for whatever reason is also causing the continuing dlumd11 crashes.

Comment 27

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

You're right, this particular bug didn't make things worse.  It was actually bug 1160295 that rendered these checks ineffective.

Comment 28

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

This patch seems to be fine the way it is.  It is not effective until the correct solution to bug 1160295 though, so I'll leave this one opened until then.  The rest of the details in bug 1160295.

Comment 29

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

Milan, this looks fixed now in bug 1160295. Do you think this is resolved ? It seems kind of unclear whether it's fixed on all branches or just for 43 though.

Comment 30

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

Yes, this should be fixed by bug 1160295, and I just asked for the uplifts there.