Cleanup ChildFrameCompositingHelper on destruction.

content/renderer/child_frame_compositing_helper.cc

Index: content/renderer/child_frame_compositing_helper.cc
diff --git a/content/renderer/child_frame_compositing_helper.cc b/content/renderer/child_frame_compositing_helper.cc
index 410e20b62a9985fef0c7bad6a349b1bce44fb4fd..08293fd016ff560655c08a4ed87fc33cfcf4756f 100644
--- a/content/renderer/child_frame_compositing_helper.cc
+++ b/content/renderer/child_frame_compositing_helper.cc
@@ -61,7 +61,10 @@ ChildFrameCompositingHelper::ChildFrameCompositingHelper(
       render_frame_proxy_(render_frame_proxy),
       frame_(frame) {}
 
-ChildFrameCompositingHelper::~ChildFrameCompositingHelper() {}
+ChildFrameCompositingHelper::~ChildFrameCompositingHelper() {
+  if (resource_collection_.get())
+    resource_collection_->SetClient(NULL);

[danakj, 2015/02/03 20:07:42]

Destruction implies the child compositor is shutting down? Or do we need to
lose+return all the resources in the collection first?

[lfg, 2015/02/03 20:26:22]

The child compositor is shutting down. I'm not sure if we need to return the
resources in the collection.

The issue I'm trying to fix is that since the resource collection is refcounted
and may be referenced in the cc tree, it may be left with a dangling pointer to
the ChildFrameCompositingHelper. Then, if we update the cc tree at the wrong
time we may get a crash.

[danakj, 2015/02/03 20:40:10]

Right. But if you just drop the client, you'll leak any resources being held by
this compositor instead of returning them to the child compositor ever. If it's
shutting down anyway, it'll just delete/drop its refs anyways so that's okay. If
it's not you leak them until it does shutdown.

So, it sounds like this is okay then. LGTM

+}
 
 BrowserPluginManager* ChildFrameCompositingHelper::GetBrowserPluginManager() {
   if (!browser_plugin_)