[Python-Dev] Bizarre new test failure

Guido van Rossum guido@python.org
Fri, 07 Jun 2002 11:50:13 -0400


> > I wonder if some new cyclic garbage structure needs two gc.collect()
> > passes in order to break it up.
> 
> If there isn't a bug, this case takes 3(!) passes.

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.

Next:
> [Guido]
> > Any idea why this would only happen on Windows?  I tried it on Linux
> > and couldn't get it to fail.  Not even with gc.set_threshold(1).

[Tim]
> What exactly is "it"?  The failure when running regrtest.py in
> whole; the failure Neil reported (and I assume on Linux) by running
> just test_descr and test_gc after *disabling* gc in regrtest.py
> ("disable" == gc.disable() or gc.set_threshold(0), not
> gc.set_treshold(1)); or the 3 gc.collect()s it takes to clear out
> the cycles in the self-contained test program I posted?

I meant the failure on Windows.

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?

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

--Guido van Rossum (home page: http://www.python.org/~guido/)