Bug 221904 – Flaky JSC test: stress/atomic-increment-bigint64.js

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Michael Catanzaro]

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....

[Michael Catanzaro]

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.

[Radar WebKit Bug Importer]

<rdar://problem/74596956>

[Yusuke Suzuki]

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.

[Yusuke Suzuki]

Created attachment 421609 [details]
Patch

[EWS]

Committed r273587: <https://commits.webkit.org/r273587>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 421609 [details].