TypeCompartment::constrainedOutputs leaks on testLeftShift.js

RESOLVED FIXED in mozilla17

Status

()

defect
RESOLVED FIXED
7 years ago
7 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

7 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

7 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

7 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

7 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

7 years ago
Posted patch Fix inverted condition. (obsolete) — Splinter Review
Oops.
Attachment #652952 - Flags: review?(bhackett1024)
Attachment #652952 - Flags: review?(bhackett1024) → review+
Reporter

Comment 5

7 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

Updated

7 years ago
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED

Comment 7

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

Comment 8

7 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 11

7 years ago
- 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

7 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

7 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.
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
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.