[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4