Possible memory leak on page reload

Issue #27 resolved
created an issue

It seems that current version of ChromiumFX leaks memory on every page reload.

VisualStudio 2013 Community,.NET 4.0 Client Profile, Windows 8.1 and 10.

You can try to reproduce this by launching a CfxTestApplication and then loading a page which continuously reloads itself (or by clicking on LoadUrl button several times).

Properly speaking:

  • start CfxTestApplication,
  • load a page that infinitely reloads itself via JavaScript,
  • monitor memory usage by the renderer process.

I've tried to reproduce this behavior using original CEF test application, cefclient.exe (pre-built binaries). Many of its versions leak too, but it seems that the test application from the latest stable CEF 3.2454.1308.g85e11f9 doesn't leak in the same conditins.

So I've tried to build ChromiumFX for CEF 3.2454.1308 by my own. I've launched CfxGenerator on the freshly downloaded CEF sources, updated CEF binaries, rebuilt ChromiumFX binaries and then ran CfxTestApplication again. Bad luck, the leak on reload continues.

Important: you should exactly reload the page, e.g. by location.reload();. Forward/backward navigation restarts renderer process which makes test useless.

I may be wrong, so could you please:

  • check whether the leak on reload is present or not,
  • properly build the ChromiumFX binaries for CEF 3.2454.*.

Thanks in advance.

Comments (13)

  1. wborgsm

    OK, render process climbs to ~ 1.6 GB, stays there for a while then crashes. This happens for Debug and Release builds, running without debugger attached (with attached debugger it just gets too slow).

    I think this might be memory waiting for GC. I am going to put GC.Collect() in some code paths executed regularly.

  2. wborgsm

    Had a thread looping and calling GC.Collect regularly, but to no avail. Still climbing to 1.6 GB. Previous memory leak problems had mostly to do with managed wrapper objects not releasing ref counted cef objects. But as a matter of fact, this test does not create that many managed wrapper objects in the render process.

  3. chge reporter

    Could you check that the newest stable cefclient.exe doesn't leak? I may be wrong and there could be leaks in CEF itself.

  4. wborgsm

    Could you check that the newest stable cefclient.exe doesn't leak? I may be wrong and there could be leaks in CEF itself.

    Yes of course, I also have to check if it is a problem with chromiumfx at all. This is a stress test requiring CEF to reload and repaint thousands of times.

    Btw, the "Remote layer stress test", which exercises much more of the chromiumfx api than the load test, doesn't seem to leak. Triggering it repeatedly, the memory can go up to > 400 MB, but then drops back regularly to < 100MB.

  5. wborgsm

    Ok, I created a test page as follows:

    <body onload='setTimeout(function(){ location.reload(); }, 500)'>
    This page reloads itself eternally. For testing only.
    <img src='api/icons/Help.png'>
    Lorem ipsum (...)

    It's location is http://chromiumfx.bitbucket.org/ with a filename of reloader dot html (I don't want this to be picked up by crawlers) and I am going to run that page for a while in cefclient and chromiumfx at the same time.

  6. wborgsm

    Ok, a few results:

    • Running this page from cefclient, the memory stabilizes quickly at about ~ 100 MB.
    • Running this page from chromiumfx test application, memory raises slowly but steadily. I cancelled the test after about half an hour with memory ~ 600 MB.
    • Disabling the remote layer in the chromiumfx test application (replace CfxRuntime.Initialize(settings, app, RenderProcess.RenderProcessMain) by CfxRuntime.Initialize(settings, app) in ProwserProcess.cs, the memory stabilizes quickly at the same level as cefclient.

    I think the reload crash test I added yesterday (commit 4abbff4) can be considered a case of library abuse and I am going to remove that.

    The slow but steady growth of memory disappears when the remote layer is disabled so there is my starting point for fixing this.

    In the meanwhile, this should not have too much impact on any reasonable client application embedding chromiumfx until it gets fixed.

  7. wborgsm

    Looks like the bug discovered through issue #29 and resolved in version 3.2357.5 uploaded today resolves this problem as well. Running the above test, the memory stabilizes below 200 MB. I left the test running for one and a half hours and everything was looking fine.

    The problem was a bug in the finalizer of the proxy objects in the browser process which caused the program to never release the corresponding objects in the render process.

    Can you confirm that this is fixed? You'd have to update again to 3.2454 starting from the new release, or you can just wait until I update this project to the 2454 branch (I'm waiting for a build for Chromium 45.0.2454.85 at Windows 64bit to show up at https://cefbuilds.com/).

  8. wborgsm

    Running the test in the 2454 branch for > 1 hour, with memory stabilizing at about ~150MB. This seems to be resolved.

    Thank you very much for pointing this out.

  9. Log in to comment