JSC stress test stress/atomic-increment-bigint64.js has been flaky since Wednesday last week. So far it has failed only on x86_64, but that might be coincidence. I have recorded failures on Wednesday, Thursday, Saturday, and Sunday. The test was added in r272341, on Feb 3, but strangely I don't have any recorded failures prior to Feb 10. That could be luck. The failure looks like this: stress/atomic-increment-bigint64.js.bytecode-cache: ../../.helpers/bytecode-cache-test-helper.sh: line 28: 3922422 Aborted (core dumped) /var/lib/jenkins/workspace/WebKit-JSC/label/x86_64/WebKitBuild/Release/bin/jsc atomic-increment-bigint64.js --useFTLJIT=false --useFunctionDotArguments=true --validateExceptionChecks=true --useDollarVM=true --maxPerThreadStackUsage=1572864 --useFTLJIT=true stress/atomic-increment-bigint64.js.bytecode-cache: Command '/var/lib/jenkins/workspace/WebKit-JSC/label/x86_64/WebKitBuild/Release/bin/jsc atomic-increment-bigint64.js --useFTLJIT=false --useFunctionDotArguments=true --validateExceptionChecks=true --useDollarVM=true --maxPerThreadStackUsage=1572864 --useFTLJIT=true' failed stress/atomic-increment-bigint64.js.bytecode-cache: ERROR: Unexpected exit code: 134 FAIL: stress/atomic-increment-bigint64.js.bytecode-cache 134 - 128 = 6 which is SIGABRT. Let's see if I can get a backtrace....
Test runs fine on my machine, but I got it to crash on my first attemtp when running it on our CI builder: #0 0x00007fad7c7409e5 in raise () from /lib64/libc.so.6 #1 0x00007fad7c729895 in abort () from /lib64/libc.so.6 #2 0x00007fad7f0a849e in JSC::UnlinkedProgramCodeBlock* JSC::CodeCache::getUnlinkedGlobalCodeBlock<JSC::UnlinkedProgramCodeBlock, JSC::ProgramExecutable>(JSC::VM&, JSC::ProgramExecutable*, JSC::SourceCode const&, JSC::JSParserStrictMode, JSC::JSParserScriptMode, WTF::OptionSet<JSC::CodeGenerationMode>, JSC::ParserError&, JSC::EvalContextType) () from /var/lib/jenkins/workspace/WebKit-JSC/label/x86_64/WebKitBuild/Release/lib/libJavaScriptCore.so.1 #3 0x00007fad7f0911c4 in JSC::CodeCache::getUnlinkedProgramCodeBlock(JSC::VM&, JSC::ProgramExecutable*, JSC::SourceCode const&, JSC::JSParserStrictMode, WTF::OptionSet<JSC::CodeGenerationMode>, JSC::ParserError&) () from /var/lib/jenkins/workspace/WebKit-JSC/label/x86_64/WebKitBuild/Release/lib/libJavaScriptCore.so.1 #4 0x00007fad7f28594a in JSC::ProgramExecutable::initializeGlobalProperties(JSC::VM&, JSC::JSGlobalObject*, JSC::JSScope*) () from /var/lib/jenkins/workspace/WebKit-JSC/label/x86_64/WebKitBuild/Release/lib/libJavaScriptCore.so.1 #5 0x00007fad7ef1b11b in JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*) () from /var/lib/jenkins/workspace/WebKit-JSC/label/x86_64/WebKitBuild/Release/lib/libJavaScriptCore.so.1 #6 0x00007fad7f0c2b5b in JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&) () from /var/lib/jenkins/workspace/WebKit-JSC/label/x86_64/WebKitBuild/Release/lib/libJavaScriptCore.so.1 #7 0x0000000000414fdd in WTF::Detail::CallableWrapper<functionDollarAgentStart(JSC::JSGlobalObject*, JSC::CallFrame*)::{lambda()#2}, void>::call() () #8 0x00007fad7f3afdea in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () from /var/lib/jenkins/workspace/WebKit-JSC/label/x86_64/WebKitBuild/Release/lib/libJavaScriptCore.so.1 #9 0x00007fad7f4035e9 in WTF::wtfThreadEntryPoint(void*) () from /var/lib/jenkins/workspace/WebKit-JSC/label/x86_64/WebKitBuild/Release/lib/libJavaScriptCore.so.1 #10 0x00007fad7cc2a432 in start_thread () from /lib64/libpthread.so.0 #11 0x00007fad7c805913 in clone () from /lib64/libc.so.6 Sadly it's a release build so there is not much to that backtrace. I can try again with a debug build if needed.
<rdar://problem/74596956>
This sounds like this test is not suitable for bytecode-cache's assumption. We have some code that is executed in the worker threads, and they are not cached because it is not running in the main thread VM.
Created attachment 421609 [details] Patch
Committed r273587: <https://commits.webkit.org/r273587> All reviewed patches have been landed. Closing bug and clearing flags on attachment 421609 [details].