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

Py_GetPath, Py_SetPath memory corruption due to mixed PyMem_New micex with PyMem_Raw_Free #75713

Closed
htgoebel mannequin opened this issue Sep 20, 2017 · 5 comments
Closed
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@htgoebel
Copy link
Mannequin

htgoebel mannequin commented Sep 20, 2017

BPO 31532
Nosy @vstinner, @benjaminp, @nurelin
PRs
  • bpo-31532: Fix memory corruption due to allocator mix #3679
  • [3.6] bpo-31532: Fix memory corruption due to allocator mix (GH-3679) #3681
  • 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 = <Date 2017-09-21.06:47:14.506>
    created_at = <Date 2017-09-20.14:38:42.817>
    labels = ['interpreter-core', 'type-crash']
    title = 'Py_GetPath, Py_SetPath memory corruption due to mixed PyMem_New micex with PyMem_Raw_Free'
    updated_at = <Date 2017-09-21.09:23:48.902>
    user = 'https://bugs.python.org/htgoebel'

    bugs.python.org fields:

    activity = <Date 2017-09-21.09:23:48.902>
    actor = 'nurelin'
    assignee = 'none'
    closed = True
    closed_date = <Date 2017-09-21.06:47:14.506>
    closer = 'benjamin.peterson'
    components = ['Interpreter Core']
    creation = <Date 2017-09-20.14:38:42.817>
    creator = 'htgoebel'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 31532
    keywords = ['patch']
    message_count = 5.0
    messages = ['302624', '302668', '302669', '302675', '302676']
    nosy_count = 4.0
    nosy_names = ['htgoebel', 'vstinner', 'benjamin.peterson', 'nurelin']
    pr_nums = ['3679', '3681']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'crash'
    url = 'https://bugs.python.org/issue31532'
    versions = ['Python 3.6']

    @htgoebel
    Copy link
    Mannequin Author

    htgoebel mannequin commented Sep 20, 2017

    When using

    Py_GetPath();
    Py_SetPath(pypath_w);

    near the beginning of a program, Py_SetPath crashes with memory corruption if run on a systems with glibc's MALLOC_CHECK enabled.

    The reason is: Py_GetPath and Py_SetPath use different memory interfaces.

    This error DOES NOT occur on Windows, since for win32 there is a separate implementation, which uses PyMem_RawMalloc (see https://github.com/python/cpython/blob/v3.6.0/PC/getpathp.c#L378).

    This error also DOES NOT occur in Python <= 3.5, since PYMEM_FUNCS have been the same as PYRAW_FUNCS (see https://github.com/python/cpython/blob/v3.5.0/Objects/obmalloc.c#L148). This was changed in v3.6.0: PYMEM_FUNCS now is PYOBJ_FUNCS, see https://github.com/python/cpython/blob/v3.6.0/Objects/obmalloc.c#L159.

    This error only occurs when running on a system with glibc's MALLOC_CHECK enabled, which seems to be the default st least on CentOS, Fedora and ArchLinux.

    Example code and relevant source see below.

    Example stack trace
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    *** glibc detected *** ./dist/jcollect3: double free or corruption (out): 0x00007fde271ab030 ***
    ======= Backtrace: =========
    /lib64/libc.so.6[0x37f0675e66]
    /lib64/libc.so.6[0x37f06789b3]
    /tmp/_MEIhKg3kx/libpython3.6m.so.1.0(Py_SetPath+0x15)[0x7fde2d20e825]
    ./dist/jcollect3[0x4043e2]
    ./dist/jcollect3[0x402db2]
    ./dist/jcollect3[0x402fb0]
    /lib64/libc.so.6(__libc_start_main+0xfd)[0x37f061ed5d]
    ./dist/jcollect3[0x401a9e]
    ======= Memory map: ========

    How to reproduce
    ~~~~~~~~~~~~~~~~~~~~~~~~~

    An example for this problem is the bootloader of PyInstaller (as of 2017-08-01).

    • Make sure you are running on a Linux distribution having glibc's MALLOC_CHECK enabled.

    • Set up a virtual environment (just too keep your system clean)

    pip install https://github.com/pyinstaller/pyinstaller/archive/develop@%7B2017-08-01%7D.zip
    echo 'print("Hello")' > test.py
    pyinstaller test.py
    dist/test/test # run the frozen script

    The relevant source of PyInstaller's bootloader is at <https://github.com/pyinstaller/pyinstaller/blob/develop@%7B2017-08-01%7D/bootloader/src/pyi_pythonlib.c#L466\>

    @htgoebel htgoebel mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump labels Sep 20, 2017
    @benjaminp
    Copy link
    Contributor

    New changeset 3d1e2ab by Benjamin Peterson (nurelin) in branch 'master':
    bpo-31532: Fix memory corruption due to allocator mix (bpo-3679)
    3d1e2ab

    @benjaminp
    Copy link
    Contributor

    New changeset 88d0663 by Benjamin Peterson (Miss Islington (bot)) in branch '3.6':
    [3.6] closes bpo-31532: Fix memory corruption due to allocator mix (GH-3679) (bpo-3681)
    88d0663

    @vstinner
    Copy link
    Member

    I'm curious. Would you mind to try to run your frozen application using PYTHONMALLOC=debug environment variable on a Python without the fix, to see if you get an error? I'm not sure that the debug hooks on memory allocators are set early enough to detect your specific bug.

    https://docs.python.org/dev/using/cmdline.html#envvar-PYTHONMALLOC

    @nurelin
    Copy link
    Mannequin

    nurelin mannequin commented Sep 21, 2017

    Tried your suggestion. Nothing is printed and program still crash.

    @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
    interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants