[erlang-bugs] Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...]

Mikael Pettersson mikpe@REDACTED
Tue May 3 10:04:57 CEST 2011


Bob Ippolito writes:
 > I only see this error on Mac OS X. I have not been able to reproduce in Linux.
 > 
 > Here's an example, any number larger than 16#7ffffffffffffe00 will
 > cause this error.
 > 
 > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
 > [async-threads:4] [hipe] [kernel-poll:true]
 > 
 > Eshell V5.8.3  (abort with ^G)
 > 1> trunc(16#7ffffffffffffdff * 1.0).
 > 9223372036854774784
 > 2> trunc(16#7ffffffffffffdff * 1.0).
 > 9223372036854774784
 > 3> trunc(16#7ffffffffffffe00 * 1.0).
 > 9223372036854775808
 > 4> trunc(16#7ffffffffffffe00 * 1.0).
 > ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
 > 0x19223372036854775808
 > 5> trunc(16#7ffffffffffffe00 * 1.0).
 > ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
 > 0x19223372036854775808
 > 6> io:format("~s~n", [os:cmd("uname -a")]).
 > Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29
 > 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
 > 
 > Here's another example:
 > 
 > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
 > [async-threads:4] [hipe] [kernel-poll:true]
 > 
 > Eshell V5.8.3  (abort with ^G)
 > 1> <<F/float>> = <<67,224,0,0,0,0,0,0>>, trunc(F).
 > 9223372036854775808
 > 2> <<F/float>> = <<67,224,0,0,0,0,0,0>>, trunc(F).
 > ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at
 > 0x19223372036854775808
 > 3> <<F/float>> = <<67,224,0,0,0,0,0,0>>, trunc(F).
 > ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at
 > 0x19223372036854775808

It means that the code at 0x19223372036854775808 in the
Erlang VM needs to use the proper ERTS_FP_CHECK_<foo> macros.

Please attach gdb (or whatever debugger Darwin uses) to a running
Erlang VM and disassemble the code at 0x19223372036854775808.
We need to know the name of the enclosing function, and preferably
also the actual instruction sequence that throws the FPE. If gdb
can show the exact original source code line then that's even better.

If this is in libc rather than the Erlang VM itself, then we need
a call trace to identify which code in the VM called out to this
FP-throwing code.  For that you should probably plant a breakpoint
at 0x19223372036854775808 and then evaluate one of those Erlang
expressions above to trigger the FPE.



More information about the erlang-bugs mailing list