[Python-Dev] Bizarre new test failure

[Tim Peters]

[Guido]
> That same testcase prints the same output for me on Linux, with Python
> 2.2, with a 2.3 from June 4th, and with 2.3 from current CVS:
>
>     collected 3
>     collected 51
>     collected 9
>     collected 0
>
>     and, at the end, collected 1
>
> So there really are test cases that require more than one collection
> to clean them up.

Same here.  I wish we understood why.  Or that at least one of Neil and I
understood why.

> ...
> But I can now reproduce on Linux what Neil did using the new -t option
> that I just added to regrtest.py:
>
>     ./python ../Lib/test/regrtest.py -t0 test_descr test_gc
>
> which tells me
>
>     test test_gc failed -- test_list: actual 10, expected 1
>
> When I put an extra gc.collect() call in test_gc.test_list(), the test
> succeeds.
>
> Is this the right fix?

No, but assuming there isn't a real bug here, repeating gc.collect() until
it returns 0 would be -- as the self-contained program showed, we *may* need
to call gc.collect() as many as 4 times before that happens.  And if it's
legit that it may need 4, I see no reason for believing there's any a priori
upper bound on how many may be needed.  And the test could have failed all
along, even in 2.2; it apparently depends on how many times gc just happens
to run before we get to test_gc.

I'll check in a "drain it" fix to test_gc, but I'm still squirming.

> I can't see anything particilarly wrong with subtype_clear() or the
> slot-traversing subtype_traverse() in typeobject.c.

I couldn't either, but in my case I had scant idea what it thought it was
trying to do <0.9 wink>.