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

RESOLVED FIXED in Firefox 40

Status

()

defect
--
critical
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: milan, Assigned: milan)

Tracking

(Blocks 1 bug, {topcrash-win})

43 Branch
mozilla43
x86
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox40+ fixed, firefox41 fixed, firefox42 fixed, firefox43 fixed, relnote-firefox 40+)

Details

(crash signature)

Attachments

(1 attachment, 1 obsolete attachment)

+++ 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.
Assignee: nobody → milan
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) {
Attachment #8649361 - Flags: review?(jmuizelaar) → review+
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.
Attachment #8649361 - Attachment is obsolete: true
Once this lands, I'll ask for an uplift.
https://hg.mozilla.org/mozilla-central/rev/0e7da11edc90
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
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?
Attachment #8649593 - Flags: approval-mozilla-beta?
Attachment #8649593 - Flags: approval-mozilla-aurora?
Milan, we will be doing a dot release this week. As it is a startup crash, we could take it, agree?
Flags: needinfo?(milan)
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.
Attachment #8649593 - Flags: approval-mozilla-beta?
Attachment #8649593 - Flags: approval-mozilla-beta+
Attachment #8649593 - Flags: approval-mozilla-aurora?
Attachment #8649593 - Flags: approval-mozilla-aurora+
(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.
Flags: needinfo?(milan)
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!
Attachment #8649593 - Flags: approval-mozilla-release+
Added to the release notes:
"Fix a startup crash when using DisplayLink (Windows Only) (1195844)"
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.

Comment 21

4 years ago
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)

Comment 23

4 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.