[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