bootstrap: Be resilient to job object failures

The build bots already use job objects, and they don't support nested job
objects, and we shouldn't entirely bail out in this case anyway!

diff --git a/src/bootstrap/build/job.rs b/src/bootstrap/build/job.rs
index 49e027ffda596112ceaf635f7ebbfe5fd8ac762b..a4e53bc45fcfbf979836b89b8ea1bba17b834122 100644 (file)
--- a/src/bootstrap/build/job.rs
+++ b/src/bootstrap/build/job.rs
@@ -64,9 +64,20 @@ pub unsafe fn setup() {
                                     mem::size_of_val(&info) as DWORD);
     assert!(r != 0, "{}", io::Error::last_os_error());
 
-    // Assign our process to this job object
+    // Assign our process to this job object. Note that if this fails, one very
+    // likely reason is that we are ourselves already in a job object! This can
+    // happen on the build bots that we've got for Windows, or if just anyone
+    // else is instrumenting the build. In this case we just bail out
+    // immediately and assume that they take care of it.
+    //
+    // Also note that nested jobs (why this might fail) are supported in recent
+    // versions of Windows, but the version of Windows that our bots are running
+    // at least don't support nested job objects.
     let r = AssignProcessToJobObject(job, GetCurrentProcess());
-    assert!(r != 0, "{}", io::Error::last_os_error());
+    if r == 0 {
+        CloseHandle(job);
+        return
+    }
 
     // If we've got a parent process (e.g. the python script that called us)
     // then move ownership of this job object up to them. That way if the python