Skip to content
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

checks whether PyArg_ParseTuple returned a negative int #75426

Closed
orenmn mannequin opened this issue Aug 21, 2017 · 7 comments
Closed

checks whether PyArg_ParseTuple returned a negative int #75426

orenmn mannequin opened this issue Aug 21, 2017 · 7 comments
Assignees
@serhiy-storchaka
Labels
3.7 (EOL) end of life easy extension-modules C modules in the Modules dir topic-IO type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@orenmn
Copy link
Mannequin

orenmn mannequin commented Aug 21, 2017

BPO 31243
Nosy @benjaminp, @serhiy-storchaka, @orenmn
PRs
  • bpo-31243: fix PyArg_ParseTuple failure checks #3171
  • [3.6] bpo-31243: Fixed PyArg_ParseTuple failure checks. (GH-3171) #3233
  • [2.7] bpo-31243: Fixed PyArg_ParseTuple failure checks. (GH-3171) #3235
    		•

    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 = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2017-08-29.16:18:10.107>
created_at = <Date 2017-08-21.08:33:08.944>
labels = ['extension-modules', 'easy', '3.7', 'expert-IO', 'type-crash']
title = 'checks whether PyArg_ParseTuple returned a negative int'
updated_at = <Date 2017-08-29.16:18:10.106>
user = 'https://github.com/orenmn'

    bugs.python.org fields:

    activity = <Date 2017-08-29.16:18:10.106>
actor = 'serhiy.storchaka'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2017-08-29.16:18:10.107>
closer = 'serhiy.storchaka'
components = ['Extension Modules', 'IO']
creation = <Date 2017-08-21.08:33:08.944>
creator = 'Oren Milman'
dependencies = []
files = []
hgrepos = []
issue_num = 31243
keywords = ['easy (C)']
message_count = 7.0
messages = ['300613', '300616', '300618', '300977', '300982', '300993', '300994']
nosy_count = 4.0
nosy_names = ['benjamin.peterson', 'stutzbach', 'serhiy.storchaka', 'Oren Milman']
pr_nums = ['3171', '3233', '3235']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue31243'
versions = ['Python 2.7', 'Python 3.6', 'Python 3.7']
    @orenmn
    Copy link
    Mannequin Author

    orenmn mannequin commented Aug 21, 2017

    according to the docs (https://docs.python.org/3.7/c-api/arg.html?highlight=pyarg_parsetuple#c.PyArg_ParseTuple), PyArg_ParseTuple
    returns true for success or false for failure. I also looked at the
    implementation in Python/getargs.c, and it seems that indeed PyArg_ParseTuple
    can return only 0 or 1.

    however, in some places in the codebase, there are checks whether
    PyArg_ParseTuple returned a negative int.
    I found a bunch in Modules/_testcapimodule.c, and one in Modules/_io/textio.c
    in textiowrapper_read_chunk. (hopefully i haven't missed other places.)

    this code crashes because of the check in textiowrapper_read_chunk:
    import codecs
    import _io
    class MyDec():
    def getstate(self):
    return 420
    class MyDecWrapper():
    def __call__(self, blabla):
    return MyDec()
    quopri = codecs.lookup("quopri")
    quopri._is_text_encoding = True
    quopri.incrementaldecoder = MyDecWrapper()
    t = _io.TextIOWrapper(_io.BytesIO(b'aaaaaa'),
    newline='\n', encoding="quopri")
    t.read(42)

    I guess all of these checks should be changed to check whether PyArg_ParseTuple
    returned 0.

    also, before this specific call to PyArg_ParseTuple in textiowrapper_read_chunk,
    we should check whether 'state' is a tuple.
    Moreover, this call shouldn't produce a wrong error message, as explained in
    bpo-28261.

    @orenmn orenmn mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) 3.7 (EOL) end of life type-crash A hard crash of the interpreter, possibly with a core dump labels Aug 21, 2017
    @serhiy-storchaka
    Copy link
    Member

    Do you want to provide a PR Oren?

    @serhiy-storchaka serhiy-storchaka added extension-modules C modules in the Modules dir easy and removed interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Aug 21, 2017
    @serhiy-storchaka serhiy-storchaka self-assigned this Aug 21, 2017
    @orenmn
    Copy link
    Mannequin Author

    orenmn mannequin commented Aug 21, 2017

    yes, soon.
    (just wanted to hear your opinion before doing that.)

    @serhiy-storchaka
    Copy link
    Member

    New changeset ba7d736 by Serhiy Storchaka (Oren Milman) in branch 'master':
    bpo-31243: Fixed PyArg_ParseTuple failure checks. (bpo-3171)
    ba7d736

    @serhiy-storchaka
    Copy link
    Member

    New changeset c7750c2 by Serhiy Storchaka (Oren Milman) in branch '3.6':
    [3.6] bpo-31243: Fixed PyArg_ParseTuple failure checks. (GH-3171) (bpo-3233)
    c7750c2

    @serhiy-storchaka
    Copy link
    Member

    New changeset 20958e6 by Serhiy Storchaka (Oren Milman) in branch '2.7':
    [2.7] bpo-31243: Fixed PyArg_ParseTuple failure checks. (GH-3171) (bpo-3235)
    20958e6

    @serhiy-storchaka
    Copy link
    Member

    Thank you for your contribution Oren!

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @serhiy-storchaka serhiy-storchaka

    Labels
    3.7 (EOL) end of life easy extension-modules C modules in the Modules dir topic-IO type-crash A hard crash of the interpreter, possibly with a core dump
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    1 participant
    @serhiy-storchaka