1496701 - Memory Leakage when writing to outerHTML in a loop can lead to the OS crashing.

Status: NEW

(Core :: XPCOM, defect, P3)

Description

[Dominik]

Attachment: The POC html file. Open and wait.

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

Steps to reproduce:

The tested systems are Firefox 62.0.3 on Ubuntu 18.04, once in a VM and once on bare metal.

Step 1) put around 500 lines of static HTML into a file (I copied some code from www.heise.de).
Step 2) append a script with the following code:
while(1) window.document.body.outerHTML = window.document.body.outerHTML
Step 3) Open in Firefox via file:// or http://. Then wait and ignore the message about the site being unresponsive.


Actual results:

The memory usage rises until 100% or RAM and 100% of swap are used. Both the VM's and the bare metal installation's operating systems freeze. Recovery is only possible via hard reboot.

Firefox shows a warning because of the long-running loop. But when the user doesn't click the stop button, the script is allowed to continue execution.

A plausible scenario is that the user opens the site, goes to get a coffee and upon returning finds that the entire OS is frozen.




Expected results:

Constant memory usage. Furthermore, Firefox normally throws a Memory Error when a script is using too much space.

The <script> tag is deactivated at the very first run of the loop because outerHTML does not evaluate <script>'s. Therefore, one could assume that the script is stopped at some point.

Regarding the unhindered script execution: Google Chrome requires the user to ->continue<- the script while Firefox prompts the user to ->stop<- the script. Both ways have pro's and con's. In this context, requesting continuation would alleviate the problem.

Comment 1

[Dominik]

Attachment: The memory usage in the Ubuntu System Monitor

Comment 2

[Johann Hofmann [:johannh]]

Considering that the user is able to stop the script from running I'd say this is not an issue that needs to stay hidden. We have public bugs that affect the chrome process as well.

Comment 3

[Selena Deckelmann :selenamarie :selena]

Handing over to memShrink to look into whether there's a leak we could do something about here, or if it's just resource exhaustion.

Comment 4

[Andrew Overholt [:overholt]]

Henri, is there anything we can/should do here or is it just a wrinkle of the web platform?

Comment 5

[Henri Sivonen (:hsivonen)]

I suspect this is a matter of the busy loop in JS not giving time for the cycle collector to run.

smaug, do we have any heuristics to pre-empt busy scripts once in a while to run CC? Should we tweak those heuristics?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

We don't have any heuristics for busy js loop case. In general we'd prefer to not run CC at such times.

But this isn't that much different to
while(1) document.documentElement.appendElement(document.documentElement.cloneNode(true));
which isn't something CC or GC can deal with.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

I guess this is still somehow generic memory management issues, so xpcom.