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.

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

BufferedReader.peek() crashes if closed #67984

Closed
vadmium opened this issue Mar 28, 2015 · 17 comments
Closed

BufferedReader.peek() crashes if closed #67984

vadmium opened this issue Mar 28, 2015 · 17 comments
Assignees
Labels
easy topic-IO type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@vadmium
Copy link
Member

vadmium commented Mar 28, 2015

BPO 23796
Nosy @vstinner, @berkerpeksag, @vadmium, @serhiy-storchaka
Files
  • bug.py
  • buffered_reader_closed_peek.patch
  • 23796_fix_with_tests.patch
  • 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/berkerpeksag'
    closed_at = <Date 2015-05-12.14:16:35.573>
    created_at = <Date 2015-03-28.00:29:49.990>
    labels = ['easy', 'expert-IO', 'type-crash']
    title = 'BufferedReader.peek() crashes if closed'
    updated_at = <Date 2015-05-12.14:43:54.990>
    user = 'https://github.com/vadmium'

    bugs.python.org fields:

    activity = <Date 2015-05-12.14:43:54.990>
    actor = 'jdherg'
    assignee = 'berker.peksag'
    closed = True
    closed_date = <Date 2015-05-12.14:16:35.573>
    closer = 'berker.peksag'
    components = ['IO']
    creation = <Date 2015-03-28.00:29:49.990>
    creator = 'martin.panter'
    dependencies = []
    files = ['38735', '38746', '38787']
    hgrepos = []
    issue_num = 23796
    keywords = ['patch', 'easy']
    message_count = 17.0
    messages = ['239445', '239450', '239456', '239482', '239592', '239645', '239647', '239831', '239840', '239855', '240306', '242076', '242742', '242970', '242971', '242972', '242975']
    nosy_count = 6.0
    nosy_names = ['vstinner', 'python-dev', 'berker.peksag', 'martin.panter', 'serhiy.storchaka', 'jdherg']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'crash'
    url = 'https://bugs.python.org/issue23796'
    versions = ['Python 3.4', 'Python 3.5']

    @vadmium
    Copy link
    Member Author

    vadmium commented Mar 28, 2015

    If the BufferedReader object has already been closed, calling peek() can cause a strange error message or a crash:

    $ python3 -bWall
    Python 3.4.2 (default, Oct  8 2014, 14:33:30) 
    [GCC 4.9.1 20140903 (prerelease)] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from io import *
    >>> b = BufferedReader(BytesIO())
    >>> b.close()
    >>> b.peek()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: PyMemoryView_FromBuffer(): info->buf must not be NULL
    >>> b = BufferedReader(BytesIO(b"12"))
    >>> b.read(1)
    b'1'
    >>> b.close()
    >>> b.peek()
    Segmentation fault (core dumped)
    [Exit 139]

    I’m not able to check with 3.5 at the moment, but looking at the code, I suspect this also applies to 3.5 and there needs to be a CHECK_CLOSED() call added somewhere around Modules/_io/bufferedio.c:884.

    @vadmium vadmium added topic-IO type-crash A hard crash of the interpreter, possibly with a core dump labels Mar 28, 2015
    @vadmium
    Copy link
    Member Author

    vadmium commented Mar 28, 2015

    Confirmed it does indeed affect the current 3.5 (default) branch.

    @serhiy-storchaka
    Copy link
    Member

    Do you want provide a patch Martin?

    @serhiy-storchaka serhiy-storchaka self-assigned this Mar 28, 2015
    @vadmium
    Copy link
    Member Author

    vadmium commented Mar 29, 2015

    Happy to when I get a chance. It should be easy to do, though it is not high on my priority list because I don’t think the scenario is very important in real world usage. I only encountered it when testing edge cases in another patch.

    @vstinner
    Copy link
    Member

    I confirm the bug on Python 3.5.0a3+.

    Is someone interested to fix buffered_peek() to add a check on the closed state?

    @jdherg
    Copy link
    Mannequin

    jdherg mannequin commented Mar 30, 2015

    If no-one else wants it, I'd love to tackle this as my first Python (and OSS in general) contribution. Attached is a one-line patch that just does a CHECK_CLOSED call in buffered_peek and is modeled on the pattern in the buffered_flush function just above. I'm under the impression that the final patch will need to include a test that confirms the patch worked, but I wanted to claim the bug and start the feedback process early :)

    @berkerpeksag
    Copy link
    Member

    Thanks for the patch, John.

    I'm under the impression that the final patch will need to include a test that confirms the patch worked,

    Correct. You could convert the reproducers in msg239445 to a test case.

    The patch looks good to me. I think you'll also need to add a similar check to buffered_read1():

    >>> from io import *
    >>> b = BufferedReader(BytesIO(b"12"))
    >>> b.read(1)
    b'1'
    >>> b.close()
    >>> b.peek()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: peek of closed file
    >>> b.read1(1)
    Segmentation fault (core dumped)

    @jdherg
    Copy link
    Mannequin

    jdherg mannequin commented Apr 1, 2015

    Thanks for the feedback, Berker!

    I've added a test case that closes a buffered reader and then attempts to both peek and read1 it. I tacked it onto the end of the BufferedReaderTest class in test_io, but let me know if there's a better place to put it.

    I've also added the check to read1 -- good catch. I opted to add it before the check that the argument to read1 is 0 -- my assumption is that a 0-length read on a closed BufferReader should fail, not return an empty bytestring.

    Thanks again for the feedback!

    @vstinner
    Copy link
    Member

    vstinner commented Apr 1, 2015

    John Hergenroeder added the comment:

    my assumption is that a 0-length read on a closed BufferReader should fail, not return an empty bytestring.

    I agree.

    @vadmium
    Copy link
    Member Author

    vadmium commented Apr 1, 2015

    New patch with tests looks good to me. The BufferedReaderTest class is a sensible place for the test.

    @jdherg
    Copy link
    Mannequin

    jdherg mannequin commented Apr 9, 2015

    Thanks!

    I submitted my contributor agreement form last week -- is there anything I can do to improve this patch while I wait for that to process?

    @jdherg
    Copy link
    Mannequin

    jdherg mannequin commented Apr 26, 2015

    It looks like my contributor form has gone through -- what should my next steps here be? Thanks!

    @berkerpeksag
    Copy link
    Member

    23796_fix_with_tests.patch LGTM. I'll apply it this weekend. Thanks for the patch, John.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented May 12, 2015

    New changeset 41e9d324f10d by Berker Peksag in branch 'default':
    Issue bpo-23796: peak and read1 methods of BufferedReader now raise ValueError
    https://hg.python.org/cpython/rev/41e9d324f10d

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented May 12, 2015

    New changeset 7d722c9049ff by Berker Peksag in branch '3.4':
    Issue bpo-23796: peak and read1 methods of BufferedReader now raise ValueError
    https://hg.python.org/cpython/rev/7d722c9049ff

    New changeset be7636fd6438 by Berker Peksag in branch 'default':
    Issue bpo-23796: Null merge.
    https://hg.python.org/cpython/rev/be7636fd6438

    @berkerpeksag
    Copy link
    Member

    Fixed. Thanks for the patch, John.

    @jdherg
    Copy link
    Mannequin

    jdherg mannequin commented May 12, 2015

    Wonderful! Thanks for your help, Berker!

    @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
    Labels
    easy topic-IO type-crash A hard crash of the interpreter, possibly with a core dump
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants