[Python-Dev] [Python-checkins] Python Regression Test Failures basics (1)

[Thomas Wouters]

On 5/9/06, Thomas Heller <theller at python.net> wrote:
>
> 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?


Eh, yes,  obviously, it can't, and I wasn't paying enough attention. I guess
something else is getting a reference to 42 somewhere, which'd have to be in
the unittest internals. And since those can change at any time, there's no
way to run the test reliably unless there are no external calls between the
two getrefcount calls.

> 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.


I'd suggest doing that, then.

> 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.


I don't think that'll work, because they aren't interned. The refcount of
the constant 12345678 and of the result of pythonapi.PyInt_FromLong(12345678)
will be unrelated.

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060509/2d395a3e/attachment-0001.htm