647424 - TI: Crash [@ js::mjit::JaegerShot]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following code crashes on TI tip (run with -m -n -a), tested on 64 bit:

test();
function test() {
  function gen()
  {   
    gc()
    try {
      new test
    } finally {
    }
  }
  gen()
}

Backtrace (most likely near-null pointer dereference):

==9144== Invalid read of size 8
==9144==    at 0x68C8ED: js::mjit::JaegerShot(JSContext*) (MethodJIT.cpp:796)
==9144==    by 0x766217: js::Interpret(JSContext*, JSStackFrame*, unsigned int, JSInterpMode) (jsinterp.cpp:4953)
==9144==    by 0x71F444: UncachedInlineCall(js::VMFrame&, unsigned int, void**, bool*, unsigned int, js::types::ClonedTypeSet*) (InvokeHelpers.cpp:436)
==9144==    by 0x71F815: js::mjit::stubs::UncachedCallHelper(js::VMFrame&, unsigned int, js::types::ClonedTypeSet*, js::mjit::stubs::UncachedCallResult*) (InvokeHelpers.cpp:509)
==9144==    by 0x703742: CallCompiler::update() (MonoIC.cpp:999)
==9144==    by 0x6FD3DD: js::mjit::ic::Call(js::VMFrame&, js::mjit::ic::CallICInfo*) (MonoIC.cpp:1059)
==9144==    by 0x41ADEDF: ???
==9144==    by 0x68C671: js::mjit::EnterMethodJIT(JSContext*, JSStackFrame*, void*, js::Value*) (MethodJIT.cpp:743)
==9144==    by 0x68C79A: CheckStackAndEnterMethodJIT(JSContext*, JSStackFrame*, void*) (MethodJIT.cpp:772)
==9144==    by 0x68C911: js::mjit::JaegerShot(JSContext*) (MethodJIT.cpp:796)
==9144==    by 0x4F4D7A: js::RunScript(JSContext*, JSScript*, JSStackFrame*) (jsinterp.cpp:682)
==9144==    by 0x4F6521: js::Execute(JSContext*, JSObject*, JSScript*, JSStackFrame*, unsigned int, js::Value*) (jsinterp.cpp:1094)
==9144==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==9144== 
==9144== 
==9144== Process terminating with default action of signal 11 (SIGSEGV)

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Here's a smaller testcase found separately and which crashes at the same location:

function f() {
    gc()
}
for (i = 0; i < 9; i++) {
    new f
    f()
}

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #1)
> Here's a smaller testcase found separately and which crashes at the same
> location:
> 
> function f() {
>     gc()
> }
> for (i = 0; i < 9; i++) {
>     new f
>     f()
> }

Tested on 32-bit Linux shell on changeset c340841f0465.

Comment 3

[Brian Hackett [Laid off!]]

When doing the initial compilation of a method from the interpreter, during cleanup we could end up discarding the code just compiled due to a triggered recompilation.  This fix ensures that the recompiler always regenerates code for the topmost stack frame.

http://hg.mozilla.org/projects/jaegermonkey/rev/42f282c4922c