537527 - Web Workers can be used to "fork bomb" Firefox

Status: RESOLVED WORKSFORME

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

Description

[andreas palsson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091216 Fedora/3.5.6-1.fc12 Firefox/3.5.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091216 Fedora/3.5.6-1.fc12 Firefox/3.5.6

With a simple script I can make Firefox degrade and finally die by using the new feature Web Workers.

Creating a Worker which calls a script, which creates a new Worker with the same script etc etc.
(I'll try to append some example files).

The operating system (Linux) also slows down and becomes sluggish.

An interesting side effect is that the page which initiated the fork bomb is of course restored by Session Restore when starting the browser after crash, so off we go again...




More details on this page on history and implementation on fork bombing;
  http://en.wikipedia.org/wiki/Fork_bomb


Reproducible: Always

Steps to Reproduce:
1. Create javascript file that creates Workers using the same javascript
2. Create a html file which creates a Worker using above javascript
3. Load page, watch and see Firefox degrade in performance and die.
Actual Results:  
Slow system, memory eaten up by Firefox.

Expected Results:  
Would be nice with some kind of limit of workers per document/website which prevented >100 workers without user confirmation.

Comment 1

[andreas palsson]

Attachment: Two example files for the bug. An HTML-document and a JavaScript file.

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

crash with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100102 Minefield/3.7a1pre ID:20100102044111

Signature	nsCOMPtr_base::~nsCOMPtr_base() | nsTArray<txExpandedNameMap_base::MapItem>::DestructRange(unsigned int, unsigned int)
UUID	0f41d41d-6494-46b2-836d-413e22100102
Time 	2010-01-02 07:39:28.787807
Uptime	5
Last Crash	483823 seconds before submission
Product	Firefox
Version	3.7a1pre
Build ID	20100102044111
Branch	1.9.3
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	GenuineIntel family 15 model 2 stepping 9
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x1
User Comments	Bug 537527
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsCOMPtr_base::~nsCOMPtr_base() 	obj-firefox/xpcom/build/nsCOMPtr.cpp:81
1 	xul.dll 	nsTArray<txExpandedNameMap_base::MapItem>::DestructRange(unsigned int,unsigned int) 	obj-firefox/dist/include/nsTArray.h:878
2 	xul.dll 	txHandlerTable::`scalar deleting destructor'(unsigned int) 	
3 	xul.dll 	txHandlerTable::shutdown() 	content/xslt/src/xslt/txStylesheetCompileHandlers.cpp:3078
4 	xul.dll 	txMozillaXSLTProcessor::Shutdown() 	content/xslt/src/xslt/txMozillaXSLTProcessor.cpp:1306
5 	xul.dll 	nsLayoutStatics::Shutdown() 	layout/build/nsLayoutStatics.cpp:304
6 	xul.dll 	nsContentUtils::WrapNative(JSContext*,JSObject*,nsISupports*,nsID const*,int*,nsIXPConnectJSObjectHolder**,int) 	
7 		@0x7fd203f 	
8 	xul.dll 	nsDOMWorkerFunctions::NewWorker(JSContext*,JSObject*,unsigned int,int*,int*) 	dom/src/threads/nsDOMWorker.cpp:367
9 	mozjs.dll 	js_Invoke 	js/src/jsinterp.cpp:1376
10 	mozjs.dll 	RefillFinalizableFreeList 	js/src/jsgc.cpp:1527
11 		@0x4cbff4f

Comment 3

[Jo Hermans]

The number of OS threads is already limited, it´s not really a fork bomb. See
<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020326.html> and
bug 530634. Bug 530886 is the master bug for improving scheduling in general.

You should be able to launch hundreds of web workers or more, by design. That´s
not a bug. I´m not sure if a maximum number would serve a real purpose, unless
its´a real huge number. It´s already possible to consume resources in lots of
different ways (loading thousands of images for instance, or lots of iframes),
this is just one of them.

Comment 4

[Jo Hermans]

I don´t want to imply that this shouldn´t be fixed, I just want to point out that launching hundreds of web workers should still be possible, even though it´s a bit silly (and scheduling will need to be improved). If there will be a limit it might be in the thousands.

Comment 5

[timeless]

comment 2 is bug 537572

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

This is fixed now with bug 649537.