BrowserSubprocess memory leak + crash.

[jsoldi]

Steps to reproduce:

• Download latest stable version (57).
• Run WinForms.Example (either x32 or x64, both have the same issue)
• Visit: https://www.kaggle.com/anirudh796/nyc-ride-time-prediction-eda-machine-learning

Then just keep an eye on BrowserSubprocess.exe on the taskbar. It'll quickly reach close to 2 GB (or 4 GB on x64) and then just stop responding. Same URL on Chrome, Firefox and Edge open fine.

I'm using Windows 10 in case that makes a difference.

I'm willing to test this on CEF except I've no idea how to. Is there any CEF exe I can download without having to build so I can confirm whether the leak occurs there or not?

[dandotevans]

I have observed similar results when using 57. Making the 32 bit app large address aware or compiling as 64 bit prevented crashes in my case but pages that produce a lot of garbage quickly used up memory. I traced this to garbage collection settings within chrome that were relaxed to improve performance between versions 53 and 59. I was able to reproduce the issues directly in the chrome browser with these versions. chrome 60 the GC settings were reverted and the issue when testing had resolved for my test case.

[jankurianski]

I'm willing to test this on CEF except I've no idea how to. Is there any CEF exe I can download without having to build so I can confirm whether the leak occurs there or not?

Yes, in the issue template see "Does this problem also occur in the CEF Sample Application from ..."

First try the same version (57), and then try newer versions to see if the problem is fixed. Let us know how you go.

[jsoldi]

Here are my results:

+--------------------------------+----------------+--------+
|          CEF Version           | Chrome Version | Result |
+--------------------------------+----------------+--------+
| 3.3202.1680.g700054b_windows64 |   62.0.3202.75 | GOOD   |
| 3.3202.1674.g2a991c4_windows64 |   62.0.3202.62 | GOOD   |
| 3.3163.1671.g700dc25_windows64 |   61.0.3163.91 | BAD    |
| 3.3163.1671.g700dc25_windows32 |   61.0.3163.91 | BAD    |
| 3.3112.1659.gfef43e0_windows64 |  60.0.3112.113 | BAD    |
| 3.3112.1649.g0dba8a1_windows64 |   60.0.3112.78 | BAD    |
| 3.2987.1601.gf035232_windows64 |  57.0.2987.133 | BAD    |
| 3.2840.1493.g4e029f4_windows64 |   54.0.2840.59 | BAD    |
| 3.2785.1485.g2b5c3a7_windows64 |  53.0.2785.116 | GOOD   |
| 3.2785.1466.g80e473e_windows64 |   53.0.2785.70 | GOOD   |
| 3.2743.1439.g7cf8c6f_windows64 |   52.0.2743.60 | GOOD   |
| 3.2704.1414.g185cd6c_windows64 |   51.0.2704.47 | GOOD   |
+--------------------------------+----------------+--------+

I think dandotevans is correct, except the error starts occurring as soon they switch to Chromium 54 and keeps occurring on 60 and 61. The difference between GOOD and BAD is very noticeable. Good ones won't use more than about 300 MB, while bad ones will quickly reach 2-3 GB and crash.

To confirm the problem is with Chromium and not CEF, I found an older version of Chromium (61.0.3153.0) here where it also crashed. Then I tested it on the latest version (62.0.3202.62) which I got here and worked fine, so I guess they fixed it somewhere in between.

I wonder if there is some kind of workaround (some setting related to GC) other than going back to CefSharp 53.

Update: Tested it on CEF 3.3202.1674, which is the earliest version that uses Chrome 62, and on 3.3202.1680 and both worked (see table).

[perlun]

@jsoldi Thanks for a high-quality analysis of the problem, it really helps! 👏

I would suggest trying with the latest master version of CefSharp now, since it includes #2203, it will give you a CEF version 62. Does it exhibit the same behavior or does it work better now? We intend to release this as a 62.0.0-prerelease very soon now; please bear with us for some time more.

(I think this hits WPF also actually, we have seen issues there with CefSharp 57.0.0 at my employer. In that case though, we managed to find a workaround by tweaking the application a bit.)

[chylex]

62 definitely resolved the issue. In 57, I had to resort to exposing window.gc and then reloading the browser whenever RAM usage got too high (which happened about once every 8 hours).

[jsoldi]

@perlun Yes, it works great on the 62 pre-release. Didn't use more than 200 MB.

[amaitland]

Closing this as the upstream issue has been resolved.

[EgleMir]

Hi, mine isn't an answer to the question, but I have the same problem and I wanted to know if or how to solve it. I was forced to use version 75 by my corporate, and I compiled CEF branch 3770 with .mp4 support with success. I have my renderer with CefSharp and recompiled CEF working. Info : Version Info - CefSharpVersion: 75.1.143.0, CefVersion: r75.1.14+gc81164e+chromium-75.0.3770.100, ChromiumVersion: 75.0.3770.100
But one of the CefSharp.BrowserSubprocess.exe increases memory usage and never releases it while browsing until the crash. What are the methods to avoid it.
Thanks, regards
Egle