Windows: native test wrapper waits for all grandchild processes

[laszlocsomor]

Description of the problem / feature request:

The Windows-native test wrapper waits for all subprocesses of the test to terminate, even after the test itself terminated.

I believe the test wrapper should use job objects:

bazel/src/main/native/windows/processes-jni.cc

Line 370 in c6c3030

HANDLE job = CreateJobObject(NULL, NULL);

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

BUILD:

java_test(
    name = "sleepy",
    main_class = "Sleepy",
    srcs = ["Sleepy.java"],
    timeout = "short",
    use_testrunner = 0,
)

Sleepy.java:

public class Sleepy {
  public static void main(String[] args) throws Exception {
    new ProcessBuilder("C:/msys64/usr/bin/sleep.exe", "15").inheritIO().start();
  }
}

Without test wrapper:

C:\src\tmp>c:\src\bazel\bazel-bin\src\bazel.exe test -t- --noincompatible_windows_native_test_wrapper //:sleepy
(...)
//:sleepy                                                                PASSED in 1.8s

With test wrapper:

C:\src\tmp>c:\src\bazel\bazel-bin\src\bazel.exe test -t- --incompatible_windows_native_test_wrapper //:sleepy
(...)
//:sleepy                                                                PASSED in 15.7s

INFO: Build completed successfully, 2 total actions

What operating system are you running Bazel on?

Windows 10

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

Built from source at c6c3030

[jmmv]

Mostly out of curiosity because I was filing #10245 and this bug turned out as suggested.

How was this fixed? If I'm reading things correctly, Bazel now kills the process group on Windows, right? But do you wait for the subprocesses at all? If not, you'd be subject to the same issues I reported.

[laszlocsomor]

If a test times out, Bazel terminates the process tree. We don't wait for subprocesses in this case, so they could leave stale state behind.

[laszlocsomor]

As best as I know, processes can't signal each other on Windows as they can on Linux, so there's no generic graceful termination mechanism like SIGINT or SIGTERM, just the blunt TerminateProcess (like SIGKILL).

PostQuitMessage comes to mind for windowed applications (which the majority of Bazel-ran tools aren't), but that requires cooperation from the process (running a message processing loop).

[jmmv]

Note that the process-wrapper on Unix systems doesn't allow processes to terminate gracefully either, in the general case: it just sends everything a SIGKILL. So what you are doing on Windows seems very similar.