Fix resource leaks in CDM implementation.

ppapi/proxy/ppp_content_decryptor_private_proxy.cc

Index: ppapi/proxy/ppp_content_decryptor_private_proxy.cc
diff --git a/ppapi/proxy/ppp_content_decryptor_private_proxy.cc b/ppapi/proxy/ppp_content_decryptor_private_proxy.cc
index fe6a928a64f753b7242e40971a832670f0c2bb56..e03cf80c2e8589b4d723f6e2c19fe5f73d1fb70a 100644
--- a/ppapi/proxy/ppp_content_decryptor_private_proxy.cc
+++ b/ppapi/proxy/ppp_content_decryptor_private_proxy.cc
@@ -140,11 +140,6 @@ PP_Bool Decrypt(PP_Instance instance,
     return PP_FALSE;
   }
 
-  // We need to take a ref on the resource now. The browser may drop
-  // references once we return from here, but we're sending an asynchronous
-  // message. The plugin side takes ownership of that reference.
-  core->AddRefResource(encrypted_block);

[dmichael (off chromium), 2012/09/05 17:13:06]

tl;dr: Keep this. What you're missing is the corresponding dereference.

I think you still need this. You want to make sure that the resource lives long
enough that it's still alive when the plugin receives it. Since you're sending
an asynchronous message (as you should), it's reasonably likely that the browser
will be done with this call before the plugin can handle the
PpapiMsg_PPPContentDecryptor_Decrypt message. What you want to do is add the
corresponding RemoveRef after the plugin has gotten the message (see comment
later in the file).

It might actually work for now. I think the IPC magic under the hood might hold
open the shared memory, since you're sending a shared memory handle. But it
might cause trouble that you have a HostResource on the other side that's no
longer valid. That'll probably bite you later if you start reusing the buffer
resources.

[Tom Finegan, 2012/09/05 19:21:43]

Done.

-
   HostResource host_resource;
   host_resource.SetHostResource(instance, encrypted_block);