[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