New submission from STINNER Victor: I modified PyMem_Malloc() to use the pymalloc allocator in the issue #26249. This change helped to find a memory leak in test_format that I introduced in Python 3.6: http://bugs.python.org/issue26249#msg264174
This memory leak gave me an idea: PyMem_RawMalloc() should also update sys.getallocatedblocks() (number of currently allocated blocks). It would help to find memory leaks using "python -m test -R 3:3" in extension modules using PyMem_RawMalloc() (and not PyMem_Malloc() or PyObject_Malloc()). Attached patch uses an atomic variable _Py_AllocatedBlocks, but only in debug mode. I chose to only change the variable in debug mode to: * not impact performances * I don't know if atomic variables are well supported (especially the "var++" operation) * I don't know yet the impact of this change (how sys.getallocatedblocks() is used). (The patch would be simpler if the release mode would also be impacted.) The patch changes _PyObject_Alloc() and _PyObject_Free() in debug mode to only account allocations directly made by pymalloc, to let PyMem_RawMalloc() and PyMem_RawFree() update the _Py_AllocatedBlocks variable. In release mode, _PyObject_Alloc() and _PyObject_Free() are responsible to update the _Py_AllocatedBlocks variable for allocations delegated to PyMem_RawMalloc() and PyMem_RawFree(). ---------- files: pymem_rawmalloc_blocks.patch keywords: patch messages: 264250 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: PyMem_RawMalloc(): update also sys.getallocatedblocks() in debug mode type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42599/pymem_rawmalloc_blocks.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26850> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
