New issue
Advanced search Search tips

Issue 875215 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Race in browser process caused by reload after renderer shutdown

Project Member Reported by u...@chromium.org, Aug 17

Issue description

Some components in the browser process assume that RenderProcessHost::GetID() is the unique identifier of the renderer process. They use the identifier as the key in internal data-structures. When the renderer process is shut down and its tab is reloaded, the new renderer process gets the same identifier because the RenderProcessHost object stays the same. 

This creates a race between the removal of the old entry from the internal data-structure and the insertion of a new entry with the same key. This is because the removal is triggered by Mojo detecting that the pipe to the old renderer is broken (mojo::core::NodeChannel::OnChannelError), which is not guaranteed to happen before the new renderer is created.

Steps to reproduce:
1) Apply this CL that delays detection of closed Mojo pipes by 4 seconds.
https://chromium-review.googlesource.com/c/chromium/src/+/1174728

2) Run
out/Release/chrome  --js-flags="--max-old-space-size=400" --enable-blink-features=BloatedRendererDetectionSkipUptimeCheck,BloatedRendererDetection https://ulan.github.io/misc/bloated_renderer_demo.html

3) Click 'Go' button on the web page.

4) Wait until the web page is reloaded. The following error will appear in the stderr:

[67748:67757:0814/184109.711342:ERROR:browser_gpu_memory_buffer_manager.cc(135)] Child process attempted to allocate a GpuMemoryBuffer with an existing ID

 
Blocking: 808143
Description: Show this description
Cc: sadrul@chromium.org
Components: Internals>GPU>Internals
Labels: OS-Android OS-Linux OS-Mac OS-Windows

Sign in to add a comment