1888994 - https://basicpitch.spotify.com/ has exponential memory increase in the content process and parent process while playing a midi file that will cause the browser to crash

Status: REOPENED

(Core :: DOM: File, defect, P2)

Description

[Daniel]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0

Steps to reproduce:

Go to https://basicpitch.spotify.com/
Upload some random mp3
Wait
Play MIDI in the browser

Actual results:

High CPU, high memory use, tab crashes

kernel: [54102.898343] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=php8.3-fpm.service,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[e-mail]/app.slice/app-firefox-63920b14a404496cbf0df4e89e747af8.scope,task=Isolated Web Co,pid=122092,uid=1000
Apr 2 00:08:36 kernel: [54102.898428] Out of memory: Killed process 122092 (Isolated Web Co) total-vm:19009680kB, anon-rss:11853540kB, file-rss:300kB, shmem-rss:65064kB, UID:1000 pgtables:25128kB oom_score_adj:100
Apr 2 00:08:36 systemd[2496]: app-firefox-63920b14a404496cbf0df4e89e747af8.scope: A process of this unit has been killed by the OOM killer.

Expected results:

MIDI played

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Mayank Bansal]

Can confirm.
As soon as you start to play the midi, the memory rises exponentially and you get a OOM.
FWIW, Chrome also has increase in memory. BUT, A)increase is slower, B)only the content process has memory increase, C)If you put the tab in background, the memory decreases

Comment 3

[Mayank Bansal]

https://share.firefox.dev/3PMRqo9
Profile with media playback preset logging.

Comment 4

[Mayank Bansal]

Attachment: memory-report.json.gz

Comment 5

[Mayank Bansal]

The website is weird. First, to analyze a simple .wav file it uses tons of GPU and then tons of CPU. Then when it does convert the file into midi, tthe playback immediately increases the memory.

Comment 6

[Mayank Bansal]

Attachment: Even larger memory use

Comment 7

[Mayank Bansal]

Attachment: about:support

Comment 8

[Mayank Bansal]

Attachment: onara.wav

Comment 9

[Mayank Bansal]

Attachment: log.txt-main.7996.moz_log

media preset logging. But I dont think for some reason the log only captured a small bit.

Comment 10

[Paul Adenot (:padenot)]

This website plays audio, but the CPU and memory usage isn't media related, redirecting. Thanks for the analysis and profile!

This looks like inefficiencies related to Blob.

Comment 11

[Andrew McCreight (out until 2026) [:mccr8]]

Thanks for gathering the memory reports, Mayank.

From the main process:

3,633.97 MB (100.0%) -- explicit
├──3,353.99 MB (92.30%) ── heap-unclassified

From the spotify process:

3,642.03 MB (100.0%) -- explicit
├──3,304.99 MB (90.75%) -- dom
│ ├──3,304.99 MB (90.75%) -- memory-file-data
│ │ ├──3,304.99 MB (90.75%) ── large/file(length=34311152, sha1=9f9d90a1c430be5fd166c861e53e348d2605face) [101]

The [101] means there were 101 entries with that exact path, so it looks like we're leaking a bunch of copies of something.

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

It's quite possible this isn't a leak but rather a difference in the situation in which we will spill a Blob/File to disk to be disk-backed instead of memory-backed. If content does new Blob/File and hands us a string/array/anything that isn't already a Blob, we just leave the underlying storage as memory-backed, whereas I believe Chrome will potentially spill to disk more aggressively in this case. (I believe we spill to disk currently only at minting time only in a few cases (uses diagram).)

Comment 13

[Mayank Bansal]

The rapid increase in parent-process bisects to this : https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=78891f7979388fa45ab723820da5f700718a953c&tochange=63e3e58c38ba175ae6d1ab68e482be74be93f723

The increase in content-process is older.

Comment 14

[Daniel]

Seems to be fixed in v137.0.1

Comment 15

[Jens Stutte [:jstutte]]

(In reply to Daniel from comment #14)

Seems to be fixed in v137.0.1

Thank you for checking! We probably cannot really know if the site changed or we really fixed this, but WFM sounds right then.

Comment 16

[Mayank Bansal]

I can still repro.