Created attachment 467131 [details] Full backtrace With: $ build-jsc --jsc-only --debug --cmakeargs="-DDEVELOPER_MODE_FATAL_WARNINGS=OFF" $ run-jsc-stress-tests --memory-limited --no-jit --no-copy --jsc WebKitBuild/Debug/bin/jsc JSTests/stress/ JSC is crashing on s390x since 259229@main "[JSC] Always use Wasm::Callee for wasm function callee". Here's one backtrace where I assume it runs out of stack space due to infinite recursion: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000003ffa3c3d532 in JSC::LLInt::CLoop::execute (entryOpcodeID=JSC::llint_vm_entry_to_javascript, executableAddress=0x3ffa3ba15f0 <JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool)+49576>, vm=0x17dea40, protoCallFrame=0x3ffd4c9a000, isInitializationPass=false) at /home/nfs/mcatanza/WebKit/WebKitBuild/Debug/JavaScriptCore/DerivedSources/LLIntAssembly.h:17269 17269 t1 = *CAST<intptr_t*>(t1.i8p() - 16); // LowLevelInterpreter.asm:1506 (gdb) bt #0 0x000003ffa3c3d532 in JSC::LLInt::CLoop::execute (entryOpcodeID=JSC::llint_vm_entry_to_javascript, executableAddress=0x3ffa3ba15f0 <JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool)+49576>, vm=0x17dea40, protoCallFrame=0x3ffd4c9a000, isInitializationPass=false) at /home/nfs/mcatanza/WebKit/WebKitBuild/Debug/JavaScriptCore/DerivedSources/LLIntAssembly.h:17269 #1 0x000003ffa3171d1e in JSC::vmEntryToJavaScript ( executableAddress=0x3ffa3ba15f0 <JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool)+49576>, vm=0x17dea40, protoCallFrame=0x3ffd4c9a000) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/llint/LLIntThunks.cpp:684 #2 0x000003ffa313b480 in JSC::JITCode::execute (this=0x183e300, vm=0x17dea40, protoCallFrame=0x3ffd4c9a000) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/jit/JITCodeInlines.h:42 #3 0x000003ffa312a9ee in JSC::Interpreter::executeCall (this=0x17fcc60, lexicalGlobalObject=0x1827dd8, function=0x3ffa08e3060, callData=..., thisValue=..., args=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/interpreter/Interpreter.cpp:1093 #4 0x000003ffa33ded12 in JSC::call (globalObject=0x1827dd8, functionObject=..., callData=..., thisValue=..., args=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/CallData.cpp:57 #5 0x000003ffa3913fb8 in JSC::performProxyGet (globalObject=0x1827dd8, proxyObject=0x3ff9f161360, receiver=..., propertyName=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/ProxyObject.cpp:130 #6 0x000003ffa391471e in JSC::ProxyObject::performGet (this=0x3ff9f161360, globalObject=0x1827dd8, propertyName=..., slot=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/ProxyObject.cpp:159 #7 0x000003ffa3916c24 in JSC::ProxyObject::getOwnPropertySlotCommon (this=0x3ff9f161360, globalObject=0x1827dd8, propertyName=..., slot=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/ProxyObject.cpp:371 #8 0x000003ffa3916d24 in JSC::ProxyObject::getOwnPropertySlot (object=0x3ff9f161360, globalObject=0x1827dd8, propertyName=..., slot=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/ProxyObject.cpp:387 #9 0x000003ffa2a50be0 in JSC::JSObject::getNonIndexPropertySlot (this=0x3ff9f161360, globalObject=0x1827dd8, propertyName=..., slot=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/JSObjectInlines.h:160 #10 0x000003ffa374c736 in JSC::JSObject::getPropertySlot<true> (this=0x3ff9f161360, globalObject=0x1827dd8, propertyName=..., slot=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/JSObject.h:1508 #11 0x000003ffa3732bca in JSC::callToPrimitiveFunction<(JSC::CachedSpecialPropertyKey)3> (globalObject=0x1827dd8, object=0x3ff9f161360, propertyName=..., hint=JSC::PreferNumber) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/JSObject.cpp:2322 #12 0x000003ffa37241a4 in JSC::JSObject::toPrimitive (this=0x3ff9f161360, globalObject=0x1827dd8, preferredType=JSC::PreferNumber) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/JSObject.cpp:2428 #13 0x000003ffa3725e98 in JSC::JSObject::toNumber (this=0x3ff9f161360, globalObject=0x1827dd8) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/JSObject.cpp:2658 #14 0x000003ffa361ae16 in JSC::JSCell::toNumber (this=0x3ff9f161360, globalObject=0x1827dd8) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/JSCell.cpp:164 #15 0x000003ffa35f839c in JSC::JSValue::toNumberSlowCase (this=0x3ffd4c9b398, globalObject=0x1827dd8) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/JSCJSValue.cpp:64 #16 0x000003ffa2ab7622 in JSC::JSValue::toNumber (this=0x3ffd4c9b398, globalObject=0x1827dd8) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/JSCJSValueInlines.h:873 #17 0x000003ffa3404682 in JSC::slow_path_to_number (callFrame=0x3ff9f379580, pc=0x183e46c) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/CommonSlowPaths.cpp:530 #18 0x000003ffa3bb89cc in JSC::LLInt::CLoop::execute (entryOpcodeID=JSC::llint_vm_entry_to_javascript, executableAddress=0x3ffa3ba15f0 <JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool)+49576>, vm=0x17dea40, protoCallFrame=0x3ffd4c9de60, isInitializationPass=false) at /home/nfs/mcatanza/WebKit/WebKitBuild/Debug/JavaScriptCore/DerivedSources/LLIntAssembly.h:3297 #19 0x000003ffa3171d1e in JSC::vmEntryToJavaScript ( executableAddress=0x3ffa3ba15f0 <JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool)+49576>, vm=0x17dea40, protoCallFrame=0x3ffd4c9de60) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/llint/LLIntThunks.cpp:684 The entire backtrace is 1629 frames, but it's just the above repeated again and again. Here's a second variant where the crash looks basically the same, but instead of 1629 frames it's only 9 frames long: (gdb) bt #0 0x000003ffbd73d4ec in JSC::LLInt::CLoop::execute (entryOpcodeID=JSC::llint_vm_entry_to_javascript, executableAddress=0x3ffbd69e522 <JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool)+37082>, vm=0x256da40, protoCallFrame=0x3ffe4878c50, isInitializationPass=false) at /home/nfs/mcatanza/WebKit/WebKitBuild/Debug/JavaScriptCore/DerivedSources/LLIntAssembly.h:17265 #1 0x000003ffbcc71d1e in JSC::vmEntryToJavaScript ( executableAddress=0x3ffbd69e522 <JSC::LLInt::CLoop::execute(JSC::OpcodeID, void*, JSC::VM*, JSC::ProtoCallFrame*, bool)+37082>, vm=0x256da40, protoCallFrame=0x3ffe4878c50) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/llint/LLIntThunks.cpp:684 #2 0x000003ffbcc3b480 in JSC::JITCode::execute (this=0x25cc340, vm=0x256da40, protoCallFrame=0x3ffe4878c50) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/jit/JITCodeInlines.h:42 #3 0x000003ffbcc2a16e in JSC::Interpreter::executeProgram (this=0x258bc60, source=..., thisObj=0x25c9dd8) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/interpreter/Interpreter.cpp:1024 #4 0x000003ffbcf11f68 in JSC::evaluate (globalObject=0x25b6dd8, source=..., thisValue=..., returnedException=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/runtime/Completion.cpp:137 #5 0x000000000102e102 in runWithOptions (globalObject=0x25b6dd8, options=..., success=@0x3ffe487953f: true) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/jsc.cpp:3466 #6 0x000000000102fcb6 in operator() (__closure=0x3ffe4879697, vm=..., globalObject=0x25b6dd8, success=@0x3ffe487953f: true) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/jsc.cpp:4038 #7 0x0000000001031ed8 in runJSC<jscmain(int, char**)::<lambda(JSC::VM&, GlobalObject*, bool&)> >(const CommandLine &, bool, const struct {...} &) (options=..., isWorker=false, func=...) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/jsc.cpp:3855 #8 0x000000000102fde8 in jscmain (argc=13, argv=0x3ffe4879a68) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/jsc.cpp:4031 #9 0x000000000102c11a in main (argc=13, argv=0x3ffe4879a68) at /home/nfs/mcatanza/WebKit/Source/JavaScriptCore/jsc.cpp:3241 I'll attach a full backtrace of this shorter one. There is probably a little endian assumption somewhere in this commit; that's almost always the cause of crashes that are specific to s390x. (JSC supports big endian systems like s390x only when built with cloop enabled.)
We do not have s390x EWS & post-commit bots so we cannot support / debug this architecture. Can you add JSC testing EWS bots for s390x to help debugging this issue?
<rdar://problem/113347059>