Closed Bug 1562700 Opened 4 months ago Closed 2 months ago

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

Categories

(Core :: JavaScript Engine, defect)

68 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1578350

People

(Reporter: gsalgado, Unassigned)

References

Details

Attachments

(2 files)

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

Version: 67 Branch → 68 Branch

Reproducible on 68.0b14 as well

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

Attached image ubuntuu.jpg
Attached image 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)

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

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

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

Component: Untriaged → Memory Allocator
Product: Firefox → Core

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

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(mh+mozilla)

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.

Component: Memory Allocator → JavaScript Engine
Flags: needinfo?(mh+mozilla)

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

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.

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) {}
}
Depends on: 1578350
See Also: → 1578220
Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1578350

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.

You need to log in before you can comment on or make changes to this bug.