1485078 - Gigabytes of script-sources memory on datascience.com

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[bht237]

https://www.datascience.com/blog/stock-price-time-series-arima

makes the computer unresponsive immediately, consuming 5GBytes of memory within seconds.

Comment 1

[Sam Foster [:sfoster] (he/him)]

(In reply to bht237 from comment #0)
> https://www.datascience.com/blog/stock-price-time-series-arima
> 
> makes the computer unresponsive immediately, consuming 5GBytes of memory
> within seconds.

Thanks for the report. A few questions: 

* Could you provide some detail on which version of the browser this is happening in.
* Can you reproduce the same problem using Nightly? You can download & install it from https://www.mozilla.org/firefox/channel/desktop/#nightly
* Would you be willing/able to try capturing a profile of this? The tool and instructions for use are at https://perf-html.io/, you would need to install the add-on, capture the profile for that page per the instructions and provide the link it produces here on this bug.

Comment 2

[Sam Foster [:sfoster] (he/him)]

Mike, I tried the datascience link and it took down Nightly on linux is short order. One for your collection?

Comment 3

[bht237]

Hi Sam, I appreciate your questions but currently I can't do this. Please see my report as my contribution. Please don't wait for me. Perhaps fixing this will also help resolve bug 1455161. I get memory leaks on 3 sites now. If a single person like me can get so many errors of the same type with a no-add-ons standard distribution then this should be a severe warning sign. I am a veteran developer and have been reporting hundreds of bugs since Netscape 2. Thanks.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Holy hell, this site is bonkers. It ate up 8GB is pretty much no time - the process became unusable before I could pull a memory report.

I think I'm going to redirect this to some MemShrink folk.

Comment 5

[Andrew McCreight [:mccr8]]

Hmm, maybe I could put together a DMD build that automatically triggers a report when we get to a few gigs of allocated memory. These cases where memory usage gets really bad really fast are hard to deal with.

Comment 6

[:Felipe Gomes (needinfo for replies!)]

Not a recent regression, I ran it with nightly from Jan 1st 2018 and the same problem happens.

Comment 7

[Justin Dolske [:Dolske]]

Over to Untriaged until we know what's happening.

Comment 8

[laszlo.bialis]

Hi!

I've reproduced the issue with success on Win 10 x64 latest Nightly 64.0a1 Build ID: 20180919123806. While trying to obtain a performance profile as requested in comment 1 I even had the following crash https://crash-stats.mozilla.com/report/index/8c17455a-d79e-431a-94f7-e26b40180919  

The performance profile can be found here : https://drive.google.com/file/d/1IIRb9wmfch11GawlpixRkHerN2VGEwly/view?usp=sharing

I've tried to obtain a regression window, going back through several versions of Nightly until Nightly version 37.0a1, but the memory consumption was high through all the versions I've tried. A difference was noticeable only form version 41.0a1 downwards, where the memory consumption peaked somewhere at 3.5 GB,compared to the previous cases where it easily reached 9.5 GB and more. Therefore I don't think we can find a regression range in this case.

Comment 9

[laszlo.bialis]

Hi Andrew,

Are there any updates related to this issue? Also please assign a component giving the fact that this is related with MemShrink.

Comment 10

[Andrew McCreight [:mccr8]]

(In reply to laszlo.bialis from comment #9)
> Are there any updates related to this issue? Also please assign a component
> giving the fact that this is related with MemShrink.

I haven't had a chance to look at this yet. Hopefully I'll get to it next week. I can't assign a component to it until some more investigation is done.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Attachment: Process sample on macOS

I was able to tease out a process sample from macOS

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Attachment: memory-report.json.gz

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Good news! I was able to get a memory report by throttling my network at just the right time before the content process got overwhelmed. Looks like script sources?

Comment 14

[Andrew McCreight [:mccr8]]

Thanks, Mike! I'll move this over to JS.

Comment 15

[Andrew McCreight [:mccr8]]

Ted, any ideas?

Comment 16

[bht237]

I don't know whether this is currently relevant, so please excuse my ignorance. When I had to deal with problems with JavaScript, I cloned the web site by copying all content to a locally running Apache web server. This is easy with both inspection of the server log and the browser's development tools. Then I would have that under version control, slowly simplifying the content step by step. Eventually I would only have a very small test case with the bug clearly exposed.

Otherwise, back to Java applets. They are safer. I can't browse the web anymore without a Firefox instance taking up 800MB and more, which is fairly much the limit with multiple processes running and other programs of course. It becomes kind of a joke needing a supercomputer just to run a web browser with five tabs open. Every monkey on the planet knows how to write some JavaScript these days which obviously is a security risk so I guess the browser needs to take care of that reality as well.

Comment 17

[André Bargull [:anba]]

The 3MB file names for the <script> elements with data-urls should probably be fixed, too. (*)

(*) It looks like the complete "src" attribute of <script> tags is passed to the compile-options as the file-name, even if the "src" is a data-url. So for example if we have:
---
<!DOCTYPE html>
<head>
    <meta charset="utf-8">
</head>
<body>
    <script>
        (function() {
            var prefix = "data:text/javascript;base64,";
            var js = `console.log("Source: %s", atob(decodeURIComponent(new Error().fileName.slice(${prefix.length}))))`;

            var script = document.createElement("script");
            script.type = "text/javascript";
            script.src = `${prefix}${encodeURIComponent(btoa(js))}`;
            document.getElementsByTagName("body")[0].appendChild(script);
        })();
    </script>
</body>
---

'Source: console.log("Source: %s", atob(decodeURIComponent(new Error().fileName.slice(28))))' will be printed to the console, which shows that the complete script source is recoverable.

Comment 18

[bht237]

I am glad you discovered the problem. Hopefully solving this will fix a few sites.

While you are involved in this, perhaps you could move on to another bug 1455161 which also produces an awful memory leak, sometimes almost as bad as this one. Thanks and good luck!

Comment 19

[Mike Conley (:mconley) (:⚙️)]

This bug is definitely outside of the purview of the front-end perf team, so fxperf-'ing.

Comment 21

[Nooni]

When loading the page:
https://www.datascience.com/blog/stock-price-time-series-arima
It still happens in latest version of FF as of today.

Installed Versions:
• Firefox version 65.0 (also relevant to previous versions: 64, 63)
• NoScript version 10.2.2rc2 (also relevant for latest stable versions: )
• Updated Windows 7 SP1

Description:
Upon loading the page (PLEASE DO NOT LOAD IT YET):
Firefox process starts consuming A LOT of memory: about 10 GB increase in few seconds,
and still increasing consuming virtual memory swap file.
The computer becomes sluggish, and there is a need to kill Firefox process.

Work around:
Either load the above mentioned page in another browser or
Use NoScript add-on and block raviolli77.github.io
There are plenty of domains linked to that page.
Seems to be only raviolli77.github.io the "bad actor".

Comment 22

[Ted Campbell [:tcampbell]]

Memory issue is fixed by Bug 1575077, but there is still a perf issue so I've opened Bug 1576999.

Comment 23

[Pablo]

Hi
I tried to replicate the bug on Windows 10 and also on windows 7 64bit
With firefox release version 85 and also with Firefox ESR 78.7.0 and i don´t see any response issue nor memory problem.

Does it still happen to you?

thanks
Pablo

Comment 24

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:sdetar, since the bug has high priority and high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 25

[mandeep]

totally! Your questions are excellent and demonstrate a genuine desire to learn. It’s inspiring to see someone actively seeking information and engaging in live discussion. It is a great opportunity to showcase your passion and knowledge. Asking questions can help you gain a deeper understanding of yourself and your life. Curiosity will be a valuable *et on your journey. Use your curiosity and never stop exploring. You can learn so much by asking questions.

https://www.sevenmentor.com/data-science-course-in-pune.php