User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Run a local web development server
Browse to localhost:port
Refresh page (CMD+R)

Actual results:

Memory usage increases with each refresh, goes on to swap when RAM is full

Expected results:

Memory usage shouldn't increase with each refresh, rendering the device unusable

Can you please try and reproduce this issue with the latest FF Nightly 70.0a1(2019-07-14)? You can use this link to download it: https://nightly.mozilla.org/

Tested with Firefox Nightly 70.0.a1, this is the RAM usage after around 50 reloads. Issue is persisting.

Can you please capture a performance profile? You can get more info on how to install and use the Cleopatra add-on (that helps you get the performance profile) by going to:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
https://perf-html.io/
Please also note that this add-on works only on FF Nightly, so that means you need to use that version.

Of course, here it is:

https:perfht.ml/32pi3Fr

Thanks muhammedbacalan for your help.

Mike can you please take a look at the capture from comment 5? Thanks

Hi muhammedbacalan, thanks for reporting this issue.

Would it be possible for you to create a report from about:memory? Here's how to do that:

1. Wait until Firefox is consuming a large amount of memory
2. Enter about:memory in the URL bar and press enter
3. Click "Measure and save" (optionally with "anonymize" checked to hide URLs, although this will likely make it more difficult for us to figure out which site, if any, is causing the leak)
4. Save the memory report somewhere
5. Attach the report to this bug

Hopefully that memory report will make it clearer what's consuming so much memory.

Hello Mike, here is the memory report as you requested. I did some more reloads and it just keeps getting more and more usage.

I have a relatively simple script that shows that 68.0.1 (and 68.0) runs about 3x slower than 67.0.4. The profiler shows that it is spending a lot more time GC-ing. Please see the attached HTML file.

This is with a fresh install, no add-ons or extensions.

I ran this on an 8 year old, 64-bit Intel i3-2310M quad-core (2.10 GHz) Windows 7 laptop with 8 GB of RAM. It takes about 300 seconds in 67.0.4, and about 900 seconds in 68.0.1. Scaling up to my actual product, what used to take 30 minutes takes almost 1.5 hours now.

It helps to set dom.max_script_run_time to a large number (I chose 10000000).

In 67.0.4, it's consistently takes about 3 seconds per 100000 iterations through the entire 10M loop. In 68.0.1, it starts slowing down (to 15 seconds per 100000 iterations) at around 5800000 (where the total size of the blobs is > 4 GB) and gets slower as the run progresses. The end result is a 3x increase in total time.

Hope this helps.

The memory report in comment 8 shows a significant amount of memory in one of the content processes consuming heap unclassified. Adding the [MemShrink] tag to get this on the MemShrink groups radar.

The STR in comment 9 may or may not be related, but adding the [qf] tag in case our GC'ing became less speedy in 68.

I'll try to bisect this if I can reproduce it with 67 and 68.

muhammedbacalan, can you reproduce this without dev tools open? Looking at the memory report it seems like there might be a lot of memory being held by that.

Particularly it would help to:

1. Restart Firefox so we're sure dev tools isn't running
2. Rerun your steps to reproduce
3. Capture a new memory report

I'm going to tentatively move this to DevTools for now.

:denispal, can you split off a separate bug for comment 9?

(In reply to Eric Rahm [:erahm] (Out until Aug 6th) from comment #13)

:denispal, can you split off a separate bug for comment 9?

Done.

Hello Eric, here is the memory report without dev tools running.

It seems to be tied with dev tools from my obversations too, as I was unable to reproduce with them closed. I did reproduce with the dev tools open and closing them frees lots of held memory over time.

Thanks for confirming! pbro, do you know if someone can look into this? It's a pretty large leak in both the content process and the parent process when using dev tools. We confirmed this doesn't reproduced with dev tools disabled (comment 15), here's a snippet from the memory report in comment 8:

Web Content (pid 4733)
Explicit Allocations

3,448.71 MB (100.0%) -- explicit
├──1,551.71 MB (44.99%) ── heap-unclassified
├──1,250.74 MB (36.27%) -- window-objects/top(http://localhost:8083/shop, id=12884901889)
│  ├────742.40 MB (21.53%) -- active/window(http://localhost:8083/shop)
│  │    ├──346.58 MB (10.05%) ++ layout
│  │    ├──306.50 MB (08.89%) ++ js-realm(http://localhost:8083/shop)
│  │    ├───88.92 MB (02.58%) ++ dom
│  │    └────0.40 MB (00.01%) ++ (2 tiny)
│  └────508.33 MB (14.74%) ++ (124 tiny)
├────289.89 MB (08.41%) ++ js-non-window
├────168.33 MB (04.88%) ++ images

Main Process (pid 4709)
Explicit Allocations

1,953.14 MB (100.0%) -- explicit
├──1,568.79 MB (80.32%) -- js-non-window
│  ├──1,543.96 MB (79.05%) -- zones
│  │  ├──1,535.39 MB (78.61%) -- zone(0x1066e5000)
│  │  │  ├──1,454.94 MB (74.49%) -- strings
│  │  │  │  ├────658.94 MB (33.74%) ++ string(length=8032733, copies=43, "/******/ (function(modules) { // webpackBootstrap/n/******/ /t// The module cache/n/******/ /tvar installedModules = {};/n/******//n/******/ /t// The require function/n/******/ /tfunction __webpack_require__(moduleId) {/n/******//n/******/ /t/t// Check if module is in cache/n/******/ /t/tif(installedModules[moduleId])/n/******/ /t/t/treturn installedModules[moduleId].exports;/n/******//n/******/ /t/t// Create a new module (and put it into the cache)/n/******/ /t/tvar module = installedModules[moduleId] = {/n/******/ /t/t/texports: {},/n/******/ /t/t/tid: moduleId,/n/******/ /t/t/tloaded: false/n/******/ /t/t};/n/******//n/******/ /t/t// Execute the module function/n/******/ /t/tmodules[moduleId].call(module.exports, module, module.exports, __webpack_require__);/n/******//n/******/ /t/t// Flag the module as loaded/n/******/ /t/tmodule.loaded = true;/n/******//n/******/ /t/t// Return the exports of the module/n/******/ /t/treturn module.exports;/n/******/ /t}/n/******//n/******//n/******/ /t// expose the modul" (truncated))
│  │  │  │  ├────319.05 MB (16.34%) ++ string(length=338120, copies=984, "/9j/4AAQSkZJRgABAQAASABIAAD/4QBARXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAAqACAAQAAAABAAABcqADAAQAAAABAAABwgAAAAD/7QA4UGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAA4QklNBCUAAAAAABDUHYzZjwCyBOmACZjs+EJ+/8AAEQgBwgFyAwERAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/dAAQAL//aAAwDAQACEQMRAD8A/v4oAKACgAoAKACgAoA" (truncated))
│  │  │  │  ├────205.58 MB (10.53%) ++ string(length=454845, copies=236, ".select2-container{box-sizing:border-box;display:inline-block;margin:0;position:relative;vertical-align:middle}.select2-container .select2-selection--single{box-sizing:border-box;cursor:pointer;display:block;height:28px;user-select:none;-webkit-user-select:none}.select2-container .select2-selection--single .select2-selection__rendered{display:block;padding-left:8px;padding-right:20px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap}.select2-container .select2-selection--single .select2-selection__clear{position:relative}.select2-container[dir=rtl] .select2-selection--single .select2-selection__rendered{padding-right:8px;padding-left:20px}.select2-container .select2-selection--multiple{box-sizing:border-box;cursor:pointer;display:block;min-height:32px;user-select:none;-webkit-user-select:none}.select2-container .select2-selection--multiple .select2-selection__rendered{display:inline-block;overflow:hidden;padding-left:8px;text-overflow:ellipsis;white-space:nowrap}.select2-container .select2-search--in" (truncated))
│  │  │  │  ├────180.31 MB (09.23%) ++ string(length=1048576, copies=80, "/******/ (function(modules) { // webpackBootstrap/n/******/ /t// The module cache/n/******/ /tvar installedModules = {};/n/******//n/******/ /t// The require function/n/******/ /tfunction __webpack_require__(moduleId) {/n/******//n/******/ /t/t// Check if module is in cache/n/******/ /t/tif(installedModules[moduleId])/n/******/ /t/t/treturn installedModules[moduleId].exports;/n/******//n/******/ /t/t// Create a new module (and put it into the cache)/n/******/ /t/tvar module = installedModules[moduleId] = {/n/******/ /t/t/texports: {},/n/******/ /t/t/tid: moduleId,/n/******/ /t/t/tloaded: false/n/******/ /t/t};/n/******//n/******/ /t/t// Execute the module function/n/******/ /t/tmodules[moduleId].call(module.exports, module, module.exports, __webpack_require__);/n/******//n/******/ /t/t// Flag the module as loaded/n/******/ /t/tmodule.loaded = true;/n/******//n/******/ /t/t// Return the exports of the module/n/******/ /t/treturn module.exports;/n/******/ /t}/n/******//n/******//n/******/ /t// expose the modul" (truncated))
│  │  │  │  └─────91.05 MB (04.66%) ++ (147 tiny)
│  │  │  ├─────43.16 MB (02.21%) ++ realm([System Principal], DevTools (Module loader))
│  │  │  └─────37.29 MB (01.91%) ++ (22 tiny)

Thanks for the report.
One more question muhammedbacalan: does this happen with any panel in DevTools or one in particular?
Note that if you want to test this, it would be good to re-open Firefox in between each test, and to specifically open a different panel from the start instead of doing something like right-click/inspect element and then switching to another panel. The reason being that if you do so, you'll always end up loading the inspector and that would pollute the results if you're trying to only see what effect, say, the debugger has.
To open a panel from the start, you can go into the Firefox menu, then Web Developer, and then try with Debugger, then Web Console, then Inspector, etc.
In the meantime, I'll try to get some insights thanks to that memory profile you provided.

Looking at the profile link might help as it has screenshots attached (the link was broken so here is the fixed version)
https://profiler.firefox.com/public/c50db87ac8e17cf69fd2898eb8ccf2286b65cce2/calltree/?globalTrackOrder=7-8-9-0-1-2-3-4-5-6&hiddenGlobalTracks=1-2-3-4-5-6&localTrackOrderByPid=4709-1-0~5788-0~5786-0~4716-0~4712-0~5403-0~4733-0~&thread=0&v=4

Thanks Julian, we can see the inspector opened there in the screenshot.
So I did some tests on Firefox Nightly (70). Here's what I tested:

TEST 1:

1. open nightly
2. open one tab on wikipedia.org
3. open about:memory in another window
4. reload wikipedia 10 times
5. in about:memory force CC and GC, then measure, note down the memory taken by the parent process and by the content process
6. start again at step 4 and do this for a few times (I did 12 cycles)

TEST 2:

1. open nightly
2. open one tab on wikipedia.org
3. open the inspector in that tab
4. open about:memory in another window
5. reload wikipedia 10 times
6. in about:memory force CC and GC, then measure, note down the memory taken by the parent process and by the content process
7. start again at step 5 and do this for a few times

The results are pretty telling.

With TEST 1 (no inspector), the parent process stayed between 230MB and 330MB, sometimes going up, sometimes down. And the content process mostly stayed flat at 46MB of memory usage.

With TEST 2 (with the inspector), the parent process ended up at 580MB of memory usage. Sometimes going up and sometimes down. So hard to conclude anything else than it just uses more memory when devtools is open, but might not leak.
The content process, however, ended up at 343MB and was just growing linearly the whole time, adding +30MB of memory usage every cycle (so every 10 reload of the page). This, I think, is pretty conclusive to the existence of a leak in the server-side code of the inspector panel.

The priority flag is not set for this bug.
:pbro, could you have a look please?

For more information, please visit auto_nag documentation.

:pbro, apologies for being late but I have uploaded 3 memory reports per your instructions at comment 17. These tests were made on localhost, in a development environment but I achieved the same results on mozilla.org too.

Same issue here.

I do frontend development. Last project was a Shopware project (with a stylesheet of ~1Mb), now I am working on a Salesforce project.

In either case, after numerous page reloads, RAM and swap memory reached 100% and my computer slowed down and sometimes crashed. I typically have a few firefox instances opened, aswell as the dev tools. If I manage to close the dev tools quickly enough before my PC crashes, RAM usage eventually goes down to ~40%, which is normal.

Ubuntu 16.04
Firefox 70.0.1

Switching to Chrome now until this issue is resolved.

Putting this back on pbro's radar now that the memory reports are in.

(clearing needinfo, sorry for not doing it earlier, I am no longer involved in the development of the project, I'll pass this on to Alex who I think the best person to keep this bug in mind)

Consolidating reload leak bugs to Bug 1682212

We made a few significantly improvements in Firefox 93 and 94, especially around network request monitoring.
Bug 1682212 is tracking all issues around leaks on page reload.
We can probably have new goals to chase more leaks, related to other panels.