mirror of
https://github.com/python/cpython.git
synced 2025-11-01 18:51:43 +00:00
ddea208be9
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. |
||
|---|---|---|
| .. | ||
| 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 | ||