Closed Bug 683271 Opened 14 years ago Closed 6 years ago

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

Categories

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

Product:
Core
Component:
DOM: Workers
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
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
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
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox-esr45: --- → affected
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: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.