Tim Peters wrote:
No, what's surprising is that it keeps running _forever_. This isn't Unix, and, e.g., a defunct child process doesn't sit around waiting for its parent to reap it. Why doesn't the leftover python_d.exe complete running the test suite, and then go away all by itself? It doesn't, no matter how long you wait. That's the mystery to me.
True. But I find that not too surprising: something deadlocks. A perfect deadlock aims to hold until the heat death of the universe; most of them only hold until reboot, or even just process termination. Now, as to *why* it deadlocks: that's indeed a mystery. But hey: it's Windows, so processes just do get stuck. It took them years to make sure they system continues running in such a case.
It suppose it's possible that killing cmd.exe actually did work, but the buildbot code misreports the outcome, and python_d.exe "runs forever" because it's blocked waiting on some resource (console I/O handle?) it inherited from its (no longer there) parent process.
It can't be that simple. Python's stdout should indeed be inherited from cmd.exe, but that, in turn, should have obtained it from buildbot. So even though cmd.exe closes its handle, Python's handle should still be fine. If buildbot then closes the other end of the pipe, Python should get ERROR_BROKEN_PIPE. The only deadlock I can see here is when buildbot does *not* close the pipe, but stops reading from it. In that case, Python's WriteFile would block. If that happens, it would be useful to attach with a debugger to find out where Python got stuck. Regards, Martin