Py_XDECREF() module on fail in Py_mod_exec

[ov2k]

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

[ov2k]

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.