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.



_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to