cypress: New headless chrome randomly hangs at the end

This issue has been present as far back as v60 but got much worse in v112 (when we switched to the new headless=new), and has persisted all the way up to v121.0.6167.57 and beyond with some versions worse than others.

It’s intermittent and hard to verify sometimes, so many issues I’ve found about it on related projects have gotten closed as “cannot reproduce”. I’ve just confirmed it’s happening particularly consistently with v121 though, but I still can’t figure out why or when, as sometimes weird things like rebooting make it go away. I can post back here as I collect more reports on the latest versions.

There are also widespread reports of similar issues with the two telltale symptoms:

• chrome headless seeems to hang indefinitely on exit sometimes
• my [insert headless driver here] appears to have a memory leak (caused by chrome child processes hanging on exit and not releasing their memory)

Possibly related reports:

• https://support.google.com/chrome/thread/179100154/mac-os-chrome-hangs-on-exit?hl=en
• https://issues.chromium.org/issues/327458826
• https://github.com/puppeteer/puppeteer/issues/7922
• https://github.com/puppeteer/puppeteer/issues/1825
• https://forum.uipath.com/t/google-chrome-hangs-freezes-after-few-100-records/581107
• https://github.com/microsoft/playwright/issues/5327
• https://github.com/microsoft/playwright/issues/4218
• https://github.com/microsoft/playwright-python/issues/1074
• https://github.com/microsoft/playwright/issues/6319
• https://github.com/microsoft/playwright/issues/15400 (longstanding playwright issue caused by old chrome contexts not exiting properly and eating up memory, closed prematurely as you can see there are still recent comments about it happening)

It’s possible some of these issues ^ are unrelated, but it’s also possible they all stem from the same underlying issue of child chromium processes not exiting correctly.

The problem is widespread enough that many of the tools that use chrome headless have implemented hacky workarounds like this: https://devforth.io/blog/how-to-simply-workaround-ram-leaking-libraries-like-puppeteer-universal-way-to-fix-ram-leaks-once-and-forever/ (spawning chrome under a child process then doing killasgroup -9 after every run)

I tried again just for fun and managed to reproduce this on the first try!

I didn’t even add any of the extra args we usually use (--disable-gpu, --no-sandbox, --disable-features=dbus, etc.), it hung immediately on the first try with only --headless=new and --screenshot!

This dispelled the last of my doubts, I think this is 100% an upstream Chromium bug and has nothing to do with Cypress/Playwright/Puppeteer/ArchiveBox/any driver.

I just opened an upstream bug report on the Chromium bug tracker, follow over there for progress: https://issues.chromium.org/issues/327583144 👾

We have the same issue, will there be a fix in the future?

--headless=old also worked for us.

We did notice that peak memory usage was around 3.5 GB with new, whereas old uses about 2.4 GB. Our github actions runner has a 4GB resource limit. Perhaps chrome is running out of memory and is making cypress hang (pure guess).

We are using the following github actions config:

  test:
    runs-on: [self-hosted, prod]
    container:
      image: cypress/included:cypress-13.2.0-node-20.6.1-chrome-116.0.5845.187-1-ff-117.0-edge-116.0.1938.76-1
      options: --ipc=host

and the following cypress.config.ts:

  e2e: {
    setupNodeEvents(_on, _config) {
      _on('before:browser:launch', (browser, launchOptions) => {
        if (browser.name === 'chrome') {
          launchOptions.args.push('--disable-dev-shm-usage');
          launchOptions.args.push('--headless=old');
        }
        console.log(launchOptions.args);
        return launchOptions;
      });
    },