[SciPy-dev] segfault during scipy.test(1) - Solaris 8, Sun compilers

Skip Montanaro skip at pobox.com
Wed Oct 9 11:53:58 CDT 2002

>>>>> "Pearu" == Pearu Peterson <pearu at cens.ioc.ee> writes:

    Pearu> On Tue, 8 Oct 2002, Skip Montanaro wrote:

    >> Python is crashing on me during scipy.test(1) (Solaris 8, Sun compilers).
    >> The start of the traceback in dbx looks like:
    >> [1] copy_ND_array(in = 0x7771d8, out = 0x777a70), line 780 in "fortranobject.c"
    >> [2] array_from_pyobj(type_num = 9, dims = 0xffbeaa3c, rank = 2, intent = 97, obj = 0x7771d8), line 556 in "fortranobject.c"
    >> [3] f2py_rout__flinalg_ddet_r(capi_self = 0x402858, capi_args = 0x85dcf8, capi_keywds = 0x85c790, f2py_func = 0xfd6bf320 = &ddet_r_()), line 298 in "_flinalgmodule.c"
    >> [4] fortran_call(fp = 0x402858, arg = 0x85dcf8, kw = 0x85c790), line 248 in "fortranobject.c"
    >> [5] PyObject_Call(func = 0x402858, arg = 0x85dcf8, kw = 0x85c790), line 1684 in "abstract.c"
    >> [6] do_call(func = 0x402858, pp_stack = 0xffbeaf40, na = 1, nk = 1), line 3262 in "ceval.c"
    >> [7] eval_frame(f = 0x386568), line 2028 in "ceval.c"
    >> [8] PyEval_EvalCodeEx(co = 0x7cbcc8, globals = 0x7cf358, locals = (nil), args = 0x3093b4, argcount = 1, kws = 0x3093b8, kwcount = 0, defs = 0x7cccbc, defcount = 1, closure = (nil)), line 2585 in "ceval.c"
    >> [9] fast_function(func = 0x7d9c50, pp_stack = 0xffbeb4a0, n = 1, na = 1, nk = 0), line 3164 in "ceval.c"
    >> Line 780 of F2PY's fortranobject.c is
    >> PyArray_VectorUnaryFunc *cast = in->descr->cast[out->descr->type_num];
    >> The value in out->descr->type_num (and in->descr->type_num for that
    >> matter) is -18789104, which is clearly out of range for an element of
    >> PyArray_TYPES.  (Why doesn't Numeric define it as such in its
    >> PyArray_Descr struct?)

    Pearu> What do you mean? type_num is defined in PyArray_Descr struct as
    Pearu> an int.

PyArray_TYPES is an enum.  It appears to me from the tests in copy_ND_array,
that the type_num field is being treated as a slot which holds values from
that enum.  I was just wondering why the Numeric folks didn't define the
type_num field to be of type 'enum PyArray_TYPES'.  It's hardly an esoteric
corner of the C language that needs to be avoided for portability.

    >> Does this seem familiar to anyone?

    Pearu> No. But I am wondering if other `in' and `out' attributes make
    Pearu> sense?

*in and *out look okay:

    *in = {
	ob_refcnt  = 5
	ob_type    = 0xfee39ad8
	data       = 0x857dc8 "?\xed\xb2k\xc5\xd8\xae^L?\xc7\xbav=k\xee ?\xe3\xfc\xbd\xc7\xee6^D?\xd6\xa2v\xd8\x93\xef\xc0?\xea^P\xf9\x90M^\xc4?\xe4Q]|\xf8\xfc\xfa?\xbfuK\xf9Y^N\xc0?\xe7.?\xa23\xd5\xc8?\xe9L\x94\xc9;\xd8\xac?\xeb^[^_\xa3^T\x91,?\xe1P\x84\xc2\xebR"?\xe8\x84Uo\xc5\x81\xb6?\xd4^\\xc3^U^F\xd9 ?\xeeFN\xffI\xc8\xe2?\xef^A\x92\xcb\xfat\x83?\xebw\xe1\xa8\xa1]^?\xe3\x92"
	nd         = 2
	dimensions = 0x782738
	strides    = 0x782768
	base       = (nil)
	descr      = 0xfee39f90
	flags      = 15
    (dbx) print *out
    *out = {
	ob_refcnt  = 1
	ob_type    = 0xfee39ad8
	data       = 0x858a58 ""
	nd         = 2
	dimensions = 0x76d6c8
	strides    = 0x782788
	base       = (nil)
	descr      = 0xfee39f90
	flags      = 15

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)?

    Pearu> To find out, uncomment lines starting at #782 and also
    Pearu> dump_attrs() function definition starting at line #455 in
    Pearu> fortranobject.c. You may also need to initialize `cast' after the
    Pearu> line #788. What is the output? Is it reasonable?  I ask this in
    Pearu> order to see if there is some memory corruption going on or if
    Pearu> just descr->type_num is not initialized correctly for some
    Pearu> reasons.

This doesn't seem like it will be fruitful.  The various printf and
dump_attrs lines are already commented out, so moving the cast variable
initialization past them won't help.

    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.


More information about the Scipy-dev mailing list