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 vstinner
Date 2016-03-14.22:52:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1457995973.59.0.0490877458577.issue26563@psf.upfronthosting.co.za>
In-reply-to
Content
With the issue #26558, debug hooks of PyObject_Malloc() now checks that the GIL is hold.

I left PyMem_Malloc() unchanged, because I am not 100% sure that it's ok yet to implement the same check in PyMem_Malloc(). So I opened this issue.

Python 3 doc explicitly asks that the GIL is hold to call PyMem_Malloc():
https://docs.python.org/dev/c-api/memory.html#memory-interface

Python 2 doc doesn't say anything about the GIL:
https://docs.python.org/2/c-api/memory.html#memory-interface

Usually, functions prefixed by "Py" require the GIL to be hold.

In practice, currently PyMem_Malloc() is implemented with malloc() which is thread-safe.

In the issue #26249, I tested numpy, lxml, Pillow and cryptography with all debug hooks enabled, including GIL checks in PyMem_Malloc() and PyObject_Malloc(). I only found one bug in numpy: https://github.com/numpy/numpy/pull/7404

Attached patch changes debug hooks on PyMem_Malloc() to ensure that the GIL is hold.
History
Date User Action Args
2016-03-14 22:52:53vstinnersetrecipients: + vstinner
2016-03-14 22:52:53vstinnersetmessageid: <1457995973.59.0.0490877458577.issue26563@psf.upfronthosting.co.za>
2016-03-14 22:52:53vstinnerlinkissue26563 messages
2016-03-14 22:52:53vstinnercreate