Closed Bug 1323800 Opened 8 years ago Closed 2 years ago

DOS with JS running CPU to 100%

Categories

(Core :: JavaScript Engine, defect, P3)

50 Branch
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: aninax, Unassigned)

Details

(Keywords: triage-deferred, Whiteboard: [sg:dos])

Attachments

(1 file)

Attached file infihtml (7).html
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce:

open HTML page with JS in Firefox, remotely or locally, whatever. If you leave it open, FF can't close easily, it is not responding, and it is eating CPU and RAM. You can try same page to open in several tabs also.


Actual results:

 If you leave it open, FF can't close easily, it is not responding, and it is eating CPU. You can try same page to open in several tabs also. CPU is 100%.


Expected results:

this script is eating cpu, and if you leave it open it will eat CPU, RAM, and FF will be unresponding, maybe you should came in stage that you will need to restart comp, depends on HD performance.
Group: firefox-core-security
Whiteboard: [sg:dos]
I see "A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.

Script: https://bug1323800.bmoattachme….org/attachment.cgi?id=8818971:2" dialog in Nightly with e10s off, no memory growth, repeated the above warning to stop it.


An "A web page is slowing down your browser. What would you like to do?" warning appear in Nightly with e10s on, the page is always show as loading, as well as the browser normal and smooth, only CPU occupied. Closing the tab/browser is a few seconds delay.
User Agent:  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0

I have tested this issue on Windows 10 x64 with the latest Firefox release (50.1.0) and the latest Nightly (53.0a1-20170108030212) with e10s enabled/disabled and managed to reproduce it.
I have observed the same behavior as described by Yang in comment 1, 

I will assign a component to this issue and perhaps there's someone with extensive knowledge on this area that might be able to help here.
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: triage-deferred
Priority: -- → P3

This seems to be better now; I am able to stop the script with the slow script dialog, and browsing is recoverable.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: