Closed
Bug 1323800
Opened 8 years ago
Closed 3 years ago
DOS with JS running CPU to 100%
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: aninax, Unassigned)
Details
(Keywords: triage-deferred, Whiteboard: [sg:dos])
Attachments
(1 file)
123 bytes,
text/html
|
Details |
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.
Updated•8 years ago
|
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.
Comment 2•8 years ago
|
||
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
Updated•8 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•8 years ago
|
Keywords: triage-deferred
Priority: -- → P3
Comment 3•3 years ago
|
||
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: 3 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•