Bug 212479 - Tests expecting a crash should use a signal handler in the JSC CLI process
Summary: Tests expecting a crash should use a signal handler in the JSC CLI process
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Keith Miller
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-05-28 11:09 PDT by Keith Miller
Modified: 2020-06-15 10:54 PDT (History)
12 users (show)

See Also:

Attachments
Patch (20.18 KB, patch)
2020-05-28 11:14 PDT, Keith Miller 		no flags Details | Formatted Diff | Diff
Patch for landing (20.22 KB, patch)
2020-06-12 15:46 PDT, Keith Miller 		no flags Details | Formatted Diff | Diff
Patch for landing (20.15 KB, patch)
2020-06-12 16:45 PDT, Keith Miller 		no flags Details | Formatted Diff | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Keith Miller 2020-05-28 11:09:42 PDT 
Tests expecting a crash should use a signal handler in the JSC CLI process
Comment 1 Keith Miller 2020-05-28 11:14:25 PDT 
Created attachment 400484 [details]
Patch
Comment 2 Yusuke Suzuki 2020-05-28 11:20:29 PDT 
Comment on attachment 400484 [details]
Patch

r=me
Comment 3 Radar WebKit Bug Importer 2020-06-12 13:36:49 PDT 
<rdar://problem/64310099>
Comment 4 Keith Miller 2020-06-12 15:46:16 PDT 
Created attachment 401795 [details]
Patch for landing
Comment 5 EWS 2020-06-12 15:47:09 PDT 
Tools/Scripts/svn-apply failed to apply attachment 401795 [details] to trunk.
Please resolve the conflicts and upload a new patch.
Comment 6 Keith Miller 2020-06-12 16:45:38 PDT 
Created attachment 401803 [details]
Patch for landing
Comment 7 EWS 2020-06-12 17:22:36 PDT 
Committed r262991: <https://trac.webkit.org/changeset/262991>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 401803 [details].
Comment 8 Michael Catanzaro 2020-06-14 06:16:09 PDT 
This broke stress/ensure-crash.js on Red Hat's internal CI:

Running stress/ensure-crash.js.default
stress/ensure-crash.js.default: ERROR: Unexpected exit code: 134
FAIL: stress/ensure-crash.js.default
Running stress/ensure-crash.js.mini-mode
stress/ensure-crash.js.mini-mode: ERROR: Unexpected exit code: 134
FAIL: stress/ensure-crash.js.mini-mode

134 - 128 = 6 = SIGABRT on Linux, so the test is failing with SIGABRT. (SIGILL = 4 so if it were to exit with SIGILL its exit status would be 132.)

Skimming the commit, I don't immediately see what could be causing a SIGABRT, so I'll take a look later this week (assuming the issue is not immediately clear to you).

I thought the most likely problem was that this change assumes HAVE(MACHINE_CONTEXT) is enabled, but looking in PlatformHave.h, that is not true on two of the four architectures we test (ppc64le and s390x). However, the test is failing in the same way on both x86_64 and aarch64, so that must not be the only problem here. I'll investigate more next week if the issue isn't immediately obvious to you....
Comment 9 Michael Catanzaro 2020-06-14 06:21:49 PDT 
This is cloop CI, so ENABLE(SIGNAL_BASED_VM_TRAPS) is disabled on all architectures because it depends on DFG and we are testing cloop. I don't know what VM traps is or if it's related, but I see it plays with signals and might possibly explain why the issue occurs on more architectures than I had expected, so I mention it.
Comment 10 Michael Catanzaro 2020-06-15 10:54:22 PDT 
Created bug #213200. Let's see if I can reproduce locally....