Tim Peters ddea208be9 Give Python a debug-mode pymalloc, much as sketched on Python-Dev. ... When WITH_PYMALLOC is defined, define PYMALLOC_DEBUG to enable the debug allocator. This can be done independent of build type (release or debug). A debug build automatically defines PYMALLOC_DEBUG when pymalloc is enabled. It's a detected error to define PYMALLOC_DEBUG when pymalloc isn't enabled. Two debugging entry points defined only under PYMALLOC_DEBUG: + _PyMalloc_DebugCheckAddress(const void *p) can be used (e.g., from gdb) to sanity-check a memory block obtained from pymalloc. It sprays info to stderr (see next) and dies via Py_FatalError if the block is detectably damaged. + _PyMalloc_DebugDumpAddress(const void *p) can be used to spray info about a debug memory block to stderr. A tiny start at implementing "API family" checks isn't good for anything yet. _PyMalloc_DebugRealloc() has been optimized to do little when the new size is <= old size. However, if the new size is larger, it really can't call the underlying realloc() routine without either violating its contract, or knowing something non-trivial about how the underlying realloc() works. A memcpy is always done in this case. This was a disaster for (and only) one of the std tests: test_bufio creates single text file lines up to a million characters long. On Windows, fileobject.c's get_line() uses the horridly funky getline_via_fgets(), which keeps growing and growing a string object hoping to find a newline. It grew the string object 1000 bytes each time, so for a million-character string it took approximately forever (I gave up after a few minutes). So, also: fileobject.c, getline_via_fgets(): When a single line is outrageously long, grow the string object at a mildly exponential rate, instead of just 1000 bytes at a time. That's enough so that a debug-build test_bufio finishes in about 5 seconds on my Win98SE box. I'm curious to try this on Win2K, because it has very different memory behavior than Win9X, and test_bufio always took a factor of 10 longer to complete on Win2K. It *could* be that the endless reallocs were simply killing it on Win2K even in the release build.		2002-03-23 10:03:50 +00:00
..
abstract.h
bitset.h
bufferobject.h
cellobject.h
ceval.h
classobject.h
cobject.h
codecs.h
compile.h
complexobject.h
cStringIO.h
descrobject.h
dictobject.h
errcode.h
eval.h
fileobject.h
floatobject.h
frameobject.h
funcobject.h
graminit.h
grammar.h
import.h
intobject.h
intrcheck.h
iterobject.h
listobject.h
longintrepr.h
longobject.h
marshal.h
metagrammar.h
methodobject.h
modsupport.h
moduleobject.h
node.h
object.h
objimpl.h
opcode.h
osdefs.h
parsetok.h
patchlevel.h
pgenheaders.h
py_curses.h
pydebug.h
pyerrors.h
pyfpe.h
pygetopt.h
pymactoolbox.h
pymem.h
pyport.h
pystate.h
Python.h
pythonrun.h
pythread.h
rangeobject.h
sliceobject.h
stringobject.h
structmember.h
structseq.h
symtable.h
sysmodule.h
token.h
traceback.h
tupleobject.h
ucnhash.h
unicodeobject.h
weakrefobject.h