Bug 238956 – REGRESSION(r292372): cloop crashes on s390x

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Michael Catanzaro]

Since r292372 "[JSC] Store CodeBlock in caller side", JSC cloop is broken on s390x, all stress tests crashing with this backtrace:

#0  0x000003ff8251f512 in JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool) ()
   from /home/jenkins/workspace/WebKit-JSC/label/s390x/WebKitBuild/Release/lib/libJavaScriptCore.so.1
No symbol table info available.
#1  0x000003ff82826f2c in vmEntryToJavaScript ()
   from /home/jenkins/workspace/WebKit-JSC/label/s390x/WebKitBuild/Release/lib/libJavaScriptCore.so.1
No symbol table info available.
#2  0x000003ff827f8f8a in JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*) () from /home/jenkins/workspace/WebKit-JSC/label/s390x/WebKitBuild/Release/lib/libJavaScriptCore.so.1
No symbol table info available.
#3  0x000003ff829d307a in JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&) () from /home/jenkins/workspace/WebKit-JSC/label/s390x/WebKitBuild/Release/lib/libJavaScriptCore.so.1
No symbol table info available.
#4  0x0000000001017f70 in int runJSC<jscmain(int, char**)::{lambda(JSC::VM&, GlobalObject*, bool&)#1}>(CommandLine const&, bool, jscmain(int, char**)::{lambda(JSC::VM&, GlobalObject*, bool&)#1} const&) [clone .constprop.0] ()
No symbol table info available.
#5  0x00000000010188be in jscmain(int, char**) ()
No symbol table info available.
#6  0x000000000100bee8 in main ()
No symbol table info available.

I can try to catch this with a debug build for a better backtrace if requested.

cloop is still working fine all other architectures, so I suspect a big endian problem.

[Yusuke Suzuki]

Please attach debug build backtrace since we have no big endian machines.

[Michael Catanzaro]

(In reply to Yusuke Suzuki from comment #1)
> Please attach debug build backtrace since we have no big endian machines.

Ah, good request, the debug backtrace is a lot better than I expected it would be. Short form:

(gdb) bt
#0  0x000003ff9e2fed5e in JSC::LLInt::CLoop::execute (entryOpcodeID=JSC::llint_vm_entry_to_javascript, 
    executableAddress=0x3ff9e1975ba <JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool)+36986>, vm=0x196ce30, protoCallFrame=0x3fffcafd460, isInitializationPass=false)
    at JavaScriptCore/DerivedSources/LLIntAssembly.h:38969
#1  0x000003ff9eaa553e in JSC::vmEntryToJavaScript (
    executableAddress=0x3ff9e1975ba <JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool)+36986>, vm=0x196ce30, protoCallFrame=0x3fffcafd460) at ../../Source/JavaScriptCore/llint/LLIntThunks.cpp:669
#2  0x000003ff9ea6f768 in JSC::JITCode::execute (this=0x19ef600, vm=0x196ce30, protoCallFrame=0x3fffcafd460)
    at ../../Source/JavaScriptCore/jit/JITCodeInlines.h:42
#3  0x000003ff9ea5e7be in JSC::Interpreter::executeProgram (this=0x199e3c0, source=..., thisObj=0x19e90d8)
    at ../../Source/JavaScriptCore/interpreter/Interpreter.cpp:977
#4  0x000003ff9ed7dfa8 in JSC::evaluate (globalObject=0x19af2e8, source=..., thisValue=..., returnedException=...)
    at ../../Source/JavaScriptCore/runtime/Completion.cpp:137
#5  0x000000000102a29a in runWithOptions (globalObject=0x19af2e8, options=..., success=@0x3fffcafdcdf: true)
    at ../../Source/JavaScriptCore/jsc.cpp:3232
#6  0x000000000102be3e in operator() (__closure=0x3fffcafde2f, vm=..., globalObject=0x19af2e8, 
    success=@0x3fffcafdcdf: true) at ../../Source/JavaScriptCore/jsc.cpp:3801
#7  0x000000000102db06 in runJSC<jscmain(int, char**)::<lambda(JSC::VM&, GlobalObject*, bool&)> >(const CommandLine &, bool, const struct {...} &) (options=..., isWorker=false, func=...) at ../../Source/JavaScriptCore/jsc.cpp:3623
#8  0x000000000102bf70 in jscmain (argc=8, argv=0x3fffcafe128) at ../../Source/JavaScriptCore/jsc.cpp:3794
#9  0x0000000001028420 in main (argc=8, argv=0x3fffcafe128) at ../../Source/JavaScriptCore/jsc.cpp:3020

I'll attach the long version with stack variables.

[Michael Catanzaro]

Created attachment 456972 [details]
full backtrace

[Yusuke Suzuki]

Hmm, it is super hard to see the issue without big-endian machine / EWS bots etc.
Michael, can you check what is happening?

[Michael Catanzaro]

I can build and run modified code, add printfs, check values in gdb, etc. But JSC is gobbledygook to me, so the odds of me successfully figuring out what it is that I ought to be looking for in this huge commit are close to zero. Any chance you have hints?

[Radar WebKit Bug Importer]

<rdar://problem/91773020>

[Daniel Kolesa]

if nobody figures this out in the meantime, i might possibly take a look later (i have some ppc64 big endian systems and have poked around jsc on big endian a bit before, and i don't think this is s390x specific)

[Michael Catanzaro]

Created attachment 457926 [details]
updated full backtrace

The backtrace changed a little. Here it is at r293005.

[Yusuke Suzuki]

Pull request: https://github.com/WebKit/WebKit/pull/321

[Yusuke Suzuki]

Landed https://commits.webkit.org/249780@main (r293041)!