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

Mikael Pettersson <>
Wed May 4 00:35:32 CEST 2011


On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito <> wrote:
> On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson <> wrote:
> > Bob Ippolito writes:
> > =C2=A0> I only see this error on Mac OS X. I have not been able to reprod=
> uce in Linux.
> > =C2=A0>
> > =C2=A0> Here's an example, any number larger than 16#7ffffffffffffe00 wil=
> l
> > =C2=A0> cause this error.
> > =C2=A0>
> > =C2=A0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
> > =C2=A0> [async-threads:4] [hipe] [kernel-poll:true]
> > =C2=A0>
> > =C2=A0> Eshell V5.8.3 =C2=A0(abort with ^G)
> > =C2=A0> 1> trunc(16#7ffffffffffffdff * 1.0).
> > =C2=A0> 9223372036854774784
> > =C2=A0> 2> trunc(16#7ffffffffffffdff * 1.0).
> > =C2=A0> 9223372036854774784
> > =C2=A0> 3> trunc(16#7ffffffffffffe00 * 1.0).
> > =C2=A0> 9223372036854775808
> > =C2=A0> 4> trunc(16#7ffffffffffffe00 * 1.0).
> > =C2=A0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
> > =C2=A0> 0x19223372036854775808
> > =C2=A0> 5> trunc(16#7ffffffffffffe00 * 1.0).
> > =C2=A0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
> > =C2=A0> 0x19223372036854775808
> > =C2=A0> 6> io:format("~s~n", [os:cmd("uname -a")]).
> > =C2=A0> Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29
> > =C2=A0> 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
> > =C2=A0>
> > =C2=A0> Here's another example:
> > =C2=A0>
> > =C2=A0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
> > =C2=A0> [async-threads:4] [hipe] [kernel-poll:true]
> > =C2=A0>
> > =C2=A0> Eshell V5.8.3 =C2=A0(abort with ^G)
> > =C2=A0> 1> <<F/float>> =3D <<67,224,0,0,0,0,0,0>>, trunc(F).
> > =C2=A0> 9223372036854775808
> > =C2=A0> 2> <<F/float>> =3D <<67,224,0,0,0,0,0,0>>, trunc(F).
> > =C2=A0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at
> > =C2=A0> 0x19223372036854775808
> > =C2=A0> 3> <<F/float>> =3D <<67,224,0,0,0,0,0,0>>, trunc(F).
> > =C2=A0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at
> > =C2=A0> 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. =C2=A0For that you should probably plant a breakpoint
> > at 0x19223372036854775808 and then evaluate one of those Erlang
> > expressions above to trigger the FPE.
> >
> 
> Well, it's actually saying 0x1, the result of the trunc is
> 9223372036854775808  and the message string is truncated to 64
> characters which is not enough to show it all. Perhaps the buffer size
> in erts_fp_check_init_error should be adjusted.

Something in your terminal or email client ate a \r\n sequence after the
0x1 from erts_fp_check_init_error() making it appear glued together with
the 9223372036854775808 that the erlang prompt printed.

That 0x1 means that the #ifdef tests in erts/emulator/sys/unix/sys_float.c
failed to enable the proper sigaction-style SIGFPE handler in your Erlang
VM build, and instead fell back to a very primitive plain SIGFPE handler.
If you run gdb or objdump on your Erlang VM (the beam.smp executable not
the erl frontend) I bet you won't find an fpe_sig_action() function but
a smallish fpe_sig_handler() one instead.

The machine-specific fpe_sig_action() handler is absolutely mandatory for
reliable FP exceptions.

The bug then is that the C compiler on your Mac OS X didn't set up the
proper preprocessor symbols so that the sigaction-style handler could
be enabled.

What does `gcc -E -dM -xc /dev/null | sort' say? (For 'gcc' substitute
whatever compiler and extra compiler options you used to build Erlang.)

/Mikael


More information about the erlang-bugs mailing list