GTTF: launch test processes using job objects on Windows.

base/test/test_launcher.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "base/test/test_launcher.h"
 
 #include "base/at_exit.h"
 #include "base/bind.h"
 #include "base/command_line.h"
 #include "base/environment.h"
@@ skipping 522 matching lines @@
 
 int LaunchChildTestProcessWithOptions(const CommandLine& command_line,
                                       const LaunchOptions& options,
                                       base::TimeDelta timeout,
                                       bool* was_timeout) {
 #if defined(OS_POSIX)
   // Make sure an option we rely on is present - see LaunchChildGTestProcess.
   DCHECK(options.new_process_group);
 #endif
 
+  LaunchOptions new_options(options);
+
+#if defined(OS_WIN)
+  DCHECK(!new_options.job_handle);
+
+  win::ScopedHandle job_handle(CreateJobObject(NULL, NULL));
+  if (!job_handle.IsValid()) {
+    LOG(ERROR) << "Could not create JobObject.";
+    return -1;
+  }
+
+  // Allow break-away from job since sandbox and few other places rely on it
+  // on Windows versions prior to Windows 8 (which supports nested jobs).
+  // TODO(phajdan.jr): Do not allow break-away on Windows 8.
+  if (!SetJobObjectLimitFlags(job_handle.Get(),
+                              JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE |

[cpu_(ooo_6.6-7.5), 2013/09/10 21:08:56]

but the job closes because its owned by the scopedhandle, so it will kill the
child, I guess it is because you always wait in line 572?

[Paweł Hajdan Jr., 2013/09/10 21:49:53]

Yes, this is intended: by the time this function returns the child process
should be terminated.

+                              JOB_OBJECT_LIMIT_BREAKAWAY_OK)) {
+    LOG(ERROR) << "Could not SetJobObjectLimitFlags.";

[cpu_(ooo_6.6-7.5), 2013/09/10 21:08:56]

so if the sandbox breaks away from your job then you cannot kill anything
sandboxed, is that ok?

[Paweł Hajdan Jr., 2013/09/10 21:49:53]

This is not worse than the current state of things. I think it's fine, unless
you have a specific recommendation that would make it better.

+    return false;

[sky, 2013/09/11 19:29:06]

-1?

[Paweł Hajdan Jr., 2013/09/11 20:43:08]

Done.

+  }
+
+  new_options.job_handle = job_handle.Get();
+#endif  // defined(OS_WIN)
+
   base::ProcessHandle process_handle;
-  if (!base::LaunchProcess(command_line, options, &process_handle))
+  if (!base::LaunchProcess(command_line, new_options, &process_handle))
     return -1;
 
   int exit_code = 0;
   if (!base::WaitForExitCodeWithTimeout(process_handle,
                                         &exit_code,
                                         timeout)) {
     *was_timeout = true;
     exit_code = -1;  // Set a non-zero exit code to signal a failure.
 
     // Ensure that the process terminates.
     base::KillProcess(process_handle, -1, true);

[cpu_(ooo_6.6-7.5), 2013/09/10 21:08:56]

do we need 579?

[Paweł Hajdan Jr., 2013/09/10 21:49:53]

Yes. For example, POSIX (Linux, Mac...).

   }
 
 #if defined(OS_POSIX)
   if (exit_code != 0) {
     // On POSIX, in case the test does not exit cleanly, either due to a crash
     // or due to it timing out, we need to clean up any child processes that
     // it might have created. On Windows, child processes are automatically
     // cleaned up using JobObjects.
     base::KillProcessGroup(process_handle);
   }
@@ skipping 29 matching lines @@
            cycles,
            &exit_code,
            true));
 
   MessageLoop::current()->Run();
 
   return exit_code;
 }
 
 }  // namespace base