On Sun, 2006-03-26 at 18:58 -0500, Tim Peters wrote:
> [Edward Loper]
> > Could the debug build's macros for PyMem/PyObject_new/free be modified
> > to check for mismatches? Or would storing information about which
> > method was used to allocate each pointer be too expensive? Perhaps a
> > speci
Tim Peters wrote:
> If extension modules in real life prove as sloppy as Python's
> front end, we'll have to revert the objimpl.h + pymem.h part of this
> patch. Note that no problems will show up in a debug build (all
> calls still go thru obmalloc then). Problems will show up on
[Edward Loper]
> Could the debug build's macros for PyMem/PyObject_new/free be modified
> to check for mismatches? Or would storing information about which
> method was used to allocate each pointer be too expensive? Perhaps a
> special build could be used to check for mismatches?
It's partly po
[Tim, on PyMem vs PyObject memory mismatches]
> ... Alas, in a release(*) build, Python's test suite segfaulted all over the
> place.
>
> So far I found one smoking gun: in _subprocess.c, ...
And Python's front end was chock full o' these, sometimes even getting
memory via PyMem and releasing it
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,
