When swap chain ResizeBuffers fails (as the first failure)

RESOLVED FIXED in Firefox 45

Status

()

Core
Graphics: Layers
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: milan, Assigned: bas)

Tracking

43 Branch
mozilla45
Unspecified
Windows
Points:
---

Firefox Tracking Flags

(firefox45 fixed)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
In bug 1204922 we see mSwapChain->ResizeBuffers fails sometimes (CompositorD3D11), and we try to deal with the consequences.

But, why does ResizeBuffers fail in the first place?

For example, https://crash-stats.mozilla.com/report/index/909ecaa4-6f7c-4478-bbab-a05da2151201 fails with error 0x887a0001 (DXGI_ERROR_INVALID_CALL), on a fairly reasonably sized request (340x74).
(Reporter)

Comment 1

2 years ago
Is it possible we somehow still didn't release the texture, despite our efforts just before calling ResizeBuffers in CompositorD3D11::VerifyBufferSize?  Any additional information we can get to help us decipher this?
Flags: needinfo?(bas)
(Reporter)

Updated

2 years ago
Whiteboard: [gfx-noted]
(Reporter)

Comment 2

2 years ago
Indirect references included...
(Assignee)

Comment 3

2 years ago
(In reply to Milan Sreckovic [:milan] from comment #1)
> Is it possible we somehow still didn't release the texture, despite our
> efforts just before calling ResizeBuffers in
> CompositorD3D11::VerifyBufferSize?  Any additional information we can get to
> help us decipher this?

We could log the refcount on -our- last release and see if it matches our expectations.
Flags: needinfo?(bas)
(Assignee)

Comment 4

2 years ago
Created attachment 8695336 [details] [diff] [review]
Ensure our rendertargetview for the backbuffer and the backbuffer itself have no lingering references, and log if they do.
Assignee: nobody → bas
Status: NEW → ASSIGNED
Attachment #8695336 - Flags: review?(milan)
(Reporter)

Comment 5

2 years ago
Comment on attachment 8695336 [details] [diff] [review]
Ensure our rendertargetview for the backbuffer and the backbuffer itself have no lingering references, and log if they do.

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

R+, but either clarify or protect against the null pointer dereference in a couple of places.

::: gfx/layers/d3d11/CompositorD3D11.cpp
@@ +1234,5 @@
> +  ID3D11RenderTargetView* view = nullptr;
> +  mContext->OMSetRenderTargets(1, &view, nullptr);
> +
> +  RefPtr<ID3D11RenderTargetView> rtView = mDefaultRT->mRTView;
> +

It seems mDefaultRT can be null, given the test right after this, so we probably shouldn't just mDefaultRT->mRTView?

Can mRTView/rtView be null?  Because we use it below as if we guarantee it is always valid.
Attachment #8695336 - Flags: review?(milan) → review+

Comment 7

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/6899517c16a2
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
You need to log in before you can comment on or make changes to this bug.