As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 654265 - GC problems with long-running Workers
: GC problems with long-running Workers
bz nominated without comment
: regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: All All
: -- normal (vote)
: ---
Assigned To: Ben Turner (not reading bugmail, use the needinfo flag!)
: Jason Orendorff [:jorendorff]
Depends on: new-web-workers
  Show dependency treegraph
Reported: 2011-05-02 14:38 PDT by Alon Zakai (:azakai)
Modified: 2013-12-27 14:19 PST (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Page (468 bytes, text/html)
2011-05-02 14:38 PDT, Alon Zakai (:azakai)
no flags Details
Worker (490 bytes, application/javascript)
2011-05-02 14:38 PDT, Alon Zakai (:azakai)
no flags Details

Description User image Alon Zakai (:azakai) 2011-05-02 14:38:12 PDT
Created attachment 529576 [details]

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


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);


3. Abort (pretty early on, before lots of memory is used),

Program received signal SIGABRT, Aborted.
0xb7fe3832 in _dl_sysinfo_int80 () from /lib/
(gdb) where
#0  0xb7fe3832 in _dl_sysinfo_int80 () from /lib/
#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.
Comment 1 User image Alon Zakai (:azakai) 2011-05-02 14:38:38 PDT
Created attachment 529577 [details]
Comment 2 User image Alon Zakai (:azakai) 2011-05-02 19:17:05 PDT
This is a regression, the test page here works fine in 3.6.16.
Comment 3 User image Johnny Stenback (:jst, 2011-05-26 14:39:50 PDT
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?
Comment 4 User image Ben Turner (not reading bugmail, use the needinfo flag!) 2011-05-26 15:03:24 PDT
I think this is just a dup of bug 617569.
Comment 5 User image Ben Turner (not reading bugmail, use the needinfo flag!) 2011-06-05 18:40:58 PDT
This test case behaves exactly as expected with the fix in bug 649537.
Comment 6 User image Alon Zakai (:azakai) 2011-07-27 13:22:55 PDT
Works ok now, as expected (see last comment).

Note You need to log in before you can comment on or make changes to this bug.