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

Use Python memory allocators in external libraries like zlib or OpenSSL #62427

Closed
vstinner opened this issue Jun 15, 2013 · 9 comments
Closed
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@vstinner
Copy link
Member

BPO 18227
Nosy @vstinner, @tiran
Files
  • set_custom_alloc.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 = None
    closed_at = <Date 2013-12-16.23:12:27.281>
    created_at = <Date 2013-06-15.23:27:49.559>
    labels = ['interpreter-core']
    title = 'Use Python memory allocators in external libraries like zlib or OpenSSL'
    updated_at = <Date 2013-12-16.23:12:27.268>
    user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2013-12-16.23:12:27.268>
    actor = 'vstinner'
    assignee = 'none'
    closed = True
    closed_date = <Date 2013-12-16.23:12:27.281>
    closer = 'vstinner'
    components = ['Interpreter Core']
    creation = <Date 2013-06-15.23:27:49.559>
    creator = 'vstinner'
    dependencies = []
    files = ['30673']
    hgrepos = []
    issue_num = 18227
    keywords = ['patch']
    message_count = 9.0
    messages = ['191248', '191249', '191250', '191610', '191676', '192568', '192571', '192573', '206388']
    nosy_count = 4.0
    nosy_names = ['vstinner', 'christian.heimes', 'python-dev', 'aliles']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = None
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue18227'
    versions = ['Python 3.4']

    @vstinner
    Copy link
    Member Author

    With the PEP-445 and the issue bpo-3329, Python will get an API to setup custom memory allocators. To be able to configure how memory is handled in external libraries, some libraries allow to setup a custom allocator too. New functions PyMem_RawMalloc(), PyMem_GetRawAllocators() PyMem_SetRawAllocators() can be used for that.

    The safest option is to only reuse custom allocators if a library allows to setup them for a specfic function call or a specific object, and not replace the memory allocators globally. For example, the lzma library allows to set memory allocators only for one compressor object: LzmaEnc_Create(&SzAllocForLzma);

    We might change the global allocators of a library if Python is not embedded, but Python *is* the application (the standard "python" program).

    I don't know yet if it is safe to reuse custom memory allocators.

    Windows has for example a special behaviour: each DLL (dynamic library) has its own heap, memory allocator in a DLL cannot be released from another DLL. Would this issue introduce such bug?

    @vstinner vstinner added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Jun 15, 2013
    @vstinner
    Copy link
    Member Author

    See also the issue bpo-18203: "Replace calls to malloc() with PyMem_Malloc() or PyMem_RawMalloc()".

    @vstinner
    Copy link
    Member Author

    Uncomplete(?) list of external libraries used by Python:

    @vstinner
    Copy link
    Member Author

    It looks like CRYPTO_set_mem_functions() of OpenSSL 1.0.1e-4.fc18 does not work: CRYPTO_set_mem_functions() calls indirectly CRYPTO_malloc() which sets "allow_customize = 0;" and so CRYPTO_set_mem_functions() does nothing (just return 0, instead of 1).

    Gdb trace with a modified _ssl module:

    #0 0x0000003803463100 in CRYPTO_malloc () from /lib64/libcrypto.so.10
    #1 0x0000003803542fae in FIPS_drbg_new () from /lib64/libcrypto.so.10
    #2 0x00000038035448e1 in FIPS_drbg_health_check () from /lib64/libcrypto.so.10
    #3 0x0000003803542e88 in FIPS_drbg_init () from /lib64/libcrypto.so.10
    #4 0x00000038034cf9d1 in RAND_init_fips () from /lib64/libcrypto.so.10
    #5 0x0000003803465764 in OPENSSL_init_library () from /lib64/libcrypto.so.10
    #6 0x0000003803462c61 in CRYPTO_set_mem_functions () from /lib64/libcrypto.so.10
    #7 0x00007ffff135bc6c in PyInit__ssl () at /home/haypo/prog/python/default/Modules/_ssl.c:3180

    See the code:
    http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/mem.c;h=f7984fa958eb1edd6c61f6667f3f2b29753be662;hb=HEAD#l124

    @vstinner
    Copy link
    Member Author

    Here is an initial attempt: set a custom allocator for bz2, lzma and zlib modules. The allocator is only replaced for an instance of a compressor or decompress, the change does not affect the library globally.

    PyMem_RawMalloc() is used instead of PyMem_Malloc() because the GIL is always released.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jul 7, 2013

    New changeset a876d9d2e4fc by Victor Stinner in branch 'default':
    Issue bpo-18227: Use PyMem_RawAlloc() in bz2, lzma and zlib modules
    http://hg.python.org/cpython/rev/a876d9d2e4fc

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jul 7, 2013

    New changeset 12f26c356611 by Victor Stinner in branch 'default':
    Issue bpo-18227: "Free" function of bz2, lzma and zlib modules has no return value (void)
    http://hg.python.org/cpython/rev/12f26c356611

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jul 7, 2013

    New changeset 7f17c67b5bf6 by Christian Heimes in branch 'default':
    Issue bpo-18227: pyexpat now uses a static XML_Memory_Handling_Suite. cElementTree uses the same approach since at least Python 2.6
    http://hg.python.org/cpython/rev/7f17c67b5bf6

    @vstinner
    Copy link
    Member Author

    I modified modules when it was possible and easy to do. More modules should be modified, but it's more tricky. If you are interested, please open new issues.

    @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)
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant