test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha

[etrepum]

BPO	1496032
Nosy	@etrepum, @mdickinson

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/mdickinson'
closed_at = <Date 2009-04-27.16:33:33.777>
created_at = <Date 2006-05-27.15:21:36.000>
labels = ['interpreter-core', 'type-bug']
title = 'test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha'
updated_at = <Date 2009-04-27.16:33:33.775>
user = 'https://github.com/etrepum'

bugs.python.org fields:

activity = <Date 2009-04-27.16:33:33.775>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2009-04-27.16:33:33.777>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2006-05-27.15:21:36.000>
creator = 'bob.ippolito'
dependencies = []
files = []
hgrepos = []
issue_num = 1496032
keywords = []
message_count = 11.0
messages = ['60924', '60925', '60926', '60927', '65724', '65771', '65792', '65974', '86670', '86672', '86676']
nosy_count = 3.0
nosy_names = ['nnorwitz', 'bob.ippolito', 'mark.dickinson']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1496032'
versions = ['Python 2.6', 'Python 3.1']

[etrepum]

Program received signal SIGFPE, Arithmetic exception.
0x0000000160418568 in bu_double (p=0x12049d29c "", f=0x0) at /
house/etrepum/src/python-46462/Modules/_struct.c:219

(this is actually due to _PyFloat_Unpack8)

[etrepum]

Logged In: YES
user_id=139309

More fun in test_long

Program received signal SIGFPE, Arithmetic exception.
0x000000012003972c in float_richcompare (v=0x120397080,
w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387
387 else if (!Py_IS_FINITE(i)) {

[etrepum]

Logged In: YES
user_id=139309

More fun in test_long

Program received signal SIGFPE, Arithmetic exception.
0x000000012003972c in float_richcompare (v=0x120397080,
w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387
387 else if (!Py_IS_FINITE(i)) {

[nnorwitz]

Logged In: YES
user_id=33168

Try adding the -mieee flag when compiling. That should fix
the problem. It looks like we only set this for OSF
platforms. It should probably be set for all Alpha platforms.

See:
http://mail.python.org/pipermail/python-dev/2006-March/063219.html

[mdickinson]

There are some current math and cmath test failures on the Debian alpha
buildbots (2.6 and 3.0), and I think there's a good possibility that
adding -mieee to BASECFLAGS would fix these.

I'm struggling to find the right way to do this in configure.in.
I've found the GCC specific section for BASECFLAGS (around line 800), but
I don't know how to write a test for an alpha CPU (rather than a test for
a specific operating system). Any hints or pointers?

[nnorwitz]

I think uname -m will be equal to "alpha" in this case. There are
several uses of uname -m in configure.in. You might need to add a
new section. It might also be possible to clean up various special
cases to make a generic uname -m section. I didn't look too closely
though.

-m is the machine type

BTW, -m works on Tru64. I also tested on Ubuntu and it reported
x86_64, on Debian it reported sparc. On OSX.4, it reported "Power
Macintosh".

[mdickinson]

Okay---I've added -mieee to BASECFLAGS in r62499, when uname -m reports
alpha* and when gcc is the compiler; I've also added a configure message
that simply reports the output of uname -m, to aid debugging in case
anything funny happens.

With luck, this should fix the problems reported by Bob Ippolito, as well
as the current test_math and test_cmath failures.

Bob, if you're still listening, are you in a position to check whether
this change fixes the failures you reported?

[mdickinson]

Adding -mieee didn't fix the math and cmath problems. Should I revert
the change in r62499, or leave it in? It seems to me that having -mieee
is a good thing on the whole. The main reason to not want IEEE 754
conformance would be speed.

It looks like the math and cmath failures are due to libm behaviour;
either (1) libm is making no attempt to be IEEE compliant, or (2) it's
setting errno in places that it shouldn't, or (3) it's trying to be IEEE
compliant but is buggy. I'm not sure how to proceed. Would it be okay
to check in some temporary autoconf tests to help identify the source of
the failures, and remove them later?

[mdickinson]

Bob, can you still reproduce the originally reported SIGFPE?

[etrepum]

I don't even recall where I had access to a FreeBSD 6.0 Alpha machine,
sorry.

[mdickinson]

No problem! I'll close this as out of date, then.