---

yaml
---
r: 274861
b: refs/heads/stable
c: 07638b9
h: refs/heads/master
i:
  274859: 194435f

Author: alexcrichton

[refs]

@@ -29,7 +29,7 @@ refs/heads/tmp: e06d2ad9fcd5027bcaac5b08fc9aa39a49d0ecd3
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: c0221c8897db309a79990367476177b1230bb264
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: a1c13d03a5bbbc99d595906e566912e0bad337b3
+refs/heads/stable: 07638b95cec645bf8f587eb7851412aa3cdf4995
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375
 refs/tags/1.1.0: bc3c16f09287e5545c1d3f76b7abd54f2eca868b
 refs/tags/1.2.0: f557861f822c34f07270347b94b5280de20a597e

branches/stable/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