[Python-Dev] pdb segfaults in 2.5 trunk?

[Tim Peters]

[Delaney, Timothy (Tim)]
> Definitely seems to me that it would be worthwhile in debug mode adding
> a field specifying which memory allocator was used, and checking for
> mismatches in the deallocators.
>
> I know this has been suggested before, but with number of mismatches
> being found now it seems like it should be put into place. I'm sure it
> will cause buildbot to go red ... ;)
>
> I might see if I can work up a patch over the easter long weekend if no
> one beats me to it. What files should I be looking at (it would be my
> first C-level python patch)?

A couple weeks back Adam DePrince said he was going to do this,
although I haven't heard more about it.  See that thread for hints
about a workable approach:

http://mail.python.org/pipermail/python-dev/2006-March/062848.html

The bulk of the work would be in obmalloc.c.  More-or-less
excruciating #if'ery would also be needed in objimpl.h and pymem.h, to
remap the build-type-independent API names to appropriate
build-type-dependent concrete calls.  For example, the current
debug-build:

#define PyMem_MALLOC		PyObject_MALLOC

would have to get messier, so that a call to PyMem_MALLOC could be
distinguished from a call to PyObject_MALLOC to begin with.  They'd
probably both have to change, to call a common doesn't-yet-exist entry
point with a "which flavor of malloc is this?" flag argument.