Closed Bug 487465 Opened 15 years ago Closed 15 years ago

Web Workers: Spining up many busy workers can make browser unresponsive

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jarbon, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3

1. Load script that creates many (1000's of workers.).
2. Browser becomes unresponsive, spins very high CPU
3. Concern is primarily that poorly written or malicious scripts can hang the browser and possible loss of user data/state.


Reproducible: Always

Steps to Reproduce:
Main repro page content:

<body>
<p>Kicking off huge # of workers. Should be prompted to stop script.</p>
<div id=result></div>
<div id=counter></div>
<script>
function log(message)
{
    document.getElementById("result").innerHTML += message + "<br>";
}
function logCounter(message)
{
    document.getElementById("counter").innerHTML = message + "<br>";
}

var bg_workers = new Array();

function makeHandler(workerNum) {
   return function(evt) {logCounter('Worker#:' + workerNum + ': ' + evt.data);};
}

function addBackgroundWorker() {
    var worker = new Worker('resources/worker-calc-primes.js');
    worker.onmessage = makeHandler(bg_workers.length); 
    worker.postMessage("100000000000");
    bg_workers.push(worker);
    
}

setTimeout(KillWorkers, 1000);

function KillWorkers() {
  var num_workers_to_term = bg_workers.length;
  for (var w=0; w < num_workers_to_term; w++) {
    bg_workers[w].terminate();
    //alert('terminated' + w);
  }
  
  alert('terminated all ' + num_workers_to_term);
}

var num_workers = 100000;
for (var i=0; i < num_workers; i++) {
  setTimeout('addBackgroundWorker()');
}

function showResults() {
  log('FAILED: Script should have been stopped automatically.');
}

</script>
</body>
</html>


Worker JS:
function onmessage(evt)
{
    try {
      var n = parseInt(evt.data);    
     while(true){
  search: while (true) {
  n += 1;
  for (var i = 2; i <= Math.sqrt(n); i += 1)
    if (n % i == 0)
      continue search;
      // found a prime!
      break;
  }  
      postMessage(n); 
     };
    } catch (ex) {
        postMessage(ex);
    }
    
}

addEventListener("message", onmessage, true);



Actual Results:  
Browser becomes unresponsive.
Machine's cpu nears 100%
Have to force quit the browser.

Expected Results:  
1. Browser not unresponsive.
2. Perhaps an 'unresponsive script' dialog shown allowing user to stop workers?


This is also an issue with WebKit. Found while testing webkit workers.
Status: UNCONFIRMED → NEW
Component: General → DOM: Mozilla Extensions
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
So I don't know what the bug you're reporting is actually. I can't make the browser become unresponsive even though the CPU goes really high (as is to be expected)...

Were you maybe running a debug build when you were testing? We have some deadlock detection code that this testcase really slows down, but that doesn't happen in release builds.

Two things about your script, btw:
1. Your terminate function isn't killing all the workers as you're not guaranteed that the KillWorkers timeout runs after all the addBackgroundWorker timeouts.
2. You're actually registering two message listeners on the worker by naming your function 'onmessage'. No need for the addEventListener call.

I did identify a little bit of extra work that we can avoid though. Patch for that in bug 488080.
Thanks, I'll make those changes to the script.  Note, I was running the latest public (non debug) build of FF3.1 on a Mac Laptop.  The browser became unresponsive to mouse clicks as the script spun up workers. I don't believe the browser was totally locked up, just very slow responding to user input as cpu was maxed out.  

I've only tested on one mac, maybe my machine with other apps doesn't behave well with low cpu...

Net Net, spinning up the cpu to near 100% is a bad thing and generally likely to make the system unresponsive for users.  Sorry if i shouldn't have made such a blanket statement as to the effects of the 100% cpu.
Going to resolve this WFM.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
I get something very similar. However I simply run the Peacekeeper test and I do not get a high CPU usage (actually 0%), instead the test simply halts and keeps loading.

I am using Firefox Nightly on Mac OS X Lion. (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120423 Firefox/14.0a1 ID:20120423030700).
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.