Commit Graph

21 Commits

Author SHA1 Message Date
Gregory P. Smith 0470bab697 Issue #2620: Overflow checking when allocating or reallocating memory
was not always being done properly in some python types and extension
modules.  PyMem_MALLOC, PyMem_REALLOC, PyMem_NEW and PyMem_RESIZE have
all been updated to perform better checks and places in the code that
would previously leak memory on the error path when such an allocation
failed have been fixed.
2008-07-22 04:46:32 +00:00
Gregory P. Smith 9d53457e59 Merge in release25-maint r60793:
Added checks for integer overflows, contributed by Google. Some are
 only available if asserts are left in the code, in cases where they
 can't be triggered from Python code.
2008-06-11 07:41:16 +00:00
Neal Norwitz d83eb316dc Stop using PyMem_FREE while the GIL is not held. For details see:
http://mail.python.org/pipermail/python-dev/2007-May/072896.html
2007-05-02 04:47:55 +00:00
Tim Peters c9d78aa470 Years in the making.
objimpl.h, pymem.h:  Stop mapping PyMem_{Del, DEL} and PyMem_{Free, FREE}
to PyObject_{Free, FREE} in a release build.  They're aliases for the
system free() now.

_subprocess.c/sp_handle_dealloc():  Since the memory was originally
obtained via PyObject_NEW, it must be released via PyObject_FREE (or
_DEL).

pythonrun.c, tokenizer.c, parsermodule.c:  I lost count of the number of
PyObject vs PyMem mismatches in these -- it's like the specific
function called at each site was picked at random, sometimes even with
memory obtained via PyMem getting released via PyObject.  Changed most
to use PyObject uniformly, since the blobs allocated are predictably
small in most cases, and obmalloc is generally faster than system
mallocs then.

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 only in a release build, most
likely segfaults.
2006-03-26 23:27:58 +00:00
Martin v. Löwis 39f59b089d Remove MALLOC_ZERO_RETURNS_NULL. 2002-11-23 09:13:40 +00:00
Mark Hammond 91a681debf Excise DL_EXPORT from Include.
Thanks to Skip Montanaro and Kalle Svensson for the patches.
2002-08-12 07:21:58 +00:00
Tim Peters 8b078f95e0 Moving pymalloc along.
As threatened, PyMem_{Free, FREE} also invoke the object deallocator now
when pymalloc is enabled (well, it does when pymalloc isn't enabled too,
but in that case "the object deallocator" is plain free()).

This is maximally backward-compatible, but it leaves a bitter aftertaste.

Also massive reworking of comments.
2002-04-28 04:11:46 +00:00
Tim Peters 51e7f5caba Moving pymalloc along.
+ Redirect PyMem_{Del, DEL} to the object allocator's free() when
  pymalloc is enabled.  Needed so old extensions can continue to
  mix PyObject_New with PyMem_DEL.

+ This implies that pgen needs to be able to see the PyObject_XYZ
  declarations too.  pgenheaders.h now includes Python.h.  An
  implication is that I expect obmalloc.o needs to get linked into
  pgen on non-Windows boxes.

+ When PYMALLOC_DEBUG is defined, *all* Py memory API functions
  now funnel through the debug allocator wrapper around pymalloc.
  This is the default in a debug build.

+ That caused compile.c to fail:  it indirectly mixed PyMem_Malloc
  with raw platform free() in one place.  This is verbotten.
2002-04-22 02:33:27 +00:00
Tim Peters af3e8de580 First stab at rationalizing the PyMem_ API. Mixing PyObject_xyz with
PyMem_{Del, DEL} doesn't work yet (compilation problems).

pyport.h:  _PyMem_EXTRA is gone.

pmem.h:  Repaired comments.  PyMem_{Malloc, MALLOC} and
PyMem_{Realloc, REALLOC} now make the same x-platform guarantees when
asking for 0 bytes, and when passing a NULL pointer to the latter.

object.c:  PyMem_{Malloc, Realloc} just call their macro versions
now, since the latter take care of the x-platform 0 and NULL stuff
by themselves now.

pypcre.c, grow_stack():  So sue me.  On two lines, this called
PyMem_RESIZE to grow a "const" area.  It's not legit to realloc a
const area, so the compiler warned given the new expansion of
PyMem_RESIZE.  It would have gotten the same warning before if it
had used PyMem_Resize() instead; the older macro version, but not the
function version, silently cast away the constness.  IMO that was a wrong
thing to do, and the docs say the macro versions of PyMem_xyz are
deprecated anyway.  If somebody else is resizing const areas with the
macro spelling, they'll get a warning when they recompile now too.
2002-04-12 07:22:56 +00:00
Neil Schemenauer 20d0a1a071 Remove PyMalloc_* symbols. PyObject_Malloc now uses pymalloc if
it's enabled.
2002-04-12 02:39:18 +00:00
Tim Peters 7ccfadf3a8 New PYMALLOC_DEBUG function void _PyMalloc_DebugDumpStats(void).
This displays stats about the # of arenas, pools, blocks and bytes, to
stderr, both used and reserved but unused.

CAUTION:  Because PYMALLOC_DEBUG is on, the debug malloc routine adds
16 bytes to each request.  This makes each block appear two size classes
higher than it would be if PYMALLOC_DEBUG weren't on.

So far, playing with this confirms the obvious:  there's a lot of activity
in the "small dict" size class, but nothing in the core makes any use of
the 8-byte or 16-byte classes.
2002-04-01 06:04:21 +00:00
Tim Peters d1139e043c PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere
fast, and just cluttered the code.  Get rid of it for now.  If a compelling
case can be made for it, easy to restore it later.
2002-03-28 07:32:11 +00:00
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
Tim Peters fbb556df15 Arrange to export the _PyMalloc_{Malloc, Realloc, Free} entry points. On
Windows some modules are considered (by me, and I don't care what anyone
else thinks about this <wink>) to be part of "the core" despite that they
happen to be compiled into separate DLLs (the "to DLL or not to DLL?"
question on Windows is nearly arbitrary).  Making the pymalloc entry
points available to them allows the Windows build to complete without
incident when WITH_PYMALLOC is #define'd.

Note that this isn't unprecedented.  Other "private API" functions we
export include _PySequence_IterSearch, _PyEval_SliceIndex, _PyCodec_Lookup,
_Py_ZeroStruct, _Py_TrueStruct, _PyLong_New and _PyModule_Clear.
2002-03-20 04:02:31 +00:00
Neil Schemenauer 25f3dc21b5 Drop the PyCore_* memory API. 2002-03-18 21:06:21 +00:00
Neil Schemenauer 11f5be8d88 Simpilify PyCore_* macros by assuming the function prototypes for
malloc() and free() don't change.
2002-03-18 18:13:41 +00:00
Tim Peters a5d78cc208 Whether platform malloc(0) returns NULL has nothing to do with whether
platform realloc(p, 0) returns NULL, so MALLOC_ZERO_RETURNS_NULL can
be correctly undefined yet realloc(p, 0) can return NULL anyway.

Prevent realloc(p, 0) doing free(p) and returning NULL via a different
hack.  Would probably be better to get rid of MALLOC_ZERO_RETURNS_NULL
entirely.

Bugfix candidate.
2002-03-02 08:43:19 +00:00
Tim Peters 76f373d081 Repair more now-obsolete references to config.h. 2001-07-26 21:34:59 +00:00
Guido van Rossum 8586991099 REMOVED all CWI, CNRI and BeOpen copyright markings.
This should match the situation in the 1.6b1 tree.
2000-09-01 23:29:29 +00:00
Vladimir Marangozov dcb45c34f5 Fix a typo in the PyMem_Resize macro, found by Andrew Kuchling 2000-08-13 11:59:08 +00:00
Peter Schneider-Kamp 25f68944c2 patch from Vladimir (move Py_Mem* interface to Include/pymem.h) 2000-07-31 22:19:30 +00:00