Closed Bug 1195844 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: Graphics: Layers, defect)

43 Branch
x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox40 + fixed
firefox41 --- fixed
firefox42 --- fixed
firefox43 --- fixed
relnote-firefox --- 40+

People

(Reporter: milan, Assigned: milan)

References

(Blocks 1 open bug)

Details

(Keywords: topcrash-win)

Crash Data

Attachments

(1 file, 1 obsolete file)

+++ 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
Closed: 5 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.
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.
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
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.