Neil Schemenauer <nas-pyt...@arctrix.com> added the comment:
I hacked up my copy of CPython to add flags to PyObject to see the GC state of objects. That makes it easier to know if an object is in the 'unreachable' list or not. > We must know that F is trash, else we never would have called tp_clear(F). Yup. In the crashing test program, F is in 'unreachable'. > We must NOT know CT is trash. If we did know that, then we would > have found W too, and then: Yes again. CT is not in 'unreachable'. > So if CT _is_ trash, we didn't know it. If/when delete_garbage > broke enough cyclea that CT's refcount fell to 0, other parts of > Python would have invoked W's callback as a matter of course, with > F possibly already tp_clear'ed. I haven't verified this but it must be what's happening. Note that my flags show that W *is* in 'unreachable'. It has to be otherwise F would not have tp_clear called on it. > Neil, at a high level it's not REALLY surprisimg that gc can screw > up if it can't tell the difference between trash & treasure ;-) > Long ago, though, it's possible the only real failure mode was > leaking objects that were actually unreachable. It has been so long I can't be sure the GC worked that way but I think it did. It would only call tp_clear on things it could really prove were garbage. If tp_clear didn't actually break the cycle, the only harmful result was leaking memory. That behavior is similar to a conservative GC. > Offhand not worried about get_objects(). That returns objects from > generation lists, but gc moves possible trash among temporary > internal (not generation) lists as it goes along. But when delete_garbage() gets done, it moves the object to 'old'. I think that means gc.get_objects() called after the collection completes can reveal objects that have had their tp_clear called (if tp_clear didn't result in them being freed). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38006> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
