This test was very rarely failing with a exitValue 143 from the debuggee. It only happened when the machine was under a lot of stress. After some investigation it was realized that on unix OSes it should *always* expect exitValue 143, but for some reason was normally getting exitValue 0. The reason 143 should be expected is because `Process.destroy()` is used on the debuggee, which results in a SIGTERM, which should produce exitValue 143. The reason we were not normally seeing this is because the `Process.destroy()` was done while the debuggee was suspended at a breakpoint. Nothing can be done with the SIGTERM while all threads are suspended, but once the debugger does the `vm.resume()` the SIGTERM can be handled. But by that time it is a race between some thread handling SIGTERM and doing the exit(143), and the main debuggee thread resuming and exiting cleanly (producing exitValue 0). In almost all cases the clean exit was winning. By adding a 5 second sleep before exiting, I made it so the SIGTERM exit always wins. Once this was in place, I had to make changes so the test would pass with exitCode 143. This was done by adding a `TestScaffold.allowExitValue()` method, which the test can override. Note I'll have more uses for this in the future, as I plan to no longer by default allow exitValue 1 (exit with an uncaught exception) and requiring tests to override this method if needed. That will be done by [JDK-8307559](https://bugs.openjdk.org/browse/JDK-8307559).
Tested by running all of test/jdk/com/sun/jdi with and without virtual threads, 10x times on each platform. ------------- Commit messages: - Allow 143 exitcode. Changes: https://git.openjdk.org/jdk/pull/13848/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13848&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306758 Stats: 46 lines in 3 files changed: 36 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13848.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13848/head:pull/13848 PR: https://git.openjdk.org/jdk/pull/13848
