Ben Kelly [:bkelly, not reviewing] Reporter
	Description • 8 years ago

STR:

1) Open fresh browser instance
2) Open a content window with a service worker (I used blog.wanderview.com)
3) Open about:debugging#workers
4) Start the service worker if necessary by refreshing the content tab (start button has a bug)
5) Click debug to open a worker debug window
6) Wait a few seconds for window to completely initialize (some things appear lazy loaded)
7) Close debug window
8) Repeat steps 4 to 7 many times
9) Open about:memory, minimize, and measure
10) Observe in the js-main-runtime-compartments section of the content process that there are numerous sandbox compartments leaked
11) Repeat steps 4 to 7
12) Minimize and measure in about:memory
13) Observe that the number of compartments has increased

In my about memory at the moment I see this:

124 (100.0%) -- js-main-runtime-compartments
├──120 (96.77%) -- system
│  ├───91 (73.39%) ++ (91 tiny)
│  ├────5 (04.03%) ── [System Principal], [anonymous sandbox] (from: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/builtin-modules.js:183) [5]
│  ├────5 (04.03%) ── [System Principal], [anonymous sandbox] (from: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/builtin-modules.js:209) [5]
│  ├────5 (04.03%) ── [System Principal], [anonymous sandbox] (from: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/builtin-modules.js:220) [5]
│  ├────5 (04.03%) ── [System Principal], [anonymous sandbox] (from: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/builtin-modules.js:227) [5]
│  ├────5 (04.03%) ── [System Principal], Addon-SDK (from: resource://gre/modules/commonjs/toolkit/loader.js:249) [5]
│  └────4 (03.23%) ── [System Principal], [anonymous sandbox] (from: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/child-process.j

Note that I tried applying the patch from bug 1281040, but it did not help.

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 1 • 8 years ago

I tried looking at the CC logs, but I don't know where to start.  What is the equivalent c++ object for a compartment?  I normally look for nsGlobalObject when windows leak.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 2 • 8 years ago

For sandboxes, SandboxPrivate.

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 3 • 8 years ago

Hmm, that didn't give me too much to go on:

$ /c/devel/heapgraph/find_roots.py cc-edges.9868.1467299147.log 000001CA7E9E65C0
Parsing cc-edges.9868.1467299147.log. Done loading graph.

000001CA7E76C1A0 [JS Object (Sandbox)]
    --[js::GetObjectPrivate(obj)]--> 000001CA7E9E65C0 [SandboxPrivate]

    Root 000001CA7E76C1A0 is a marked GC object.


bkelly@kosh /c/devel/tmp/cclogs/addon-loader
$ /c/devel/heapgraph/find_roots.py gc-edges.9868.1467299147.log -bro 000001CA7E76C1A0
Parsing gc-edges.9868.1467299147.log. Done loading graph.

via persistent-Object :
000001CA7E76C1A0 [Sandbox 1ca7e9e65d8]

	Andrew McCreight [:mccr8]
	Comment 4 • 8 years ago

That means there is some PersistentRooted sitting around in C++ for this sandbox. Somebody who understands how the debugger roots things probably needs to figure this out.

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 5 • 8 years ago

Eddy, any thoughts?

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 6 • 8 years ago

Of course, I don't know if I have the right sandbox in the CC log...  there are a lot with rc=1.

	Eddy Bruel [:ejpbruel]
	Comment 7 • 8 years ago

(In reply to Ben Kelly [:bkelly] from comment #5)
> Eddy, any thoughts?

To my knowledge, in a worker, the debugger can create sandboxes, but the debuggee cannot. Moreover, these sandboxes can never be accidentally exposed to the debuggee (we have a security wrapper that ensures this). Consequently, if we are leaking a sandbox, we must be leaking it in the debugger server.

The debugger server is written in pure JS, so it's not immediately obvious to me how it could be leaking a sandbox. The debugger server does interact with the debugger API, so if we are leaking a root somewhere, that's where I would look for it.

Unfortunately, without more information about what we're leaking, I don't really know where to go from there. Is there some way we could get more information on the nature of the leak?

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 8 • 8 years ago

(In reply to Eddy Bruel [:ejpbruel] from comment #7)
> The debugger server is written in pure JS, so it's not immediately obvious
> to me how it could be leaking a sandbox.

If only it were that easy.

One thing you might try is taking logs before starting the debugger and afterwards.  Then you'll know which Sandboxes are presumably debugger-related.

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 9 • 8 years ago

Nick, do you have any time to look at this?  Since you are already in devtools memory land...

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 10 • 8 years ago

It would be interesting to see if this is fixed after bug 1261869 merges into m-c. Unfortunately, I don't have time to dig into this at the moment, but maybe in a couple weeks.

	Eric Rahm [:erahm]
	Comment 11 • 8 years ago

bug 1261869 merged to central 6 days ago, Ben can you try to repro again?

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 12 • 8 years ago

This still reproduces as of nightly 50.0a1 (2016-07-14).

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 13 • 8 years ago

My nightly was lagging quite a lot tonight.  Looking in about:memory I found this in the content process:

898.04 MB (100.0%) -- explicit
├──472.93 MB (52.66%) -- js-non-window
│  ├──453.76 MB (50.53%) -- zones
│  │  ├──448.97 MB (49.99%) -- zone(0x113133000)
│  │  │  ├──305.00 MB (33.96%) ++ compartment([System Principal], Addon-SDK (from: resource://gre/modules/commonjs/toolkit/loader.js:249))

That's a huge amount of js-non-window.  Seems it might be related to this bug:

1,362 (100.0%) -- js-main-runtime-compartments
├──1,359 (99.78%) -- system
│  ├────296 (21.73%) ── [System Principal], [anonymous sandbox] (from: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/builtin-modules.js:185) [296]
│  ├────296 (21.73%) ── [System Principal], [anonymous sandbox] (from: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/builtin-modules.js:209) [296]
│  ├────296 (21.73%) ── [System Principal], [anonymous sandbox] (from: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/builtin-modules.js:24) [296]
│  ├────296 (21.73%) ── [System Principal], Addon-SDK (from: resource://gre/modules/commonjs/toolkit/loader.js:249) [296]