<br><div><span class="gmail_quote">On 5/9/06, <b class="gmail_sendername">Thomas Heller</b> <<a href="mailto:theller@python.net">theller@python.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thomas Wouters wrote:<br>> On 5/8/06, Neal Norwitz <<a href="mailto:neal@metaslash.com">neal@metaslash.com</a>> wrote:<br>><br>>> test_ctypes<br>>> test test_ctypes failed -- Traceback (most recent call last):
<br>>> File "/home/neal/python/trunk/Lib/ctypes/test/test_python_api.py", line<br>>> 41, in test_PyInt_Long<br>>> self.failUnlessEqual(grc(42), ref42)<br>>> AssertionError: 336 != 337
<br>>><br>><br>> We've been seeing this error for a while now, and given the test, it isn't<br>> entirely surprising. The test tries to do what regrtest -R:: also does:<br>> check for refcount leakage. I'm not entirely sure why it's failing as I
<br>> can't reproduce it (although it could be because 42's refcount is actually<br>> 42 :) but it does seem to me that this kind of refleak-checking is somewhat<br>> redundant in the Python testsuite, and it is obvious to me that the
<br>> breakage<br>> is precisely because it's being run in the Python testsuite (which is a lot<br>> less reliable an environment than ctypes' own, standalone testsuite.)<br><br>I'm not sure I understand this analysis - how can the refcount be 42 and then,
<br>a little bit later, be 366 or 337?</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Thomas, given the refcount-leakage-coverage the ctypes tests are getting in
<br>> the Python distribution, do you want to keep running these tests? Is<br>> there a<br>> way to not run them in the Python testsuite, but still keep them for the<br>> standalone tests? (If you want that, that is.)
<br><br>Yes there is.</blockquote><div><br>I'd suggest doing that, then.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Alternatively, we could try
<br>> to fix the test. If the problem is indeed what I think it is (42's refcount<br>> being 42 or 41 or 43 at the first grc() call there; I'm not sure) we could<br>> perhaps work around it, using something like:
<br><br>Hm, an easier way would be to use an integer other than 42 which cannot be its<br>own refcount, say, a negative value, or a much larger value like 12345678.</blockquote><div><br>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.</div></div><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!