[Python-Dev] Bizarre new test failure
Fri, 07 Jun 2002 12:03:49 -0400
> 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
> 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
> 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>.