GC problems with long-running Workers

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
RESOLVED WORKSFORME
6 years ago
4 years ago

People

(Reporter: azakai, Assigned: Ben Turner (not reading bugmail, use the needinfo flag!))

Tracking

({regression})

Other Branch
regression
Points:
---

Firefox Tracking Flags

(firefox6-)

Details

(Whiteboard: bz nominated without comment)

Attachments

(2 attachments)

468 bytes, text/html
Details
490 bytes, application/javascript
Details
(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
Created attachment 529577 [details]
Worker
tracking-firefox6: --- → ?
(Reporter)

Comment 2

6 years ago
This is a regression, the test page here works fine in 3.6.16.
Keywords: regression

Updated

6 years ago
Whiteboard: bz nominated without comment
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?
Assignee: general → bent.mozilla
tracking-firefox6: ? → -
I think this is just a dup of bug 617569.
This test case behaves exactly as expected with the fix in bug 649537.
Depends on: 649537
(Reporter)

Comment 6

6 years ago
Works ok now, as expected (see last comment).
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.