> I have downloaded python-1.1 and applied patch-1.1.1. I am compiling
>on an AlphaServer 2100 running DEC-OSF/1 V3.0B, and have tried using
>both the native C compiler and gcc. In both cases make test fails with
>the following sort of message:
>
>fiachra python-1.1 % make test
>(cd Modules; make -f Makefile.pre Makefile)
>`Makefile' is up to date.
>for i in . Parser Objects Python Modules; do (echo $i; cd $i; make
>Makefile); done
>.
>`Makefile' is up to date.
>Parser
>`Makefile' is up to date.
>Objects
>`Makefile' is up to date.
>Python
>`Makefile' is up to date.
>Modules
>`Makefile' is up to date.
>for i in Parser Objects Python Modules; do (echo $i; cd $i; make
>OPT="-g" all); done
>Parser
>Objects
>Python
>Modules
>rm -f ./Lib/test/*.pyc
>PYTHONPATH=./Lib:./Lib/test ./python -c 'import autotest'
>Unaligned access pid=17817 <python> va=14009f087 pc=3ff800c0e50
>ra=12005f7b4 type=stq
>Unaligned access pid=17817 <python> va=14009f07f pc=3ff800c0e38
>ra=120062f24 type=ldq
>sh: 17817 Memory fault - core dumped
>*** Exit 139
>Stop.
>
> I was wondering if anyone else has had this problem and figured out a
>way of compiling a working version of python for DEC-OSF? The unaligned
>access is only an inconvenience, and just means that somewhere in the
>code accesses are not quadword aligned.
Since then I have gotten two messages:
A "Me too" from Harrie Overdijk <overdijk@ecn.nl>
An enlightening message from Bob Kras <kras@syo.dec.com> which I have
included below.
However I have also spotted a few more things:
If compiled under gcc (2.6.3) then when I do a
make libinstall
(after having commented out the ternery pow() tests), I find that the
make crashs out due to python dying while compiling the test_b1 file
for installation, with an error message of "Bad Object Code", or
something like that. When made with plain cc this doesn't happen.
I also experimented with compiling python with the the F_ math
functions, by defining _FASTMATH, and found that the tests fail in the
test_b1.py file on line 208, the map(sqrt,...) test, as follows
from math import sqrt
if map(lambda x: map(sqrt,x), [[16, 4], [81, 9]]) <> [[4.0, 2.0], [9.0,
3.0]]:
raise TestFailed, 'map(lambda x: map(sqrt,x), [[16, 4], [81,
9]])'
However if I interactively run the python binary and test things I get
the following:
Python 1.1.1 (Mar 27 1995)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
>>> from math import sqrt
>>> map(lambda x: map(sqrt,x), [[16, 4], [81, 9]])
[[4.0, 2.0], [9.0, 3.0]]
>>>
As you can see this is the correct answer, as displayed on the rhs of
the "<>" above.
This could result from a number of possibilities, and since I haven't
checked out the code I'm not sure of the exact cause. But it either
suggests an error in the sqrt() and comparions code in python, or more
probably an error in the F_ math routines.
The reason I tried out the _F math routines is because of the
performance improvements; on a test on the above system I found that I
could get 1.25e6 sin()'s a second or so with the ordinary version,
whereas with the F_ routines I was getting 2e+6 sin()'s a second. I
must test the accuracies further.
Fergal.
------- Forwarded Message
Date: Fri, 24 Mar 1995 14:25:18 -0500
From: Bob Kras <kras@syo.dec.com>
Subject: Re: Python make test fails
To: fergal@fiachra.ucd.ie
Message-Id: <9503241925.AA01991@aosf1.syo.dec.com>
X-Envelope-To: fergal@fiachra.ucd.ie
Content-Transfer-Encoding: 7BIT
In article <9503210313.AA17659@fiachra.ucd.ie> you write:
|> I was wondering if anyone else has had this problem and figured out
a
|>way of compiling a working version of python for DEC-OSF? The
unaligned
|>access is only an inconvenience, and just means that somewhere in the
|>code accesses are not quadword aligned.
|>
I've run 1.1 for some time (and more recently been testing 1.2 beta)
Builds
have not been a problem under 3.0, and 3.0B is a hw upgrade so the two
should
be the same. I think I might know the problem though:
One test that had to be commented out in 1.1.1 might be your problem.
This
was due to a problem in python (fixed in 1.2 when its available) that
occurs
noticably in tertiary pow() with mismatched types.
pow(1,10,100) would work, while pow(2,10,1000L) would core dump within
a
couple more commands, but somewhat randomly. This was due to some
reference
count issues. Alpha and Linux find the problem, it goes undetected in
some
other systems.
You can check if this is it by using the same PYTHONPATH as the make
test and
then "import test_b2".
Bob Kras
Digital Equipment
Here is the note from Guido:
Return-Path: guido@cwi.nl
Received: from charon.cwi.nl by inet-gw-2.pa.dec.com (5.65/10Aug94)
id AA27841; Mon, 19 Dec 94 15:39:59 -0800
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
id <AA07053@cwi.nl>; Tue, 20 Dec 1994 00:38:28 +0100
Received: by voorn.cwi.nl with SMTP
id <AA12004@cwi.nl>; Tue, 20 Dec 1994 00:38:27 +0100
Message-Id: <9412192338.AA12004=guido@voorn.cwi.nl>
To: "Bob Kras" <kras@syo.dec.com>
Subject: Re: Python v1.1.1 pow(x,y,z) problems
In-Reply-To: Your message of "Mon, 19 Dec 1994 17:52:54 MET."
<9412192252.AA21539@syorrk.syo.dec.com>
References: <9412192252.AA21539@syorrk.syo.dec.com>
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 94079, 1090 GB Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199
(fax)
Date: Tue, 20 Dec 1994 00:38:26 +0100
Sender: Guido.van.Rossum@cwi.nl
Bob,
This bug was discussed on the list maybe a week ago. It is a subtle
logic
error in my code -- basically, after
INCREF(a);
coerce(&a, &b);
DECREF(a);
the INCREF and DECREF *don't* always cancel each other out, since
coerce() may have replaced either of its arguments with a new object.
I haven't devised a fix yet (it will have to involve copying some
variables into temporaries). If you urgently need a fix, let me know
and I'll write the code right now... (Otherwise, just disable this
part of the tests and don't use ternary pow().)
- --Guido van Rossum, CWI, Amsterdam <mailto:Guido.van.Rossum@cwi.nl>
<http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>
------- End of Forwarded Message
--
/ Fergal Mc Carthy <fergal@fiachra.ucd.ie>, | Fergal Mc Carthy, \
| Advanced Computational Research Group, | 31 Fosterbrook, |
| Chemistry Department., U.C.D., Belfield, | Stillorgan Road, |
| Dublin 4, Ireland. | Dublin 4, Ireland. |
\ Ph: +353-1-706{2284,2418} | Ph: +353-1-2601304 /
--
/ Fergal Mc Carthy <fergal@fiachra.ucd.ie>, | Fergal Mc Carthy, \
| Advanced Computational Research Group, | 31 Fosterbrook, |
| Chemistry Department., U.C.D., Belfield, | Stillorgan Road, |
| Dublin 4, Ireland. | Dublin 4, Ireland. |
\ Ph: +353-1-706{2284,2418} | Ph: +353-1-2601304 /