Blocked Render Process vs "--process-per-site" switch

Having problems with building or using CEF's C/C++ APIs? This forum is here to help. Please do not post bug reports or feature requests here.

Blocked Render Process vs "--process-per-site" switch

Postby JozefK » Tue Nov 07, 2017 11:47 am

Hi,
we have problem with "frozen/stuck" render process (blank/white window) on some machines, when applications is displaying more window with same origin(more browser processes vs 1 render process).
This problem is presented mostly on Windows 10 64bit and machines with 1 core (noticed also on CPU Intel Xeon v2 2,7 GHz - 2 cores)
CEF version: 3.2987.1601.gf035232_windows32 / chromium 57.0.2987.133
I'm are pretty sure it is related to chromium switch "--process-per-site"

Render Process is waiting for response from CefProcessHostMsg_GetNewBrowserInfo...

I try to describe what's goning on:

During the creation of new Browser instance -> there is registering BrowserInfo (which is defined by comination of ID RenderProcessID + RenderViewID)
This info is stored into BrowserInfoManager container. After Browser is created - LoadUrl is called, during this call another BrowserInfo is trying to stored/registered,
but on the IO thread a "moment" before the BrowseInfo is stored, render process send IPC message to obtain BrowserInfo for current Browser, CefBrowserInfoManager::GetInstance()->OnGetNewBrowserInfo(render_process_id_, render_view_routing_id, render_frame_routing_id, ... )
But in this moment the BrowserInfo with "requested combination of IDs" is not stored in BrowserInfoManager.
So render process is waiting for reply message and is stuck!!

Correct behavior on Win7:
--------------------------------------------------------------------------------
BrowserProcess: MainThread:
Browser is created
BrowserInfo with RenderProcesID = 3, RenderViewID=1 is stored
LoadUrl is called
BrowserInfo with RenderProcesID = 3, RenderViewID=1 is stored (duplication)
BrowserProcess : IO Thread is asking for BrowserInfo for RenderProcesID = 3, RenderViewID=1 -> browser info is returned - OK

Wrong behavior on Win10: OSBuild: 15063.632
--------------------------------------------------------------------------------
BrowserProcess: MainThread:
Browser is created
BrowserInfo with RenderProcesID = 3, RenderViewID=1 is stored
LoadUrl is called
BrowserInfo with RenderProcesID = 2, RenderViewID=4 is stored but due to lock for container it is not inserted !!!
BrowserProcess : IO Thread is asking for BrowserInfo for RenderProcesID = 2, RenderViewID=4 -> browser info is not returned - FAIL

I can see 2 possible problems:
1) Wrong Render Process ID generation
or
2) RaceCondition during storing pair od RenderProcessID into BrowserInfoManager container.

Is anybody fighting with similar issue?
Any help would be greatly appreciated!
We are using "--process-per-site" switch as a memory optimization. Removing of this cmd line switch will help. But we would like to save some memory.

Thanks
JozefK
Techie
 
Posts: 20
Joined: Mon Feb 27, 2017 3:24 pm

Re: Blocked Render Process vs "--process-per-site" switch

Postby aasmagarg » Mon Nov 20, 2017 4:32 am

We are also facing the same issue. While debugging, found out that the browser info is NULL and thats why it is not sending a response to the renderer process.
aasmagarg
Techie
 
Posts: 22
Joined: Sun Mar 20, 2016 11:42 pm

Re: Blocked Render Process vs "--process-per-site" switch

Postby magreenblatt » Mon Nov 20, 2017 4:10 pm

Only the default mode (process-per-site-instance) is supported/tested by CEF. You'll need to debug any issues yourself if you're using a different mode.
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: Blocked Render Process vs "--process-per-site" switch

Postby apte » Thu Jan 18, 2018 10:29 am

We have tried the following snippet in
Code: Select all
CefBrowserInfoManager::CreateBrowserInfo()

It seems to work.

Code: Select all
  // Continue any pending NewBrowserInfo requests.
  PendingNewBrowserInfoList::iterator it =
         pending_new_browser_info_list_.begin();
  for (; it != pending_new_browser_info_list_.end(); ) {
         PendingNewBrowserInfo* info = *it;
 
         bool is_guest_view = false;
 
         scoped_refptr<CefBrowserInfo> browser_info = GetBrowserInfo(
                info->render_process_id, info->render_view_routing_id,
                info->render_process_id, info->render_frame_routing_id,
                &is_guest_view);
 
         if (browser_info.get()) {
                // Send the response immediately.
                SendNewBrowserInfoResponse(info->render_process_id, browser_info.get(),
                        is_guest_view, info->reply_msg);
                it = pending_new_browser_info_list_.erase(it);
         }
         else
              ++it;
  }


This is already being done in
Code: Select all
CefBrowserInfoManager::CreatePopupBrowserInfo()
, but for some reason missing in the function CreateBrowserInfo().
This way, all the queued up requests from renderer are addressed and renderers are prevented from blocking.
magreenblatt - please give your inputs.
apte
Newbie
 
Posts: 2
Joined: Sat Oct 28, 2017 5:54 am

Re: Blocked Render Process vs "--process-per-site" switch

Postby magreenblatt » Thu Feb 01, 2018 5:43 pm

magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: Blocked Render Process vs "--process-per-site" switch

Postby lavv17 » Wed Sep 26, 2018 3:05 am

I have a similar problem with --process-per-site on linux (VM with single core), but it happens on closing a browser: another browser with the same site stops responding to input or window resize and JS seems to stop also; killing the helper process gives a zombie (i.e. the helper termination is not handled).
lavv17
Techie
 
Posts: 23
Joined: Tue May 22, 2018 8:50 am


Return to Support Forum

Who is online

Users browsing this forum: Google [Bot] and 49 guests