Martin v. Löwis wrote:
> It can't be that simple. Python's stdout should indeed be inherited
> from cmd.exe, but that, in turn, should have obtained it from
> buildbot. So even though cmd.exe closes its handle, Python's handle
> should still be fine. If buildbot then closes the other end of the
> pipe, Python should get ERROR_BROKEN_PIPE. The only deadlock I
> can see here is when buildbot does *not* close the pipe, but stops
> reading from it. In that case, Python's WriteFile would block.
>
> If that happens, it would be useful to attach with a debugger to
> find out where Python got stuck.
I doubt it has anything to do with this issue, but I just thought I'd
mention something strange I've encountered on Windows XP Pro (SP2) at
work.
If Python terminates due to an uncaught exception, with stdout & stderr
redirected externally (ie within the batch file that started Python),
the files that were redirected to cannot be deleted/renamed until the
system is rebooted.
If a bare except is used to trap any such exceptions (and the traceback
printed explicitly) so that Python terminates normally, there is no
problem (ie the redirected files can be deleted/renamed etc).
I've never reported this as a Python bug because I've considered the
antivirus SW likely to be the culprit. I don't recall seeing this with
Windows 2000, but much was changed in the transition from the Win2k SOE
to the WinXP SOE.
A wild shot at best...
Andrew.
--
-------------------------------------------------------------------------
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370
andymac at pcug.org.au (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4