[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