Closed Bug 650663 Opened 13 years ago Closed 13 years ago

TI: Crash [@ JSString::isLinear]

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: decoder, Unassigned)

References

Details

(Keywords: crash, testcase)

Crash Data

The following testcase crashes on TI revision ac0989a03bf1 (run with options -m
-a -n), tested on 32 bit:

var cnBadSyntax = '1=2';
var obj = new testObject;
f.call(obj);
g();
function testObject() {
        this.badSyntax = cnBadSyntax;
}
function f() {
    try {
        eval(this.badSyntax)
    } catch (e) {}
}
function g() {
        f.call();
}


==26888== Invalid read of size 4
==26888==    at 0x805AA0C: JSString::isLinear() const (jsstr.h:288)
==26888==    by 0x8080D84: JSString::ensureLinear(JSContext*) (jsstr.h:693)
==26888==    by 0x8154B53: js::EvalKernel(JSContext*, unsigned int, js::Value*, js::EvalType, JSStackFrame*, JSObject*) (jsobj.cpp:1208)
==26888==    by 0x8139F54: js::DirectEval(JSContext*, unsigned int, js::Value*) (jsinterp.cpp:1432)
==26888==    by 0x8362491: js::mjit::stubs::Eval(js::VMFrame&, unsigned int) (InvokeHelpers.cpp:499)
==26888==    by 0x57AA4BA: ???
==26888==    by 0x82C85B2: js::mjit::EnterMethodJIT(JSContext*, JSStackFrame*, void*, js::Value*) (MethodJIT.cpp:689)
==26888==    by 0x82C86D7: CheckStackAndEnterMethodJIT(JSContext*, JSStackFrame*, void*) (MethodJIT.cpp:718)
==26888==    by 0x82C87AC: js::mjit::JaegerShot(JSContext*) (MethodJIT.cpp:735)
==26888==    by 0x8137733: js::RunScript(JSContext*, JSScript*, JSStackFrame*) (jsinterp.cpp:678)
==26888==    by 0x8137C69: js::Invoke(JSContext*, js::CallArgs const&, unsigned int) (jsinterp.cpp:768)
==26888==    by 0x80F9D4C: js_fun_call(JSContext*, unsigned int, js::Value*) (jsfun.cpp:2208)
==26888==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==26888== 
==26888== 
==26888== Process terminating with default action of signal 11 (SIGSEGV)
Fused opcode bug.  For JSOP_GETTHISPROP, the Compiler tags the possible types of the intermediate value pushed by the 'THIS' portion so we can optimize the GETPROP, but did so incorrectly --- it just used the script's possible 'this' types and did not include the type constraint which transforms primitive 'this' into objects.  This fix just duplicates in the compiler what type inference does for this opcode.  The real fix is to get rid of GETTHISPROP and related fused opcodes (bug 647626).

http://hg.mozilla.org/projects/jaegermonkey/rev/f60bb600974b
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
I saw this (unreproducible) crash on the trunk in the test case <http://www.sirdarckcat.net/firefox-memoryexhaust1.html> for bug 390090:

Operating system: Windows NT
                  5.1.2600 Service Pack 3
CPU: x86
     GenuineIntel family 6 model 44 stepping 2
     1 CPU

Crash reason:  EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0x0

Thread 0 (crashed)
 0  mozjs.dll!JSString::isLinear() [jsstr.h : 288 + 0x3]
    eip = 0x0068fb8a   esp = 0x0012a8c8   ebp = 0x0012a8cc   ebx = 0x02da0030
    esi = 0x00000020   edi = 0x02da0060   eax = 0x00000000   ecx = 0x00000000
    edx = 0x00000000   efl = 0x00010246
    Found by: given as instruction pointer in context

and 

Operating system: Linux
                  0.0.0 Linux 2.6.35.12-88.fc14.i686.PAE #1 SMP Thu Mar 31 21:54:35 UTC 2011 i686
CPU: x86
     GenuineIntel family 6 model 44 stepping 2
     1 CPU

Crash reason:  SIGSEGV
Crash address: 0x3ae041d0

Thread 0 (crashed)
 0  0x3ae041d0
    eip = 0x3ae041d0   esp = 0xbfcf69c0   ebp = 0x00615600   ebx = 0x03160874
    esi = 0x5d2244fc   edi = 0x0231aa44   eax = 0x00000000   ecx = 0x00000003
    edx = 0x00022511   efl = 0x00010286
    Found by: given as instruction pointer in context
 1  libmozsqlite3.so!exprAnalyze [sqlite3.c : 96854 + 0x6]
    eip = 0x001f0000   esp = 0xbfcf69cc   ebp = 0x00615600
    Found by: stack scanning

I haven't been able to reproduce but the original machines were very low memory (1G). The JSString::isLinear crash did involve js_ReportUncaughtException, but the exprAnalyze involved PR_GetThreadPrivate and AssertActivityIsLegal.

Are these related, or ignorable due to low memory conditions or ?
Crash Signature: [@ JSString::isLinear]
A testcase for this bug was automatically identified at js/src/jit-test/tests/jaeger/bug650663.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.