Fuite: a tool for finding memory leaks in web apps | Hacker News Reader

Fuite: a tool for finding memory leaks in web apps

nolanlawson.com

219 pointstodsacerdoti31 comments

When I worked at Facebook, I worked on a web memory tracking tool I was particularly proud. It went through links, grabbed heap snapshots, diff'ed them, found objects that weren't cleaned up and gave detailed information about its retain chain. You can see a lighting talk I did on it at BlinkOn: https://www.youtube.com/watch?v=JuyaGFApifA&t=1427s&ab_chann...

We used it to find a problem fixed in React 18 that caused large leaks on Facebook.com: https://github.com/facebook/react/pull/21039#issuecomment-80...

We also found one issue that caused a leak that's impossible to spot unless you know how V8 closures are implemented and retain one another.

I'm really hoping to see Facebook open source the tool some day!

Fuite seems really interesting. I like the idea of an automatic crawler!

Author here. I wasn't aware of your talk, but it's super interesting! Showing info about the retain chain is a great idea, but I didn't get around to doing it in fuite. IME just counting the number of objects is actually pretty effective to find the smoking gun. (You leaked 1 event listener, which leaked a bazillion strings, arrays, objects, etc., but all you really care about is the 1 event listener.)

I would love to see how your tool approaches this! Hope it gets open-sourced. :)

Colleague of bgirard at Facebook here, we are planning to open source the tool in 2022. Great to find someone also working on memory tooling here :) Fuite seems really interesting, will try it out!

Hi bgirard! I support the FB team that works on this - it's on the roadmap to open source hopefully H1 next year :) It's continued to find significant leaks in other parts of our infra too, so hopefully it will be equally helpful to others. Great to see others looking at memory tools now too - I'll definitely be checking Fuite out

Almost all SPAs do have memory leaks in my experience. I was once involved in Eclipse Memory Analyzer project(for Java, short MAT), and I mentored a student who built a prototype to support JS in MAT. We easily found significant memory leaks everywhere. That prototype was never released for reasons I cannot comment on in public.

misunderstood, nvm!

I think they meant the student built a prototype leaks detector for SPAs.

Oh cool, thanks for the correction

The only thing more tedious and brain-breaking than tracking down client-side JS memory leaks is tracking down server-side JS (Node) memory leaks.

Serious question, is it really more difficult fir server side JS? At least you don't have to fiddle around with DOM references. The potential impact on the server side is of course potentially bigger.

I mean it depends on the application naturally, but flame graphs or no and especially when dealing with heap dump comparisons, sometimes very opaquely named symbols, etc, it can be an exercise in frustration.

Browsers - Chrome especially - have really fantastic tooling for doing stuff like this. I think there's some way to hook those up to Node, but they're very readily available on the front-end

You can use chrome's tooling directly from nodejs. You just need to invoke nodejs with `node --inspect` (or --inspect-brk to pause before the first line of code is executed). Then open chrome's dev tools. A nodejs icon will magically appear at the top left of the dev tools pane. If you click that it'll open a new window with chrome's debugger, profiler and memory tools working directly with nodejs's v8 instance.

Or ndb[0].

[0]: https://github.com/GoogleChromeLabs/ndb

Gmail and other gsuite apps’ developers, would you please use Fuite? Thx.

Personally I prefer JS-light sites, but in today's SPA filled world, this tool is very welcome.

This is actually really important. If you're a tab whore like me you'll always find a site that eventually eats up all your RAM and kills the browser dead. More SPAs need to test for memory "leaks" like these, especially if they're repeatedly creating large numbers of DOM elements through scripting.

Having to point at a URL and crawl for pages seems awkward. Is there something I can directly integrate into my app? How would it deal with a login page?

Ran into the same limitation. I had tried logging in to a local dev server and then running fuite, but it looks like it runs the tests in its own personal chromium instance so my session wasn't used.

There are no memory leaks on my login and sign up pages though!

edit: just checked the docs and it says you can specify a scenario script with a setup hook to get passed authentication.

I jump into this project implementation and it supports login page by using some config. You should give it a try

This specific issue makes the "PHP way" (just to mention a notable example) of having an interpreter created to serve a page and then destroyed at the end, much more convenient, even if more resource intensive. Assuming the problem is not in the Javascript side of a single page application, of course.

How do crawler approaches like this handle SPAs that have a multi-step onboarding flow before getting into the actual heavy-hitting areas that need the most testing? (e.g. where you may have to click through several things before even hitting a route change)

Author here. I added support for custom scenarios, where you can define a "setup" step that logs in or does whatever you may need to do: https://github.com/nolanlawson/fuite/#extending-the-default-...

Very cool. Looks extremely easy to use which is the difference between people using tools or just reading about them :)

As an aside, I created some tooling for identifying memory leaks in Python apps. Once I started sending the results to Slack and formatting them nicely, I found people ran the tool more frequently. Usability is everything.

This is a welcome surprise. I have been hunting down memory leak problems for a hardware installation that runs a JS heavy app 24/7. Had to build in auto software resets just to clean the garbage because there was no real solution. Looking forward trying this out asap

Most SPAs nowadays load JS for new components dynamically on route change. I expect this to increase the stack, too. Just something to keep in mind.

Great point! This is exactly why fuite does a preflight iteration before the "real" iterations. One-time setup costs shouldn't count against the "leak" – only sustained memory growth.

Memory leaks on the client side, in a single-page app.

Is "fuite" french for fleeing?

Leak

Turns out that it also means fleeing :)

Reply on news.ycombinator.com