[Python-Dev] [Python-checkins] Python Regression Test Failures basics (1)
Thomas Heller
theller at python.net
Tue May 9 08:53:46 CEST 2006
Thomas Wouters wrote:
> On 5/8/06, Neal Norwitz <neal at metaslash.com> 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.)
More information about the Python-Dev
mailing list