+++ 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 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) {

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

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

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

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

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?

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

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.

(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 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!

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

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

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

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.

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.

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)

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.

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

(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.

(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.

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

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.

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.

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