[Python-Dev] _PyString_Resize

Tim Peters tim.one@comcast.net
Sat, 27 Apr 2002 21:42:59 -0400


[Neil Hodgson]
> Do you have a good way to test out-of-memory handling with either
> reproducible or random failures?

Not really.  If I have time, when I fix something like that I'll get into a
debugger and force a NULL result from a memory allocator, to exercise the
new code.  That doesn't prevent bit-rot later, though.

> Some of the time I'm conscientious about this and at other times not.
> Without being able to simulate memory exhaustion the handling code
> never gets tested and so will be full of bugs.

Sure.  Luckily, they're on paths that should never get executed anyway
<wink>.

Cute:  for the heck of it, I just tried adding

	if ((serialno & 0x3ff) == 0) return NULL;

near the start of pymalloc's debug-mode malloc and realloc routines.  That
instantly caused a segfault, pointing at:

PyObject *
_PyObject_GC_New(PyTypeObject *tp)
{
	PyObject *op = _PyObject_GC_Malloc(_PyObject_SIZE(tp));
	return PyObject_INIT(op, tp);
}

The problem is that PyObject_INIT *assumes* its first argument is non-NULL,
and code that can't guarantee that shouldn't even be using it.

So I'll fix that, but I've got no way to add a test to ensure that someone
cleverer than I <wink> doesn't break it again.