654668 - TI: Crash [@ JSString::isAtom] // Null pointer dereference

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on TI revision 3062ff7fef83 (run with -m -n -a),
tested on 64 bit:

var summary = 'foo';
function crashMe2(n) {
  var nasty = [], fn;
  while (summary + + fn) nasty[n]+n
}
try {
  crashMe2(0x10000)
} catch(e) {}


Backtrace:

==8954== Invalid read of size 8
==8954==    at 0x43965A: JSString::isAtom() const (jsstr.h:354)
==8954==    by 0x5AD331: js_ConcatStrings(JSContext*, JSString*, JSString*) (jsstr.cpp:338)
==8954==    by 0x79B319: js::mjit::stubs::Add(js::VMFrame&) (StubCalls.cpp:1180)
==8954==    by 0x41AF674: ???
==8954==    by 0x697C71: js::mjit::EnterMethodJIT(JSContext*, js::StackFrame*, void*, js::Value*) (MethodJIT.cpp:692)
==8954==    by 0x697DB6: CheckStackAndEnterMethodJIT(JSContext*, js::StackFrame*, void*) (MethodJIT.cpp:722)
==8954==    by 0x697E92: js::mjit::JaegerShot(JSContext*) (MethodJIT.cpp:739)
==8954==    by 0x4F77AD: js::RunScript(JSContext*, JSScript*, js::StackFrame*) (jsinterp.cpp:605)
==8954==    by 0x4F8DE3: js::Execute(JSContext*, JSObject&, JSScript*, js::StackFrame*, unsigned int, js::Value*) (jsinterp.cpp:997)
==8954==    by 0x4348B6: JS_ExecuteScript (jsapi.cpp:5169)
==8954==    by 0x405A2C: Process(JSContext*, JSObject*, char*, int, int) (js.cpp:453)
==8954==    by 0x406ACF: ProcessArgs(JSContext*, JSObject*, char**, int) (js.cpp:983)
==8954==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==8954== 
==8954== 
==8954== Process terminating with default action of signal 11 (SIGSEGV)

Comment 1

[Brian Hackett [Laid off!]]

WFM, fixed I think by c963b24694cd.  Did not pin down exactly what was going on in this test, but it looks like we had an invariant failure while entering the loop (nasty[n] is out of bounds) and when rejoining did not load 'summary' and got a trash value passed to the ADD.  With rev c963b24694cd on the invariant failure we get kicked back into the interpreter and need to wait another iteration of the loop before we can try to compile again.

Comment 2

[Paul Biggar]

Test added: http://hg.mozilla.org/projects/jaegermonkey/rev/2d4c3ee5f9f4

Comment 3

[Christian Holler (:decoder)]

A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug654668.js.