Re: [Python-Dev] [Python-checkins] r46005 - in python/trunk: Lib/tarfile.py Lib/test/test_tarfile.py Misc/NEWS
Author: georg.brandl Date: Mon May 15 21:30:35 2006 New Revision: 46005
Modified: python/trunk/Lib/tarfile.py python/trunk/Lib/test/test_tarfile.py python/trunk/Misc/NEWS Log: [ 1488881 ] tarfile.py: support for file-objects and bz2 (cp. #1488634)
"Something went wrong" here on Windows. The Windows buildbot slaves other than mine eventually died with: """ ... test_tarfile command timed out: 1200 seconds without output """: I was working on my box at the time, and it became dramatically unusable: took about two minutes just to swap enough of the OS back in to _bring up_ Task Manager to see what was going on. The Python test process was close to 2GB in size, and of course the box was swapping madly. So I killed python_d.exe and waited to see how the other buildbots fared. Sure appears to be a Windows-specific problem -- or maybe all the Linux boxes come with a terabyte of RAM these days ;-) I'll take a peek later, but won't be disappointed if someone else figures it out first.
[Tim]
"Something went wrong" here on Windows. The Windows buildbot slaves other than mine eventually died with:
""" ... test_tarfile
command timed out: 1200 seconds without output """:
I was working on my box at the time, and it became dramatically unusable: took about two minutes just to swap enough of the OS back in to _bring up_ Task Manager to see what was going on. ...
OK, I fixed that, but unfortunately the checkin comment was correct: The Windows buildbot slaves shouldn't swap themselves to death anymore. However, test_tarfile may still fail because of a temp directory left behind from a previous failing run. Windows buildbot owners may need to remove that directory by hand. I did that on my box, and test_tarfile passes there now, but test_tarfile is still failing on other Windows slaves; e.g., http://www.python.org/dev/buildbot/all/x86%20W2k%20trunk/builds/694/step-tes... ... WindowsError: [Error 183] Cannot create a file when that file already exists: 'c:\\docume~1\\trentm~1.act\\locals~1\\temp\\testtar.dir\\directory'
On 5/15/06, Tim Peters <tim.peters@gmail.com> wrote:
[Tim]
"Something went wrong" here on Windows. The Windows buildbot slaves other than mine eventually died with:
""" ... test_tarfile
command timed out: 1200 seconds without output """:
I was working on my box at the time, and it became dramatically unusable: took about two minutes just to swap enough of the OS back in to _bring up_ Task Manager to see what was going on. ...
OK, I fixed that, but unfortunately the checkin comment was correct:
The Windows buildbot slaves shouldn't swap themselves to death anymore. However, test_tarfile may still fail because of a temp directory left behind from a previous failing run. Windows buildbot owners may need to remove that directory by hand.
I did that on my box, and test_tarfile passes there now, but test_tarfile is still failing on other Windows slaves; e.g.,
http://www.python.org/dev/buildbot/all/x86%20W2k%20trunk/builds/694/step-tes...
...
WindowsError: [Error 183] Cannot create a file when that file already exists: 'c:\\docume~1\\trentm~1.act\\locals~1\\temp\\testtar.dir\\directory' _______________________________________________
Ignorant question probably, but why can't the test just check for the directory first, and remove it if it exists? -Brett
[Brett Cannon]
Ignorant question probably, but why can't the test just check for the directory first, and remove it if it exists?
Because it's a stupid hack that should never be necessary: the test cleans up after itself in a "finally" clause. It only looks attractive right now because an earlier bug caused the Windows boxes to swap themselves to death, and the "finally" clause never executed. So, what the heck, sure, I checked that in :-)
participants (2)
-
Brett Cannon -
Tim Peters