Crash in mozilla::layers::DXGITextureHostD3D11::GetDevice

RESOLVED FIXED in Firefox 55

Status

()

Core
Graphics: Layers
--
critical
RESOLVED FIXED
a year ago
10 months ago

People

(Reporter: calixte, Assigned: dvander)

Tracking

(Blocks: 1 bug, {crash, regression, topcrash})

52 Branch
mozilla55
Unspecified
Windows 10
crash, regression, topcrash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 unaffected, firefox-esr52 unaffected, firefox53 unaffected, firefox54 unaffected, firefox55 fixed)

Details

(Whiteboard: [clouseau], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

a year ago
This bug was filed from the Socorro interface and is 
report bp-002ca00a-e507-460b-bf33-97f112170323.
=============================================================

There are 255 crashes on nightly 55 with buildid 20170323030203. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1343814.

[1] https://hg.mozilla.org/mozilla-central/rev?node=30cf9aea9a001b3a08e0d115a2dd1d865c718a72
Flags: needinfo?(dvander)
(Reporter)

Comment 1

a year ago
This crash is ranked #1 for the GPU process.
Keywords: topcrash
Adding another similiar signature which is also correlated to that checkin, and all with 20170324030205.
Crash Signature: [@ mozilla::layers::DXGITextureHostD3D11::GetDevice] → [@ mozilla::layers::DXGITextureHostD3D11::GetDevice] [@ mozilla::layers::DXGIYCbCrTextureHostD3D11::GetDevice]
(In reply to Marcia Knous [:marcia - use ni] from comment #2)
> Adding another similiar signature which is also correlated to that checkin,
> and all with 20170324030205.

One URL that seems to be crashing in this signature is https://threejs.org/examples/#webvr_vive
Oops. The VR code doesn't set a compositor, probably because before this refactoring, TextureHosts were tied to the compositor's hip. In theory VR should now provider a TextureSourceProvider, but since that's kind of a big change, we can revert to the old behavior.
Assignee: nobody → dvander
Status: NEW → ASSIGNED
Flags: needinfo?(dvander)
Created attachment 8851321 [details] [diff] [review]
fix

If using a TextureSourceProvider, the device is cached on the TextureHost. If locking without a compositor, we force the device to be the compositor device.
Attachment #8851321 - Flags: review?(matt.woodrow)

Updated

a year ago
status-firefox52: --- → unaffected
status-firefox53: --- → unaffected
status-firefox54: --- → unaffected
Attachment #8851321 - Flags: review?(matt.woodrow) → review+
Thanks for getting to this quickly.

I did some tests with the attached patch on real VR hardware.

Unfortunately, further changes will be required to correct the regression.

DXGITextureHostD3D11::GetDevice now succeeds; however, later in DXGITextureHostD3D11::::LockInternal() we have:

mTextureSource = new DataTextureSourceD3D11(mFormat, mProvider, mTexture);

The DataTextureSourceD3D11 constructor is dereferencing aProvider (which is null):

DataTextureSourceD3D11::DataTextureSourceD3D11(gfx::SurfaceFormat aFormat, TextureSourceProvider* aProvider, ID3D11Texture2D* aTexture)
 : DataTextureSourceD3D11(aProvider->GetD3D11Device(), aFormat, aTexture)
{
}

Comment 7

a year ago
Pushed by danderson@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/133f72d4b8fc
Fix DXGITextureHostD3D11 not being able to lock without a compositor. (bug 1350247, r=mattwoodrow)
Sorry I didn't see comment #5 before pushing. Kip, can we just read the global d3d11 device there if aProvider is null?
Depends on: 1350794
Blocks: 1350794
No longer depends on: 1350794
(In reply to David Anderson [:dvander] from comment #8)
> Sorry I didn't see comment #5 before pushing. Kip, can we just read the
> global d3d11 device there if aProvider is null?

Exactly, it appears that doing this will fix the remaining crash in WebVR.

I've created a patch on Bug 1350794, which when combined with your fix here, will correct the regression/crash in WebVR.

Thanks again!

Comment 10

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/133f72d4b8fc
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox55: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
status-firefox-esr52: --- → unaffected
Blocks: 1396527
You need to log in before you can comment on or make changes to this bug.