[HN Gopher] Fuite: a tool for finding memory leaks in web apps
___________________________________________________________________
Fuite: a tool for finding memory leaks in web apps
Author : todsacerdoti
Score : 144 points
Date : 2021-12-17 15:21 UTC (7 hours ago)
(HTM) web link (nolanlawson.com)
(TXT) w3m dump (nolanlawson.com)
| tyingq wrote:
| Memory leaks on the client side, in a single-page app.
| danuker wrote:
| Personally I prefer JS-light sites, but in today's SPA filled
| world, this tool is very welcome.
| scubakid wrote:
| 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)
| nolanl wrote:
| 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-...
| bgirard wrote:
| 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!
| mrsharpoblunto wrote:
| 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
| lgong wrote:
| 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!
| nolanl wrote:
| 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. :)
| nyellin wrote:
| 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.
| krossitalk wrote:
| 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?
| somehnacct3757 wrote:
| 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.
| kohlerm wrote:
| 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.
| vdnkh wrote:
| misunderstood, nvm!
| ahmedfromtunis wrote:
| I think they meant the student built a prototype leaks
| detector for SPAs.
| vdnkh wrote:
| Oh cool, thanks for the correction
| enesismail wrote:
| Gmail and other gsuite apps' developers, would you please use
| Fuite? Thx.
| krm01 wrote:
| 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
| antirez wrote:
| 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.
| [deleted]
| The_rationalist wrote:
| As a reminder, one can use weakreferences
| sillyquiet wrote:
| 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.
| kohlerm wrote:
| 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.
| sillyquiet wrote:
| 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.
| Lamad123 wrote:
| Is "fuite" french for fleeing?
| iampims wrote:
| Leak
| oakfr wrote:
| Turns out that it also means fleeing :)
| kingcharles wrote:
| 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.
___________________________________________________________________
(page generated 2021-12-17 23:00 UTC)