[SciPy-dev] a.resize() segfaults

[Ed Schofield]

I've found another segfault:

>>> a = arange(10)
>>> a
array([[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0]])
>>> a.resize(1,11)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208457536 (LWP 19305)]
0xb7d713e6 in array_resize (self=0x83a4230, args=0xb62363ac)
    at arraymethods.c:601
601             Py_DECREF(ret);
(gdb) bt
#0  0xb7d713e6 in array_resize (self=0x83a4230, args=0xb62363ec)
    at arraymethods.c:601
#1  0x08108e5b in PyCFunction_Call (func=0xb646ee8c, arg=0xb62363ec, kw=0x0)
    at Objects/methodobject.c:73

I have more 'luck' reproducing this after displaying the array, as here:

>>> a = arange(10)
>>> a.resize((1,11))
>>> a.resize((5,6))
>>> a.resize((1,11))
>>> a
array([[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0]])
>>> a.resize((5,15))
Segmentation fault

I first thought displaying the array increases the chance that the stray
pointer lands in a different memory page.  But I've now realised that
it's probably the result of 'a' being cached by the interpreter as the
'_' variable, so the warning in the docstring that

"Array must own its own memory and not be referenced by other arrays"

doesn't hold.

I know the bomb came with a warning, but I'd still prefer an exception
to a segfault when I ignore it and light a match anyway.  Is it feasible
for the resize() function to test these conditions itself?


-- Ed