I don't know if it is pertinent to this at all, but I raised https://bugs.python.org/issue44449 in which the faulthandler module can lead to a segfault inside Py_TRASHCAN_SAFE_BEGIN. Would that be avoided if frameobject.c was changed to use Py_TRASHCAN_BEGIN / END?
Duncan. On Tue, 2021-08-17 at 12:00 +0200, Łukasz Langa wrote: > Hi everybody, > I'd like to revive this thread as I feel like we have to do something > here but some consensus is needed first. > > To recap, the current state of things is as follows: > - in March 2000 (d724b23420f) Christian Tismer contributed the > "trashcan" patch that added Py_TRASHCAN_SAFE_BEGIN > and Py_TRASHCAN_SAFE_END macros which allow destroying nested objects > non-recursively. > - in May 2019 (GH-11841 of BPO-35983) Antoine Pitrou merged a change > by Jeroen Demeyer which made Py_TRASHCAN_SAFE_BEGIN/END > (unintentionally?) backwards incompatible; this was released in > Python 3.8.0. > - by the way, GH-11841 introduced a new pair of macros (because they > have different signatures) called simply Py_TRASHCAN_BEGIN and > Py_TRASHCAN_END. > - by that time there was already a follow-up PR open (GH-12607) to > improve backwards compatibility of the macros, as well as introduce > tests for them; this was never merged. > - in Feb 2020 (0fa4f43db08) Victor Stinner removed the trashcan > mechanism from the limited C API (note: not ABI, those are macros) > since it accesses fields of structs not exposed in the limited C API; > this was released in Python 3.9.0. > - in May 2020 Irit noticed that the backwards incompatibility (BPO- > 40608) causes segfaults for C API code that worked fine with Python > 3.7. Using the new macros requires code changes but doesn't crash. > > Now, there are a couple of things we can do here: > Option 1: Finish GH-12607 to fix the old macros, keeping in mind this > will restore compatibility lost with Python 3.8 - 3.10 only for users > of 3.11+ > Option 2: Review and merge GH-20104 that reverts the macro changes > that make old client code segfault -- unclear what else this needs > and again, that would only fix it for users of 3.11+ > Option 3: Abandon GH-12607 and GH-20104, instead declaring the old > macros deprecated for 3.11 and remove them in 3.13 > > I personally agree with Irit, voting +1 for Option 3 since the old > macros were soft-deprecated already by introducing new macros in 3.8, > and more importantly made incompatible with pre-3.8 usage. > > Let's talk on how to proceed. > > - Ł -- Duncan Grisby <dun...@grisby.org>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SB6ODKKHANAHDXST2W73RNDZSCZQFOHS/ Code of Conduct: http://python.org/psf/codeofconduct/
