<div class="gmail_quote">On Tue, Apr 13, 2010 at 14:43, David Bolen <span dir="ltr"><<a href="http://db3l.net">db3l.net</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">Brian Curtin <<a href="mailto:brian.curtin@gmail.com">brian.curtin@gmail.com</a>> writes:<br>
<br>
> The tests are run on a native Win32 build as compiled by VS2008. The<br>
> functionality is Win32 specific and wouldn't work on Cygwin, so the tests<br>
> are skipped there. I believe Cygwin is used for kicking off the tests and<br>
> other buildbot stuff, but they don't actually run through Cygwin.<br>
<br>
</div>Yes, that's correct. Cygwin is on my buildbot just for management<br>
convenience. The build slave happens to be started from a Cygwin bash<br>
shell (and beneath a Cygwin-based home directory, which is why you see<br>
it in various path references in logs), but the buildbot code itself<br>
is responsible for executing the python process directly for testing.<br>
And python itself is built normally with VS 2008 as a pure win32<br>
build, no Cygwin dependency.<br>
<br>
I did also verify over the weekend that the failures occur whether the<br>
python_d process is started from a Cygwin bash shell or from the<br>
normal Windows cmd process, and even if test_os is used directly,<br>
without running through rt.bat. The case that ran successfully was<br>
not via test_os, but only by interactively replicating the test.<br>
<br>
I'm back at this point, and to the extent my buildbot is the only<br>
place currently replicating the problem, am working with Brian for<br>
whatever access or resources might be helpful.<br>
<font color="#888888"><br>
-- David</font></blockquote><div><br>Although the fix still needs a bit of cleanup, test_os seems to be working fine on this buildbot now. The test now waits for the subprocess to communicate back that it is running, rather than the time.sleep hacks, then it goes forward with os.kill.<br>
<br>Big thanks to David for access to the machine.<br></div></div>