The default bug view has changed. See this FAQ.

TypeCompartment::constrainedOutputs leaks on testLeftShift.js

RESOLVED FIXED in mozilla17

Status

()

Core
JavaScript Engine
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: njn, Assigned: nbp)

Tracking

unspecified
mozilla17
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js:t])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Running jit_test.py with --valgrind I get this:

==22813==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22813==    by 0x4148C4: js_malloc (Utility.h:157)
==22813==    by 0x418AB2: JSRuntime::malloc_(unsigned long, JSContext*) (jscntxt.h:892)
==22813==    by 0x418B2F: JSContext::malloc_(unsigned long) (jscntxt.h:1350)
==22813==    by 0x4F2343: js::Vector<js::analyze::SlotValue, 0ul, js::TempAllocPolicy>* JSContext::new_<js::Vector<js::analyze::SlotValue, 0ul, js::TempAllocPolicy>, JSContext*>(JSContext*) (in /home/njn/moz/mi9/js/src/d64/shell/js)
==22813==    by 0x717D3D: js::types::AutoEnterCompilation::init(JSScript*, bool, unsigned int) (jsinferinlines.h:315)
==22813==    by 0x7240E9: js::mjit::Compiler::performCompilation() (Compiler.cpp:514)
==22813==    by 0x722C78: js::mjit::Compiler::compile() (Compiler.cpp:114)
==22813==    by 0x726322: js::mjit::CanMethodJIT(JSContext*, JSScript*, unsigned char*, bool, js::mjit::CompileRequest, js::StackFrame*) (Compiler.cpp:1008)
==22813==    by 0x50AFE2: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:1468)
==22813==    by 0x50607B: js::RunScript(JSContext*, JSScript*, js::StackFrame*) (jsinterp.cpp:308)
==22813==    by 0x506E50: js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::StackFrame*, JS::Value*) (jsinterp.cpp:492)

In other words, the TypeCompartment::constrainedOutputs vector allocated in AutoEnterCompilation::init() isn't being freed.  There is a corresponding delete in TypeCompartment::sweepCompilerOutputs() but it's conditional and I guess it's not being hit.

Judging from |hg blame|, bug 772509 is the likely cause here.
(Assignee)

Comment 1

5 years ago
The only allocation site of this vector is AutoEnterCompilation::init() which set the flag preventing the sweeping of the vector in sweepCompilerOutputs because the index is still used by frozen constraints created between AutoEnterCompilation::init() and the GC cycle.  This flag is supposed to be reset by AutoEnterCompilation's destructor.

Ask me for review if you want to do it, or assigned me the bug otherwise.

Do you have a precise test case or all of them have this leak?
(Assignee)

Comment 2

5 years ago
(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #1)
> Do you have a precise test case or all of them have this leak?

Ok, I read the bug title: testLeftShift.js
(Reporter)

Comment 3

5 years ago
I assigned it to myself by mistake -- I'm happy for you to take it.

jit_test.py only runs three tests under Valgrind, so I suspect it will be happening on plenty of other test case.
Assignee: n.nethercote → nicolas.b.pierron
(Assignee)

Comment 4

5 years ago
Created attachment 652952 [details] [diff] [review]
Fix inverted condition.

Oops.
Attachment #652952 - Flags: review?(bhackett1024)
Attachment #652952 - Flags: review?(bhackett1024) → review+
(Reporter)

Comment 5

5 years ago
Now I'm wondering why this wasn't detected automatically.  Are we not running jit_test.py with --valgrind on Linux on TBPL?
(Assignee)

Comment 6

5 years ago
Comment on attachment 652952 [details] [diff] [review]
Fix inverted condition.

inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/1906fe4159fe
ionmonkey: https://hg.mozilla.org/projects/ionmonkey/rev/8b2c0239f5bc
Attachment #652952 - Flags: checkin+
(Assignee)

Updated

5 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 7

5 years ago
May want to hold up on resolving it FIXED until it lands on M-C.
(Assignee)

Comment 8

5 years ago
(In reply to Paul Wright from comment #7)
> May want to hold up on resolving it FIXED until it lands on M-C.

Sorry, I am used to do so with IonMonkey, and the patch will be backout from inbound after-all.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 9

5 years ago
reverted on inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/9434db5cfd47
Blocks: 784187
(Assignee)

Comment 10

5 years ago
reverted on ionmonkey: https://hg.mozilla.org/projects/ionmonkey/rev/6b2a947da355
(Assignee)

Comment 11

5 years ago
Created attachment 654307 [details] [diff] [review]
Fix condtion for freeing compiler output vector.

- Fix inverted condition.
- Invalidate if we are not discarding the constraints.
Attachment #652952 - Attachment is obsolete: true
Attachment #654307 - Flags: review?(bhackett1024)
Comment on attachment 654307 [details] [diff] [review]
Fix condtion for freeing compiler output vector.

Review of attachment 654307 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jscompartment.cpp
@@ +534,5 @@
>  JSCompartment::sweep(FreeOp *fop, bool releaseTypes)
>  {
>      {
>          gcstats::AutoPhase ap(rt->gcStats, gcstats::PHASE_SWEEP_DISCARD_CODE);
> +        discardJitCode(fop, true);

This should pass the condition under which constraints are actually being discarded below, '!activeAnalysis && !gcPreserveCode', to match the assumed semantics of the discardConstraints parameter.

::: js/src/jsinfer.cpp
@@ +5728,5 @@
>  {
>  
>      if (constrainedOutputs) {
>          bool isCompiling = compiledInfo.outputIndex != RecompileInfo::NoCompilerRunning;
> +        if (discardConstraints && !isCompiling && !compartment()->activeAnalysis) {

The above change means that discardConstraints should imply !isCompiling and !activeAnalysis, can you remove those two from the 'if' and add an assert?
Attachment #654307 - Flags: review?(bhackett1024) → review+
(Assignee)

Comment 13

5 years ago
(In reply to Brian Hackett (:bhackett) from comment #12)
> ::: js/src/jsinfer.cpp
> @@ +5728,5 @@
> >  {
> >  
> >      if (constrainedOutputs) {
> >          bool isCompiling = compiledInfo.outputIndex != RecompileInfo::NoCompilerRunning;
> > +        if (discardConstraints && !isCompiling && !compartment()->activeAnalysis) {
> 
> The above change means that discardConstraints should imply !isCompiling and
> !activeAnalysis, can you remove those two from the 'if' and add an assert?

The analysis can happen while we are not compiling and an analysis is only a subset of the allocations we have during a compilation.  So I cannot remove isCompiling from the list of conditions, but I can indeed remove the activeAnalysis condition.
isCompiling should imply activeAnalysis, so discardConstraints should imply !isCompiling.  There is an AutoEnterTypeInference wrapping AutoEnterCompilation.  The AutoEnterCompilation should assert compartment->activeAnalysis but doesn't (can you add that, if you don't mind?)
(Assignee)

Comment 15

5 years ago
I applied these modifications, this seems to work fine with JIT tests so I pushed it to try to avoid latest mistake:

https://tbpl.mozilla.org/?tree=Try&rev=c4741976e9e2

I will push it to inbound/ionmonkey as soon as the try server turns green.
(Assignee)

Comment 16

5 years ago
Comment on attachment 654307 [details] [diff] [review]
Fix condtion for freeing compiler output vector.

https://hg.mozilla.org/integration/mozilla-inbound/rev/bbf6a7e1598d
https://hg.mozilla.org/projects/ionmonkey/rev/c1b7927df546
Attachment #654307 - Flags: checkin+
This was landed on top of an orange tree so I've backed out as:

https://hg.mozilla.org/projects/ionmonkey/rev/fbba6ea2b076

As this landed on m-i, we can take this in the next merge or re-land when the tree is green.
https://hg.mozilla.org/mozilla-central/rev/bbf6a7e1598d
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.