Check that RWHI isn't deleted manually while owned by a scoped_ptr in RVHI

content/browser/renderer_host/render_widget_host_impl.cc

Index: content/browser/renderer_host/render_widget_host_impl.cc
diff --git a/content/browser/renderer_host/render_widget_host_impl.cc b/content/browser/renderer_host/render_widget_host_impl.cc
index baf1cc4c75a4ec24ab4afaa3c1617df86882f133..4a21dd4d70f17761ab47cb2a8f2ce561f148b69b 100644
--- a/content/browser/renderer_host/render_widget_host_impl.cc
+++ b/content/browser/renderer_host/render_widget_host_impl.cc
@@ -1469,8 +1469,10 @@ void RenderWidgetHostImpl::Destroy(bool also_delete) {
   if (delegate_)
     delegate_->RenderWidgetDeleted(this);
 
-  if (also_delete)
+  if (also_delete) {
+    CHECK(!owner_delegate_);

[nasko, 2016/03/01 17:13:43]

Is the goal of this to help us discover further UaF bugs?

[gzobqq, 2016/03/01 18:30:13]

I would guess that if there is a way to fail this check, it won't happen by
accident. At least bug 590284 required deliberate steps from a compromised
renderer. RWHI ownership logic is fairly complicated. RWHI can be owned by RVHI,
RFHI or a WCI. Many paths call RWHI::Destroy(true). Should something get
confused and call it on a RWHI owned by RVHI, we'll UaF. I think the CHECK is a
good idea for protection.

Of course on the other hand it's not nice to clutter the code with CHECKs and
there's a perf hit. If you think we shouldn't have it, that's ok. I'll try to
verify the Destroy(true) calls at some point.

     delete this;
+  }
 }
 
 void RenderWidgetHostImpl::RendererIsUnresponsive() {