numarray indexing problems with Python2.5 and 64-bit platforms

Francesc Altet faltet at carabos.com
Fri Nov 3 09:00:10 CST 2006


Hi Todd,

A Dijous 02 Novembre 2006 22:04, Todd Miller escrigué:
> Here's a stab at a solution but I don't have easy access to 64-bit linux
> at the moment so it is untested.   If someone is willing to test it
> (and/or fix it) I'll add it to the next numarray release.  It should be
> noted that numarray is not 64-bit enabled (it compiles as a 32-bit
> program in terms of arrays) which is another motivation to switch to numpy.

Many thanks for the patch. The good news is that it seems to fix the
main issue:

>>> a=numarray.array([1,2,3])
>>> a[1:2]
array([2])

and moreover, all the tests in PyTables (with numarray at its core) do
pass in 64-bit platforms and Python 2.5 run ok (except for the known
bug that also happens in 32-bit platforms; see [1]).

The bad news is that the numarray tests seems more finicky than
PyTables ones and they are throwing a "segmentation fault":

>>> import numarray.testall as testall
>>> testall.test()
Testing numarray 1.5.2 on normal Python (2, 5, 0, 'final', 0) on platform 
linux2 with builtin linear algebra support
Violación de segmento

I've run this through valgrind, and here it is the offending line:

unhandled opc_aux = 0x 7
first_opcode == 0xDD
vex amd64->IR: unhandled instruction bytes: 0xDD 0x7C 0x24 0xFC
==29710==
==29710== Process terminating with default action of signal 4 (SIGILL)
==29710==  Illegal opcode at address 0x11F603A0
==29710==    at 0x11F603A0: fetestexcept (in /lib64/tls/libm-2.3.5.so)
==29710==    by 0x1272E21D: NA_clearFPErrors (libnumarraymodule.c:1949)
==29710==    by 0x13465311: _Py_cum_exec (_ufuncmodule.c:998)
==29710==    by 0x1346562C: _cum_cached (_ufuncmodule.c:1087)
==29710==    by 0x134659E7: _cum_swapped (_ufuncmodule.c:1199)
==29710==    by 0x13465ED0: _Py_reduce (_ufuncmodule.c:1374)
==29710==    by 0x483166: PyEval_EvalFrameEx (ceval.c:3566)
==29710==    by 0x4845B0: PyEval_EvalCodeEx (ceval.c:2833)
==29710==    by 0x48331D: PyEval_EvalFrameEx (ceval.c:3662)
==29710==    by 0x4845B0: PyEval_EvalCodeEx (ceval.c:2833)
==29710==    by 0x48331D: PyEval_EvalFrameEx (ceval.c:3662)
==29710==    by 0x4845B0: PyEval_EvalCodeEx (ceval.c:2833)
==29710==    by 0x48331D: PyEval_EvalFrameEx (ceval.c:3662)
==29710==    by 0x4845B0: PyEval_EvalCodeEx (ceval.c:2833)
==29710==    by 0x4CF0D3: function_call (funcobject.c:517)
==29710==    by 0x415C32: PyObject_Call (abstract.c:1860)
==29710==    by 0x41D0A2: instancemethod_call (classobject.c:2493)
==29710==    by 0x415C32: PyObject_Call (abstract.c:1860)
==29710==    by 0x47C660: PyEval_CallObjectWithKeywords (ceval.c:3435)
==29710==    by 0x454823: slot_tp_repr (typeobject.c:4504)

it seems to my inexpert eyes that the compiler has generated some code
that it is not understood by the amd64 architecture (?).

[1] 
<http://sourceforge.net/tracker/index.php?func=detail&aid=1565683&group_id=1369&atid=450446>

Regards,

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


More information about the Numpy-discussion mailing list