Author tim.peters
Recipients Mark.Shannon, benjamin.peterson, christian.heimes, jdemeyer, larry, lukasz.langa, methane, miss-islington, nascheme, ned.deily, pablogsal, petr.viktorin, pitrou, tim.peters, vstinner
Date 2019-10-04.17:51:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
BTW, the phrase "missing tp_traverse" is misleading.  If an object with a NULL tp_traverse appears in a gc generation, gc will blow up the next time that generation is collected.  That's always been so - gc doesn't check whether tp_traverse is NULL, it just calls it.  It's tp_clear that it checks, because that one is optional.

I don't recall any problem we've had with extensions implementing the gc protocol incorrectly or incompletely.  It's this issue's problem:  containers not participating in gc _at all_.

If we had a traditional mark-sweep collector, that would be massively catastrophic.  Miss a pointer and you can conclude a live object is actually trash, and tear it down while it's still in use.

Our problem is the opposite:  miss a pointer and we can conclude a trash object is actually live.  At the start, the worst that _could_ do is leak memory.  It's the later introduction of time-to-die finalizers (weakref callbacks at first) that created the opportunity for segfaults:  the only 100% clearly safe way to run finalizers in cyclic trash is to force them to run _before_ anything at all is torn down by force (tp_clear).  But to run them in advance, we have to know the relevant objects _are_ trash.  Which we can't always know if containers don't always participate.

While Neil & I haven't thought of ways that can go wrong now beyond that a "surprise finalizer" may get run any number of times, that doesn't mean far worse things can't happen - just that they'll surprise us when they do :-)
Date User Action Args
2019-10-04 17:51:10tim.peterssetrecipients: + tim.peters, nascheme, pitrou, vstinner, larry, christian.heimes, benjamin.peterson, ned.deily, petr.viktorin, methane, lukasz.langa, Mark.Shannon, jdemeyer, pablogsal, miss-islington
2019-10-04 17:51:10tim.peterssetmessageid: <>
2019-10-04 17:51:10tim.peterslinkissue38006 messages
2019-10-04 17:51:09tim.peterscreate