This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nascheme
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-14.22:44:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1571093042.65.0.827472874937.issue38006@roundup.psfhosted.org>
In-reply-to
Content
> It's fundamentally insane to expect any gc to work perfectly when it may be blind to what the object graph _is_.

I'm often amazed it works at all, let alone perfectly. ;-P

This did trigger me to think of another possible problem.  I setup my unit test as you suggested:

        #   Z <- Y <- A--+--> WZ -> C
        #             ^  |
        #             +--+
        # where:
        #   WZ is a weakref to Z with callback C
        #   Y doesn't implement tp_traverse
        #   A contains a reference to itself, Y and WZ

But what happens if the GC doesn't see that WZ is trash?  Then it will not be cleared.  Hang it off Y so the GC can't find it.  We can set things up so that Z is freed before WZ (e.g. WZ in a second and newer cycle).  Then, the callback might still run.

On further thought, this seems safe (but maybe broken) because of the handle_weakrefs() logic.  The GC will think WZ is going to outlive Z so it will call it before doing any tp_clear calls.
History
Date User Action Args
2019-10-14 22:44:02naschemesetrecipients: + nascheme, tim.peters, pitrou, vstinner, larry, christian.heimes, benjamin.peterson, ned.deily, petr.viktorin, methane, lukasz.langa, Mark.Shannon, jdemeyer, pablogsal, miss-islington
2019-10-14 22:44:02naschemesetmessageid: <1571093042.65.0.827472874937.issue38006@roundup.psfhosted.org>
2019-10-14 22:44:02naschemelinkissue38006 messages
2019-10-14 22:44:02naschemecreate