TI: Crash [@ JSString::isAtom]

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: decoder, Unassigned)

Tracking

(Blocks: 2 bugs, {crash, testcase})

Trunk
x86
Linux
crash, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

6 years ago
The following testcase crashes on TI revision d78eef12a329 (run with -m -n -a),
tested on 32 bit:

var i = 0;
test();
function test() {
  var jstop  = 1000;
  var code = '';
  code+=createCode(i);
  eval();
}
function createCode(i) {
  jstop+= +  +  + i + " string.';";
}


==32738== Invalid read of size 4
==32738==    at 0x8080C55: JSString::isAtom() const (jsstr.h:345)
==32738==    by 0x81EB156: js_ConcatStrings(JSContext*, JSString*, JSString*) (jsstr.cpp:337)
==32738==    by 0x83BF1DE: js::mjit::stubs::Add(js::VMFrame&) (StubCalls.cpp:1180)
==32738==    by 0x57A9970: ???
==32738==    by 0x82C87FE: js::mjit::EnterMethodJIT(JSContext*, JSStackFrame*, void*, js::Value*) (MethodJIT.cpp:689)
==32738==    by 0x82C8923: CheckStackAndEnterMethodJIT(JSContext*, JSStackFrame*, void*) (MethodJIT.cpp:718)
==32738==    by 0x82C89F8: js::mjit::JaegerShot(JSContext*) (MethodJIT.cpp:735)
==32738==    by 0x8137733: js::RunScript(JSContext*, JSScript*, JSStackFrame*) (jsinterp.cpp:678)
==32738==    by 0x8138B72: js::Execute(JSContext*, JSObject*, JSScript*, JSStackFrame*, unsigned int, js::Value*) (jsinterp.cpp:1071)
==32738==    by 0x807BB51: JS_ExecuteScript (jsapi.cpp:5226)
==32738==    by 0x804C87F: Process(JSContext*, JSObject*, char*, int, int) (js.cpp:451)
==32738==    by 0x804D93C: ProcessArgs(JSContext*, JSObject*, char**, int) (js.cpp:966)
==32738==  Address 0x3e8 is not stack'd, malloc'd or (recently) free'd
==32738== 
==32738== 
==32738== Process terminating with default action of signal 11 (SIGSEGV)
We only want to inline scripted calls when the caller and callee have the same scope chains.  We already ruled out cases where the function objects themselves have different parents, but not where the caller is a heavyweight function and gets a call object created when it is called.  This disallows inlining from heavyweight functions and eval scripts (which can also get their own call objects).

Not sure this fix is complete, though.  Are there situations in which we will put call objects or block objects on the scope chains of non-heavyweight frames?

http://hg.mozilla.org/projects/jaegermonkey/rev/e2ac5bec56fb
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Depends on: 653980
Crash Signature: [@ JSString::isAtom]
(Reporter)

Updated

6 years ago
Blocks: 676763
(Reporter)

Comment 2

4 years ago
A testcase for this bug was automatically identified at js/src/jit-test/tests/jaeger/inline/bug651209.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.