New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 608061 link

Starred by 2 users
Status: Duplicate
Merged: issue 584845
Owner:
█ nick@chromium.org
not working at Google anymore
Closed: May 2016
Cc:
creis@chromium.org
alex...@chromium.org
wfh@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

RFH_NO_PROXY_TO_PARENT renderer kill on first run with --site-per-process

Project Member Reported by creis@chromium.org, Apr 29 2016 
Version: 50.0.2661.94 (not M52)
OS: All

What steps will reproduce the problem?
(1) Start Chrome Stable in a new profile with --site-per-process.
(2) Wait for the first run pages to load (chrome://chrome-signin/?access_point=0&reason=0 and https://www.google.com/intl/en/chrome/browser/welcome.html).

On the console, you'll see [21463:1295:0429/144317:ERROR:bad_message.cc(18)] Terminating renderer for bad IPC message, reason 4

That's a RFH_NO_PROXY_TO_PARENT kill.

This repros the first two runs of any profile, and not after that.  Unfortunately, it doesn't repro on Canary or tip-of-tree, but we might be able to use these steps to diagnose the other RFH_NO_PROXY_TO_PARENT kills that do happen there.

Assigning to Nick since he volunteered to debug a stable build.

Comment 1 by nick@chromium.org, Apr 29 2016 

Here's what I see:

 - This appears to be on the background page for the Google Docs Offline extension. That probably explains why it's happening on first-run on our dev machines, since I think this extension might be installed by corp policy.

 - The RFH that is triggering the kill is currently the pending RenderFrameHost for that FrameTreeNode. It is in a google.com SiteInstance. Because the cross-process navigation it hasn't committed yet, there is no reason for a proxy to have been created for this frametree node in the extension siteinstance.

I think it's unexpected for a "load complete" event to arrive prior to commit, so my instinct is to call this a blink bug.

Comment 2 by nick@chromium.org, Apr 29 2016 

This can be reproduced with --isolate-extensions as well.

The extension in question is: https://chrome.google.com/webstore/detail/google-docs-offline/ghbmnnjooekpmoecnnnilnnbdlolhkhi

Once you have a profile that reproduces the issue, it seems like a simpler repro step is to go to chrome://extensions, and toggle the "enabled" checkbox off and on again.

Debugging on a local debug build, I can't repro: I see the RenderFrameHostImpl::OnDispatchLoad occur reliably, but when it happens, the frame is not a pending RFH.

It could mean this is already fixed, or it could mean this it's timing sensitive, though I'm banking on the former.

Comment 3 by alex...@chromium.org, Apr 29 2016 

Could this be related to  issue 584845 ?  I.e., happening because of XFO/CSP denied?  My fix for that isn't in M50, so that would be consistent with Nick's observations.

Comment 4 by creis@chromium.org, May 2 2016 

Seems plausible-- Nick, can you confirm?

Alex, do you have any ideas what might be causing RFH_NO_PROXY_TO_PARENT other than that case?  We're still seeing these kills on Canary.  Maybe we can pursue that in a different bug, if this turns out to be a dupe of  issue 584845 .

Comment 5 by nick@chromium.org, May 2 2016

Mergedinto: 584845
Status: Duplicate (was: Untriaged)
Debugged it and yup, dupe of 584845.

Good to know that fixing layout test bugs leads to real world behavior improvements.
►

Sign in to add a comment