[Bug]: Memory problem

[FKlindt]

Version

Version 1.48.0

Steps to reproduce

Set up a new Playwright project.

Run the tests using npx playwright test --ui.

Observe the memory usage during test execution, especially on a machine with limited resources (e.g., 20GB RAM).

You should see the memory usage increase rapidly, especially if multiple tests are queued, leading to an "out of memory" error.

Expected behavior

The tests should execute normally without exhausting available memory. Chromium instances should close automatically after each test in UI mode, similar to non-UI mode, without building up in memory.

Actual behavior

Running tests in UI mode with npx playwright test --ui results in excessive memory usage. Chromium instances remain open after test execution, which causes the system to run out of memory (particularly noticeable on a machine with limited memory). This issue does not occur when running tests without UI mode, where Chromium instances close correctly after each test.

Additional context

The issue is only observed in UI mode. Running the same tests without UI mode does not cause high memory usage, and Chromium instances close as expected after each test. my config.txt

Environment

System: OS: Windows Server 2016 10.0.14393 CPU: (4) x64 Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz Memory: 13.43 GB / 20.00 GB Binaries: Node: 22.3.0 - ~\AppData\Local\nodejs\node.EXE npm: 10.8.1 - ~\AppData\Local\nodejs\npm.CMD IDEs: VSCode: 1.90.2 - C:\Program Files\Microsoft VS Code\bin\code.CMD npmPackages: @playwright/test: ^1.48.0 => 1.48.0 playwright: ^1.48.0 => 1.48.0 playwright-chromium: ^1.48.0 => 1.48.0 playwright-firefox: ^1.48.0 => 1.48.0

[dgozman]

@FKlindt I tried to reproduce on Windows 11 Enterprise with @playwright/test version 1.48.0, and the number of chrome.exe processes stays the same for me. Most likely, there is an issue on your particular computer, but I'm not sure we'll be able to help with that. I guess you could share a full repro with us, and we can try to reproduce locally, but the chances are not very high.

[FKlindt]

@dgozman Thanks for checking! Given that the issue seems specific to my environment, would you recommend any particular steps I could take to troubleshoot further? I'd be happy to share a full repro if that helps. Do you suggest anything else I can try to isolate the problem before submitting the repro?

[dgozman]

@FKlindt Perhaps try running the UI mode with DEBUG=pw:browser, click the "Toggle output" button in the top toolbar and see the browser logs there. Maybe that will tell us what's going on.

[louwsph]

Just in support of the author I am facing the same issue, it started after upgrading to 1.48.0. I've been using the tool for over a year on the same machine/OS and never observed the UI crash with 'out of memory' previously, it's occurring after running just 2 or 3 larger e2e tests in UI mode.

As far as I can see there is no increase in the number of chrome processes however memory usage on processes does seem to have increased compared with previous playwright versions for the same tests.

No idea if this will be of any value but here is a simple test I used to compare on a clean install of npx init playwright@latest using only 'Desktop Firefox' -

for (let index = 1; index <= 5; index++) {
  test(`get started link ${index}`, async ({ page }) => {
    await page.goto('https://playwright.dev/');
    await page.getByRole('link', { name: 'Get started' }).click();
    await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible();
    await page.getByRole('link', { name: 'Release notes' }).click();
    await expect(page.getByRole('heading', { name: 'Version 1.46' })).toBeVisible();
    await page.getByRole('link', { name: 'Locators', exact: true }).click();
    await expect(page.getByRole('heading', { name: 'Locating elements' })).toBeVisible();
  });
}

This doesn't push it to a crash but my actual tests when it fails are far heavier and longer running.

On 1.48.0 - (Spawned 8 Chromium processes upon launching UI)

Action	Total memory usage ~15 seconds after action
npx playwright test --ui	138mb
Run 1st test	321mb
Run 2nd test	487mb
Run 3rd test	565mb
Run 4th test	775mb
Run 5th test	875mb

On 1.45.3 - (Spawned 9 Chromium processes upon launching UI)

Action	Total memory usage ~15 seconds after action
npx playwright test --ui	174mb
Run 1st test	318mb
Run 2nd test	376mb
Run 3rd test	430mb
Run 4th test	484mb
Run 5th test	520mb

There is clearly freeing of memory happening after the test finishes but it seems like the amount freed has reduced so maybe that is contributing to the issue?

I could not see any difference that stood out comparing the output between versions with DEBUG=pw:browser enabled.

[FKlindt]

I've also noticed that the memory usage ramps up significantly with each test, much like your example. For me, running multiple UI tests results in similar behavior—memory usage climbs test by test until the system crashes, even though this didn't happen in earlier versions like 1.45.3.

It looks like this could be related to how memory is being freed or managed between tests in 1.48.0. I’ll keep monitoring and try running tests with different configurations, but it definitely feels like something changed with this version. Thanks for sharing your comparison—it helps confirm this issue!

[AndyGBC]

Also seeing 'out of memory' problems running a long running test since upgrading to 1.48.0. Rolled back to 1.47.2 and all OK again. I was just running from command line, so UI mode not in use here. Will try and find a repro....

[reager]

Also facing this issue since upgrading this morning.

[dgozman]

Should be fixed by linked PRs.

[notngan]

I've upgraded @playwright/test to v1.48.2 but the memory issue still remains.

Environment System: OS: macOS Sonoma 14.7 Chip: Apple M1 Pro Memory: 14.84 GB / 16 GB Binaries: Node: 16.10 pnpm: 7.33.6 IDEs: WebStorm 2024.2.4 npmPackages: @playwright/test: ^1.48.2 => 1.48.2

[ssougnez]

I'm having the exact same behavior with the version 1.49 on a windows 2022 build server. I reverted to version 1.47 and it went fine.

[nbaldzhiev]

I am on 1.49.1, intel MacBook Pro 2019, and using the VSCode's Playwright extension in browser mode instantly causes the CPU to peak. From the activity monitor, I can see that the Chromium processes drain it. So, it could be a matter of this new Chromium version, but my regular Chrome is updated as well, so I am more inclined to think it's Playwright/VSCode's Playwright extension.

[FKlindt]

Yup, I'm facing this issue. It only happens when I'm in the UI, so I can 'live' with it.

[coderyuyu]

same issue on 2025-3-14

[FranciscoKnebel]

Happening very frequently now. Almost always crashes when running a test for the 2nd time, so forced to close and reopen --ui mode after every test run.

[FKlindt]

Yes, there fix didnt work at all. Maybe i can reopen this issue?

[FKlindt]

@dgozman any chance you can reopen this?

[FranciscoKnebel]

Coming back to this issue because I found a way that solved it for me.

Out of memory crashes has been a recurring problem for me for the last couple of months. I noticed that if running npx playwright test --ui while also having --ui-port=8080 --ui-host=0.0.0.0 flags set (https://playwright.dev/docs/test-ui-mode#docker--github-codespaces), to open the UI mode in an external browser, those crashes stopped happening.

Hopefully this helps.

[ScarletMcLearn]

Facing similar issue: https://github.com/microsoft/playwright/issues/36337

[ScarletMcLearn]

@FKlindt please do give it a look and suggest if you faced your issue under similar conditions!

[FKlindt]

@ScarletMcLearn Yes, is pretty much the same issue. It still doesnt work for me proper. I have to run one test in the ui. Then close the UI and reopen it for another test. I am not able to run multible UI test, otherwise i will get that memory error.

I work on a DEV server so sometimes i even get the error when just running one test, if there are other devs, using a lot of memory.

I dont have permission to reopen the issue.

[ScarletMcLearn]

Thanks for the confirmation @FKlindt !

Please do comment on the new issue - the one I made - or upvote it to gain visibility.

Thank you!