1562700 - Uninterrupted 100% CPU usage on Santander Totta's login page

Status: RESOLVED DUPLICATE of bug 1578350

(Core :: JavaScript Engine, defect)

Description

[Guilherme Salgado]

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

Steps to reproduce:

Using fresh firefox 67.0.4 profile, open https://www.particulares.santandertotta.pt/pagina/indice/0,,276_1_2,00.html?usr=Nome%20de%20Utilizador

Actual results:

Page loads (with some hiccups) and firefox uses 100% of one of my cores

Expected results:

Page loads and firefox does not use 100% of one of my cores, like when I open that page in Chromium

Comment 1

[Guilherme Salgado]

Reproducible on 68.0b14 as well

Comment 2

[Pablo]

Good afternoon
i was unable to replicate this problem, i used ubuntu 18.04.2 LTS 64bit With firefox release 67.0.4 64bit. (see screenshot attached)
Are you using any addons that could cause problems?

please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.

If you still have the issue please create a new profile, you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Lastly test if the issue is reproducible in safe mode, here is a link that can help you:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Regards
Pablo

Comment 3

[Pablo]

Attachment: ubuntuu.jpg

Comment 4

[Guilherme Salgado]

Attachment: nightly cpu usage

As mentioned in the description, I was able to reproduce this using a fresh profile (using firefox --profile=/tmp/ff-tmp), so no extensions. But I'm running Ubuntu 19.04.

Just tested it on FF nightly, and got the same behaviour (see screenshot)

Comment 5

[Guilherme Salgado]

Oh, just noticed that on Pablo's screenshot, the Web Content process is using 12% CPU, so if he has 8 cores, that would be the same behaviour I'm seeing -- i.e. one core at 100%. In my case it's 25% as I have 4 cores

Comment 6

[Pablo]

Hi

Can you please capture a performance profile? You can get more info on how to install and use the Cleopatra add-on (that helps you get the performance profile) by going to:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
https://perf-html.io/
Please also note that this add-on works only on Firefox Nightly, so that means you need to be able to reproduce the issue on Nightly first.

Regards
Pablo

Comment 7

[Guilherme Salgado]

Here's the profile data: https://perfht.ml/2GcMfdd

Comment 8

[Pablo]

Hi, thanks for the performance profile captured, Im not sure if Memory Allocator is the correct component but maybe one of our developers can take a look at the profile and move this to a more suitable component

Comment 9

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

The priority flag is not set for this bug.
:glandium, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 10

[Eric Rahm [:erahm]]

The perf profile indicates there's a script on that page that's using a ton of CPU. Lets move this over to JS for now to see if they have any insights.

Comment 11

[Jason Orendorff [:jorendorff]]

This looks like bug 1537609. The profile shows runaway JS recursion and the string debuggerProtection appears in the script.

Comment 12

[Jason Orendorff [:jorendorff]]

Summary of that bug: we increased the stack size on Windows. This was supposed to be a good thing. But some web sites contain do-nothing code that just overflows the stack, to discourage debugger usage. These sites rely on the stack size being quite low; if it is too generous, they become extremely slow.

Comment 13

[Jason Orendorff [:jorendorff]]

Well, obfuscated stack overflow code is the culprit here, but according to nbp, our stack is only 8MB on Linux—a reasonable size. I don't know why the same thing doesn't happen in Chrome.

This appears in the script:

function _0x350612(_0x4b463f){function _0x2ef841(_0x5ec3e5){if(typeof _0x5ec3e5===_0x3a6d('0x93d','d0)f')){return
function(_0x57572e){}[_0x3a6d('0x93e','qHvK')](_0x3a6d('0x93f','b!8W'))[_0x3a6d('0x940','szhN')](_0x3a6d('0x941','X56f'));
}else{if((''+_0x5ec3e5/_0x5ec3e5)[_0x3a6d('0x942','F)Br')]!==0x1||_0x5ec3e5%0x14===0x0){(function(){return!![];}
[_0x3a6d('0x943','@x3s')](_0x3a6d('0x944','^lIo')+'gger')[_0x3a6d('0x43e','qHvK')](_0x3a6d('0x945','^lIo')));}else{
(function(){return![];}[_0x3a6d('0x946','Vkyn')](_0x3a6d('0x947','NR4[')+_0x3a6d('0x948','jc1*'))[_0x3a6d('0x949','A7K%')]
('stateObject'));}}_0x2ef841(++_0x5ec3e5);}try{if(_0x4b463f){return _0x2ef841;}else{_0x2ef841(0x0);}}catch(_0x473c12){}}

Many calls to this function are sprinkled throughout the script, including this: setInterval(function(){_0x350612();},0xfa0). So this is called at least every 4 seconds.

It boils down to this:

function annoy_user(create_function_only) {
  function stay_busy(x) {
    debugger;
    stay_busy(x + 1);
  }

  try {
    stay_busy(0);
  } catch (err) {}
}

Comment 15

[Michael Ficarra]

Programs that have been "protected" using javascript-obfuscator with the debugProtection feature enabled will contain the code to intentionally try/catch a stack overflow for self-recursive functions. The setInterval usage comes from enabling its debugProtectionInterval feature.