New submission from STINNER Victor <vstin...@python.org>:
A bug in Python/hamt.c was only discovered 4 months after the code was added to Python: * https://mail.python.org/pipermail/python-dev/2018-June/153857.html * https://bugs.python.org/issue33803 The problem was that an object was tracked by the GC, whereas calling its traverse method crashed Python... depending when the traverse method is called exactly. Pseudo-code: PyObject_GC_Track(<partially initialized object>); ... obj2 = PyObject_GC_NewVar(...); ... <finish to initialize the first object> The problem is that PyObject_GC_NewVar() can trigger a GC collection which uses the partially initialized object, and then we get a cryptic crash in the GC (usually seen in visit_decref()). I propose to make PyObject_GC_Track() stricter: validate that the object seems to be "valid" or "fully initialized". From the GC point of view, it means that calling tp_traverse must not crash. Attached PR is a concrete implementation. This issue is a follow-up of my previously failed attempt bpo-36389 "Add gc.enable_object_debugger(): detect corrupted Python objects in the GC". While bpo-36389 attempts to discoverd corrupted objects once a GC collection is triggered, this issue is restricted to objects entering the GC. First problem: my PR breaks Modules/pyexpat.c whereas the code is not strictly a bug: in Python 3.8, it's ok to put a partially initialized object into the GC if no GC collection can be triggered before the object is fully initialized. In Modules/pyexpat.c case, the code looks safe from that point of view. It means that such change is a backward incompatible change. IMHO it's a good step forward, since it is likely to discovered hidden bugs. ---------- components: Interpreter Core messages: 354074 nosy: vstinner priority: normal severity: normal status: open title: Ensure that objects entering the GC are valid versions: Python 3.9 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38392> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
