[Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause (original) (raw)
Trent Nelson tnelson at onresolve.com
Wed Apr 2 18:20:21 CEST 2008
- Previous message: [Python-Dev] [Python-3000] the release gods are angry at python
- Next message: [Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Looking into some of the recent Windows buildbot failures, I see things like this:
sqlite3 : error PRJ0008 : Could not delete file 'c:\buildbot\trunk.heller-windows-amd64\build\PCbuild\amd64\sqlite3_d.dll'.
build-amd64.bat doesn't go through the kill_python.c hoopla, so I figure the above error is being caused by the fact that an erroneous/stalled python_d.exe from a previous run is still open. I was looking at modifying kill_python.c to accept an 'x64' argument if we want to kill amd64\python_d.exe instead of the usual 32-bit exe, however, this caught my attention:
if ((strstr(path, "pcbuild\python_d.exe") != NULL) || (strstr(path, "\build\python.exe") != NULL)) { printf("Terminating %s (pid %d)\n", path, pids[i]); if (!TerminateProcess(hProcess, 1)) { printf("Termination failed: %d\n", GetLastError()); return 1; } return 0;
That'll kill the first python_d.exe instance it finds matching the given path; given that our buildbots run trunk/release25-maint/py3k in parallel, it seems as though it wouldn't be hard for us to get into a situation where kill_python.exe ends up killing the wrong python_d.exe (i.e. trunk checkin, trunk builds, starts testing, py3k checkin, calls kill_python.exe, kills trunk's python_d.exe that was in the middle of testing).
That can't be helping our cause, unless I'm missing something... Unless anyone advises otherwise, I'll start on a patch.
Trent.
- Previous message: [Python-Dev] [Python-3000] the release gods are angry at python
- Next message: [Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]