Description

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'

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']

Activity

1. ov2k commented on Feb 1, 2022

   

   ov2kmannequin

   on Feb 1, 2022

   MannequinAuthor

   More actions

   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.
2. ov2k

   added

   3.7 (EOL)end of lifeend of life

   3.8 (EOL)end of lifeend of life

   3.9 (EOL)end of lifeend of life

   3.10 (EOL)end of lifeend of life

   3.11only security fixesonly security fixes

   extension-modulesC modules in the Modules dirC modules in the Modules dir

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Feb 1, 2022
3. ezio-melotti

   transferred this issue fromon Apr 10, 2022
4. erlend-aasland commented on May 22, 2022

   

   erlend-aasland

   on May 22, 2022

   Contributor

   More actions

   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).
5. erlend-aasland

   linked a pull request that will close this issuegh-90763: Modernise xx template module initialisation #93078on May 22, 2022
6. erlend-aasland

   closed this as completedin #93078on Jun 10, 2022
7. erlend-aasland

   added a commit that references this issue on Jun 10, 2022

   gh-90763: Modernise xx template module initialisation (#93078)

   a87c9b5
8. miss-islington

   added a commit that references this issue on Jun 10, 2022

   pythongh-90763: Modernise xx template module initialisation (pythonGH…

   b8d6a08
9. erlend-aasland

   added a commit that references this issue on Jun 10, 2022

   [3.11] pythongh-90763: Modernise xx template module initialisation (p…

   931c9df
10. miss-islington

    added a commit that references this issue on Jun 10, 2022

    gh-90763: Modernise xx template module initialisation (GH-93078)

    8d8251a
11. erlend-aasland

    added a commit that references this issue on Jun 10, 2022

    [3.11] gh-90763: Modernise xx template module initialisation (GH-93078)…

    175ed6e
12. erlend-aasland commented on Jun 10, 2022

    

    erlend-aasland

    on Jun 10, 2022

    Contributor

    More actions

    Fixed by:

    • gh-90763: Modernise xx template module initialisation #93078
    • [3.10] gh-90763: Modernise xx template module initialisation (GH-93078) #93679
    • [3.11] gh-90763: Modernise xx template module initialisation (GH-93078) #93681

    Reacted by Petr Viktorin
13. serhiy-storchaka

    added a commit that references this issue on Jun 26, 2022

    Revert 30935 defer bpo45162 to 312 (#94285)

    1ffde3e

Issue actions