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.

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?

(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

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.

Oops.

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

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

May want to hold up on resolving it FIXED until it lands on M-C.

(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.

reverted on inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/9434db5cfd47

reverted on ionmonkey: https://hg.mozilla.org/projects/ionmonkey/rev/6b2a947da355

- Fix inverted condition. - Invalidate if we are not discarding the constraints.

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?

(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?)

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.

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

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.