Right. The problem occurs at the end of VOID_getitem where it returns the result of PyBuffer_FromReadWriteMemory, which does not hold any references to the original array. Presumably we can also get segfaults by doing x = va[0].item(); del va; x[0] although I can't get it to happen here.

I would have to read up on it, but it looks like the "old-style" PyBufferObject being used here has a base field, since PyBuffer_FromObject says it keeps a ref to the base object. Maybe there is a way to finagle it so the base gets set. It might also be worth upgrading that code to use memoryviews.

Moving to memoryviews would be good. They are available in Python 2.7, so python version dependency is not a problem.

Yeah that would be good because it would unify the py2 and py3 code paths, which are totally separate right now.

Also, I was debugging this a little more, and did find a simpler (py2) example that segfaults:

>>> va = np.zeros(300000, 'V4')
>>> x = va[:1].item()
>>> del va
>>> x[0]
zsh: segmentation fault (core dumped)

The difference beween va[0].item() and va[:1].item() is that the former calls item on a void scalar, and it turns out that unstructured void scalars make a copy (not a view like structured void scalars), so x does not point to va's memory. The latter case with [:1] calls item on a size-1 array, which ends up being a view, and so can segfault.

Also, because the py3 code is totally different it does not have this problem. Although, I can get some pretty strange things to happen:

>>> va = np.zeros(300000, 'V4')
>>> va[0].item().base
array(array([0, 0, 0, 0], dtype=int8), 
      dtype='|V4')

not sure why it prints that way!

Oops this shouldn't be closed yet. I accidentally used the phrase "fixes" in the PR description of #10044.

This will be be fixed in the future by #8157