[Python-Dev] _PyString_Resize (original) (raw)

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 .

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 doesn't break it again.