[Python-Dev] pdb segfaults in 2.5 trunk? (original) (raw)

Tim Peters tim.peters at gmail.com
Wed Apr 12 00:29:32 CEST 2006

[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.

More information about the Python-Dev mailing list