8000 Calling "functions" used to implement generators/comps easily cause crash · Issue #81137 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

Calling "functions" used to implement generators/comps easily cause crash #81137

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
mr-nfamous mannequin opened this issue May 18, 2019 · 5 comments · Fixed by #111823
Closed

Calling "functions" used to implement generators/comps easily cause crash #81137

mr-nfamous mannequin opened this issue May 18, 2019 · 5 comments · Fixed by #111823
Labels
3.13 bugs and security fixes type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@mr-nfamous
Copy link
Mannequin
mr-nfamous mannequin commented May 18, 2019 •
edited by bedevere-app bot
Loading
BPO 36956
Nosy @rhettinger, @mr-nfamous, @websurfer5, @iritkatriel

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 2019-05-18.13:53:21.143>
labels = ['3.10', '3.9', 'type-crash', '3.11']
title = 'Calling "functions" used to implement generators/comps easily cause crash'
updated_at = <Date 2021-09-19.21:54:42.882>
user = 'https://github.com/mr-nfamous'

bugs.python.org fields:

activity = <Date 2021-09-19.21:54:42.882>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2019-05-18.13:53:21.143>
creator = 'bup'
dependencies = []
files = []
hgrepos = []
issue_num = 36956
keywords = []
message_count = 5.0
messages = ['342797', '346807', '346808', '346809', '402171']
nosy_count = 4.0
nosy_names = ['rhettinger', 'bup', 'Jeffrey.Kintscher', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue36956'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']

Linked PRs
@mr-nfamous
Copy link
Mannequin Author
mr-nfamous mannequin commented May 18, 2019

As far as I know, generators, set comprehensions, list comprehensions, and dict comprehensions, (along with their asynchronous variants) are implemented by first calling the GET_(A)ITER opcode and then building and calling a function that acepts the resulting iterator as its sole argument.

Assigning the code object used to make that function (or using it in the types.FunctionType constructor) and then calling it with a non-iterator argument will obviously cause a crash since the FOR_ITER opcode rightly expects that it will never have to deal with non-iterators and calls tp_iternext without checking if it exists.

The 4-liner demonstrates the crash:

if 1:
  fn = lambda: None
  gi = (i for i in ())
  fn.__code__ = gi.gi_code
  [*fn("abc")]

@mr-nfamous mr-nfamous mannequin added 3.7 (EOL) end of life 3.8 (EOL) end of life type-crash A hard crash of the interpreter, possibly with a core dump labels May 18, 2019
@huntertur huntertur mannequin added the 3.9 only security fixes label Jun 16, 2019
@websurfer5
Copy link
Mannequin
websurfer5 mannequin commented Jun 28, 2019

What is the preferred behavior? Raise an exception of some kind?

@websurfer5
Copy link
Mannequin
websurfer5 mannequin commented Jun 28, 2019

Specifically, the crash occurs in Python/ceval.c function _PyEval_EvalFrameDefault() in the TARGET(FOR_ITER) case at line 3198 (master branch):

PyObject *next = (*iter->ob_type->tp_iternext)(iter);

It segfaults because tp_iternext is NULL.

@rhettinger
Copy link
Contributor

ISTM this report is close to that covered by the traditional stance that word code hacks aren't protected from crashes because trying to do can be complicated, can be expensive, and isn't always possible.

I'm not really sure where this falls on the grey scale with "normal, everyday python shouldn't crash" on one end and "with ctypes or code hacks, all bets are off" on the other end.

Offhand, the posted snippet seems closer to "messing with the internals" but perhaps small cheap check can be added when the __code__ variable is updated.

@iritkatriel
Copy link
Member

Reproduced on 3.11.

@iritkatriel iritkatriel added 3.10 only security fixes 3.11 only security fixes and removed 3.7 (EOL) end of life 3.8 (EOL) end of life labels Sep 19, 2021
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
@kumaraditya303 kumaraditya303 mentioned this issue May 11, 2022
Closed
@iritkatriel iritkatriel added 3.13 bugs and security fixes and removed 3.11 only security fixes 3.10 only security fixes 3.9 only security fixes labels Nov 7, 2023
iritkatriel added a commit to iritkatriel/cpython that referenced this issue Nov 7, 2023
@iritkatriel
pythongh-81137: deprecate assignment of code object to a function of …
c8b0f8d 
…a diferent type
@iritkatriel iritkatriel mentioned this issue Nov 7, 2023
Merged
iritkatriel added a commit that referenced this issue Nov 7, 2023
@iritkatriel
gh-81137: deprecate assignment of code object to a function of a mism…
2f9cb7e 
…atched type (#111823)
hugovk pushed a commit to hugovk/cpython that referenced this issue Nov 8, 2023
@iritkatriel @hugovk
pythongh-81137: deprecate assignment of code object to a function of …
143cf0f 
…a mismatched type (python#111823)
aisk pushed a commit to aisk/cpython that referenced this issue Feb 11, 2024
@iritkatriel @aisk
pythongh-81137: deprecate assignment of code object to a function of …
abeaf80 
…a mismatched type (python#111823)
Glyphack pushed a commit to Glyphack/cpython that referenced this issue Sep 2, 2024
@iritkatriel @Glyphack
pythongh-81137: deprecate assignment of code object to a function of …
4bc7879 
…a mismatched type (python#111823)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
3.13 bugs and security fixes type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

gh-81137: deprecate assignment of code object to a function of a mismatched type iritkatriel/cpython
2 participants
@iritkatriel @rhettinger
0