[SciPy-dev] PyArray_New problem
Robert Cimrman
cimrman3 at ntc.zcu.cz
Fri Dec 2 11:41:12 EST 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