BrowserContext has a memory leak perhaps.

Steps to reproduce

Tell us about your environment:

• Puppeteer version: 1.17.0
• Platform / OS version: Mac OS 10.14.5
• URLs (if applicable): no need
• Node.js version: v9.6.1

What steps will reproduce the problem?

Keep running the code below will cause memory raising slowly. It seams unusual and I don’t how to fix it.

const puppeteer = require('puppeteer');

puppeteer.launch({headless : false}).then(async browser => {

    while (true){

        let context = await browser.createIncognitoBrowserContext();
        await context.close();
    }
});

What is the expected result? The memory should be stable.

What happens instead? But it’s keeping raising.

[aslushnikov]

Ok, this took a while to figure.

Summary

This particular example is not a memory leak. This happens because DevTools protocol method Target.disposeBrowserContext completes before all browsercontext-related resources are freed. As a result, memory is allocated way faster than it is released.

Mitigation

The script is executing a synthetic scenario: usually each context hosts at least a single page it deals with which slows down context creation/disposal and gives enough time for memory disposal. In our tests, real world scenarios do not exhibit this memory starvation behavior.

In ideal world, we can instrument when browsercontext-related resources are getting freed. This is, however, a major engineering effort, that doesn’t worth investment given synthetic nature of the use case.

Investigation

We built a custom chromium version with instrumenting heap profiler for the browser process, and were able to do a few observations with this script:

(All of the memory observations below are done based on the reports of Instrumenting Heap Profiler)

1. If we just run the script, the memory allocated on the heap increases drastically.
2. If we stop issuing browser.createIncognitoBrowserContext() / browserContext.close() commands but keep the browser running, allocated memory is gradually getting freed.
3. If we slow down creation and destruction of browser contexts (basically, connecting puppeteer instance with the slowMo: 100 option), then the memory is stable.

We were also monitoring memory consumption with htop - which did not report any memory getting freed in (2). This turned out to be due to the fact that tcmalloc does not return claimed memory back to the system (source#1 and source#2).

This whole behavior seems to be provoked by the lazy initialization and lazy destructuring when creating/disposing browser contexts. Each context sets up a lot of bindings to different mojo components that are gradually destroyed later on. If we create/dispose contexts too fast, then memory is getting allocated faster than it is getting freed.

Afterwords

Chromium team is constantly fighting against memory leaks, but it’s impossible to eliminate them all given the massive Chromium complexity. Unlike renderer processes that are getting recreated, browser process is alive forever, and thus especially susceptible to leaks in the long-run.

Keep running the code below will cause memory raising slowly. It seams unusual and I don’t how to fix it.

@zebulonzh We were initially very frightened by the massive scale of the leak that your script demonstrated. However, investigation revealed that it’s not that bad. To sum up, leaks are likely to be in the browser process; I’d recommend restarting every once in a while if you run at scale.

We’re currently killing Puppeteer processes every hour to “solve” the issue.

@derrekyoung restarting browser instance every once in a while is a good thing to do if you run at scale.

Any other ideas for creating parallel browser contexts that behave like incognito sessions?

The only other thing you can do is to launch a whole new browser.

[derrekyoung]

Adding our confirmation of this bug as well. We’ll spin up 100s of parallel sessions and they’ll kill the VM with OOM. We’re currently killing Puppeteer processes every hour to “solve” the issue.

Any other ideas for creating parallel browser contexts that behave like incognito sessions?