The attached patch fixes the bug pointed out in crashers/gc_inspection.py, namely that gc.get_referrers() can be used to see objects (in this case tuples) before their built, leading to segfaults. The patch works by modifying Objects/abstract.c:PySequence_AsTuple, wrapping the call to PyIter_Next() with _PyObject_GC_TRACK/UNTRACK calls. This has the effect of hiding the being-created tuple from gc.get_referrers() while fetching the next item from the iterator. Also attached is a patch to crashers/gc_inspection.py itself, which allows the test to actually pass (the previous version would raise IndexErrors in the event the test passed).
Logged In: YES user_id=1344176 The improve_gc_inspection.patch file has been superseded by a patch attached to bug #1517663. The bug details another interpreter crash in the same vein as the one fix in tuple() by this patch.
Logged In: YES user_id=80475 Crashers based on gc.get_referrers() should not be considered real bugs. It is certainly not worth complexifying the code or slowing it down just to preclude these little perverse safe-cracking exercises. Also, it is not worth the risk of introducing a real bug when the code was working fine. That being said, if the code is genuinely defective and has potential to cause real-world problems, then it should be fixed. I would think that if there were a long- standing problem with tuples, it would have manifested itself long ago.
Logged In: YES user_id=4771 This patch is pointless. I recommend rejecting it. The crashers/gc_inspection.py was just one example among many of crashing Python with gc.get_referrers(). I don't see why we should care to fix just this specific way. What would be needed is a complete review, possibly with an API change to decouple object creation and GC registration, and appropriate documentation for extension module writers. I don't think it's likely to happen though.
