Py_XDECREF() module on fail in Py_mod_exec · Issue #90763 · python/cpython
Comments
| BPO | 46605 |
|---|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None closed_at = None created_at = <Date 2022-02-01.21:49:08.439> labels = ['type-bug', '3.8', '3.9', '3.10', '3.11', 'extension-modules', '3.7'] title = 'Py_XDECREF() module on fail in Py_mod_exec' updated_at = <Date 2022-02-01.21:49:08.439> user = 'https://bugs.python.org/ov2k'
bugs.python.org fields:
activity = <Date 2022-02-01.21:49:08.439> actor = 'ov2k' assignee = 'none' closed = False closed_date = None closer = None components = ['Extension Modules'] creation = <Date 2022-02-01.21:49:08.439> creator = 'ov2k' dependencies = [] files = [] hgrepos = [] issue_num = 46605 keywords = [] message_count = 1.0 messages = ['412315'] nosy_count = 1.0 nosy_names = ['ov2k'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue46605' versions = ['Python 3.7', 'Python 3.8', 'Python 3.9', 'Python 3.10', 'Python 3.11']
In some of the xx modules, a Py_mod_exec function steals a reference to the module argument when an error occurs (Py_XDECREF(m) after goto fail). It's a bit pernicious given the modules' stated intent to be used as a template, although I'm not sure how often this has actually happened. At the very least, I haven't noticed this outside the xx modules.
For Python <= 3.9, this affects xx_exec() in xxmodule.c and xx_modexec() in xxlimited.c. For Python >= 3.10, this affects xx_exec() in xxmodule.c and xx_modexec() in xxlimited_35.c.
We might as well clean up the whole init functions of those two template modules. For example, xxmodule.c does not check the return value of PyModule_AddObject (and it should use PyModule_AddType instead).
erlend-aasland added a commit to erlend-aasland/cpython that referenced this issue
May 22, 2022
Use C APIs such as PyModule_AddType instead of PyModule_AddObject. Also remove incorrect module decrefs if module fails to initialise.
erlend-aasland added a commit to erlend-aasland/cpython that referenced this issue
May 22, 2022
Use C APIs such as PyModule_AddType instead of PyModule_AddObject. Also remove incorrect module decrefs if module fails to initialise.
erlend-aasland added a commit that referenced this issue
Jun 10, 2022
Use C APIs such as PyModule_AddType instead of PyModule_AddObject. Also remove incorrect module decrefs if module fails to initialise.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue
Jun 10, 2022erlend-aasland added a commit to erlend-aasland/cpython that referenced this issue
Jun 10, 2022
…ythonGH-93078) Use C APIs such as PyModule_AddType instead of PyModule_AddObject. Also remove incorrect module decrefs if module fails to initialise. (cherry picked from commit a87c9b5) Co-authored-by: Erlend Egeberg Aasland <erlend.aasland@protonmail.com>
miss-islington added a commit that referenced this issue
Jun 10, 2022
Use C APIs such as PyModule_AddType instead of PyModule_AddObject. Also remove incorrect module decrefs if module fails to initialise. (cherry picked from commit a87c9b5) Co-authored-by: Erlend Egeberg Aasland <erlend.aasland@protonmail.com>
erlend-aasland added a commit that referenced this issue
Jun 10, 2022
1 participant