arraytypes.c : can't read descrs table

Using Python 1.5.2, gcc 2.95.2 and Numeric CVS as of 4/3/2000 on Solaris 7 (Sparc). When I attempt to import Numeric, I get a segmentation fault. After 'multiarray'. '_numpy' and 'umath' are imported, the stack trace is: #0 PyArray_DescrFromType (type=70) at Src/arraytypes.c:593 #1 0xfe768dd0 in PyArray_FromDims (nd=1, d=0xffbecfc8, type=70) at Src/arrayobject.c:416 #2 0xfe7952f0 in array_zeros (ignored=0x1, args=0x1) at Src/multiarraymodule.c:961 #3 0x1f72c in call_builtin (func=0xe6928, arg=0xedd40, kw=0x0) at ceval.c:2359 #4 0x1f5f8 in PyEval_CallObjectWithKeywords (func=0xe6928, arg=0xedd40, kw=0x0) at ceval.c:2324 #5 0x1dde0 in eval_code2 (co=0xe7ec8, globals=0x0, locals=0x83, args=0xffffffff, argcount=944424, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1654 #6 0x1dc88 in eval_code2 (co=0xc9dc0, globals=0xfda98, locals=0xffffffff, args=0x1, argcount=1015296, kws=0x0, kwcount=0, defs=0xe6b2c, defcount=1, owner=0x0) at ceval.c:1612 #7 0x1dc88 in eval_code2 (co=0xf78f0, globals=0xfdc7c, locals=0x1, args=0x1, argcount=1014976, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1612 #8 0x1b8a0 in PyEval_EvalCode (co=0xf78f0, globals=0xf0f70, locals=0xf0f70) at ceval.c:324 #9 0x277a8 in PyImport_ExecCodeModuleEx (name=0xffbede80 "Precision", co=0xf78f0, pathname=0xffbed4a0 "/usr/local/lib/python1.5/site-packages/Numeric/Precision.pyc") at import.c:485 gdb shows the fault right after line 596 in Src/arraytypes.c : if (type < PyArray_NTYPES) { return descrs[type]; # type = 'F' } else { switch(type) { case 'c': return descrs[PyArray_CHAR]; case 'b': return descrs[PyArray_UBYTE]; case '1': return descrs[PyArray_SBYTE]; case 's': return descrs[PyArray_SHORT]; case 'i': return descrs[PyArray_INT]; case 'l': return descrs[PyArray_LONG]; case 'f': return descrs[PyArray_FLOAT]; case 'd': return descrs[PyArray_DOUBLE]; case 'F': return descrs[PyArray_CFLOAT]; If I try to examine descrs[0], gdb says: (gdb) print descrs[0] Cannot access memory at address 0x0. This is probably shared library weardness, but I'm not sure how to fix it. Any ideas? -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu
participants (1)
-
Joe Van Andel