[issue15967] Slaves don't seem to clean up their /tmp mess if a step fails.

Trent Nelson added the comment: > > All my slaves' /tmp's are polluted with regrtest fluff. > Which "regrtest fluff" exactly? I was being lazy when I wrote that. By "regrtest fluff" I was referring to lingering files/directories in /tmp, owned by cpython, starting with tmp*. Few examples be

[issue15967] Slaves don't seem to clean up their /tmp mess if a step fails.

Trent Nelson added the comment: > Cleanup on test failure is supposed to be done. Cleanup on crash or > buildbot timeout isn't done as far as I know (and that was a concern I > had with the changes made to support.TESTFN and the cwd, but I didn't > articulate it very well). Ah, yeah, this is

[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS

Ronald Oussoren added the comment: The workaround should not be implemented in os.read because it is a very thin wrapper around the system call and should stay that way. -- ___ Python tracker _

[issue15967] Slaves don't seem to clean up their /tmp mess if a step fails.

Chris Jerdonek added the comment: > Personally I think the best solution is to have the test framework allocate a > single test directory This is partially done. See here: http://hg.python.org/cpython/file/19c74cadea95/Lib/test/regrtest.py#l1810 # Run the tests in a context manager that temp

[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS

Vitaly added the comment: > The workaround should not be implemented in os.read because it is a very thin > wrapper around the system call and should stay that way. Although this issue was initially filed as "Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS", the s

<    1   2