User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

When developer tools are open, it strongly looks like nothing at all in memory is cleared on page reloads / new page loads. This leads to FF eating up more and more RAM, until it's so full that it needs a nap (restart). Obviously for web developers, this is a huge issue. Depending on available RAM, a restart could be needed after as little as 10 page reloads. With 16GB of ram and some other stuff like phpstorm open, about 20-30 reloads require a restart, from 10-15 Reloads it starts to get slow.

The issue is really easy to reproduce. I will add further details and some results of my investigation below.

To reproduce:

1. Open any taskmanager (or use about:memory) and check the Memory usage of firefox, keep this number in your mind
2. simply open any website (I used cnn.com), but it can be reproduced with pretty much any website
3. Open developer tools
4. Click on the reload page button top left, or press f5 to reload the page. wait until page has loaded and reload page again. repeat for 10 times.
5. Check the task manager (or about:memory) again and you will see a massive increase in RAM usage. Keep the number in mind
6. Repeat 4. again (reload the page another 10 times), and check task manager (or about:memory) again.
7. Instead of reloading a page 10 times, you could also visit 10 different sites with the dev. tools open, result is the same.

Actual results:

I tested this on multiple systems, the Memory usage from 10 reloads to 20 reloads was massive in all cases, here is one of the results:

Main Process:
10 Reloads: 588.83 MB
20 Reloads: 1310.63 MB

Web Process:
10 Reloads: 807.36 MB
20 Reloads: 1518.02 MB

Both the Main and the Web process more than doubled from 10 to 20 reloads. To me this does not even look like an individual memory leak, it looks more like the memory is not cleared at all when the developer tools are open. This can be repeated until all RAM on the system is exhausted, the more Memory that is used, the slower Firefox becomes.

However, when the developer tools are not open, this problem does not exist.

I tried to investigate this a bit more, so I did the following:

1. I opened about:config and tried deactivating most of the relevant settings (devtools.x) - Disabled many things to see if it had an effect. no luck unfortunately. The issue persists.

2. I fully disabled javascript (javascript.enabled = false) to see if the problem still exists. It does, no change at all (percentage wise).

3. I created memory profiles after 10 and 20 reloads and compared them. These are my findings from this:

Main Process - 10 Reloads:
588.83 MB (100.0%) -- explicit
├──329.52 MB (55.96%) ++ js-non-window
├──115.94 MB (19.69%) ── heap-unclassified
├───36.63 MB (06.22%) ++ images
├───21.50 MB (03.65%) ++ storage
├───19.17 MB (03.25%) ++ heap-overhead
├───17.94 MB (03.05%) ++ (23 tiny)
├───16.86 MB (02.86%) ++ window-objects
├───14.16 MB (02.40%) ++ startup-cache
├────8.85 MB (01.50%) ++ workers/workers(chrome)
└────8.26 MB (01.40%) ++ script-preloader

Main Process - 20 Reloads:
1,310.63 MB (100.0%) -- explicit
├────776.83 MB (59.27%) ++ js-non-window
├────329.27 MB (25.12%) ── heap-unclassified
├─────48.94 MB (03.73%) ++ window-objects
├─────32.86 MB (02.51%) ++ (24 tiny)
├─────29.90 MB (02.28%) ++ heap-overhead
├─────28.51 MB (02.17%) ++ workers/workers(chrome)
├─────28.28 MB (02.16%) ++ images
├─────21.65 MB (01.65%) ++ storage
└─────14.38 MB (01.10%) ++ startup-cache

As you can see, Most things doubled or more. This indicates that memory is not cleared at all.

Web Process - 10 Reloads:
807.36 MB (100.0%) -- explicit
├──388.28 MB (48.09%) ++ window-objects
├──182.82 MB (22.64%) ++ js-non-window
├──160.67 MB (19.90%) ── heap-unclassified
├───40.36 MB (05.00%) ++ heap-overhead
├───17.91 MB (02.22%) ++ (22 tiny)
└───17.32 MB (02.14%) ++ workers/workers(chrome)/worker(resource:///modules/translation/cld-worker.js, 0x2af64041800)

Web Process - 20 Reloads:
1,518.02 MB (100.0%) -- explicit
├────702.08 MB (46.25%) ++ window-objects
├────380.08 MB (25.04%) ++ js-non-window
├────317.58 MB (20.92%) ── heap-unclassified
├─────81.67 MB (05.38%) ++ heap-overhead
├─────19.29 MB (01.27%) ++ (22 tiny)
└─────17.32 MB (01.14%) ++ workers/workers(chrome)/worker(resource:///modules/translation/cld-worker.js, 0x2af64041800)

Again, almost everything doubled. Strong indication that nothing is unloaded at all.

4. I tried closing the developer tools, and this releases a lot of memory, but not instantly, for example: I opened the browser with 1 tab on cnn.com and dev. tools open. I reloaded the page a few times until firefox was using 3570 MB of RAM. Then I closed the dev. tools. and within 30-60 secs, memory usage was down to 1450 MB and stayed there.
   I opened a new empty tab and closed the tab with cnn.com. Memory usage instantly fell down to 862 MB.

-> This indicates that when closing developer tools, some code is executed that properly clears the memory. It might be a good thing to start checking there, it should be possible to pretty quickly find the code that releases a lot of memory. By checking this code, it might be possible to see what exactly is not cleared when the dev. tools are open.

I have attached 4 profiles which can be loaded and compared on about:memory
10, 20 Reloads on cnn.com, JS enabled
10, 20 Reloads on cnn.com JS disabled

Expected results:

When loading a page with dev. tools open, memory should be cleared and unneeded stuff should be removed, in the same way as if dev. tools were not open.

Hi andrew

Can you please check the memory reports attached? do you know what component should be set for this one?

So far i have reproduced this on windows10 64bit

Using firefox (release 84) + (beta 85.0b3) + (Nightly 86.0a1)
Went to cnn.com and pressed Control shift , then refreshed many times.

For the first 10 refreshes i saw in task manager 1.5gb memory
For the second 10 refreshes, i saw 2gb of memory used
but it never drops, stays at 2gb.

I will also check on ubuntu and Mac0s

This is unfortunately a known issue. I think some of the idea is that you might want to debug a page after it is closed, but it can lead to large memory leaks.

(In reply to Andrew McCreight [:mccr8] from comment #2)

This is unfortunately a known issue. I think some of the idea is that you might want to debug a page after it is closed, but it can lead to large memory leaks.

*** This bug has been marked as a duplicate of bug 1084605 ***

Even if the idea is that you might want to debug a page after it is closed, the problem is that the memory expands on each page reload, so in the terminology of bug 1084605, a ghost window is created on each page reload, as it seems that nothing is unloaded after a page reload.

This makes working with FF an unpleasant experience, as the browser starts lagging / freezing within minutes in some cases and either a restart is required or the console needs to be closed and reopened over and over again.

I see that the other bug is open for 6 years already. Will somebody from the dev team have a look at this issue within a reasonable timeframe, or is this one of these bugs that will never get fixed? As a developer, I need a working console, that's why I reported this bug. Closing my bug report (which took me quite a while to create) and make it a duplicate of a 6 yr old 'dead' bug does not seem to be a step in the right direction when it comes to finding a solution and fixing the problem.

I do understand that there might be more important things in the queue, or simply that this bug is too difficult to fix, in this case please let me know. Thanks for your time.

Sorry, I don't work on Firefox devtools. I don't know how they prioritize issues.

(In reply to Andrew McCreight [:mccr8] from comment #4)

Sorry, I don't work on Firefox devtools. I don't know how they prioritize issues.

I am also not sure if this bug is a duplicate of bug 1084605. I think not. The problem with bug 1084605 is that there is a ghost window after a tab is closed. The problem with this bug is that the memory keeps expanding when the page is reloaded. These are two different problems. Can you explain a bit more why these two things are related? Thanks for your time.

Closing a tab, reloading a tab, or navigating away from a tab are all basically the same from the perspective of the browser.

I can leave it as a separate issue if you prefer. I did not do any kind of deep investigation, so they might be similar but different issues.

(In reply to Andrew McCreight [:mccr8] from comment #6)

Closing a tab, reloading a tab, or navigating away from a tab are all basically the same from the perspective of the browser.

I can leave it as a separate issue if you prefer. I did not do any kind of deep investigation, so they might be similar but different issues.

I think that makes sense, thank you.

Try to reproduce and aggregate info from other similar bugs.

The issue reproduces easily with the STRs from the summary, thanks for logging a reproducible bug!

First observation, the size of the leak depends on the page. DevTools+cnn.com leaks ~50MB per reload. DevTools+mozilla.org only leaks 10MB per reload.

I first tried to disable sourcemaps (in devtools settings). The leak goes down to ~20MB per reload. So we seem to have a huge leak related to sourcemaps.

Then I started looking at what was not cleaned on navigation, both by watching our internal Pool sizes and looking at the leaked strings I could see in the GC log.

The list is quite big:

• network event actors
• script actors
• grid actors
• ...

Some of them are leaked in custom maps (eg network event resources here https://searchfox.org/mozilla-central/rev/1ebc9745be02eebf7a694f5c527a44a045b8c97a/devtools/server/actors/resources/network-events.js#36), but most of them are simply leaked because they remain in the pool of their parent actor which is never cleaned on navigation.

Note that some of those actors are target-scoped actors. When we will create a new target actor for every navigation, the leaks on target-scoped actors (eg thread actor leaking scripts, layout actor leaking grids etc...) should be automatically fixed. This should be enabled by Bug 1644397 + Bug 1686748. But that's not the case for all of them. For instance, network events are not target scoped. And network events are responsible for the bulk of the remaining leak. If I stop saving them in the watcher pool & in the local networkEvents map, the leak goes down from ~20MB to ~2MB per cnn.com reloads again without sourcemaps.

I identified the following pools leaking:

• [actor] thread leaks sources
• [front] domwalker leaks nodes
• [actor] watcher leaks network events
• [actor & front] layout leaks grids
• [actor & front] pagestyle leaks style rule
• [actor] something(?) leaks stylesheet
• [front] stylesheets leaks stylesheet

By "leaking" we mean that those pools keep references to fronts/actors which correspond to the previous browsing context.
Will file bugs for each of those.

Hot reload sample app provided by :florian.greinus on another similar bug

(In reply to florian.greinus from Bug 1645325 comment #8)

https://github.com/fgreinus/react-spa-firefox-leak. You can just clone it, run npm install (or use yarn, just as you like) and then use yarn start or npm run start. Your browser should open for localhost:3000. Then just go into App.js and change something, save and the browser will automatically reload the SPA according to your changes. This is already the moment where it start's leaking (from what i have seen). Memory report diffs also show that. More often reloads (saves) lead to more memory and bigger size leads to more significant leaks (quite obvious though).

Hope this helps!

Another test application for reload bugs, should also cover sourcemap leaks: https://github.com/Lavaei/firefox-memory-leak

The network event leak is a known issue, already tracked by Bug 1439509.
The main challenge with this work is that we don't have a good solution to know if "persist logs" is enabled or not.
So for now we keep all the requests, all the time.

To address this leak correctly, we need a good framework solution to pass a client configuration information to the server.
This will have to wait until the current Fission refactors are done.

I don't know if it is the right solution still, but a prior attempt to address this issue from the platform side is bug 1084626. The drawback was that it broke a bunch of devtools tests that poked at pages after they closed.

I did some testing on top of Bug 1644397. The main difference after this bug is that we recreate a target everytime we get a new window global. When doing that, we perform a lot of cleanup (in particular we will destroy all the target-scoped pools of objects).

With this change the leak reduces significantly. For 10 reloads of cnn.com we go from a 400-500MB leak to a 30MB leak. It's still a lot , but it's already a great step forward. Going to block this on Bug 1686748 (it's a follow up to 1644397, which will enable the new target behavior for all targets, while 1644397 is more conservative).

(In reply to Andrew McCreight [:mccr8] from comment #24)

I don't know if it is the right solution still, but a prior attempt to address this issue from the platform side is bug 1084626. The drawback was that it broke a bunch of devtools tests that poked at pages after they closed.

Thanks for the info. Any chance this comment relates to Bug 1084605 rather than this one?

Another duplicate: https://bugzilla.mozilla.org/show_bug.cgi?id=1644310

(In reply to Julian Descottes [:jdescottes] from comment #25)

Thanks for the info. Any chance this comment relates to Bug 1084605 rather than this one?

From the perspective of the DOM and page lifetime stuff, reloading a page, navigating away from a page, and closing a tab are all basically the same. I could certainly see how from a devtools perspective you might want them to behave differently in those cases.

(In reply to Andrew McCreight [:mccr8] from comment #28)

(In reply to Julian Descottes [:jdescottes] from comment #25)

Thanks for the info. Any chance this comment relates to Bug 1084605 rather than this one?

From the perspective of the DOM and page lifetime stuff, reloading a page, navigating away from a page, and closing a tab are all basically the same. I could certainly see how from a devtools perspective you might want them to behave differently in those cases.

What I meant is that on DevTools side, we keep a lot of objects alive after a navigation. We have maps in our Toolbox frontend code which are not cleaned up on navigation (eg keyed by source URLs). I don't see how a platform solution can fix that, there's definitely an issue with object retention in DevTools frontend code (keeping in mind that the toolbox UI stays alive across reloads/navigation).

Firefo Is using about 11GB RAM with just one tab using dev tool that is oppened.

(In reply to jeremy.munsch from comment #31)

Created attachment 9213706 [details]
memory-report.json.gz

Firefo Is using about 11GB RAM with just one tab using dev tool that is oppened.

This bug is too complicated to fix :( it exists since many years. what you can do to migitate this issue a bit is to close and reopen the developer tools console from time to time. This will release the memory. it's not optimal but better than nothing.

(In reply to christoph.mosimann from comment #32)

(In reply to jeremy.munsch from comment #31)

Created attachment 9213706 [details]
memory-report.json.gz

Firefo Is using about 11GB RAM with just one tab using dev tool that is oppened.

This bug is too complicated to fix :( it exists since many years. what you can do to migitate this issue a bit is to close and reopen the developer tools console from time to time. This will release the memory. it's not optimal but better than nothing.

It's true it's a long standing issue, but the situation will be significantly better after Bug 1686748 lands.
It is a mandatory refactor for other ongoing work in DevTools, so it will definitely happen.

I have 1-2 tabs open, one of them with dev-tools.
Refreshing the page with the dev-tools, eventually leads to almost -5-8 gigs of ram.
Then I close/open the tab with the dev-tool, and it's back to <1gb.

Hello,
I'm extension developer and I'm using web-ext for development. This reloads addon each time I change sources.
I have my addon background script open all the time and this single tab will over the day accumulate several GB of memory, depending on how productive day I have and how big the addon I'm working on is. My record was something above 15GB!!!
Originally I've reported it in web-ext repo: https://github.com/mozilla/web-ext/issues/1910

You can reproduce it quite easily:

1. open about:debugging#/runtime/this-firefox
2. click "Inspect" button next to some big addon, for example "uBlock Origin"
3. execute this line 30 times:

browser.runtime.reload()

That will consume about 500MB of memory - on top of what Firefox was originally taking. (my addon I'm working on consumes this amount in only 10 reloads).

The leak should be significantly reduced after Bug 1702715 lands.

Honza

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #37)

The leak should be significantly reduced after Bug 1702715 lands.

Honza

Bug 1702715 has now landed and should be included in the current Nightly build. If anyone subscribed to this bug would like to try the latest Nightly and check if this improved the memory consumption issue, feedback would be great!

maximakimov3: since you recently opened a similar bug, maybe you could quickly test the latest Nightly and let us know if this improved the situation for you?

Overall the issue on the place, just seem a little changed behaviour. Now a tab process doesn't grab a lot of memory, but a main process does it much faster than it was before.

Could you clarify future of this bug? It already has been taking months, is it possible to launch at least a temporary solution, like an additional checkbox in the devTools settings, which will force clearing memory after every page refresh, like it happens when a tab is closing? Your answer would be useful for all developers, if nobody is going to fix it, there is sense to change the browser for development (unfortunately)

I've tested it in 93.0a1 (2021-08-18) (64-bit) using the STR in my comment 35 but the memory leak is still there, maybe 10% smaller, maybe not.
Do I need to activate some hidden switch for it to work?

(In reply to maximakimov3 from comment #40)

Could you clarify future of this bug? It already has been taking months, is it possible to launch at least a temporary solution, like an additional checkbox in the devTools settings, which will force clearing memory after every page refresh, like it happens when a tab is closing? Your answer would be useful for all developers, if nobody is going to fix it, there is sense to change the browser for development (unfortunately)

The next focus of the team will be on performance. We were blocked on rewriting a lot of the backend for devtools for a long time. Sorry it's been taking so long, but I don't have specific next steps to share, you can expect this bug to be updated when we have news to share.

(In reply to juraj.masiar from comment #41)

I've tested it in 93.0a1 (2021-08-18) (64-bit) using the STR in my comment 35 but the memory leak is still there, maybe 10% smaller, maybe not.
Do I need to activate some hidden switch for it to work?

Bug 1702715 will only help for regular DevTools toolboxes opened against a web page. For addon toolboxes, I imagine we have to wait until Bug 1675456, sorry.

I re-tested the STRs from the summary:

• open cnn.com
• open devtools with the inspector selected
• check memory for main and web process in about:memory
• reload cnn.com 20 times,
• check the memory
• force gc/cc
• check the memory

I get the following results:

Without Bug 1702715:

With Bug 1702715:

The main process leak has not changed much, and we did not really expect Bug 1702715 to help there.
However there is a significant improvement for the web process leak, which goes from 600MB to 60MB.

Maybe this is not true in all test cases, and that's why if Bug 1702715 didn't help with a specific use case, it would be great to get detailed steps to reproduce.

Note: this is done with a clean profile

To followup on comment 44, with the tooling and tests added via bug 1727571, bug 1539518, bug 1727837, I think I narrowed down the parent process leak. So I hope to fix this parent process issue and only have improvement coming from bug 1702715.

Bug 1727839 and bug 1727838 are the two underlying issue which cause the parent process leak.

Quick update:
As said in comment 44, bug 1702715, which shipped in Firefox 93 (today in beta) drastically reduced memory consumption.
We saw a 10x improvement (-90%) on the memory usage in the content process.

And bug 1439509, which landed today, will ship in Firefox 94 (today in nightly) and drastically reduced memory consumption in the parent process.
We saw a 3,7x improvement (-73%) on the memory usage in the parent process.

Here is a quick overview of the impact of all patches against the two allocation tests:

• browser_allocations_toolbox.js, which covers leaks after a toolbox close
• browser_allocations_reload.js, which covers leaks after reloading a page with the inspector opened

The following number are the number of objects leaked in the parent process.

Here is a first stack of patches to focus on target front and markup view leaks,
especially the ones that occurs during a page reload.

• Current metrics on mozilla-central:
  • toolbox: 44082
  • reload : 2240
• Bug 1727838 Avoid leaking InspectorFront via the STYLESHEET resource listener:
  https://phabricator.services.mozilla.com/D123920
  • toolbox: 44001
  • reload : 2170
• Bug 1727839 Avoid leaking targets from the ResourceCommand
  https://phabricator.services.mozilla.com/D123921
  • toolbox: 44001
  • reload : 1360
• Bug 1728069 Avoid leaking the markup view via a dangling listener on node picker
  https://phabricator.services.mozilla.com/D123922
  • toolbox: 44001
  • reload : 1360
• Bug 1728070 Avoid leaking the MarkupView via a DOM event listener
  https://phabricator.services.mozilla.com/D123923
  • toolbox: 44001
  • reload : 70
• Bug 1728071 Avoid leaking the previous target via DOCUMENT_EVENT's will-navigate
  https://phabricator.services.mozilla.com/D123924
  • toolbox: 44001
  • reload : 70
• Bug 1728072 Prevent leaking the first top level target
  https://phabricator.services.mozilla.com/D123925
  • toolbox: 43995
  • reload : 0

Up to this point, we no longer leak anything in the parent process when reloading the test page!
But this test page is rather trivial. If we use the same test against CNN, we can see some more leaks.
It should be easy to later complexify the test page to reproduce these leaks.

The severity field for this bug is relatively low, S3. However, the bug has 13 duplicates.
:Honza, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Wondering if there is an ETA on a fix.

Without an ETA or at least an automated hack like adding a checkbox to auto close and open dev tools I am going to switch from Firefox which I have been using forever to Chrome because of the problems this bug has caused me. Without anything like that Developer Firefox might as well be removed as there really isn't a point in using it over Chrome since the better devtools are not worth periodically rendering the browser inoperable.

Without an ETA I would recommend you add a prominent warning somewhere in devtools to warn the user that devtools has a memory leak which I would consider due diligence for a critical known issue for multiple years so you don't frustrate new devs who aren't aware of the issue.

(In reply to brian_haley from comment #49)

Wondering if there is an ETA on a fix.

Without an ETA or at least an automated hack like adding a checkbox to auto close and open dev tools I am going to switch from Firefox which I have been using forever to Chrome because of the problems this bug has caused me. Without anything like that Developer Firefox might as well be removed as there really isn't a point in using it over Chrome since the better devtools are not worth periodically rendering the browser inoperable.

Without an ETA I would recommend you add a prominent warning somewhere in devtools to warn the user that devtools has a memory leak which I would consider due diligence for a critical known issue for multiple years so you don't frustrate new devs who aren't aware of the issue.

It's hard to share an ETA, there are multiple sources which can create leaks in DevTools and we have been fixing some of those already. See earlier reports in this bug about improvements made over the last year.
Can you share a scenario where you experience a visible leak? Are you debugging webpages, extensions, workers? Which panels are you using the most? Are your sessions with DevTools usually long, do you reload a lot (or use hot reload etc...). Specific steps would be even better.

I don't really have any new information to share I will just be repeating what everyone has already said.

I have attached two memory dumps. One immediately after a load and the 2nd after 4h of work without ever touching firefox just hot reloads from CRA.

I leave devtools open with pause on error, run react dev tools as well as redux dev tools.
I use hot reload with create react app.
I am debugging web pages.
My sessions with dev tools open are until the memory usage freezes my web page at which point i kill the firefox process and reopen firefox.
I cannot provide you with steps to reproduce with my exact setup as all the code is private but I believe setting this up should be trivial using CRA and vs code just automate saving a file over and over again with the above setup to hot reload many many times and watch the memory usage increase. Alternatively forcing rerenders of the page many times with forceupdate may be able to reproduce the issue reliable. All I know is that while developing devtools expands its memory usage over time while I develop in vscode without me ever interacting with the devtools as today the memory usage report I have attached was reproduced while I developed in my new chrome setup I never actually touched firefox I just left it open from yesterday.

If this will be worked on I should be able to create a simple test environment if there is a guarantee it will be worked on.

Thanks for sharing the memory exports. The second one seems broken.
Could you try to uncheck "Enable Source Maps" in the DevTools Settings panel (advanced settings) and see if that makes a noticeable difference?

Yeah for some reason transferring the gzip corrupted the zip. Here is the raw json.