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 vstinner
Recipients methane, pablogsal, serhiy.storchaka, vstinner
Date 2019-03-22.15:55:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1553270129.99.0.424364941573.issue36389@roundup.psfhosted.org>
In-reply-to
Content
> I don't think calling APIs like _PyDict_CheckConsistency() is super useful.

I looked a multiple old issues which contain "visit_decref". Most of them are really strange crashes and were closed with a message like "we don't have enough info to debug, sorry". So honestly, I'm not sure of what is the most "efficient" way to detect corrupted objects.

I guess that we need a trade-off between completeness of the checks and the performance.

gc.enable_object_debugger(1) simply makes Python completely unusable. Maybe such very bad performance makes the feature basically useless. I'm not sure at this point.

I tried to find an old bug which mentioned "visit_decref", tried to reintroduced the fixed bug, but I'm not really convinced by my experimental tests so far.

That being said, I *like* your idea of reusing tp_traverse. Not only it fits very well into the gc module (I chose to put the new feature in the gc module on purpose), but it's closer to the existing "visit_decref crash". If someone gets a crash if visit_decref() and the object debugger uses tp_traverse, object debugger *will* catch the same bug. The expectation is to be able to get it early.

--

Oh by the way, why not using lower GC thresholds? I proposed this idea, but there are multiple issues with that. It can hide the bug (objects destroyed in a different order). It can also change the behavior of the application, which is linked to my previous point (again, objects destroyed in a different order).

That's how Serhiy Storchaka proposed the design of gc.enable_object_debugger(): traverse without touching the reference counter.
https://mail.python.org/pipermail/python-dev/2018-June/153860.html

Thanks Serhiy for this nice idea ;-)
History
Date User Action Args
2019-03-22 15:55:30vstinnersetrecipients: + vstinner, methane, serhiy.storchaka, pablogsal
2019-03-22 15:55:29vstinnersetmessageid: <1553270129.99.0.424364941573.issue36389@roundup.psfhosted.org>
2019-03-22 15:55:29vstinnerlinkissue36389 messages
2019-03-22 15:55:29vstinnercreate