Fuite

A tool for finding memory leaks in web apps

Performance
nolanlawson/fuitefuite

README

fuite


fuite _/fɥit/_ French for "leak"


fuite is a CLI tool for finding memory leaks in web apps.

Introductory blog post

Tutorial video

Usage


  1. ```shell
  2. npx fuite https://example.com
  3. ```

This will check for leaks and print output to stdout.

By default, fuite will assume that the site is a client-rendered webapp, and it will search for internal links on the given page. Then for each link, it will:

1. Click the link
2. Press the browser back button
3. Repeat to see if the scenario is leaking

For other scenarios, see scenarios.

How it works


fuite launches Chrome using Puppeteer, loads a web page, and runs a scenario against it. It runs the scenario some number of iterations (7 by default) and looks for objects that leaked 7 times (or 14 times, or 28 times). This might sound like a strange approach, but it's useful for cutting through the noise in memory analysis.

fuite looks for the following leaks:

- Objects (captured with Chrome heap snapshots)
- Event listeners
- DOM nodes (attached to the DOM – detached nodes will show under "Objects")
- Collections such as Arrays, Maps, Sets, and plain Objects

The default scenario clicks internal links because it's the most generic scenario that can be run against a wide variety of SPAs, and it will often catch leaks if client-side routing is used.

Options


  1. ```
  2. Usage: fuite [options] <url>

  4. Arguments:
  5.   url                        URL to load in the browser and analyze

  7. Options:
  8.   -o, --output <file>        Write JSON output to a file
  9.   -i, --iterations <number>  Number of iterations (default: 7)
  10.   -s, --scenario <scenario>  Scenario file to run
  11.   -S, --setup <setup>        Setup function to run
  12.   -H, --heapsnapshot         Save heapsnapshot files
  13.   -d, --debug                Run in debug mode
  14.   -p, --progress             Show progress spinner (use --no-progress to disable)
  15.   -b, --browser-arg <arg>    Arg(s) to pass when launching the browser
  16.   -V, --version              output the version number
  17.   -h, --help                 display help for command
  18. ```

URL


fuite

The URL to load. This should be whatever landing page you want to start at. Note that you can use [--setup](#setup) for a custom setup function (e.g. to log in with a username/password).

Output


-o, --output

fuite generates a lot of data, but not all of it is shown in the CLI output. To dig deeper, use the --output option to create a JSON file containing fuite's analysis. This contains additional information such as the line of code that an event listener was declared on.

Anything that you see in the CLI, you can also find in the output JSON file.

Iterations


-i, --iterations

By default, fuite runs 7 iterations. But you can change this number.

Why 7? Well, it's a nice, small, prime number. If you repeat an action 7 times and some object is leaking exactly 7 times, it's pretty unlikely to be unrelated. That said, on a very complex page, there may be enough noise that 7 is too small to cut through the noise – so you might try 13, 17, or 19 instead. Or 1 if you like to live dangerously.

Scenario


--scenario

The default scenario is to find all internal links on the page, click them, and press the back button. You can also define a scenario file that does whatever you want:

  1. ```bash
  2. fuite --scenario ./myScenario.mjs https://example.com
  3. ```

Your myScenario.mjs can export several async functions, most of which are optional.

Here is a template:

  1. ```js
  2. // myScenario.mjs

  4. /**
  5. * OPTIONAL: Setup code to run before each test
  6. * @param { import("puppeteer").Page } page
  7. */
  8. export async function setup(page) {
  9. }

  11. /**
  12. * OPTIONAL: Code to run once on the page to determine which tests to run
  13. * @param { import("puppeteer").Page } page
  14. */
  15. export async function createTests(page) {
  16. }

  18. /**
  19. * REQUIRED: Run a single iteration against a page – e.g., click a link and then go back
  20. * @param { import("puppeteer").Page } page
  21. * @param { any } data
  22. */
  23. export async function iteration(page, data) {
  24. }

  26. /**
  27. * OPTIONAL: Teardown code to run after each test
  28. * @param { import("puppeteer").Page } page
  29. */
  30. export async function teardown(page) {
  31. }

  33. /**
  34. * OPTIONAL: Code to wait asynchronously for the page to become idle
  35. * @param { import("puppeteer").Page } page
  36. */
  37. export async function waitForIdle(page) {
  38. }
  39. ```

You can delete any optional functions you don't need.

Note that your scenario file can also extend the default scenario.

setup function (optional)


The async setup function takes a Puppeteer [Page][] as input and returns undefined. It runs before each iteration, or before createTests. This is a good place to log in, if your webapp requires a login.

If this function is not defined, then no setup code will be run.

Note that there is also a [--setup flag](#setup). If defined, it will override the setup function defined in a scenario.

createTests function (optional)


The async createTests function takes a Puppeteer [Page][] as input and returns an array of _test data objects_ representing the tests to run, and the data to pass for each one. This is useful if you want to dynamically determine what tests to run against a page (for instance, which links to click).

If createTests is not defined, then the default tests are [{}] (a single test with empty data).

The basic shape for a test data object is like so:

  1. ```json
  2. {
  3.   "description": "Some human-readable description",
  4.   "data": {
  5.     "some data": "which is passed to the test"
  6.   }
  7. }
  8. ```

For instance, your createTests might return:

  1. ```json
  2. [
  3.   {
  4.     "description": "My test 1",
  5.     "data": { "foo": "foo" }
  6.   },
  7.   {
  8.     "description": "My test 2",
  9.     "data": { "foo": "bar" }
  10.   }
  11. ]
  12. ```

iteration function (required)


The async iteration function takes a Puppeteer [Page][] and _iteration data_ as input and returns undefined. It runs for each iteration of the memory leak test. The _iteration data_ is a plain object and comes from the createTests function, so by default it is just an empty object: {}.

Inside of an iteration, you want to run the core test logic that you want to test for leaks. The idea is that, at the beginning of the iteration and at the end, the memory _should_ be the same.  So an iteration might do things like:

- Click a link, then go back
- Click to launch a modal dialog, then press the Esc key
- Hover to show a tooltip, then hover away to dismiss the tooltip
- Etc.

The iteration assumes that whatever page it starts at, it ends up at that same page. If you test a multi-page app in this way, then it's extremely unlikely you'll detect any leaks, since multi-page apps don't leak memory in the same way that SPAs do when navigating between routes.

teardown function (optional)


The async teardown function takes a Puppeteer [Page][] as input and returns undefined. It runs after each iteration, or after createTests.

If this function is not defined, then no teardown code will be run.

waitForIdle function (optional)


The async waitForIdle function takes a Puppeteer [Page][] and should resolve when the page is considered "idle."

Here is an example idle check:

  1. ```js
  2. export async function waitForIdle(page) {
  3.   await new Promise(resolve => setTimeout(resolve, 2000)) // wait 2 seconds
  4.   await page.waitForSelector('#my-element') // wait for element
  5. }
  6. ```

If this function is not defined, then the default idle check is used. The default is based on heuristics, using the network idle and main thread idle.

Setup


--setup

The --setup option can define a custom setup function, which runs immediately after the page is loaded, but before any other scenario code.

For instance, you can use --setup to log in with a username/password. To do so, first create a file called mySetup.mjs:

  1. ```js
  2. export async function setup (page) {
  3.   await page.type('#username', 'myusername');
  4.   await page.type('#password', 'mypassword');
  5.   await page.click('#submit');
  6. }
  7. ```

Then pass it in:

  1. ```shell
  2. npx fuite https://example.com --setup ./mySetup.mjs
  3. ```

The [setup function](#setup-function-optional) defined here is the same one that you can define in a custom scenario using [--scenario](#scenario) (i.e. it takes a Puppeteer [Page][] as input).

If both --scenario and --setup are defined, then --setup will override the setup function in the scenario.

Heap snapshot


      -H, --heapsnapshot         Save heapsnapshot files

By default, fuite doesn't save any heap snapshot files that it captures (to avoid filling up your disk with large files). If you use the --heapsnapshot flag, though, then the files will be saved in the /tmp directory, and the CLI will output their location. That way, you can inspect them and load them into the Chrome DevTools memory tool yourself.

Debug


      -d, --debug                Run in debug mode

Debug mode lets you drill in to a complex scenario and debug it yourself using the Chrome DevTools. The best way to run it is:

  1. ```shell
  2. NODE_OPTIONS=--inspect-brk fuite --debug <url>
  3. ```

(Note that NODE_OPTIONS will _not_ work if you run npx fuite. So you have to install fuite locally or globally, e.g. using npm i -g fuite.)

Then navigate to chrome:inspect in Chrome, click "Open dedicated DevTools for Node," and now you are debugging fuite itself.

This will launch Chrome in non-headless mode, and it will also automatically pause before running iterations and afterwards. That way, you can open up the Chrome DevTools and analyze the scenario yourself, take your own heap snapshots, etc.

Progress


    -p, --progress             Show progress spinner (use --no-progress to disable)

Enable or disable the progress spinner while the test runs. It's true by default, so you should use --no-progress to disable.

Browser args


-b, --browser-arg Arg(s) to pass when launching the browser

This allows you to pass args (aka flags) into Puppeteer when launching the browser. You can define multiple args,
and they are passed ver batim to [Puppeteer's launch args option](https://pptr.dev/#?product=Puppeteer&version=v13.0.1&show=api-puppeteerlaunchoptions).

For example:

  1. ```shell
  2. fuite <url> -b --use-fake-device-for-media-stream -b --enable-experimental-web-platform-features
  3. ```

JavaScript API


fuite can also be used via a JavaScript API, which works similarly to the CLI:

  1. ```js
  2. import { findLeaks } from 'fuite';

  4. const results = findLeaks('https://example.com', {
  5.   scenario: scenarioObject,
  6.   iterations: 7,
  7.   heapsnapshot: false,
  8.   debug: false,
  9.   progress: true,
  10.   browserArgs: ['--use-fake-device-for-media-stream']
  11. });
  12. for await (const result of results) {
  13.   console.log(result);
  14. }
  15. ```

Note that findLeaks returns an async iterable.

This returns the same output you would get using `--output ` in the CLI – a plain object describing the leak. The format of the object is not fully specified yet, but a basic shape can be found in [the TypeScript types](https://github.com/nolanlawson/fuite/blob/master/types/index.d.ts).

Options


The options for findLeaks are basically the same as for the CLI. The only differences between the JavaScript API and the CLI are:

- scenario takes an object with keys setup, createTests, and iteration rather than a filename (see Scenario object and Extending the default scenario below).
- setup is not supported – use scenario instead.
- signal can be used to cancel the test (see Cancel the test below).

Cancel the test


You can pass in an [AbortSignal](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) as the signal option to cancel the test on-demand:

  1. ```js
  2. const controller = new AbortController();
  3. const { signal } = controller;
  4. findLeaks('https://example.com', { signal });

  6. // Later
  7. controller.abort();
  8. ```

Scenario object


For the JavaScript API, you can pass in a custom scenario as a plain object. First, define it:

  1. ```js
  2. const myScenario = {
  3.   async setup(page) { /* ... */ },
  4.   async createTests(page) { /* ... */ },
  5.   async iteration(page, data) { /* ... */ },
  6.   async teardown(page) { /* ... */ }
  7. };
  8. ```

Then pass it in:

  1. ```js
  2. import { findLeaks } from 'fuite';

  4. for await (const result of findLeaks('https://example.com', {
  5.   scenario: myScenario
  6. })) {
  7.   console.log(result);
  8. }
  9. ```

If scenario is undefined, then the default scenario will be used.

Extending the default scenario


If you're writing your own custom scenario, you can also extend the default scenario. For instance, if you want the default scenario, but to be able to log in with a username and password first:

  1. ```js
  2. import { defaultScenario, findLeaks } from 'fuite';

  4. const myScenario = {
  5.   ...defaultScenario,
  6.   async setup(page) {
  7.     await page.type('#username', 'myusername')
  8.     await page.type('#password', 'mypassword')
  9.     await page.click('#submit')
  10.   }
  11. };

  13. for await (const result of findLeaks('https://example.com', {
  14.   scenario: myScenario
  15. })) {
  16.   console.log(result);
  17. }
  18. ```

Note that the above works if you're using the JavaScript API. For the CLI, you probably want to use [the --setup flag](#setup).

Limitations


fuite focuses on the main frame of a page. If you have memory leaks in cross-origin iframes or web workers, then the tool will not find those.

Similarly, fuite measures the JavaScript heap size of the page, corresponding to what you see in the Chrome DevTool's Memory tab. It ignores the size of native browser objects.

fuite works best when your source code is unminified. Otherwise, the class names will show as the minified versions, which can be hard to debug.

fuite may use a lot of memory itself to analyze large heap snapshot files. If you find that Node.js is running out of memory, you can run something like:

NODE_OPTIONS=--max-old-space-size=8000 fuite

The above command will provide 8GB of memory to fuite. (Note that NODE_OPTIONS will not work if you run npx fuite; you have to run fuite directly, e.g. by running npm i -g fuite first.)

FAQs


The results seem wrong or inconsistent.

Try running with --iterations 13 or --iterations 17.  The default of 7 iterations is decent, but it might report some false positives.

It says I'm leaking 1kB. Do I really need to fix this?

Not every memory leak is a serious problem. If you're only leaking a few kBs on every interaction, then the user will probably never notice, and you'll certainly never hit an Out Of Memory error in the browser. Your ceiling for "acceptable leaks" will differ, though, depending on your use case. E.g., if you're building for embedded devices, then you probably want to keep your memory usage much lower.

It says my page's memory grew, but it also said it didn't detect any leaks. Why?

Web pages can grow memory for lots of reasons. For instance, the browser's JavaScript engine may JIT certain functions, taking up additional memory. Or the browser may decide to use certain internal data structures to prioritize CPU over memory usage.

The web developer generally doesn't have control over such things, so fuite tries to distinguish between browser-internal memory and JavaScript objects that the page owns. fuite will only say "leak detected" if it can actually give some actionable advice to the web developer.

How do I debug leaking event listeners?

Use the --output command to output a JSON file, which will contain a list of event listeners and the line of code they were declared on. Otherwise, you can use the Chrome DevTools to analyze event listeners:

- Open the DevTools
- Open the Elements panel
- Open Event Listeners
- Alternatively, run getEventListeners(node) in the DevTools console

How do I debug leaking collections?

fuite will analyze your leaking collections and print out a stacktrace of which code caused the increase –
for instance, pushing to an Array, or seting a Map. So this is the first place to look.

If you have sourcemaps, it will show the original source. Otherwise, it'll show the raw stacktrace.

Sometimes more than one thing is increasing the size, and not every increase is at fault (e.g. it deletes right after).
In those cases, you should use --output and look at the JSON output to see the full list of stacktraces.

In some other cases, fuite is not able to track increases in collections. (E.g. the object disallows modifications, or the code uses Array.prototype.push.call() instead of .push()ing directly.)

In those cases, you may have to do a manual analysis. Below is how you can do that.

First, run fuite in debug mode:

    NODE_OPTIONS=--inspect-brk fuite https://example.com --debug

Then open chrome:inspect in Chrome and click "Open dedicated DevTools for Node." Then, when the breakpoint is hit, open the DevTools in Chromium (the one running your website) and click the "Play" button to let the scenario keep running.

Eventually fuite will give you a breakpoint in the Chrome DevTools itself, where you have access to the leaking collection (Array, Map, etc.) and can inspect it.

It will also give you debugger breakpoints on when the collection is increasing (e.g. push, set, etc.). For plain objects, it tries to override the prototype and spy on setters to accomplish this.

Note that not every leaking collection is a serious memory leak: for instance, your router may keep some metadata about past routes in an ever-growing stack. Or your analytics library may store some timings in an array that continually grows. These are generally not a concern unless the objects are huge, or contain closures that reference lots of memory.

Why not support multiple browsers?

Currently fuite requires Chromium-specific tools such as heap snapshots, getEventListeners, queryObjects, and other things that are only available with Chromium and the Chrome DevTools Protocol (CDP). Potentially, such things could be accessible in a cross-browser way, but today it just isn't possible.

That said, if something is leaking in Chrome, it's likely leaking in Safari and Firefox too.

[Page]: https://pptr.dev/#?product=Puppeteer&version=v12.0.1&show=api-class-page