Closed Bug 683271 Opened 13 years ago Closed 4 years ago

Endless nested Web Workers loop with passing a large string crashes firefox [@ OOM | small ]

Categories

(Core :: DOM: Workers, defect, P5)

x86_64
Windows 7
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox48 --- affected
firefox49 --- affected
firefox-esr45 --- affected
firefox50 --- affected
firefox51 --- affected

People

(Reporter: andreasschrade, Unassigned)

References

Details

(Keywords: crash)

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.215 Safari/535.1

Steps to reproduce:

I created a simple script that uses nested Web Workers to create a endless loop that consumes a big amount of memory through passing a large string value.
I dont know if this is a real bug. However my firefox 6.0 crashes after a few of seconds (~2sec).
It looks like that the problem is not direct the nested situation. It looks more like that the crash is caused by passing the large string.

:
HTML:
<html>
  <head>...</head>
  <body>
    <script>
    var worker = new Array();
    for(var i = 0; i < 10000; i++){
      worker[i] = new Worker('worker.js');
      worker[i].postMessage(0);
    }  
  </script>
  </body>
</html>


worker.js
onmessage = function (evt) {
    var worker = new Array();
    var x = evt;
    for(var i = 0; i < 220000; i++){
      worker[i] = new Worker('worker.js');
      var x = '000000000000000000000000000';
      x = x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x
      x = x+x+x+x+x+x+x+x+x+x+x+x;      
      worker[i].postMessage(x+x+x+x);
    }
};



Actual results:

Firefox crashes after few seconds ( 2 until max. 4 seconds)
Crash Signature: AdapterDeviceID: 9553 AdapterVendorID: 1002 Add-ons: firebug@software.joehewitt.com:1.8.1,{c45c406e-ab73-11d8-be73-000a95be3b12}:1.1.9,{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}:1.3.9 {972ce4c6-7e08-4474-a285-3208198ce6fd}:6.0 AvailableVirtualMemory: 87334…
Against Trunk I get no Crash just crawling Memory Usage (using WinXP). Probaply you just OOM'ed no?

And please name the Crash ID itself:
https://support.mozilla.com/en-US/kb/Firefox%20crashes?s=Crash+ID&as=s#w_get-help-fixing-this-crash
Crash Signature: AdapterDeviceID: 9553 AdapterVendorID: 1002 Add-ons: firebug@software.joehewitt.com:1.8.1,{c45c406e-ab73-11d8-be73-000a95be3b12}:1.1.9,{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}:1.3.9 {972ce4c6-7e08-4474-a285-3208198ce6fd}:6.0 AvailableVirtualMemory: 87334…
(I think Andreas is not around anymore.)
Severity: normal → critical
Component: General → Untriaged
Keywords: crash, stackwanted
Summary: Huge amout of nested Web Workers with passing a large string crashes firefox → Endless nested Web Workers loop with passing a large string crashes firefox (OOM?)
Whiteboard: dupeme
Here's a crash report: https://crash-stats.mozilla.com/report/index/df5d1309-ddec-416a-92d4-5d50c2141012

It's OOM indeed. Since bug 1034254's status whiteboard says to file reproducible cases as bugs, I'm not resolving it, although I'm not sure what could be done with this.
Status: UNCONFIRMED → NEW
Crash Signature: [@ OOM | small ]
Ever confirmed: true
Keywords: stackwanted
Product: Firefox → Core
Summary: Endless nested Web Workers loop with passing a large string crashes firefox (OOM?) → Endless nested Web Workers loop with passing a large string crashes firefox [@ OOM | small ]
Whiteboard: dupeme
Version: 6 Branch → Trunk
Blocks: 1096831
Component: Untriaged → DOM: Workers
Crash volume for signature 'OOM | small':
 - nightly (version 51): 326 crashes from 2016-08-01.
 - aurora  (version 50): 1858 crashes from 2016-08-01.
 - beta    (version 49): 35404 crashes from 2016-08-02.
 - release (version 48): 31967 crashes from 2016-07-25.
 - esr     (version 45): 56603 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly     124      83      67
 - aurora      789     535     129
 - beta      12624   11501    3868
 - release   10933    8962    4845
 - esr        4931    4726    4411

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly #23       #8
 - aurora  #8        #4
 - beta    #2        #1
 - release #1        #1        #1202
 - esr     #1
Priority: -- → P5

This falls under "eviltraps" wherein it's definitely possible to OOM firefox with behavior like this, but in particular this repro should now only cause termination of the content process in question, although the raid memory consumption could presumably cause the system OOM process terminator to terminate many uninvolved processes before the content process itself is terminated.

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