Tim Peters <t...@python.org> added the comment:
Sorry, this is very hard for me - broke an arm near the shoulder on Tuesday, and between bouts of pain and lack of good sleep, concentration is nearly impossible. Typing with one hand just makes it worse :-( We must know that F is trash, else we never would have called tp_clear(F). We must NOT know CT is trash. If we did know that, then we would have found W too, and then: 1. If we thought W was trash, we would have suppressed the callback. 2. If we thought W was not trash, we would have invoked the callback directly, long before delete_garbage even started (i.e., F would have been intact). 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. 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. 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. Am concerned that weakref callbacks may not be the only hole. We force-run finalizers before ever calling tp_clear for the same reason we force-run weakref callbacks: finalizers may also need to access trash objecta while they're still sane. Having finalizers on objects in trash cycles isn't special anymore (we used to refuse to run them). But my brain is fried again for now ;-) ---------- _______________________________________ 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
