1542995 - Thousands of window.onload events creates high memory/CPU until it crashes

Status: NEW

(Core :: General, defect, P3)

Description

[Karl Dubost💡 :karlcow]

This is https://webcompat.com/issues/28200

The site is indeed creating heavy processing and sometimes crashing.
I managed to create a performance profile on macOS.
https://perfht.ml/2Ia0xhf

There are basically thousands of cascading window.onload events.
You can see the browser getting super busy.

I'm not sure which component it should be but that's quite bad.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

I mean, the page has two scripts like this repeated:

<script>
  var $buoop = {
    vs:{i:7,f:5,o:10.6,s:5,n:9},
    text: "Váš prohlížeč je <b>zastaralý. Jsou známa <b>bezpečnostní rizika a pravděpodobně <b>nedokáže fungovat správně na této a dalších webových stránkách. <a target='_blank' href='https://browser-update.org/update-browser.html#3'>Naučte se, jak aktualizovat svůj prohlížeč"
  };
  $buoop.ol = window.onload;
  window.onload=function(){
    try {if ($buoop.ol) $buoop.ol();}catch (e) {}
    var e = document.createElement("script");
    e.setAttribute("type", "text/javascript");
    e.setAttribute("src", "https://browser-update.org/update.js");
    document.body.appendChild(e);
  }
</script>

Which means that it just recursively calls itself. Indeed chrome shows 10451 scripts at the end of the body, and presumably they just silently stop executing at some point.

I'm pretty sure we have such a recursion limit too. I wonder if this particular pattern bypasses it or something, or we don't even get to that point.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Testcase.

Chrome seems to stop executing script after a couple seconds... Jan, do you know why we're not in this case?

Comment 3

[Jan de Mooij [:jandem]]

It's related to recursion depth but profiles reveal an interesting perf issue with ObjectGroup::allocationSiteGroup. I have to double check my suspicion but I think we can go quadratic there due to bad HashTable behavior.

Comment 4

[Jan de Mooij [:jandem]]

(In reply to Jan de Mooij [:jandem] from comment #3)

It's related to recursion depth but profiles reveal an interesting perf issue with ObjectGroup::allocationSiteGroup. I have to double check my suspicion but I think we can go quadratic there due to bad HashTable behavior.

Filed bug 1543055. I'll fix that and see how it affects this.

Comment 5

[Jan de Mooij [:jandem]]

It's possible bug 1537609 will fix this in 66.0.3, but that's only on Windows.

We should probably consider capping our Mac/Linux recursion limits too :(

Comment 6

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 7

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 8

[Jan de Mooij [:jandem]]

Bug 1537609 should have fixed this on Windows (or at least improved it a lot). I filed bug 1578350 to apply the same stack quota cap on all platforms. It won't fix this completely (the JS code is just garbage) but it should make things a bit more usable.