Bug 182567 – WebKitGTK/JavaScriptCore crashes with segfault

• Status: NEW
• Component: JavaScriptCore

[Suyoung Lee]

WebKitGTK/JavaScriptCore 2.19.90/32 bit/debug build crashes at DerivedSources/ForwardingHeaders/wtf/text/StringImpl.h:272.
Release build also crashes with the same test code.

Here is the test code.

var_0 = "";
for (;; -0[var_0]) {
  var_0 += var_0 + 1;
}

Thread 1 "jsc" received signal SIGSEGV, Segmentation fault.
0x080a84e8 in WTF::StringImpl::is8Bit (this=0x0) at DerivedSources/ForwardingHeaders/wtf/text/StringImpl.h:272
272	    bool is8Bit() const { return m_hashAndFlags & s_hashFlag8BitBuffer; }
(gdb) bt
#0  0x080a84e8 in WTF::StringImpl::is8Bit (this=0x0) at DerivedSources/ForwardingHeaders/wtf/text/StringImpl.h:272
#1  0xb7132702 in JSC::JSRopeString::<lambda()>::operator()(void) const (__closure=0xbfffe384)
    at ../../Source/JavaScriptCore/runtime/JSString.cpp:185
#2  0xb7132954 in JSC::JSRopeString::resolveRopeToAtomicString (this=0xb0473d80, exec=0xbfffe608)
    at ../../Source/JavaScriptCore/runtime/JSString.cpp:206
#3  0x080b07a1 in JSC::JSString::toAtomicString (this=0xb0473d80, exec=0xbfffe608)
    at ../../Source/JavaScriptCore/runtime/JSString.h:532
#4  0x080b072a in JSC::JSString::toIdentifier (this=0xb0473d80, exec=0xbfffe608)
    at ../../Source/JavaScriptCore/runtime/JSString.h:526
#5  0x080b7c52 in JSC::JSValue::toPropertyKey (this=0xbfffe504, exec=0xbfffe608)
    at ../../Source/JavaScriptCore/runtime/JSCJSValueInlines.h:653
#6  0xb6e6904c in JSC::(anonymous namespace)::getByVal (vm=..., exec=0xbfffe608, baseValue=..., subscript=...)
    at ../../Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:865
#7  0xb6e69245 in JSC::(anonymous namespace)::llint_slow_path_get_by_val (exec=0xbfffe608, pc=0xb28a5198)
    at ../../Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:874
#8  0xb6e60206 in llint_entry () at DerivedSources/ForwardingHeaders/wtf/RefPtr.h:79
#9  0xb6e5d6ad in vmEntryToJavaScript () at DerivedSources/ForwardingHeaders/wtf/RefPtr.h:79
#10 0xb6dfaff3 in JSC::JITCode::execute (this=0xb28aa168, vm=0xb06f8000, protoCallFrame=0xbfffe7e8)
    at ../../Source/JavaScriptCore/jit/JITCode.cpp:81
#11 0xb6da47a2 in JSC::Interpreter::executeProgram (this=0xb28fc208, source=..., callFrame=0xb04ec034, 
    thisObj=0xb04dc2a0) at ../../Source/JavaScriptCore/interpreter/Interpreter.cpp:969
#12 0xb701cfd3 in JSC::evaluate (exec=0xb04ec034, source=..., thisValue=..., returnedException=...)
    at ../../Source/JavaScriptCore/runtime/Completion.cpp:103
#13 0x080a35cf in runWithOptions (globalObject=0xb04ec000, options=...) at ../../Source/JavaScriptCore/jsc.cpp:2291
#14 0x080a480c in <lambda(JSC::VM&, GlobalObject*)>::operator()(JSC::VM &, GlobalObject *) const (__closure=0xbfffef7c, 
    globalObject=0xb04ec000) at ../../Source/JavaScriptCore/jsc.cpp:2695
#15 0x080a5a7b in runJSC<jscmain(int, char**)::<lambda(JSC::VM&, GlobalObject*)> >(CommandLine, bool, const <lambda(JSC::VM&, GlobalObject*)> &) (options=..., isWorker=false, func=...) at ../../Source/JavaScriptCore/jsc.cpp:2596
#16 0x080a48c6 in jscmain (argc=2, argv=0xbffff0c4) at ../../Source/JavaScriptCore/jsc.cpp:2695
#17 0x080a20de in main (argc=2, argv=0xbffff0c4) at ../../Source/JavaScriptCore/jsc.cpp:2123

[Robin Morisset]

I tried reproducing this and could not: all I got was an out-of-memory exception, which makes perfect sense for this test case.