Closed
Bug 993417
Opened 11 years ago
Closed 11 years ago
[OMTC Windows] CairoTextureClientD3D9's destruction can race with the creation of it's texture host
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
FIXED
mozilla31
People
(Reporter: nical, Assigned: nical)
Details
Attachments
(2 files, 1 obsolete file)
|
1.50 KB,
patch
|
bas.schouten
:
review+
|
Details | Diff | Splinter Review |
|
4.72 KB,
patch
|
bas.schouten
:
review+
|
Details | Diff | Splinter Review |
If a CairoTextureClientD3D9 is destroyed after being serialized but before it's texture is deserialized on the host size, the content of the SurfaceDescriptorD3D9 (a pointer to a IDirect3DTexture9) ends up being a dangling pointer. and we crash in the host side when deserializing it.
| Assignee | ||
Comment 1•11 years ago
|
||
Attachment #8403293 -
Flags: review?(bas)
Comment 2•11 years ago
|
||
This is pretty hacky. Modeling this with a return type that implies that its addref-ed would be nicer.
Comment 3•11 years ago
|
||
Comment on attachment 8403293 [details] [diff] [review]
Fix the race by addreffing the texture on the client side and releasing it on the host side
Review of attachment 8403293 [details] [diff] [review]:
-----------------------------------------------------------------
::: gfx/layers/d3d9/TextureD3D9.cpp
@@ +644,5 @@
> if (!IsAllocated()) {
> return false;
> }
>
> + mTexture->AddRef(); // Release in TextureHostD3D9::TextureHostD3D9
This is very scary, it requires careful documentation, as this basically depends strongly on the SurfaceDescriptor that's being retrieved -actually- being used somewhere to create a texturehost. That's okay, but it will be very easy to accidentally break in the future.
Attachment #8403293 -
Flags: review?(bas) → review+
| Assignee | ||
Comment 4•11 years ago
|
||
Agreed. The deprecated code used to do exactly that so I didn't look for a fancier solution. This patch makes ToSurfaceDescriptor protected and adds a comment, which isn't quite as good as a bunch of well placed assertions but I guess it'll make do for now.
I have a few ideas to better track the internal state of TextureClient and make it easier to assert the things we care about, but I'd rather focus on getting OMTC everywhere at the moment.
Attachment #8403961 -
Flags: review?(bas)
| Assignee | ||
Comment 5•11 years ago
|
||
Oops, I was building the wrong tree and the previous version of this patch didn't build.
Attachment #8403961 -
Attachment is obsolete: true
Attachment #8403961 -
Flags: review?(bas)
Attachment #8403974 -
Flags: review?(bas)
Updated•11 years ago
|
Attachment #8403974 -
Flags: review?(bas) → review+
| Assignee | ||
Comment 6•11 years ago
|
||
Comment 7•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ba08bcd1d729
https://hg.mozilla.org/mozilla-central/rev/7906728a1b88
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in
before you can comment on or make changes to this bug.
Description
•