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

_json crash on scanner/encoder initialization error #51235

Closed
vstinner opened this issue Sep 24, 2009 · 18 comments
Closed

_json crash on scanner/encoder initialization error #51235

vstinner opened this issue Sep 24, 2009 · 18 comments
Assignees
Labels
type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@vstinner
Copy link
Member

BPO 6986
Nosy @etrepum, @pitrou, @vstinner, @serhiy-storchaka, @orenmn
PRs
  • bpo-6986: Add a comment to clarify a test of _json.make_encoder() #3789
  • Files
  • _json_encoder_init.patch
  • _json_scanner_init.patch
  • json-crash.patch
  • json-crash-3.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/etrepum'
    closed_at = <Date 2009-12-08.16:09:58.926>
    created_at = <Date 2009-09-24.11:21:05.754>
    labels = ['type-crash']
    title = '_json crash on scanner/encoder initialization error'
    updated_at = <Date 2018-03-26.15:04:44.469>
    user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2018-03-26.15:04:44.469>
    actor = 'serhiy.storchaka'
    assignee = 'bob.ippolito'
    closed = True
    closed_date = <Date 2009-12-08.16:09:58.926>
    closer = 'pitrou'
    components = []
    creation = <Date 2009-09-24.11:21:05.754>
    creator = 'vstinner'
    dependencies = []
    files = ['14964', '14965', '15190', '15292']
    hgrepos = []
    issue_num = 6986
    keywords = ['patch']
    message_count = 18.0
    messages = ['93068', '93069', '93077', '94396', '94397', '94398', '94399', '94429', '95052', '95054', '96125', '96131', '96134', '302513', '302522', '303129', '303139', '314457']
    nosy_count = 5.0
    nosy_names = ['bob.ippolito', 'pitrou', 'vstinner', 'serhiy.storchaka', 'Oren Milman']
    pr_nums = ['3789']
    priority = 'high'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'crash'
    url = 'https://bugs.python.org/issue6986'
    versions = ['Python 3.1', 'Python 2.7', 'Python 3.2']

    @vstinner
    Copy link
    Member Author

    scanner_init() and encoder_init() don't manage errors correctly.

    scanner_init() gets context.encoding argument without checking context
    type, nor GetAttrString() error. It should check for NULL result...
    which is done in the same function for other attributes (strict,
    object_hook, object_pairs_hook, parse_float, parse_int, parse_constant).

    Example to reproduce the crash:
    import _json
    _json.make_scanner(1)

    encoder_init() copies a refence (for each argument) without incrementing
    the reference counter. And then encoder_clear() decrements the
    reference, counter, which may crash Python.

    Example to reproduce the crash:
    import _json
    _json.make_encoder(
    (False, True),
    -826484143518891896,
    -56.0,
    "a",
    )
    # do anything creating/destroying new objects
    " abc ".strip()
    len(" xef ".strip())

    Attached patches for the crashes.

    @vstinner
    Copy link
    Member Author

    About _json_encoder_init.patch, an alternative patch is to write
    arguments references (addresses) in local variables, and only copy them
    on success. Something like:
      PyObject *arg;
      if (!PyTuple_ParseArgs(..., &arg)) return NULL;
      Py_INCREF(arg);
      self->arg = arg;

    I prefered to write a shorter patch.

    Tell me if you prefer the alternative fix, and if you would like unit tests.

    @pitrou
    Copy link
    Member

    pitrou commented Sep 24, 2009

    Unit tests are definitely desireable!
    I would also like the "alternate approach" fix, it would probably be
    cleaner.

    @vstinner
    Copy link
    Member Author

    pitrou> Unit tests are definitely desireable!

    done

    pitou> I would also like the "alternate approach" fix,
    pitou> it would probably be cleaner.

    done. See the new patch.

    @pitrou
    Copy link
    Member

    pitrou commented Oct 23, 2009

    There is actually a Lib/json/tests/ directory contain all JSON tests,
    you should add yours there.

    @vstinner
    Copy link
    Member Author

    pitrou> There is actually a Lib/json/tests/ directory contain all
    pitrou> JSON tests, you should add yours there.

    My patch creates the file Lib/json/tests/test__json.py. Do you mean
    that I should add the new tests to an existing file? Which one?

    @pitrou
    Copy link
    Member

    pitrou commented Oct 23, 2009

    Ah, my bad, I thought it created the file in Lib/test.
    The tests probably need to be skipped if _json can't be imported, though.
    (the _json accelerators are just an implementation detail)

    @pitrou
    Copy link
    Member

    pitrou commented Oct 24, 2009

    The tests could go in Lib/json/tests/test_speedups.py.

    @vstinner
    Copy link
    Member Author

    vstinner commented Nov 9, 2009

    New version of my patch:

    @vstinner
    Copy link
    Member Author

    vstinner commented Nov 9, 2009

    Oops, you forget json-crash-2.patch, the patch was completly wrong.
    Check the json-crash-3.patch.

    @vstinner
    Copy link
    Member Author

    vstinner commented Dec 8, 2009

    I wrote new patches to:

    • implement the "alternate method"
    • add unit tests
    • and finally to move the tests in the right file

    Is the patch now correct? Can you apply it? It doesn't still crash
    Python trunk and it generates a lot of noise in my fuzzer :-)

    @pitrou
    Copy link
    Member

    pitrou commented Dec 8, 2009

    The patch looks good to me.

    @pitrou pitrou added the type-crash A hard crash of the interpreter, possibly with a core dump label Dec 8, 2009
    @pitrou
    Copy link
    Member

    pitrou commented Dec 8, 2009

    This has been committed in r76708, r76710, r76711. Thank you!

    @pitrou pitrou closed this as completed Dec 8, 2009
    @serhiy-storchaka
    Copy link
    Member

    Could you please add a comment for test_make_encoder Victor? Invalid arguments are passed to c_make_encoder, but it raises a TypeError not because wrong types of argument, but because the number of arguments is insufficient. At first glance it looks as an error in the test. Only reading this issue give a hint that perhaps this is intentional. But there is no reference to this issue in the test.

    @vstinner
    Copy link
    Member Author

    Oh wow, this issue was fixed 8 years ago and it's now closed! Please open a write issue, or maybe even propose directly a PR? (If you do, I will review it.)

    @orenmn
    Copy link
    Mannequin

    orenmn mannequin commented Sep 27, 2017

    I would be happy to open such a PR, if you don't mind.

    @serhiy-storchaka
    Copy link
    Member

    It would be nice.

    @serhiy-storchaka
    Copy link
    Member

    New changeset 7c2d978 by Serhiy Storchaka (Oren Milman) in branch 'master':
    bpo-6986: Add a comment to clarify a test of _json.make_encoder(). (GH-3789)
    7c2d978

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

    No branches or pull requests

    3 participants