Last Comment Bug 654265 - GC problems with long-running Workers
: GC problems with long-running Workers
Status: RESOLVED WORKSFORME
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]
Mentors:
Depends on: new-web-workers
Blocks:
  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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
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 Alon Zakai (:azakai) 2011-05-02 14:38:12 PDT
Created attachment 529576 [details]
Page

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.
Comment 1 Alon Zakai (:azakai) 2011-05-02 14:38:38 PDT
Created attachment 529577 [details]
Worker
Comment 2 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 Johnny Stenback (:jst, jst@mozilla.com) 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 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 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 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.