|
|
Rank: Member
Groups: Member
Joined: 6/12/2015
Posts: 20
|
I noticed a severe memory leak in the latest release 2015.1.84.0.
You can easily reproduce the memory leak in the last test project I e-mailed you guys early last week for the other bug.
If you look at the resources used by the RunDLL32.exe, everytime you call LoadUrl, memory increases significantly (for yahoo.com it eats up about 15MB everytime you call LoadUrl). The memory never seems to be released.
This is causing a significant memory issue on my Terminal Servers. Each user session is currently using nearly 1GB of memory compared to the normal 150MB used prior to me using EO.WebBrowser at all.
This is a serious issue.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,088
|
Hi,
We have looked into this issue. The issue seems to be related to Chrome's garbage collector and the memory will eventually released. During our test, the memory usage keeps climbing until it hits around 500M. Once it reaches there it will start to drop and hover around that mark. If that is an issue for you, you may want to destroy the WebView periodiacally.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/12/2015
Posts: 20
|
That seems about right, with the memory usage. Yes the memory usage is an issue due to the fact that i am using this in a Terminal Server environment, so 20-30 users running on the same server - the memory gets eaten up very quickly.
- The only reason this should be happening is if a resource variable is not being disposed and null'ed properly. Which is why the GC is having to come along and "clean up"
- Could their be a option to fire the Chrome GC from the EO.WebBrowser?
I will try to destroy/re-create the webview periodically as you suggest, but that is just putting a bandage on the problem.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,088
|
Hi,
While we do have the full source code, we do not have the capacity to fine tune Chrome's memory management or even add code to trigger GC manually ---- the project is simply too huge and it's beyond our capacity to do that level of customization. The rundll32.exe process that consumes the memory is the render process, which runs Chrome's JavaScript engine, local resource cache, DOM tree and rendering. All these parts have some kind of GC mechanism (JavaScript engine being the most extensive one). So in order to bring the memory usage down would requires a thorough visit to all these places, which would not be a practical option for us.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/12/2015
Posts: 20
|
Makes sense. I guess I should of pointed out that is is causing other issues as well. In particular, one of our TS servers is a x86 with 4GB of RAM, (so it maxes out on memory very quickly with this issue), and it causes crashes/bugs within the EO.Base.Runtime (see screen shot: https://www.triosoft.com/images/PART_1436276171270_IMG951815.jpg) - it also causes rendering issues (https://www.triosoft.com/images/PART_1436294234853_IMG959343.jpg , notice the fonts are not drawn correctly, it almost appears to be a bad picture, but it's actually how it appears)
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,088
|
Hi,
In that case you will need to try to either increase your system RAM or try to reduce the number of concurrent users that you can support. We have no magic bullet to modify Chrome to fit exactly what you need --- it is simply not doable to us and this is the reality we both have to face. Even if we managed to do that, most likely we will run into problems with other customers since they might be counting on Chrome's current optimization strategy for something else. As such our policy would be stay in sync with Chrome on such matters. Our primary goal is to allow you to integrate Chrome browser engine seamlessly into your application, not to modify the browser engine to fit every single unique scenarios. I hope you understand.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/12/2015
Posts: 20
|
I understand. However, I originally have been using IE's WebBrowser control for about 8 years now without ANY issues other than the JavaScript engine running "slow". The only reason I changed to EO.WebBrowser is because my application was rendering at a snails pace for JavaScript intense pages. Slowness is one thing, but crashes and major rendering issues due to memory leaks is a major issue.
I depend on EO.WebBrowser to be stable and reliable, just as IE's WebBrowser was. But as you can see by the two screen shots I provided in my last reply, stable and reliable is not what I am getting.
I understand you're essentially building a wrapper on Chromium and the source-code of Chromium may be where the issues are -- but then again, the latest version of Google Chrome Browser does not have these issues.
I am not asking you to "modify the browser engine to fit every single unique scenario" as you put it, I am simply asking for a stable and reliable product.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,088
|
We have been very clear and honest with you on various issues. There are issues that we will work on and there are issues that we will not work on. A memory tuning on the massive Chrome's browser engine is NOT something we will work on since we see a lot of risk and no benefit of doing so, precisely because it is both yours and ours best interest to maintain a stable product. Such task itself is a huge technical challenge that we might be biting off more than what we can chew if we do choose to do so, so it is not something we will get into. So please consider this as our final decision on this issue.
|
|
Rank: Member
Groups: Member
Joined: 6/12/2015
Posts: 20
|
Thank you. I was not suggesting you work on the Chrome side. My confusion is why this memory leak is not observed in the Google's version of Chrome.
I appreciate your honesty. I'd just feel better knowing you guys will put some sort of long-term effort to resolve the issue, maybe by submitting as a bug with the Chromium consortium, etc, rather than calling this "Case Closed".
I have confirmed that calling WebView.Destroy or .Close clears the memory usage. This works as a semi-work-around on my end for now, although in some situations this work-around is not a option for me.
Thank you again for your honesty and straight--forwardness.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,088
|
Thanks for understanding. The same memory behavior does occur with Google Chrome browser as well. If you start Google Chrome browser and load Yahoo's home page, then keep clicking the refresh button, you will see the memory usage of one of the Chrome.exe process keeps climbing --- eventually it will come down and stabilize, but it will take a while to reach that point. This is the same behavior you observed with our library.
|
|