@bytesnz

Jack Farley, Computer Engineer

Once I saw my memory was being eaten, I tried capturing a memory report using the about:memory special page in Firefox.

The memory report showed that Deezer's process was eating 5.4GB of memory! In particular memory-file-data/string was taking up 5.1GB.

My next step was to see if I could figure out what it was. I brought up the Firefox Dev Tools and did a memory snapshot in the Memory tool.

The memory hog did not show up in the memory snapshot, so after a little bit of fruitless searching, I decided to try and have a look into the memory report in a little more depth.

When saved, the memory reports are saved as gzipped JSON. Once ungzipped, the memory report I looked at was 4.9MB (only 2GB of memory was used by Deezer).

$ gzip -d memory-report.json.gz

{
 "version": 1,
 "hasMozMallocUsableSize": true,
 "reports": [
  {
   "process": "Main Process (pid 510923)",
   "path": "explicit/network/hpack/dynamic-tables",
   "kind": 1,
   "units": 0,
   "amount": 1376,
   "description": "Aggregate memory usage of HPACK dynamic tables."
  },
  {
  ...
}

I opened a node prompt, loaded the JSON file and filtered the reports by the process name ((web pid 511027)).

// Import the JSON file
const report = require('./memory-report.json');

// Create a function to make the size (`amount`) human readable
const humanize = (number) => number > 1000000000
  ? (number / 1000000000).toFixed(2) + 'GB' : number > 1000000
  ? (number / 1000000).toFixed(2) + 'MB' : number > 1000 
  ? (number / 1000).toFixed(2) + 'kB' : number;

// Filter out reports not associated with the Deezer tab
let filtered = report.reports.filter(
  (item) => item.process === 'web (pid 511027)'
);

// Sort the reports by their size, highest first
filtered.sort((a, b) => a.amount > b.amount ? -1 : a.amount < b.amount ? 1 : 0);

// Print the reports to the console (warning: there are lots)
filtered.forEach((item) => console.log(
  humanize(item.amount), item.path, item.description
));

Looking at the output of the console log let me find the issue

6.67GB vsize Memory mapped by the process, including code and data segments, the heap, thread stacks, memory explicitly mapped by the process via mmap and similar operations, and memory shared with other processes. This is the vsize figure as reported by 'top' and 'ps'.  This figure is of limited use on Mac, where processes share huge amounts of memory with one another.  But even on other operating systems, 'resident' is a much better measure of the memory resources used by the process.
3.94GB heap-mapped Amount of memory currently mapped. Includes memory that is uncommitted, i.e. neither in physical memory nor paged to disk.
2.17GB resident-peak The peak 'resident' value for the lifetime of the process.
2.11GB resident Memory mapped by the process that is present in physical memory, also known as the resident set size (RSS).  This is the best single figure to use when considering the memory resources used by the process, but it depends both on other processes being run and details of the OS kernel and so is best used for comparing the memory usage of a single process at different points in time.
2.05GB resident-unique Memory mapped by the process that is present in physical memory and not shared with any other processes.  This is also known as the process's unique set size (USS).  This is the amount of RAM we'd expect to be freed if we closed this process.
1.99GB heap-committed/allocated Memory mapped by the heap allocator that is currently allocated to the application.  This may exceed the amount of memory requested by the application because the allocator regularly rounds up request sizes. (The exact amount requested is not recorded.)
1.99GB heap-allocated The same as 'heap-committed/allocated'.
44.50MB heap-committed/overhead The sum of 'explicit/heap-overhead/*'.
33.53MB js-main-runtime/realms/classes/objects/malloc-heap/elements/normal Normal (non-wasm) indexed elements.
...
524.29kB explicit/dom/memory-file-data/string Memory used to back a File/Blob based on a string.
524.29kB explicit/dom/memory-file-data/string Memory used to back a File/Blob based on a string.
524.29kB explicit/dom/memory-file-data/string Memory used to back a File/Blob based on a string.
...

There were 7965 reports in total, 3594 of which where

524.29kB  explicit/dom/memory-file-data/string Memory used to back a File/Blob based on a string.

These added up to the 2GB. Yahoo. So the issue was the Files/Blobs/MediaSources used to store the streamed music were not being cleaned up.

Looking for a way to list these objects, I found mention of revokeObjectURL() and wonder if this is what was happening - one of the ways to access a File or Blob from the DOM (the visible aspects of a web site), is to create an ObjectURL that you can then use on an HTML element (such as an img element to display an image). Once you are done with it, you have to revoke the ObjectURL so that the File or Blob can be removed from memory. If you don't they stick around until the page is closed or refreshed.

I ran some demonstration code in the DevTools Console to validate my thought.

// Create a ~520kB string to fill the Blobs
const part = 'zzzzzzzzz ';
let big = '';

for (let i = 0;i < 52000; i++) {
  big += part;
}

// Generate a memory report (60MB)

// Try making 400 Blobs without create an ObjectURL
for (let i = 0; i < 400; i++) {
  const blob = new Blob([big], {type: 'text/plain'});
}

// Generate a memory report (60MB)

// Make blobs and create an ObjectURL for each blob
// (saving the urls so they can be cleared later)
let urls = [];
for (let i = 0; i < 400; i++) {
  const blob = new Blob([big], {type: 'text/plain'});
  urls.push(URL.createObjectURL(blob));
}

// Generate a memory report (260MB)

// Revoke the ObjectURLs
urls.forEach((url) => URL.revokeObjectURL(url))

// Generate a memory report (60MB)

I found also found a note saying you don't need to use ObjectURLs for media streams any more, if anyone is dealing with a similar issue.

With the possible culprit nabbed, I reported it in hopes it will be fixed very soon.