JSC stress test is flaky on Red Hat's internal CI (which runs with JIT disabled and cloop enabled). The first known failure was Dec 13. I didn't report it until now because until earlier this week, all the failures occurred on ppc64le, so I incorrectly assumed the issue was specific to that architecture. But the test has since failed on both s390x and x86_64 as well, so it's a more general problem. Unfortunately, the error message is pretty generic: Running stress/shared-array-buffer-sort-while-different-thread-is-modifying.js.default stress/shared-array-buffer-sort-while-different-thread-is-modifying.js.default: Exception: JavaScript execution terminated. stress/shared-array-buffer-sort-while-different-thread-is-modifying.js.default: ERROR: Unexpected exit code: 1 FAIL: stress/shared-array-buffer-sort-while-different-thread-is-modifying.js.default I don't know what to make of "JavaScript execution terminated," but it's this same error on all architectures. Based on the failure history, it might be due to some change that landed in trunk during early December: Dec 13: failed on ppc64le Jan 5: failed on ppc64le Jan 8: failed on ppc64le Jan 19: failed on ppc64le Jan 26: failed on s390x Jan 29: failed on s390x and x86_64
<rdar://problem/74023276>
Created attachment 419715 [details] Patch
(In reply to Michael Catanzaro from comment #0) > Based on the failure history, it might be due to some change that landed in > trunk during early December: > > Dec 13: failed on ppc64le > Jan 5: failed on ppc64le > Jan 8: failed on ppc64le > Jan 19: failed on ppc64le > Jan 26: failed on s390x > Jan 29: failed on s390x and x86_64 Feb 2: failed on s390x Feb 6: failed on x86_64
Sadly this is going to be very difficult to track down. I am currently running this test in a continuous loop on (a) my desktop, and (b) the s390x server that we use for our internal CI (since it seems to fail more often on this server than it does for x86_64). Sadly the test passes every time. Since it is a timing issue, I bet it only fails when the tests are run all at once instead of one at a time. I was hoping to bisect it, but it doesn't fail often enough for it to be practical to bisect in this way.
This test is still flaky on all architectures: Feb 13: failed on ppc64le Feb 14: failed on s390x Feb 15: failed on s390x Feb 19: failed on ppc64le Feb 20: failed on aarch64 March 1: failed on ppc64le
Comment on attachment 419715 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=419715&action=review > JSTests/stress/shared-array-buffer-sort-while-different-thread-is-modifying.js:3 > +//@ skip > //@ runDefault("--watchdog=1000", "--watchdog-exception-ok") > +// FIXME: unskip this test when https://bugs.webkit.org/show_bug.cgi?id=221129 is fixed. Can we land this...?
@Michael Thanks. Could you paste the crash trace of the failure?
Unfortunately I don't think it's crashing because the process exit status is 1. If there was a crash, the exit status would be (128 + signal value). So we don't have much to go on other than the stdout/stderr in comment #0.
OK, "JavaScript execution terminated" this sounds like this is not a real bug. Possibly, the thread is terminated, and we are not properly handling that case in jsc shell...?
Created attachment 422016 [details] Patch
Created attachment 422019 [details] Patch
Comment on attachment 422019 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=422019&action=review Thanks Yusuke! > Source/JavaScriptCore/jsc.cpp:416 > + CommandLine(CommandLineForWorkersTag); This could use: explicit
Comment on attachment 422019 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=422019&action=review Thanks! >> Source/JavaScriptCore/jsc.cpp:416 >> + CommandLine(CommandLineForWorkersTag); > > This could use: explicit Fixed.
Committed r273779 (234776@main): <https://commits.webkit.org/234776@main>