[Python-Dev] [Windows, buildbot] kill_python.c mystery

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