When a worker thread runs a very long section of code without stopping, during which it creates garbage, there are problems with cleaning it up. In the attached case, I see the following: 1. Memory usage goes up until the machine is out of memory, that is, GC is not done or 2. Memory usage goes up until it stops, at which point the console shows lots of /threads/nsDOMWorkerTimeout.cpp, line 142 WARNING: NS_ENSURE_TRUE(ok) failed: file /home/alon/Dev/mozilla-central/dom/ that is in nsDOMWorkerTimeout::FunctionCallback::Run, this fails: JSBool ok = JS_CallFunctionValue(aCx, global, mCallback, mCallbackArgsLength, argv.Elements(), &rval); NS_ENSURE_TRUE(ok, NS_ERROR_FAILURE); or 3. Abort (pretty early on, before lots of memory is used), Program received signal SIGABRT, Aborted. 0xb7fe3832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) where #0 0xb7fe3832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7fc3230 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42 #2 0xb78b64b6 in JS_Assert (s=0xb7cb861c "acx->hasRunOption(JSOPTION_UNROOTED_GLOBAL)", file=0xb7cb8314 "/home/alon/Dev/mozilla-central/js/src/xpconnect/src/xpcjsruntime.cpp", ln=434) at /home/alon/Dev/mozilla-central/js/src/jsutil.cpp:89 I have seen all three happen. I suspect which happens depends on how much system memory there is and/or is random to some degree. The attachments are a web page and a worker. In both, set HANG to 1 for the script to hang as it runs a silly benchmark that creates lots of garbage. A. When the web page hangs, memory usage remains controlled (GC works properly), no matter how long it runs. B. When the web worker hangs, we get the issues mentioned above. C. When the web worker does not hang, it still creates the same amount of garbage over time, but apparently running in a timeout is enough for GC to clean it up. The problems mentioned above happen when HANG is 0 in the page and 1 in the worker.

This is a regression, the test page here works fine in 3.6.16.

Not tracking this, but if this is a bigger problem in the wild than it appears, please renominate and explain why this is important for 6. Ben, I don't think this is a JS engine bug, can you have a look on the worker side?

I think this is just a dup of bug 617569.

This test case behaves exactly as expected with the fix in bug 649537.

Works ok now, as expected (see last comment).