[Python-Dev] [Windows, buildbot] kill_python.c mystery (original) (raw)

Tim Peters tim.peters at gmail.com
Fri Jul 28 02:46:30 CEST 2006

[Martin v. Löwis]

Didn't you know that you signed in to run arbitrary viruses, worms, and trojan horses when you added your machine to the buildbot infrastructure :-?

Hey, I signed up for that when I bought a Windows box :-)

You just haven't seen buildbot erasing your hard disk and filling your coffee machine with tea, yet.

Not the buildbot, no, but visiting random web pages does that routinely.

(strstr(path, "build\python.exe") != NULL)) { Why is the second clause there?

That's for Cygwin (i.e. Anthony Baxter's machine). As Neal suggests, preceding the executable path with another backslash should solve this problem.

And he checked that in, and I haven't noticed another similar problem since (but then it was rare to begin with).

As a related note, this entire approach will also manage to kill python.exe from an unrelated buildbot installation, e.g. a 2.4 build job might kill python.exe from the trunk. This actually helped when I tried to get the Cygwin slave to get unstuck, and shouldn't do harm since we currently don't run to builds on the same slave simultaneously, but could be surprising when parallel builds are activated some day.

I don't think we /can/ yet -- I believe some tests T exist that implicitly assume only one instance of T is running. I don't recall details, although I'm sure we'll bump into them sporadically the instant parallel builds are enabled. As a purely pragmatic matter, I expect my hard drive would quickly be reduced to dust if two instances of test_largefile ran simultaneously (Windows XP writes physical zeroes in the entire multi-GB file, and that takes finite time only if the disk head doesn't have to keep seeking).

Sorry for messing with your machine,

No problem! That's what it's here for :-)

More information about the Python-Dev mailing list