On 4/22/06, Tim Peters <tim.peters at gmail.com> 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 into test_threading_local, I checked in what > appeared to be a total leak fix for it last week. On my Windows box, > it's steady as a rock now: > > """ > $ python_d -E -tt ../lib/test/regrtest.py -R:50: test_threading_local > test_threading_local > beginning 55 repetitions > 1234567890123456789012345678901234567890123456789012345 > ....................................................... > 1 test OK. > [27145 refs] > """ > > Is it still flaky on other platforms? > > If not, maybe the reported > > test_threading_local leaked [-93, 0, 0] references > > is due to stuff from a _previous_ test getting cleaned up (later than > expected/hoped)? When you first sent this message I was able to reproduce the leaks inconsistently on the box that runs this test. I *think* all that was required was test_cmd_line test_suprocess and test_threading_local (in that order). I suspect that the problem is some process is slow to die. I don't think I can provoke any of these in isolation. I definitely can't provoke them consistently. Today, I wasn't able to provoke them at all. 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. Sometimes it gets stuck. But the most you should ever receive is 2 mails a day. n
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