[SciPy-dev] PyArray_New problem

Robert Cimrman cimrman3 at ntc.zcu.cz
Fri Dec 2 10:41:12 CST 2005


Travis Oliphant wrote:
> Robert Cimrman wrote:
> 
> 
>>Travis Oliphant wrote:
>> 
>>
>>
>>>Robert Cimrman wrote:
>>>
>>>
>>>   
>>>
>>>
>>>>Could someone tell me what I am doing wrong? I would like to use a
>>>>function like the snippet below to create an array.
>>>>
>>>>PyArrayObject *helper_newCArrayObject_i32( int32 len, int32 *array
>>>>) { intp plen[1]; PyArrayObject *obj = 0;
>>>>
>>>>plen[0] = len; printf( "11111 %d\n", PyArray_INT32 ); /*   obj =
>>>>(PyArrayObject *) PyArray_SimpleNew( 1, plen, PyArray_INT32 ); */
>>>>
>>>>obj = (PyArrayObject *) PyArray_New( &PyArray_Type, 1, plen, 
>>>>PyArray_INT32, NULL, NULL, 0, CARRAY_FLAGS, NULL ); ....
>>>>
>>>>
>>>>     
>>>>
>>>
>>>First of all, don't pass in CARRAY_FLAGS when the data argument to 
>>>PyArray_New is NULL.  A non-zero flags entry tells the subroutine to
>>>create a FORTRAN strides array if no data is passed.
>>>
>>>Remember:  DATA flags are only to describe already available memory.
>>>If you create the memory  in PyArray_New, then the only thing to
>>>decide is FORTRAN or C- contiguous.   So, in this routine, you are
>>>creating a Fortran array.  Perhaps this is causing problems later.
>>>   
>>>
>>
>>I understand this - I first tried with  PyArray_SimpleNew(), then with
>>PyArray_New() with zero flags and finally tried to play with the flags 
>>to no avail.
>>
>> 
>>
>>
>>>Also, you are not showing us the rest of the code.  Your traceback is
>>>showing PyArray_ValidType being called which is not shown anywere...
>>>   
>>>
>>
>>Well, that is what is really strange - I have just traced the execution 
>>with gdb and what is hapenning is, that, instead of PyArray_New(), 
>>PyArray_ValidType() gets called, and so, obviously, it sees 
>>&PyArray_Type as its 'int type', which is -1212938592 in my case -> 
>>segfault. I am clueless why this happens.
>>
>> 
>>
> 
> Have you completely re-compiled since upgrading your scipy_core 
> installation.  If you haven't, you are using the wrong function-pointer 
> table (the C-API is actually a function-pointer table).  If there are 
> changes to the C-API and you don't recompile, this kind of thing happens.

I use the script below for updates. Now I have manually removed 'build' 
directories in both core and scipy, and removed also
/home/share/software/usr/lib/python2.4/site-packages/scipy dir where the 
installed package resides. Oh wait - I have an old installation in 
python2.3 direcotry... Did not help... But! Well, thanks! Because of my 
nonstadard installation dir, I have manually copied the include files 
into a location that is on my include path... and forgot to update them.
Removing the dir and making a symbolic link solved the problem!

So sorry for the hassle, but it might have been illuminating for others :)

thank you!
r.

---
rm -r core/build
svn co http://svn.scipy.org/svn/scipy_core/trunk core
#svn co http://svn.scipy.org/svn/scipy_core/branches/newcore/
cd core
python setup.py install --root=/home/share/software
cd ..

rm -r scipy/build
svn co http://svn.scipy.org/svn/scipy/trunk scipy
#svn co http://svn.scipy.org/svn/scipy/branches/newscipy/
cd scipy
python setup.py install --root=/home/share/software
cd ..




More information about the Scipy-dev mailing list