[Tim, gets different results across whole runs of
python_d ../Lib/test/regrtest.py -R 2:40: test_filecmp test_exceptions
]
I think I found the cause for test_filecmp giving different results
across runs, at least on Windows. It appears to be due to this test
line:
Tim Peters wrote:
and filecmp contains a module-level _cache with a funky scheme for
avoiding file comparisons if various os.stat() values haven't changed.
But st_mtime on Windows doesn't necessarily change when a file is
modified -- it has limited resolution (2 seconds on FAT32, and I'm
[moving to python-dev]
[Tim, gets different results across whole runs of
python_d ../Lib/test/regrtest.py -R 2:40: test_filecmp test_exceptions
]
Does that make any sense? Not to me -- I don't know of a clear reason
other than wild loads/stores for why such runs should ever differ.
On 4/22/06, Tim Peters [EMAIL PROTECTED] wrote:
[19 Apr 2006, Neal Norwitz]
test_cmd_line leaked [0, 17, -17] references
test_filecmp leaked [0, 13, 0] references
test_threading_local leaked [-93, 0, 0] references
test_urllib2 leaked [-121, 88, 99] references
Thanks to Thomas digging
[Neal Norwitz]
...
I have disabled the leak warning for:
LEAKY_TESTS=test_(cmd_line|ctypes|filecmp|socket|threadedtempfile|threading|urllib2)
This is an attempt to reduce the spam. Would people rather me reduce
this list so we can try to find the problems? The test runs 2 times
per day.
[19 Apr 2006, Neal Norwitz]
test_cmd_line leaked [0, 17, -17] references
test_filecmp leaked [0, 13, 0] references
test_threading_local leaked [-93, 0, 0] references
test_urllib2 leaked [-121, 88, 99] references
Thanks to Thomas digging into test_threading_local, I checked in what
appeared
[Thomas Wouters]
I did the same narrowing-down last week, and submitted a patch to add
cycle-GC support to itertools.tee . It really needs it.
I agree.
Come to think of it, now that I remember how to properly do GC, I think
the patch cuts some corners, but it solved the problem.
You mean
