1660922 - Memory leak on mlb.com

Status: UNCONFIRMED

(Core :: JavaScript Engine, defect, P3)

Description

[Rick Alther]

Attachment: Memory utilization for that process running mlb.com, after 1 hour.

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

Steps to reproduce:

I keep the mlb.com tab open on my browser, but the memory usage on that page ramps up quickly. After a few hours it's several gigabytes.

Actual results:

The tab displaying the mlb.com either has a memory leak or continued allocation.

Expected results:

I don't expect memory to continually go up.

Comment 1

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: memory-report.json.gz

Hi Rick,

Can you provide your about:support information? I will try to replicate, I'm using Windows 10 pro. I'll come back after some hours with https://www.mlb.com/ open, ( attaching currently memory report)
Can you try this on the latest version of nightly? You can download it from here: https://nightly.mozilla.org/

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Comment 2

[Rick Alther]

Attachment: about:support information for my browser

This is the about:support information that was requested.

Comment 3

[Rick Alther]

Ran this on Nightly. Only page was MLB.com. Enhanced tracking protection was off and AutoPlay videos was off. This is how I have it normally. BTW, Enhanced tracking protection is off in order to properly view MLB.tv. With it on, if you try to fast forward, drag the slider or go back, it messes up. Once tracking protection is off, it all works properly.

Initial startup with only mlb.com: 381.00MB
After 6 hours, 37 minutes: 3,3513.41 MB
Attached another screenshot of the about:memory allocations.

Comment 4

[Rick Alther]

Attachment: Memory utilization after 6.5 hours for mlb.com on Firefox Nightly

Memory utilization after 6.5 hours on Firefox nightly. Only tab was mlb.com. Enhanced tracking protection is off. Auto-play of video & audio is off. Page started off at 381 MB and grew to 3,513.41 MB after 6.5 hours.

Comment 5

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: memory-reportafter5hours.json.gz

Hi,

I'm still not able to reproduce, attaching my memory report after 5 hours having https://www.mlb.com/ open. If the dev team needs additional information they'll let you know.

Best regards,
Clara

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Redirecting to General as there's no evidence in this bug the Memory Allocator itself is at fault.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

Didn't intend to close this.

Comment 8

[Gian-Carlo Pascutto [:gcp]]

Looks like about 1.7GB in JS objects. Could just be the site itself leaking though?

Comment 9

[Jon Coppeard (:jonco)]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #8)

Could just be the site itself leaking though?

That's the most likely explanation.

Comment 10

[Nicolas B. Pierron [:nbp]]

Hi Rick,

Would you mind sharing the dominator view of the memory which is reported by the devtools, to help us isolate which part of the JS code is holding on memory. However, beware that the following memory profile would not be anonymized, as far as I can tell.

https://developer.mozilla.org/en-US/docs/Tools/Memory/Dominators_view

Comment 11

[Andrew McCreight [:mccr8]]

It would be good to know what happens with this site in Chrome. I'd expect it has the same issues there, but maybe not.

I've left MLB.com open for a few days, and I'm seeing similar behavior. I got a heap log (which is 2.6GB so it likely won't be too useful).

Here are some of the most common functions that showed up in the heap log (with their count and then the name of the script): 105316 Rf/t</< https://www.googletagservices.com/activeview/js/current/rx_lidar.js?cache=r20110914, 105316 Rf/t< https://www.googletagservices.com/activeview/js/current/rx_lidar.js?cache=r20110914, 82193 Function https://www.googletagservices.com/activeview/js/current/rx_lidar.js?cache=r20110914, 58700 n/this.dispatch https://snippet.minute.ly/publishers/70700/mi-1.14.2.40.js, 52806 Zb/< https://www.googletagservices.com/activeview/js/current/rx_lidar.js?cache=r20110914, 44574 [Symbol.hasInstance], 43598 <no private>, 39718 r https://snippet.minute.ly/publishers/70700/mi-1.14.2.40.js, 39715 o https://snippet.minute.ly/publishers/70700/mi-1.14.2.40.js, 39660 s https://snippet.minute.ly/publishers/70700/mi-1.14.2.40.js, 39239 i https://snippet.minute.ly/publishers/70700/mi-1.14.2.40.js,

and some of the most common scripts: scripts: 620917 https://www.googletagservices.com/activeview/js/current/rx_lidar.js?cache=r20110914, 148026 https://cdn.doubleverify.com/dv-measurements632.js, 65170 https://www.googletagservices.com/activeview/js/current/osd_listener.js?cache=r20110914, 54978 https://tpc.googlesyndication.com/pagead/js/r20201203/r20110914/abg_lite_fy2019.js, 28089 https://www.mlb.com/ line 1 > injectedScript,

Some other stats: shapes: 4794138, objects: 2889211, arrays: 772574, calls: 579322, object groups: 231516.

Comment 12

[Nicolas B. Pierron [:nbp]]

I managed to reproduce it once on Firefox and noticed some memory stacking up after a few days. However, when I tried to reproduce it while capturing the allocation stacks using the memory tab of the debugger, I failed to notice any increase of memory.

So far I noticed a non-conclusive increase of memory Chromium, but failed to leave the tab opened for 3 days.

I will reduce the priority&severity unless we manage to find a similar leak which ramp up faster.