Closed
Bug 1229533
Opened 9 years ago
Closed 9 years ago
When swap chain ResizeBuffers fails (as the first failure)
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
FIXED
mozilla45
Tracking | Status | |
---|---|---|
firefox45 | --- | fixed |
People
(Reporter: milan, Assigned: bas.schouten)
Details
(Whiteboard: [gfx-noted])
Attachments
(1 file)
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•9 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•9 years ago
|
Whiteboard: [gfx-noted]
Reporter | ||
Comment 2•9 years ago
|
||
Indirect references included...
Assignee | ||
Comment 3•9 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•9 years ago
|
||
Reporter | ||
Comment 5•9 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•9 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6899517c16a2
Status: ASSIGNED → RESOLVED
Closed: 9 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.
Description
•