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)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: nical, Assigned: nical)

Details

Attachments

(2 files, 1 obsolete file)

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.
This is pretty hacky. Modeling this with a return type that implies that its addref-ed would be nicer.
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+
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)
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)
Attachment #8403974 - Flags: review?(bas) → review+
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.

Attachment

General

Created:
Updated:
Size: