Thomas Wouters wrote: > On 5/8/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: > >> test_ctypes >> test test_ctypes failed -- Traceback (most recent call last): >> File "/home/neal/python/trunk/Lib/ctypes/test/test_python_api.py", line >> 41, in test_PyInt_Long >> self.failUnlessEqual(grc(42), ref42) >> AssertionError: 336 != 337 >> > > We've been seeing this error for a while now, and given the test, it isn't > entirely surprising. The test tries to do what regrtest -R:: also does: > check for refcount leakage. I'm not entirely sure why it's failing as I > can't reproduce it (although it could be because 42's refcount is actually > 42 :) but it does seem to me that this kind of refleak-checking is somewhat > redundant in the Python testsuite, and it is obvious to me that the > breakage > is precisely because it's being run in the Python testsuite (which is a lot > less reliable an environment than ctypes' own, standalone testsuite.)
I'm not sure I understand this analysis - how can the refcount be 42 and then, a little bit later, be 366 or 337? > Thomas, given the refcount-leakage-coverage the ctypes tests are getting in > the Python distribution, do you want to keep running these tests? Is > there a > way to not run them in the Python testsuite, but still keep them for the > standalone tests? (If you want that, that is.) Yes there is. > Alternatively, we could try > to fix the test. If the problem is indeed what I think it is (42's refcount > being 42 or 41 or 43 at the first grc() call there; I'm not sure) we could > perhaps work around it, using something like: Hm, an easier way would be to use an integer other than 42 which cannot be its own refcount, say, a negative value, or a much larger value like 12345678. Thomas (H.) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
