-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Comments
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. |
The new
How many were you able to open in
Please post the stack trace. |
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 |
Without a stack trace I couldn't even speculate. |
Hey @amaitland, Just to clarify without a new 'RequestContext' I can only ever open about 80 browser instances that successfully bind to the 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! |
@lukecaan Have you managed to get a strack trace? |
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. |
Great 👍 Thanks for confirming. Closing this issue as unable to reproduce in the latest version.
The only change I'm aware of related to Unless someone is prepared to sponsor the development there will be no further updates to the |
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
orOffScreen
?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).
Open the application and the task manager.
Use the task manager to monitor the number of BrowserSubProcesses open.
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]".
Open tabs until the number of BrowserSubProcesses in the task manager reaches 84.
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)".
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
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?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)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?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)cef_binary_3.3029.1611.g44e39a8_windows64_client.tar.bz2
The text was updated successfully, but these errors were encountered: