> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4