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

Issue 724275 link

Starred by 3 users
Status: Assigned
Owner:
clamy@chromium.org
Cc:
jam@chromium.org
clamy@chromium.org
creis@chromium.org
█ nasko@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 705744


Sign in to add a comment

PlzNavigate: Avoid leaks if renderer does not request stream URL after CommitNavigation

Project Member Reported by creis@chromium.org, May 18 2017 
I haven't confirmed if this is an actual leak yet or not, but I'm not sure if we have code to handle it.

PlzNavigate normally sends a CommitNavigation IPC to the renderer and expects it to request a stream URL in response.  It's possible for the renderer process to ignore the IPC and never request the stream URL, though.  For example, the interrupted_by_client_redirect may kick in for a subframe history navigation that gets preempted by a JS navigation in the frame, as we found in https://codereview.chromium.org/2890613002/#msg15.

If this happens, is there any way for the browser process to find out and not leave the stream lying around forever?  Maybe it will go away when the renderer exits?  (Ideally we could clean it up without waiting that long.)

Comment 1 by creis@chromium.org, May 31 2017

Components: Internals>Network
Owner: clamy@chromium.org
Status: Assigned (was: Untriaged)
clamy@: Can you confirm whether there's a leak here and see if we need to fix it?

I was concerned this might prevent future navigations to the same URL (similar to interstitials), but thankfully that doesn't seem to be the case.  Still, a leak of the network request would be concerning.

Comment 2 by clamy@chromium.org, Jun 1 2017 

Before the stream is requested by the renderer, its lifetime is controlled by a StreamHandle owned by the RenderFrameHost. Right now it's only cleaned when the RFH is destroyed or we do a new navigation. This is not ideal, but this shouldn't lead to a URLRequest leak. We can try to improve the situation, though I'm worried about edge cases where we release the stream while the renderer wants to claim it. Also note that we plan to switch to a Mojo stream soon, which should hopefully help with this issue.

Comment 3 by jam@chromium.org, Jun 23 2017

Blockedon: 705744
►

Sign in to add a comment