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

Issue 755558 link

Starred by 1 user

Issue metadata

Status: Duplicate
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug

Blocking:
issue 614281



Sign in to add a comment

Renderer kill 108 after renderer crash with pending download

Project Member Reported by alogvi...@yandex-team.ru, Aug 15 2017

Issue description

Chrome Version: Dev 61.0.3163.27
OS: Android

What steps will reproduce the problem?
(1) Go to about:flags and set "Enable browser side navigation (aka PlzNavigate)" to Disabled. Restart Chrome.
(2) Open attached web page using a local web server.
(3) Click "Big file" link. Grant download permissions and wait until the download is started.
(4) Trigger renderer crash by typing "about:crash" in the omnibox.
(5) Reload the page.
(6) Click on the "Trigger the problem" link.

What is the expected result?

Current tab's renderer does not crash.

What happens instead?

Current tab's renderer is killed with bad_message_reason 108.

The bad message kill is caused by GlobalRequestID collision in ResourceDispatcherHostImpl::pending_loaders_. When there is a pending download and the renderer crashes, the download continues and the request is not removed from pending_loaders_. When the renderer process is re-created after page reload, it starts issuing resource requests with the same child_id and request_id starts form the initial value. As soon as request_id reaches the one used by the pending download, ResourceDispatcherHostImpl sees that this (child_id, request_id) combination is already in use and kills the renderer in ResourceDispatcherHostImpl::BeginRequest with bad message reason 108 (RDH_INVALID_REQUEST_ID).

The problem is not reproduced with browser-side navigation (PlzNavigate) enabled.

All current chrome versions (stable, beta, dev, canary, public apk) are affected, provided that PlzNavigate is not enabled.
 
kill_108_repro_for_chrome.html
875 bytes View Download
It looks like RDHI::CancelRequestsForRoute specifically excludes download and stream requests from cancellation, so perhaps the scenario above is not the only possible one that leads to the the kill. Fundamentally, the problem is that child_id in GlobalRequestID is tied to RenderProcessHost (RenderProcessHostImpl::id_ which is const), not the actual render process. When one render process quits and another one replaces it, it is still the same child_id. When some requests outlive their source render process, they may collide with requests issued by the new render process for this RenderProcessHost.
Components: Internals>Network
Cc: mmenke@chromium.org csharrison@chromium.org
CC'ing a couple RDHI owners.
Blocking: 614281
Cc: creis@chromium.org nasko@chromium.org clamy@chromium.org
Awesome! This crash was a longstanding mystery and investigated in issue 614281 (Restrict-view-google unfortunately). Let me cc some folks from that bug.

We were hoping on just shipping PlzNavigate in M60 to fix this but the plans fell through. Still, we may just wait for it to launch in M61 rather than merging a fix for this bug.

Comment 5 by mge...@chromium.org, Aug 17 2017

Cc: -clamy@chromium.org
Mergedinto: 614281
Owner: clamy@chromium.org
Status: Duplicate (was: Untriaged)
Merging this into the other bug.

Comment 6 by nasko@chromium.org, Aug 17 2017

M61 is close enough, but PlzNavigate isn't yet guaranteed shipping on it. Still, I don't know if it is worthwhile fixing, unless the fix is trivial.

Sign in to add a comment