This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients serhiy.storchaka, vstinner
Date 2016-04-26.11:35:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1461670523.49.0.555580906198.issue26850@psf.upfronthosting.co.za>
In-reply-to
Content
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().
History
Date User Action Args
2016-04-26 11:35:24vstinnersetrecipients: + vstinner, serhiy.storchaka
2016-04-26 11:35:23vstinnersetmessageid: <1461670523.49.0.555580906198.issue26850@psf.upfronthosting.co.za>
2016-04-26 11:35:23vstinnerlinkissue26850 messages
2016-04-26 11:35:23vstinnercreate