Python on Altix (re-cap)

Todd Miller jmiller at stsci.edu
Wed Oct 8 15:20:23 EDT 2003


Todd Miller wrote:
> I'm trying to set up Python on a 64-bit Linux super computer which looks 
> like this:
> 
> Linux somewhere.in.au 2.4.20-sgi221r3 #1 SMP Tue Jul 22 15:32:18 PDT 
> 2003 ia64 unknown
> 
> I configure Python like this:
> 
> ./configure --prefix=$HOME --with-pydebug --without-threads
> 
> But as soon as I try to run my software self-tests (for the numarray 
> Numeric-like array package),  I get this:
> 
> python(11030): unaligned access to 0x60000fffffff61cc, 
> ip=0x40000000002b9221

This message is apparently a kernel level debug message.  It is not on 
stdout or stderr.  This message went away when I switched off 
--with-pydebug.

> 
>      Debug memory block at address p=0x6000000000718310:
>     88 bytes originally requested
>     The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected.
>     The 4 pad bytes at tail=0x6000000000718368 are not all FORBIDDENBYTE 
> (0xfb):
>         at tail+0: 0x02 *** OUCH
>         at tail+1: 0x00 *** OUCH
>         at tail+2: 0x00 *** OUCH
>         at tail+3: 0x00 *** OUCH
>     The block was made by call #0 to debug malloc/realloc.
>     Data at p: 00 00 00 00 00 00 00 00 ... 01 00 00 00 00 00 00 00
> Fatal Python error: bad trailing pad byte
> Abort (core dumped)

This message was related to a bug in the numarray setup.py.  Once I 
configured numarray for LP64=1, it disappeared.

Interestingly,  there is no discernable difference between the 
sys.platform of i386 Linux and the sys.platform of a 64-bit x86 Linux; 
they are both "linux2".  I worked around this by adding a branch based 
on sys.maxint > 2**31-1 to distinguish between 32 and 64 bit linux.

I fixed a total of 3 other bugs in numarray,  one out-and-out bug, one 
64-bit self-test issue, and one C type casting portability issue.

> 
> I've poked around with this for a few hours,  but I'm not getting much 
> out of GDB.  Does anyone have any suggestions on how to get Python up 
> and running on an Altix or how to solve this problem more generally?
> 

Even with Skip's suggestion to use watchpoints,  I still had poor luck 
with GDB compared to 32-bit Linux.  I did learn the *<hex_address> 
syntax for specifying addresses rather than symbolic names for 
breakpoints and watchpoints.

With pydebug switched on, numarray still dumps core (on exit?) like this:

python: Modules/gcmodule.c:231: visit_decref: Assertion `gc->gc.gc_refs 
!= 0' failed.

With pydebug off, all is quiet and all the numarray self-tests now pass.


> Please CC me if you respond.

Thanks again for the pointers.

Todd





More information about the Python-list mailing list