Closed Bug 1291905 Opened 8 years ago Closed 2 years ago

Rogue web worker script on page hangs browser and/or performance profiler

Categories

(DevTools :: Performance Tools (Profiler/Timeline), defect, P2)

51 Branch
x86_64
All
defect

Tracking

(firefox51 affected)

RESOLVED WORKSFORME
Tracking Status
firefox51 --- affected

People

(Reporter: jujjyl, Unassigned)

Details

STR:

1. Visit http://s3.amazonaws.com/mozilla-games/emunittest-public/index.html?selectedTests=10kcubes
2. Scroll down the page and click on "Run tests" button, don't change any options. The "10kCubes" test will run
3. Wait until the test runs to completion (it spawns in a new window and closes after done)
4. Keeping the main page open, open a terminal window and type "htop -d 5"

Observed:

htop shows there is a plugin-container process that sits there, continuously taking up 100% of a single core. Waiting for x amount of time does not settle the process. Closing the main window does spin the process down. 

71490 clb        20   0 10.4G  401M  141M R 99.7  0.6  1:00.64 /home/clb/code/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/plugin-container -appdir /home/clb/code/gecko-de...

This performance hogging occurs deterministically on Linux, Windows and OS X each. (Windows Task Manager and OS X Process Monitor shows it)

I've tried to use the profiler to debug if there might be something running on the main page URL that is causing the performance leak, however Firefox profiler gets very unresponsive after running the above STR, so I've been unable to profile this in detail. Continuing the STR after step 4:

5. Right-click on the page, choose "Inspect Element..."
6. Open the "Performance" panel.
7. Choose "Start Recording Performance"
8. Profile for a small duration of time, e.g. for 2-5 seconds or so.
9. Click on "Stop Recording Performance"
10. Try to find the cause of the high CPU consumption in the profiler view.

Observed:

Firefox hangs or becomes very unresponsive in between steps 7-10, consuming 200% of CPU usage (2 cores at full load) and more than 4 GB of RAM. At this point, killing the Firefox process is the only option.
Upon further inspection, it looks like the culprit for the high memory usage is somehow related to a bug(?) in the core estimator script that is being used on the page, and removing that avoid the high memory usage. This resolves the first part, assuming that core estimator is going to a spinloop on its own.

The second part of this bug does seem valid still, raising the question of why the core estimator JavaScript worker would be able to bring down Firefox in such an effective manner. Nevertheless, lowering the importance, as it looks like the originating source is not in Firefox code, but in the core estimator add-on.
Severity: critical → normal
Summary: Plugin container busy-spins and hogs 100% of CPU, followed by browser deadlock if attempting to profile → Rogue web worker script on page hangs browser and/or performance profiler
Err, sorry, in comment 1, s/"memory usage"/"cpu usage", not sure why I was writing memory there.
Component: DOM: Content Processes → Developer Tools: Performance Tools (Profiler/Timeline)
Product: Core → Firefox
The STR from comment 0 was moved to permanently live in

https://s3.amazonaws.com/mozilla-games/bug1291905/index.html?selectedTests=10kCubes

because for the URL in comment 0, core estimator was removed altogether to work around the issue.
Reported the root issue with core estimator back to the project at https://github.com/oftn-oswg/core-estimator/issues/9. Debugging through the code suggests a minimal test case page that hangs Firefox altogether when one attempts to profile the following page:

<html>
  <script>
    onmessage = function() { postMessage(null, "*"); };
    postMessage(null, "*");
  </script>
</html>
Priority: -- → P2
Product: Firefox → DevTools

(In reply to Jukka Jylänki from comment #4)

Reported the root issue with core estimator back to the project at
https://github.com/oftn-oswg/core-estimator/issues/9. Debugging through the
code suggests a minimal test case page that hangs Firefox altogether when
one attempts to profile the following page:

<html>
<script>
onmessage = function() { postMessage(null, ""); };
postMessage(null, "
");
</script>
</html>

I tried this use case with the current profiler. The new profiler itself doesn't hang the browser so I'm gonna close this bug, but I do see the memory usage go up and up. I think this shouldn't happen so I filed a separate bug about that: bug 1768023.

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