Clear RenderFrameImpl::frame_ pointer after deleting it.

content/renderer/render_frame_impl.cc

Index: content/renderer/render_frame_impl.cc
diff --git a/content/renderer/render_frame_impl.cc b/content/renderer/render_frame_impl.cc
index 437e8c98be937398ffd4b3ca46cdfb4c5b964f16..7e9230558fcca26af5af51c99b1fd8baf76efe29 100644
--- a/content/renderer/render_frame_impl.cc
+++ b/content/renderer/render_frame_impl.cc
@@ -952,6 +952,11 @@ void RenderFrameImpl::DidHideExternalPopupMenu() {
 #endif
 
 bool RenderFrameImpl::OnMessageReceived(const IPC::Message& msg) {
+  // We may get here while detaching, when the WebFrame has been deleted.  Do
+  // not process any messages in this state.
+  if (!frame_)
+    return false;
+
   // TODO(kenrb): document() should not be null, but as a transitional step
   // we have RenderFrameProxy 'wrapping' a RenderFrameImpl, passing messages
   // to this method. This happens for a top-level remote frame, where a
@@ -2104,8 +2109,11 @@ void RenderFrameImpl::frameDetached(blink::WebFrame* frame) {
   if (is_subframe)
     frame->parent()->removeChild(frame);
 
-  // |frame| is invalid after here.
+  // |frame| is invalid after here.  Be sure to clear frame_ as well, since this
+  // object may not be deleted immediately and other methods may try to access
+  // it.
   frame->close();
+  frame_ = nullptr;
 
   if (is_subframe) {
     delete this;

[nasko, 2015/03/16 17:12:17]

Based on this, isn't it the case that frame_ is invalid between the close() call
above and the destruction of RenderFrameImpl, only if it is the main frame? Have
any of the crashes we've seen been in the case of subframes?
If that's the case, I think it will be useful to clarify this in the header file
comment, as main frame and subframe lifetimes will always behave differently.

[Charlie Reis, 2015/03/16 17:21:18]

Yes, it's only for the main frame.  Comment updated.