Clear RenderFrameImpl::frame_ pointer after deleting it.

Clear RenderFrameImpl::frame_ pointer after deleting it.

Also avoid dereferencing it in OnMessageReceived after deletion.

BUG=461191
TEST=No more crashes in RenderFrameImpl::OnMessageReceived

Committed: https://crrev.com/cfaa4468f3394995a9f1565104ee2743a30d58e0
Cr-Commit-Position: refs/heads/master@{#320773}

[Charlie Reis, 2015-03-16 17:04:28]

creis@chromium.org changed reviewers:
+ nasko@chromium.org

[Charlie Reis, 2015-03-16 17:04:28]

Nasko, can you take a look?

[nasko, 2015-03-16 17:12:18]

Code looks good. Just one question/comment.

https://codereview.chromium.org/1007123003/diff/20001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1007123003/diff/20001/content/renderer/render...
content/renderer/render_frame_impl.cc:2119: delete this;
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:19]

https://codereview.chromium.org/1007123003/diff/20001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1007123003/diff/20001/content/renderer/render...
content/renderer/render_frame_impl.cc:2119: delete this;
On 2015/03/16 17:12:17, nasko wrote:
> 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.

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

[nasko, 2015-03-16 17:40:04]

LGTM

[Charlie Reis, 2015-03-16 17:43:24]

The CQ bit was checked by creis@chromium.org

[commit-bot: I haz the power, 2015-03-16 17:43:49]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1007123003/40001

[Charlie Reis, 2015-03-16 18:00:31]

The CQ bit was unchecked by creis@chromium.org

[Charlie Reis, 2015-03-16 18:07:43]

Fixed a leak in the test in patch 4.

[Charlie Reis, 2015-03-16 18:11:42]

The CQ bit was checked by creis@chromium.org

[Charlie Reis, 2015-03-16 18:11:42]

The patchset sent to the CQ was uploaded after l-g-t-m from nasko@chromium.org
Link to the patchset: https://codereview.chromium.org/1007123003/#ps80001
(title: "Verify OnMessageReceived returns false")

[commit-bot: I haz the power, 2015-03-16 18:12:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1007123003/80001

[commit-bot: I haz the power, 2015-03-16 19:27:30]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-03-16 19:28:07]

Patchset 5 (id:??) landed as
https://crrev.com/cfaa4468f3394995a9f1565104ee2743a30d58e0
Cr-Commit-Position: refs/heads/master@{#320773}