On Tue, 9 May 2023 22:49:28 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> 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 ma de 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. > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > minor comment changes. Thanks for the reviews Alex and Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13848#issuecomment-1542671755
