Open Bug 1439509 Opened 2 years ago Updated 6 months ago

High RAM usage when the developer tool is open


(DevTools :: General, defect, P2)

60 Branch


(Not tracked)


(Reporter: guirec.corbel, Unassigned)


(Blocks 1 open bug)



(3 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180215141455

Steps to reproduce:

Open a page in a local server;
Open the Developer Tool;
Do a change in a JavaScript file;
Reload the page;

Actual results:

The number of copies stored and the memory usage increase.

Expected results:

Do a garbage collection.
I reproduced the bug with this HTML file : 

    <script src='./bigfile.js' type="text/javascript" charset="utf-8"></script>

And this js file : . Any big files should be the same. I didn't saw the bug with a small file.

As you can see in the attachment, I can take 4go of RAM and 18go of "vsize". I had to closed Firefox and the CPU usage was very high. I had to kill the process to really stop Firefox.

As you can see here "string(length=515416, copies=101, "/* jsTree default theme */" there is a lot of copies of the same files.

I have to close the dev tool and run a Garbage Collection and Cycle Collection to release the memory. It took the CPU for a while when I run a Garbage Collection. The "Disable Cache" checkbox was checked in the network tab.
Does it happen with every tools or were you using one in particular (debugger, console, inspector)?
I see you are having LiveReload add-on via the memory profile you attached.
Were you using any particular workflow/tool, or just a plain http server and F5?
I imagine live-reload add-ons may make such memory leak even more present!
I send an memory report with livereload disabled. I was on the console, I will test in other tabs in a few minutes. As you can see, there 7 copies of "/app/lib/assets/stylesheets/loader.scss" but I didn't touch this file. There is other files loaded multiple times too.
Attached file memory-report.json.gz
It is the same with other tabs. For information, I was modifying the file that starts with "Modernizer". I reloaded with F5.
Component: Untriaged → Developer Tools
(In reply to guirec.corbel from comment #1)
> I reproduced the bug with this HTML file : 
>     <script src='./bigfile.js' type="text/javascript"
> charset="utf-8"></script>
> And this js file :
> dist/jstree.js .

I tried to reproduce that on today's nightly, without success.

I used this html file:
  <script src='jquery.js' type="text/javascript"
> charset="utf-8"></script>
  <script src='bigfile.js' type="text/javascript"
> charset="utf-8"></script>

With the following js files next to it:
$ wget -O jquery.js
$ wget -O bigfile.js

My STR was:
* open DevTools on the console
* press F5 to reload the page tons of times

My result was that the memory is surely growing, that's expected.
But nothing really bad, here is the memory after 30seconds of reloads:
  224MB for parent process and 211MB for content process
(Firefox started at: 172MB for parent and 53MB for content with the test document opened with the console)

Also I do not see anything really special in about:memory.

So, there must be something special in your usecase.
Are you sure you opened only the console and directly the console?
Did you reproduced with just a <script> tag in an empty html document?
I wasn't able to reproduce the same bug with the same file I used when I created the issue. I was able to reproduce with a brand new ember app. I did just `ember new my-app && cd my-app && ember s` when ember cli is installed. You can install ember with `npm install -g ember-cli`.

I attached a small video with a new profile.

As you can see in the video, the memory is clean first. I open the console with Ctrl+Shift+k and refresh some times. After that, there is 4 copies of the same files. It's cleaned when I close the console. I don't need to click on "GC" and "CC" this time. I suppose this is because the memory is not loaded.

It isn't a problem specific to Ember. I have it with other applications.
Ah ok, I see. This is related to source map, this is why the simplest example doesn't work.

108.15 MB (25.29%) -- worker(resource://devtools/client/shared/source-map/worker.js, 0x7f8ca8b53800)
│  │  ├──103.92 MB (24.30%) -- zone(0x7f8ca915f000)
│  │  │  ├───53.03 MB (12.40%) -- strings
│  │  │  │   ├──32.13 MB (07.51%) -- string(length=3368956, copies=5, "{"version":3,"sources":["vendor/ember

So the source-map worker is loading the sources multiple times.
If you force a GC, these strings go away, so it isn't a leak.
It's just that the source map is allocating a lot of memory because of the JS content copies.
There is multiple ways to improve that:
* force GC on page reload
* kill, respawn a source worker on reload, that may help releasing the worker objets sooner
* optimize source map to allocate less memory?
* try to detect when the resources don't change and do not re-request the source map worker to re-parse the files
* ...
On the reports I gave, the memory leaks dosen't seems to be related to the source map (or it's less obvious) as you can see here : 

4,893.12 MB (100.0%) -- explicit
├──3,357.53 MB (68.62%) -- window-objects/top(, id=6442450990)
│  ├──2,301.10 MB (47.03%) ++ active
│  └──1,056.43 MB (21.59%) ++ js-zone(0x7fa71f048000)
├────972.40 MB (19.87%) -- js-non-window
│    ├──888.73 MB (18.16%) -- zones
│    │  ├──871.52 MB (17.81%) -- zone(0x7fa74637d000)
│    │  │  ├──831.51 MB (16.99%) -- strings
│    │  │  │  ├──502.44 MB (10.27%) ++ (276 tiny)
│    │  │  │  ├───99.42 MB (02.03%) -- string(length=515416, copies=101, "/* jsTree" (truncated))
│    │  │  │  │   ├──99.42 MB (02.03%) ── malloc-heap/two-byte
│    │  │  │  │   └───0.00 MB (00.00%) ── gc-heap/two-byte
│    │  │  │  ├───92.18 MB (01.88%) -- string(length=893446, copies=54, ""use strict" (truncated))
│    │  │  │  │   ├──92.18 MB (01.88%) ── malloc-heap/two-byte
│    │  │  │  │   └───0.00 MB (00.00%) ── gc-heap/two-byte
│    │  │  │  ├───81.35 MB (01.66%) -- string(length=1092231, copies=39, "/n/n(function() " (truncated))
│    │  │  │  │   ├──81.35 MB (01.66%) ── malloc-heap/two-byte
│    │  │  │  │   └───0.00 MB (00.00%) ── gc-heap/two-byte
│    │  │  │  └───56.11 MB (01.15%) -- string(length=1049559, copies=28, "window.EmberENV"(truncated))
│    │  │  │      ├──56.11 MB (01.15%) ── malloc-heap/two-byte

It seems to be under the tab where the page is loaded. In the screencast, it seems to be the same than you.
I just realized I forgot an important part yesterday (and you too). We have to do a small change in a JS file before to reload as I specified in the first comment.
I still have the issue. It keeps multiple copies of JS files when we change a file and reload with the dev tool open.
Ever confirmed: true
Priority: -- → P2
Product: Firefox → DevTools
I tried again to reproduce the bug and it seems be a little bit different. Now, to reproduce the bug, I have to open the file in the debugger tab. It seems to keep copies of old JS files. I think it needs less memory than before but I suppose some garbage collection have to be performed. The file is still in memory if close the file in the debugger.
Blocks: 1553178
No longer blocks: devtools-performance
Blocks: dt-leak
No longer blocks: 1553178
You need to log in before you can comment on or make changes to this bug.