Rarely I'll be running the Python tests in my sandbox from a DOS box, and the test run will just end. Like so: C:\Code\python\PCbuild>python -E -tt ../lib/test/regrtest.py -uall -rw test_softspace test_codecmaps_kr ... test_float test_userdict C:\Code\python\PCbuild> No indication of success or failure -- the process just vanishes mid-stream. Today I noticed this happened when the buildbot started to run tests, and I'm 100% sure it's due to this code in Tools/buildbot/kill_python.c (the buildbot log files showed that kill_python.c killed /some/ Python process, and the Python running release-build tests in my sandbox was the only plausible candidate): if ((strstr(path, "build\\pcbuild\\python_d.exe") != NULL) || (strstr(path, "build\\python.exe") != NULL)) { printf("Terminating %s (pid %d)\n", path, pids[i]); if (!TerminateProcess(hProcess, 1)) { The second clause in the first `if` looks for a substring match on: build\python.exe and that just happens to match a suffix of: C:\Code\python\PCbuild\python.exe which is the release-build Python I happen to be running in my sandbox. Why is the second clause there? That is, are we /trying/ to kill a release-build Python running from the user's sandbox, and if so why? Introducing the second clause was the sole change in rev 46817, and the checkin comment doesn't really explain it: Port cygwin kill_python changes from 2.4 branch. Since I don't know what it's trying to accomplish, I hesitate to change it. It's quite clear what the first clause is trying to accomplish, and that one hasn't caused any problems.