[Python-Dev] Prevalence of low-level memory abuse?

Tim Peters tim.peters at gmail.com
Sun Mar 26 07:20:09 CEST 2006


When Python's small-object memory allocator was introduced, some
horrid hacks came with it  to map PyMem_{Del, DEL} and PyMem_{Free,
FREE} to PyObject_{Free, FREE}.  This was to cater to less than a
handful of extension modules found at the time that obtained memory
for an object via PyObject_{New, NEW}, but released that memory via
the insanely mismatched PyMem_{Del, DEL} or PyMem_{Free, FREE}.

Since such combinations were found rarely in real life, have been
officially forbidden for years, the hacks are ugly & hard to
understand, and the hacks needlessly slow PyMem_{Del, DEL, Free,
FREE}, I'm trying to get rid of them now.  Alas, in a release(*)
build, Python's test suite segfaulted all over the place.

So far I found one smoking gun:  in _subprocess.c, sp_handle_new()
gets memory via PyObject_NEW(), but sp_handle_dealloc() releases that
memory via PyMem_DEL().  That's nuts, and after removing the
now-ancient hacks obtains the memory from obmalloc but releases it
directly to the system free().  That ends up corrupting both
obmalloc's _and_ the platform C library's ultra-low-level memory
bookkeeping bytes.

Since this wasn't common before, has it become common since then :-)? 
I checked Zope and ZODB a long time ago, and there were no
PyMem/PyObject mismatches there.  See any in your code?

(*) Nothing failed in a debug build, since all PyObject_ and PyMem_
calls go thru
    obmalloc in a debug build.  Note that, because of this, the buildbot test
    runs wouldn't have detected anything wrong.


More information about the Python-Dev mailing list