[SciPy-dev] segfault during scipy.test(1) - Solaris 8, Sun compilers
Pearu Peterson
pearu at cens.ioc.ee
Wed Oct 9 14:54:55 CDT 2002
On Wed, 9 Oct 2002, Skip Montanaro wrote:
> but the contents of their descr field looks bogus:
>
> *out->descr = {
> cast = (0xfee14410 = &`_numpy.so`arrayobject.c`DOUBLE_to_CHAR(double *ip, int ipstep, char *op, int opstep, int n), 0xfee144c0 = &`_numpy.so`arrayobject.c`DOUBLE_to_UBYTE(double *ip, int ipstep, unsigned char *op, int opstep, int n), 0xfee14570 = &`_numpy.so`arrayobject.c`DOUBLE_to_SBYTE(double *ip, int ipstep, signed char *op, int opstep, int n), 0xfee14620 = &`_numpy.so`arrayobject.c`DOUBLE_to_SHORT(double *ip, int ipstep, short *op, int opstep, int n), 0xfee146d0 = &`_numpy.so`arrayobject.c`DOUBLE_to_USHORT(double *ip, int ipstep, unsigned short *op, int opstep, int n), 0xfee14780 = &`_numpy.so`arrayobject.c`DOUBLE_to_INT(double *ip, int ipstep, int *op, int opstep, int n), 0xfee14830 = &`_numpy.so`arrayobject.c`DOUBLE_to_UINT(double *ip, int ipstep, unsigned int *op, int opstep, int n), 0xfee148e0 = &`_numpy.so`arrayobject.c`DOUBLE_to_LONG(double *ip, int ipstep, long *op, int opstep, int n), 0xfee14990 = &`_numpy.so`arrayobject.c`DOUBLE_to_FLOAT(double *ip, int ipstep, float *op, int opstep, int n), 0xfee14a38 = &`_numpy.so`arrayobject.c`DOUBLE_to_DOUBLE(double *ip, int ipstep, double *op, int opstep, int n), 0xfee14ae0 = &`_numpy.so`arrayobject.c`DOUBLE_to_CFLOAT(double *ip, int ipstep, float *op, int opstep, int n))
> getitem = 0xfee14ba0 = &`_numpy.so`arrayobject.c`DOUBLE_to_CDOUBLE(double *ip, int ipstep, double *op, int opstep, int n)
> setitem = 0xfee14c60 = &`_numpy.so`arrayobject.c`DOUBLE_to_OBJECT(double *ip, int ipstep, PyObject **op, int opstep, int n)
> type_num = -18789104
> elsize = -18789024
> one = 0x9 "<bad address 0x9>"
> zero = 0x8 "<bad address 0x8>"
> type = '\0'
> }
>
> Evaluating -18789104 as a hex value yields something which looks strangely
> like a pointer: 0xfee14d10. I wonder if the cast field got initialized with
> an array that was too long for the size it was declared (PyArray_NTYPES)?
I think you have different Numeric versions or old Numeric header files
lying in your system.
Note that in Numeric-22.0 the size of PyArray_TYPES is 15 while in
Numeric-21.0 it is 13. That may explain the two additional pointer values
that you see in type_num and elsize above.
I suspect that when you upgraded Numeric, the new header files
did not get installed, possibly because of the well-know distutils bug we
have seen earlier...
> Pearu> PS: I assume that f2py tests were all ok on your platform. Is
> Pearu> that correct?
>
> I don't know. I'm just building and installing f2py as part of a larger
> build of SciPy. I don't even know how to run f2py's tests independently.
Once I explained it to you...
Pearu
More information about the Scipy-dev
mailing list