Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There seems to be a limit on the number of ChromiumWebBrowser's that can be open at any given time #2419

Closed
ghost opened this issue Jun 13, 2018 · 8 comments
Milestone

Comments

@ghost
Copy link

ghost commented Jun 13, 2018

  • What version of the product are you using?
    Nuget 63.0.3

  • What architecture x86 or x64?
    x64

  • On what operating system?
    Win10

  • Are you using WinForms, WPF or OffScreen?
    WinForms

  • What steps will reproduce the problem?
    The commit of the CefSharp.MinimalExample fork below is an easy way of reproducing this issue.
    The implementation below has a TabControl that opens multiple tabs each with their own instance of the ChromiumWebBrowser with the help of a button. The webpage has a JavascriptObject Binding that simply calls a method in C# that returns a number and that number gets printed in the webpage console.log (as a Promise Object (see the statusLabel at the bottom of each page).

  1. Open the application and the task manager.

  2. Use the task manager to monitor the number of BrowserSubProcesses open.

  3. Press the open button to open tabs with ChromiumWebBrowsers inside (the screen should be blank but note the bottom of the screen where there should be a "Message: [object Promise]".
    image

  4. Open tabs until the number of BrowserSubProcesses in the task manager reaches 84.

  5. Open another tab, note that the number of SubProcesses does not increase and that the message at the bottom of the screen now show "Uncaught (in promise)".
    image

This issue has only started occurring after upgrading from CefSharp 57.0.0 to 63.0.3 and updating the bindings.

Note : If you provide a new RequestContext, the 84 limit can be surpassed but the application will crash after 110 chromium instances are opened.

This issue has been reproduced below and happens exactly the same way in the project I work on.

https://github.com/rajdevraj1/CefSharp.MinimalExample/commit/af5b205b142f78452f91b84177ad4a2d42910ff1

  • What is the expected output? What do you see instead?

I expect that the number of ChromiumInstances keeps increasing and that the Promises are fulfilled and Javascript Binding continues to work.

I apologies for the submission, this is the first time I have submitted an issue. I am free to answer anymore questions to attempt to solve this.

  • Please provide any additional information below.

    • A stack trace if available, any Exception information.

    • Does the cef log provide any relevant information? (By default there should be a debug.log file in your bin directory)

    • Any other background information that's relevant? Are you doing something out of the ordinary? 3rd party controls?

  • Does this problem also occur in the CEF Sample Application from http://opensource.spotify.com/cefbuilds/index.html?

    • To compare with WPF run cefclient --multi-threaded-message-loop --off-screen-rendering-enabled
    • To compare with WinForms run cefclient --multi-threaded-message-loop
    • If you can reproduce the problem with cefclient then you'll need to report the bug on https://bitbucket.org/chromiumembedded/cef/overview there is no point opening an issue here. (Make sure you search before opening an issue)
    • Please include the version you tested with e.g. cef_binary_3.3029.1611.g44e39a8_windows64_client.tar.bz2
  • Does this problem also occur in the CEF Sample Application from http://opensource.spotify.com/cefbuilds/index.html?

    • To compare with WPF run cefclient --multi-threaded-message-loop --off-screen-rendering-enabled
    • To compare with WinForms run cefclient --multi-threaded-message-loop
    • If you can reproduce the problem with cefclient then you'll need to report the bug on https://bitbucket.org/chromiumembedded/cef/overview there is no point opening an issue here. (Make sure you search before opening an issue)
    • Please include the version you tested with e.g. cef_binary_3.3029.1611.g44e39a8_windows64_client.tar.bz2
@welcome
Copy link

welcome bot commented Jun 13, 2018

Welcome! If you're reporting a bug, please make sure you have completed the bug report template see https://github.com/cefsharp/CefSharp/blob/master/ISSUE_TEMPLATE.md#bug-report. Please make sure you provide enough detail that someone else can reproduce the issue you are experiencing.
We prefer to keep this issue track just for bug reports. If you have a question or need help with something I'd ask that you self close this issue and have a read over https://github.com/cefsharp/CefSharp/blob/master/ISSUE_TEMPLATE.md it contains background information, details on where to ask your questions (hint, Gitter is one such place)
It's also reportant to remember that CefSharp is just a wrapper around the Chromium Embedded Framework(CEF), a lot of questions people have aren't actually CefSharp specific, they're generic to CEF and for those CEF has it's own support forum at http://magpcss.org/ceforum/index.php and issue tracker at https://bitbucket.org/chromiumembedded/cef

@amaitland
Copy link
Member

There is a limit to the number of renderer processes that Chromium will create. This prevents the browser from overwhelming the user's computer with too many processes. The limit is is proportional to the amount of memory on the computer, and may be as high as 80 processes. Because of the limit, a single renderer process may be dedicated to multiple sites. This reuse is currently done at random, but future versions of Chromium may apply heuristics to more intelligently allocate sites to renderer processes.

CefSharp now uses the default Chromium process model which limits render processes to 80, see https://www.chromium.org/developers/design-documents/process-models#Caveats

The new Javascript Binidng implementation is currently limited in how it stores objects, using a RequestContext will get around this to some degree, at some point this limitation will be removed see #2306

I expect that the number of ChromiumInstances keeps increasing and that the Promises are fulfilled and Javascript Binding continues to work.

How many were you able to open in 57? From memory Windows also has limits on the number of child processes an application can spawn. It's unrealistic to think you can open an infinite number of browser instances.

the application will crash after 110 chromium instances are opened.

Please post the stack trace.

@lukecaan
Copy link

Getting the same issue, finding that when it gets to 110 processes it crashes.

Important for us because we want to have as many separate browser sessions as possible running on servers in the cloud.

I only started learning CefSharp / Chromium yesterday, but do you think it's reasonably fixable @amaitland ?

Just tried going back to 57 and was able to get 300+ browsers side-by-side

@amaitland
Copy link
Member

Without a stack trace I couldn't even speculate.

@ghost
Copy link
Author

ghost commented Jun 15, 2018

Hey @amaitland,

Just to clarify without a new 'RequestContext' I can only ever open about 80 browser instances that successfully bind to the JavascriptBinding, if I provide my own context I can continue opening more instances with successful binding but the app crashes at exactly 110 instances of the browser.

I have tried to get the stack trace for the crash but I am having issues, the app I created (repository of which is in the original post above) to test this issue and report it crashes uncleanly. I can't even reattach the debugger successfully.

I have also attempted to follow the following link unmanaged-crashes-when-the-process-dies to get some sort of stack trace, but I am having trouble doing this (I am sure I can get it to work eventually).

Is there something I am missing, should I be able to retrieve the stack trace?

/edit - On 57.0.0 I was able to open as many tabs as I wanted,

Thank you so much for your help!

@ghost
Copy link
Author

ghost commented Jun 18, 2018

@lukecaan Have you managed to get a strack trace?

@ghost
Copy link
Author

ghost commented Jun 20, 2018

According to a chap on gitter (plinehan) there was some issue with the symbols for CEF on the nuget package of CEFSharp 63 and that was the reason I wasn't able to load the symbols to get a stack trace. The suggestion was to either compile CEFSharp locally or to simply use the pre-release version to load the symbols.

This problem is somehow fixed in CEFSharp 65.0.0 Pre-Release, providing a RequestContext to each browser instance seems to make it so that I can open as many Browser instances as I wish (@lukecaan)!!

In terms of the stack trace (@amaitland) it doesn't seem like I can do much about it now. I am trying to build my own nuget packages for CEFSharp 63 and will slowly continue doing that to see if I can figure something out.

@amaitland
Copy link
Member

This problem is somehow fixed in CEFSharp 65.0.0 Pre-Release, providing a RequestContext to each browser instance seems to make it so that I can open as many Browser instances as I wish (@lukecaan)!!

Great 👍 Thanks for confirming. Closing this issue as unable to reproduce in the latest version.

In terms of the stack trace (@amaitland) it doesn't seem like I can do much about it now. I am trying to build my own nuget packages for CEFSharp 63 and will slowly continue doing that to see if I can figure something out.

The only change I'm aware of related to JSB that made it into 65.0.0-pre01 is f6e5828

Unless someone is prepared to sponsor the development there will be no further updates to the cefsharp/63 branch. Upgrading to the latest 65.0.0-pre01 or newer is the suggested solution.

@amaitland amaitland added this to the 65.0.0 milestone Jun 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants