On 3/30/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> Disabling a test on a platform is usually a bad thing, overall. The
Agreed.
> purpose of the test suite isn't to get a lot of green buildbot boxes
> <0.5 wink>, it's to determine whether Python works as expected. If a
> platform bug causes some test to fail, then that test _should_ fail on
> that platform -- it's not a Python bug, after all, and users on that
> platform aren't served by hiding that platform bugs cause Python tests
> to fail. If they try the same things in their programs they'll fail
> there too, and the test suite is supposed to warn them about that.
Fair enough. However, it's not just that the test fails. It's that
Python exits. Hell, if I'm in bash, bash dies too! If I'm running
python in gdb, gdb dies. I tried building a trace (supposedly like
truss), but that crashes while python is starting up. So we can never
get results on which tests failed, since we can never finish
reasonably.
When I single stepped in gdb, the code died when executing the
equivalent of fseek(stdin, -1, 0);
I tried to seek(-1) on a different file and that was ok. The test is
meant to stress a failure condition, but fseek is expected to return.
Upgrading the machine isn't an option (it's not mine), and I don't
know that upgrading would fix the problem.
> If the primary goal here is really to "make the alpha Tru64 5.1
> buildbot columns green", then maybe the Alpha needs a different test
> runner, to exclude the tests that are doomed to fail due to Alpha
> bugs.
That's not my goal. I just want to get as much information as
possible. I also don't want to skip all of test_file, only one test
case.
> > ...
> > With gcc, there are also several issues:
> > * test_float and test_struct fail due to NaN handling
> > * test_long fails
>
> Which version of gcc is in use? Alpha hardware has incomplete support
4.0.1.
> Looks like compiling with
>
> -mieee
>
> would be an excellent idea for Python, and looks like we're not using
> that now. I've never used an Alpha, but I recall that this suggestion
> fixed other peoples' problems :-)
Since we are already using -ieee for the platform cc, I thought this
was an excellent idea as well. I almost put in my message that I
tried it along with a couple other options. But I guess I was on
crack or something, cause I tried it again, being very careful (ie,
not trying to do 4 things at once) and voila! it worked. Thanks Tim!
It fixed the problem with test_float, test_long, and test_struct. The
thing that seems really odd is that I was sure test_pty passed before
with gcc, now it's failing. Given the problem with -mieee, I was
probably just very confused when I did everything the first time.
So now the failures with gcc are: test_file, test_pty, test_ctypes.
I believe this is the same as with the platform cc.
Additional ctypes failure info for Thomas:
AssertionError: ('dlopen: Cannot map library libc.so.6', 'libc.so.6',
('posix', 'osf1V5'))
Note: there is no version info on osf1, ie no 6. ldd python shows:
libc.so => /usr/shlib/libc.so
n
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
