[SciPy-dev] Check reading the nested fields of a nested array

[Stefan van der Walt]

Hi,

My message below wasn't very helpful, mainly due to my inability to
use valgrind properly.  With some help from Albert, I think I narrowed
down the problem.

The following writes at an invalid memory location:


from numpy import *

ulen = 1
ucs_value = u'\U0010FFFF'

ua = array([[[ucs_value*ulen]*2]*3]*4,
           dtype='U%s' % ulen)
ua2 = ua.newbyteorder()


which generates this warning under Valgrind:

==22943== Invalid write of size 1
==22943==    at 0x4902AAF: UNICODE_copyswap (arraytypes.inc:10223)
==22943==    by 0x48FB166: PyArray_Scalar (arrayobject.c:1093)
==22943==    by 0x49431B7: array_subscript_nice (arrayobject.c:2446)
==22943==    by 0x80B3DB4: PyEval_EvalFrame (in /usr/bin/python2.4)
==22943==    by 0x80B6FDA: PyEval_EvalFrame (in /usr/bin/python2.4)
==22943==    by 0x80B76BE: PyEval_EvalCodeEx (in /usr/bin/python2.4)
==22943==    by 0x80FBF2C: (within /usr/bin/python2.4)
==22943==  Address 0x454F771 is 1 bytes after a block of size 8 alloc'd
==22943==    at 0x401B422: malloc (vg_replace_malloc.c:149)
==22943==    by 0x48FB11D: PyArray_Scalar (arrayobject.c:1023)
==22943==    by 0x49431B7: array_subscript_nice (arrayobject.c:2446)
==22943==    by 0x80B3DB4: PyEval_EvalFrame (in /usr/bin/python2.4)
==22943==    by 0x80B6FDA: PyEval_EvalFrame (in /usr/bin/python2.4)
==22943==    by 0x80B76BE: PyEval_EvalCodeEx (in /usr/bin/python2.4)
==22943==    by 0x80FBF2C: (within /usr/bin/python2.4)


I filed a ticket at
http://projects.scipy.org/scipy/numpy/ticket/79

Regards
Stéfan

On Tue, Apr 25, 2006 at 01:49:14PM +0200, Stefan van der Walt wrote:
> I've installed numpy from svn on two machines this morning, and on
> both installations I see the glibc segfault.
> 
> Nils' python snippet does not reproduce the problem, however.
> 
> I attach the last output of 
> 
>  valgrind -v --error-limit=no --leak-check=full python -c 'import numpy; numpy.test()'
> 
> If I do
> 
> export GLIBCXX_FORCE_NEW=1
> 
> the tests crash simply with "Segmentation fault" instead of with
> 
> *** glibc detected *** free(): invalid next size (fast): 0x0830e828 ***
> Aborted
> 
> I'll try to find a minimal snippet that reproduces the problem.
> 
> Regards
> Stéfan