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

[Bob Ippolito]

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

-bob
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

[Mikael Pettersson-3]

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.
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

[Bob Ippolito]

On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson <[hidden email]> wrote:

> 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.
>

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.

My gdb skills are very rusty, let me know if you need anything else
(and how to get it).

(gdb) attach 36833
Attaching to process 36833.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ...... done
0x00007fff87605e52 in select$DARWIN_EXTSN ()
(gdb) b erts_fp_check_init_error
Breakpoint 1 at 0x101209f7: file sys/unix/sys_float.c, line 87.
(gdb) c
Continuing.
[Switching to process 36833]

Breakpoint 1, erts_fp_check_init_error (fpexnp=0x110f2528) at
sys/unix/sys_float.c:87
87 {
(gdb) p (void*)*fpexnp
$1 = (void *) 0x10025433

And in another attach (I don't know how to get gdb out of the state
where it's telling me there's an EXC_ARITHMETIC which I guess is
SIGFPE):

(gdb) break *0x10025433
Breakpoint 1 at 0x10025433: file beam/erl_bif_guard.c, line 301.
(gdb) c
Continuing.
[Switching to process 36833]

Breakpoint 1, double_to_integer [inlined] () at
/Users/bob/src/otp_src_R14B02/erts/emulator/beam/erl_bif_guard.c:301
301 d = x;            /* trunc */
(gdb) list
296
297    for (i = ds-1; i >= 0; i--) {
298 ErtsDigit d;
299
300 x *= dbase;      /* "shift" left */
301 d = x;            /* trunc */
302 xp[i] = d;        /* store digit */
303 x -= d;           /* remove integer part */
304    }
305    while ((ds & (BIG_DIGITS_PER_WORD-1)) != 0) {
(gdb) disassemble
Dump of assembler code for function trunc_1:
0x00000000100252c0 <trunc_1+0>: mov    %rbx,-0x20(%rsp)
0x00000000100252c5 <trunc_1+5>: mov    %rbp,-0x18(%rsp)
0x00000000100252ca <trunc_1+10>: mov    %r12,-0x10(%rsp)
0x00000000100252cf <trunc_1+15>: mov    %r13,-0x8(%rsp)
0x00000000100252d4 <trunc_1+20>: sub    $0x38,%rsp
0x00000000100252d8 <trunc_1+24>: mov    %rdi,%rbx
0x00000000100252db <trunc_1+27>: mov    %esi,%edx
0x00000000100252dd <trunc_1+29>: and    $0x1,%edx
0x00000000100252e0 <trunc_1+32>: jne    0x100252e9 <trunc_1+41>
0x00000000100252e2 <trunc_1+34>: cmpq   $0x58,-0x2(%rsi)
0x00000000100252e7 <trunc_1+39>: je     0x10025340 <trunc_1+128>
0x00000000100252e9 <trunc_1+41>: mov    %rsi,%rax
0x00000000100252ec <trunc_1+44>: and    $0xf,%eax
0x00000000100252ef <trunc_1+47>: cmp    $0xf,%rax
0x00000000100252f3 <trunc_1+51>: je     0x10025306 <trunc_1+70>
0x00000000100252f5 <trunc_1+53>: test   %edx,%edx
0x00000000100252f7 <trunc_1+55>: je     0x10025330 <trunc_1+112>
0x00000000100252f9 <trunc_1+57>: movq   $0x350,0x148(%rbx)
0x0000000010025304 <trunc_1+68>: xor    %esi,%esi
0x0000000010025306 <trunc_1+70>: mov    %rsi,%rax
0x0000000010025309 <trunc_1+73>: mov    0x18(%rsp),%rbx
0x000000001002530e <trunc_1+78>: mov    0x20(%rsp),%rbp
0x0000000010025313 <trunc_1+83>: mov    0x28(%rsp),%r12
0x0000000010025318 <trunc_1+88>: mov    0x30(%rsp),%r13
0x000000001002531d <trunc_1+93>: add    $0x38,%rsp
0x0000000010025321 <trunc_1+97>: retq
0x0000000010025322 <trunc_1+98>: nopl   0x0(%rax)
0x0000000010025329 <trunc_1+105>: nopl   0x0(%rax)
0x0000000010025330 <trunc_1+112>: mov    -0x2(%rsi),%rax
0x0000000010025334 <trunc_1+116>: and    $0x3b,%eax
0x0000000010025337 <trunc_1+119>: cmp    $0x8,%rax
0x000000001002533b <trunc_1+123>: jne    0x100252f9 <trunc_1+57>
0x000000001002533d <trunc_1+125>: jmp    0x10025306 <trunc_1+70>
0x000000001002533f <trunc_1+127>: nop
0x0000000010025340 <trunc_1+128>: movq   0x6(%rsi),%xmm0
0x0000000010025345 <trunc_1+133>: xorpd  %xmm1,%xmm1
0x0000000010025349 <trunc_1+137>: ucomisd %xmm1,%xmm0
0x000000001002534d <trunc_1+141>: jb     0x100254cb <trunc_1+523>
0x0000000010025353 <trunc_1+147>: callq  0x1018777a <dyld_stub_floor>
0x0000000010025358 <trunc_1+152>: movapd %xmm0,%xmm1
0x000000001002535c <trunc_1+156>: ucomisd 0x172d6c(%rip),%xmm1
# 0x101980d0 <C.73.20233+176>
0x0000000010025364 <trunc_1+164>: jae    0x10025376 <trunc_1+182>
0x0000000010025366 <trunc_1+166>: jp     0x10025376 <trunc_1+182>
0x0000000010025368 <trunc_1+168>: ucomisd 0x172d68(%rip),%xmm1
# 0x101980d8 <C.73.20233+184>
0x0000000010025370 <trunc_1+176>: ja     0x1002549a <trunc_1+474>
0x0000000010025376 <trunc_1+182>: xor    %r13d,%r13d
0x0000000010025379 <trunc_1+185>: xorpd  %xmm0,%xmm0
0x000000001002537d <trunc_1+189>: ucomisd %xmm0,%xmm1
0x0000000010025381 <trunc_1+193>: jb     0x100254d9 <trunc_1+537>
0x0000000010025387 <trunc_1+199>: movsd  0x172d51(%rip),%xmm2        #
0x101980e0 <C.73.20233+192>
0x000000001002538f <trunc_1+207>: mov    $0x1,%r12d
0x0000000010025395 <trunc_1+213>: mov    $0xffffffff,%ebp
0x000000001002539a <trunc_1+218>: ucomisd %xmm2,%xmm1
0x000000001002539e <trunc_1+222>: jb     0x100253c5 <trunc_1+261>
0x00000000100253a0 <trunc_1+224>: xor    %ecx,%ecx
0x00000000100253a2 <trunc_1+226>: movsd  0x172d3e(%rip),%xmm0        #
0x101980e8 <C.73.20233+200>
0x00000000100253aa <trunc_1+234>: nopw   0x0(%rax,%rax,1)
0x00000000100253b0 <trunc_1+240>: mulsd  %xmm0,%xmm1
0x00000000100253b4 <trunc_1+244>: inc    %ecx
0x00000000100253b6 <trunc_1+246>: ucomisd %xmm2,%xmm1
0x00000000100253ba <trunc_1+250>: jae    0x100253b0 <trunc_1+240>
0x00000000100253bc <trunc_1+252>: lea    0x1(%rcx),%eax
0x00000000100253bf <trunc_1+255>: movslq %eax,%r12
0x00000000100253c2 <trunc_1+258>: lea    -0x1(%rcx),%ebp
0x00000000100253c5 <trunc_1+261>: mov    (%rbx),%rcx
0x00000000100253c8 <trunc_1+264>: mov    0x8(%rbx),%rax
0x00000000100253cc <trunc_1+268>: sub    %rcx,%rax
0x00000000100253cf <trunc_1+271>: sar    $0x3,%rax
0x00000000100253d3 <trunc_1+275>: cmp    %r12,%rax
0x00000000100253d6 <trunc_1+278>: jb     0x100254ac <trunc_1+492>
0x00000000100253dc <trunc_1+284>: lea    0x0(,%r12,8),%rdx
0x00000000100253e4 <trunc_1+292>: lea    (%rcx,%rdx,1),%rax
0x00000000100253e8 <trunc_1+296>: mov    %rax,(%rbx)
0x00000000100253eb <trunc_1+299>: mov    %rax,%rdi
0x00000000100253ee <trunc_1+302>: sub    %rdx,%rdi
0x00000000100253f1 <trunc_1+305>: lea    0x2(%rdi),%rsi
0x00000000100253f5 <trunc_1+309>: test   %ebp,%ebp
0x00000000100253f7 <trunc_1+311>: js     0x10025473 <trunc_1+435>
0x00000000100253f9 <trunc_1+313>: movslq %ebp,%rax
0x00000000100253fc <trunc_1+316>: lea    (%rdi,%rax,8),%rcx
0x0000000010025400 <trunc_1+320>: movsd  0x172ce8(%rip),%xmm3        #
0x101980f0 <C.73.20233+208>
0x0000000010025408 <trunc_1+328>: movsd  0x172ce8(%rip),%xmm2        #
0x101980f8 <C.73.20233+216>
0x0000000010025410 <trunc_1+336>: mov    $0x8000000000000000,%r8
0x000000001002541a <trunc_1+346>: jmp    0x1002542f <trunc_1+367>
0x000000001002541c <trunc_1+348>: nopl   0x0(%rax)
0x0000000010025420 <trunc_1+352>: subsd  %xmm0,%xmm1
0x0000000010025424 <trunc_1+356>: dec    %ebp
0x0000000010025426 <trunc_1+358>: sub    $0x8,%rcx
0x000000001002542a <trunc_1+362>: cmp    $0xffffffffffffffff,%ebp
0x000000001002542d <trunc_1+365>: je     0x10025473 <trunc_1+435>
0x000000001002542f <trunc_1+367>: mulsd  %xmm3,%xmm1
0x0000000010025433 <trunc_1+371>: cvttsd2siq %xmm1,%rdx
0x0000000010025438 <trunc_1+376>: ucomisd %xmm2,%xmm1
0x000000001002543c <trunc_1+380>: jb     0x1002544e <trunc_1+398>
0x000000001002543e <trunc_1+382>: movapd %xmm1,%xmm0
0x0000000010025442 <trunc_1+386>: subsd  %xmm2,%xmm0
0x0000000010025446 <trunc_1+390>: cvttsd2siq %xmm0,%rdx
0x000000001002544b <trunc_1+395>: xor    %r8,%rdx
0x000000001002544e <trunc_1+398>: mov    %rdx,0x8(%rcx)
0x0000000010025452 <trunc_1+402>: cvtsi2sdq %rdx,%xmm0
0x0000000010025457 <trunc_1+407>: test   %rdx,%rdx
0x000000001002545a <trunc_1+410>: jns    0x10025420 <trunc_1+352>
0x000000001002545c <trunc_1+412>: mov    %rdx,%rax
0x000000001002545f <trunc_1+415>: shr    %rax
0x0000000010025462 <trunc_1+418>: and    $0x1,%edx
0x0000000010025465 <trunc_1+421>: or     %rdx,%rax
0x0000000010025468 <trunc_1+424>: cvtsi2sdq %rax,%xmm0
0x000000001002546d <trunc_1+429>: addsd  %xmm0,%xmm0
0x0000000010025471 <trunc_1+433>: jmp    0x10025420 <trunc_1+352>
0x0000000010025473 <trunc_1+435>: test   %r13d,%r13d
0x0000000010025476 <trunc_1+438>: je     0x10025489 <trunc_1+457>
0x0000000010025478 <trunc_1+440>: shl    $0x6,%r12
0x000000001002547c <trunc_1+444>: lea    -0x34(%r12),%rax
0x0000000010025481 <trunc_1+449>: mov    %rax,(%rdi)
0x0000000010025484 <trunc_1+452>: jmpq   0x10025306 <trunc_1+70>
0x0000000010025489 <trunc_1+457>: shl    $0x6,%r12
0x000000001002548d <trunc_1+461>: lea    -0x38(%r12),%rax
0x0000000010025492 <trunc_1+466>: mov    %rax,(%rdi)
0x0000000010025495 <trunc_1+469>: jmpq   0x10025306 <trunc_1+70>
0x000000001002549a <trunc_1+474>: cvttsd2siq %xmm1,%rax
0x000000001002549f <trunc_1+479>: shl    $0x4,%rax
0x00000000100254a3 <trunc_1+483>: lea    0xf(%rax),%rsi
0x00000000100254a7 <trunc_1+487>: jmpq   0x10025306 <trunc_1+70>
0x00000000100254ac <trunc_1+492>: xor    %edx,%edx
0x00000000100254ae <trunc_1+494>: mov    %r12,%rsi
0x00000000100254b1 <trunc_1+497>: mov    %rbx,%rdi
0x00000000100254b4 <trunc_1+500>: movsd  %xmm1,(%rsp)
0x00000000100254b9 <trunc_1+505>: callq  0x1004cc40 <erts_heap_alloc>
0x00000000100254be <trunc_1+510>: mov    %rax,%rdi
0x00000000100254c1 <trunc_1+513>: movsd  (%rsp),%xmm1
0x00000000100254c6 <trunc_1+518>: jmpq   0x100253f1 <trunc_1+305>
0x00000000100254cb <trunc_1+523>: callq  0x101876f0 <dyld_stub_ceil>
0x00000000100254d0 <trunc_1+528>: movapd %xmm0,%xmm1
0x00000000100254d4 <trunc_1+532>: jmpq   0x1002535c <trunc_1+156>
0x00000000100254d9 <trunc_1+537>: xorpd  0x172c2f(%rip),%xmm1        #
0x10198110 <C.73.20233+240>
0x00000000100254e1 <trunc_1+545>: mov    $0x1,%r13b
0x00000000100254e4 <trunc_1+548>: jmpq   0x10025387 <trunc_1+199>
End of assembler dump.

-bob
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

[Mikael Pettersson-3]

On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito <[hidden email]> wrote:

> On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson <[hidden email]> 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
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

[Bob Ippolito]

On Tue, May 3, 2011 at 3:35 PM, Mikael Pettersson <[hidden email]> wrote:

> On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito <[hidden email]> wrote:
>> On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson <[hidden email]> 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.

Not my terminal or email client, this is a bug in
erts_fp_check_init_error. It only allocates a 64 byte buffer for the
error message. The pointer address and the \r\n are eaten because the
buffer is too small to fit the whole error message. buf[64] is too
small... the format string itself is already 57 chars (including the
NULL).

void erts_fp_check_init_error(volatile unsigned long *fpexnp)
{
    char buf[64];
    snprintf(buf, sizeof buf, "ERTS_FP_CHECK_INIT at %p: detected
unhandled FPE at %p\r\n",
         __builtin_return_address(0), (void*)*fpexnp);


> 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.

Maybe you missed it in my previous email, it's not 0x1, it is
0x10025433. I showed that by breaking at the function that prints the
error.
Breakpoint 1, erts_fp_check_init_error (fpexnp=0x110f2528) at
sys/unix/sys_float.c:87
87      {
(gdb) p (void*)*fpexnp
$1 = (void *) 0x10025433

There is a fpe_sig_action, and no fpe_sig_handler.

$ gdb beam.smp
GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May  5 04:36:56 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
shared libraries .... done

(gdb) list fpe_sig_action
523 #elif defined(__sun__) && defined(__x86_64__)
524 #define mc_pc(mc) ((mc)->gregs[REG_RIP])
525 #endif
526
527 static void fpe_sig_action(int sig, siginfo_t *si, void *puc)
528 {
529    ucontext_t *uc = puc;
530    unsigned long pc;
531
532 #if defined(__linux__)
(gdb) list fpe_sig_handler
Function "fpe_sig_handler" not defined.


> 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.)

#define OBJC_NEW_PROPERTIES 1
#define _LP64 1
#define __APPLE_CC__ 5664
#define __APPLE__ 1
#define __BLOCKS__ 1
#define __CHAR_BIT__ 8
#define __CONSTANT_CFSTRINGS__ 1
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __DBL_DIG__ 15
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __DBL_HAS_DENORM__ 1
#define __DBL_HAS_INFINITY__ 1
#define __DBL_HAS_QUIET_NAN__ 1
#define __DBL_MANT_DIG__ 53
#define __DBL_MAX_10_EXP__ 308
#define __DBL_MAX_EXP__ 1024
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_MIN_10_EXP__ (-307)
#define __DBL_MIN_EXP__ (-1021)
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DEC128_DEN__ 0.000000000000000000000000000000001E-6143DL
#define __DEC128_EPSILON__ 1E-33DL
#define __DEC128_MANT_DIG__ 34
#define __DEC128_MAX_EXP__ 6144
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __DEC128_MIN_EXP__ (-6143)
#define __DEC128_MIN__ 1E-6143DL
#define __DEC32_DEN__ 0.000001E-95DF
#define __DEC32_EPSILON__ 1E-6DF
#define __DEC32_MANT_DIG__ 7
#define __DEC32_MAX_EXP__ 96
#define __DEC32_MAX__ 9.999999E96DF
#define __DEC32_MIN_EXP__ (-95)
#define __DEC32_MIN__ 1E-95DF
#define __DEC64_DEN__ 0.000000000000001E-383DD
#define __DEC64_EPSILON__ 1E-15DD
#define __DEC64_MANT_DIG__ 16
#define __DEC64_MAX_EXP__ 384
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __DEC64_MIN_EXP__ (-383)
#define __DEC64_MIN__ 1E-383DD
#define __DECIMAL_DIG__ 21
#define __DEC_EVAL_METHOD__ 2
#define __DYNAMIC__ 1
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1067
#define __FINITE_MATH_ONLY__ 0
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __FLT_DIG__ 6
#define __FLT_EPSILON__ 1.19209290e-7F
#define __FLT_EVAL_METHOD__ 0
#define __FLT_HAS_DENORM__ 1
#define __FLT_HAS_INFINITY__ 1
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MANT_DIG__ 24
#define __FLT_MAX_10_EXP__ 38
#define __FLT_MAX_EXP__ 128
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MIN_EXP__ (-125)
#define __FLT_MIN__ 1.17549435e-38F
#define __FLT_RADIX__ 2
#define __GNUC_GNU_INLINE__ 1
#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1
#define __GNUC__ 4
#define __GXX_ABI_VERSION 1002
#define __INTMAX_MAX__ 9223372036854775807L
#define __INTMAX_TYPE__ long int
#define __INT_MAX__ 2147483647
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __LDBL_DIG__ 18
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __LDBL_HAS_DENORM__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __LDBL_MANT_DIG__ 64
#define __LDBL_MAX_10_EXP__ 4932
#define __LDBL_MAX_EXP__ 16384
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __LDBL_MIN_10_EXP__ (-4931)
#define __LDBL_MIN_EXP__ (-16381)
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __LITTLE_ENDIAN__ 1
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __LONG_MAX__ 9223372036854775807L
#define __LP64__ 1
#define __MACH__ 1
#define __MMX__ 1
#define __NO_INLINE__ 1
#define __PIC__ 2
#define __PTRDIFF_TYPE__ long int
#define __REGISTER_PREFIX__
#define __SCHAR_MAX__ 127
#define __SHRT_MAX__ 32767
#define __SIZE_TYPE__ long unsigned int
#define __SSE2_MATH__ 1
#define __SSE2__ 1
#define __SSE3__ 1
#define __SSE_MATH__ 1
#define __SSE__ 1
#define __SSP__ 1
#define __STDC_HOSTED__ 1
#define __STDC__ 1
#define __UINTMAX_TYPE__ long unsigned int
#define __USER_LABEL_PREFIX__ _
#define __VERSION__ "4.2.1 (Apple Inc. build 5664)"
#define __WCHAR_MAX__ 2147483647
#define __WCHAR_TYPE__ int
#define __WINT_TYPE__ int
#define __amd64 1
#define __amd64__ 1
#define __block __attribute__((__blocks__(byref)))
#define __k8 1
#define __k8__ 1
#define __pic__ 2
#define __strong
#define __tune_core2__ 1
#define __weak __attribute__((objc_gc(weak)))
#define __x86_64 1
#define __x86_64__ 1

-bob
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

[Mikael Pettersson-3]

On Tue, 3 May 2011 16:48:20 -0700, Bob Ippolito <[hidden email]> wrote:

> On Tue, May 3, 2011 at 3:35 PM, Mikael Pettersson <[hidden email]> wrote:
> > On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito <[hidden email]> wrote:
> >> On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson <[hidden email]> wrote=
> :
> >> > Bob Ippolito writes:
> >> > =3DC2=3DA0> I only see this error on Mac OS X. I have not been able to=
>  reprod=3D
> >> uce in Linux.
> >> > =3DC2=3DA0>
> >> > =3DC2=3DA0> Here's an example, any number larger than 16#7ffffffffffff=
> e00 wil=3D
> >> l
> >> > =3DC2=3DA0> cause this error.
> >> > =3DC2=3DA0>
> >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq=
> :4]
> >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true]
> >> > =3DC2=3DA0>
> >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G)
> >> > =3DC2=3DA0> 1> trunc(16#7ffffffffffffdff * 1.0).
> >> > =3DC2=3DA0> 9223372036854774784
> >> > =3DC2=3DA0> 2> trunc(16#7ffffffffffffdff * 1.0).
> >> > =3DC2=3DA0> 9223372036854774784
> >> > =3DC2=3DA0> 3> trunc(16#7ffffffffffffe00 * 1.0).
> >> > =3DC2=3DA0> 9223372036854775808
> >> > =3DC2=3DA0> 4> trunc(16#7ffffffffffffe00 * 1.0).
> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE a=
> t
> >> > =3DC2=3DA0> 0x19223372036854775808
> >> > =3DC2=3DA0> 5> trunc(16#7ffffffffffffe00 * 1.0).
> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE a=
> t
> >> > =3DC2=3DA0> 0x19223372036854775808
> >> > =3DC2=3DA0> 6> io:format("~s~n", [os:cmd("uname -a")]).
> >> > =3DC2=3DA0> Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat J=
> an 29
> >> > =3DC2=3DA0> 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
> >> > =3DC2=3DA0>
> >> > =3DC2=3DA0> Here's another example:
> >> > =3DC2=3DA0>
> >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq=
> :4]
> >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true]
> >> > =3DC2=3DA0>
> >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G)
> >> > =3DC2=3DA0> 1> <<F/float>> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F).
> >> > =3DC2=3DA0> 9223372036854775808
> >> > =3DC2=3DA0> 2> <<F/float>> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F).
> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE a=
> t
> >> > =3DC2=3DA0> 0x19223372036854775808
> >> > =3DC2=3DA0> 3> <<F/float>> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F).
> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE a=
> t
> >> > =3DC2=3DA0> 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. =3DC2=3DA0For that you should probably plant a break=
> point
> >> > 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 =C2=A0and 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.
>
> Not my terminal or email client, this is a bug in
> erts_fp_check_init_error. It only allocates a 64 byte buffer for the
> error message. The pointer address and the \r\n are eaten because the
> buffer is too small to fit the whole error message. buf[64] is too
> small... the format string itself is already 57 chars (including the
> NULL).

Ah yes. I did see your comment about the short buffer but failed
to connect that with the strange message. The buffer needs to be at
least (calculating..) 89 bytes, making it 96 bytes should suffice.

This means that my comment about 0x1 and the wrong type SIGFPE
handler was invalid. (0x1 is used as a fake PC value in that case.)

> Maybe you missed it in my previous email, it's not 0x1, it is
> 0x10025433. I showed that by breaking at the function that prints the
> error.
> Breakpoint 1, erts_fp_check_init_error (fpexnp=3D0x110f2528) at
> sys/unix/sys_float.c:87
> 87      {
> (gdb) p (void*)*fpexnp
> $1 =3D (void *) 0x10025433

In your previous disassembly that pointed to a cvttsd2siq instruction.
That can probably throw a SIGFPE, but I see similar code in a build on
Linux, and there SIGFPE isn't thrown.

If you attach gdb to a freshly started beam instance, let the process
continue, and evaluate one of those expressions at the Erlang prompt,
then gdb should wake up with a SIGFPE at that location.  At that point
dump parts of the SSE2 state with:

print $mxcsr (SSE control and status flags)
print $xmm1 (the source operand in the failing SSE instruction)

(If the first SIGFPE occurs elsewhere, disassemble that code first, then
adjust the print $xmm1 to match that instruction's source operand.)

/Mikael
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

[Bob Ippolito]

On Wed, May 4, 2011 at 1:14 AM, Mikael Pettersson <[hidden email]> wrote:

> On Tue, 3 May 2011 16:48:20 -0700, Bob Ippolito <[hidden email]> wrote:
>> On Tue, May 3, 2011 at 3:35 PM, Mikael Pettersson <[hidden email]> wrote:
>> > On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito <[hidden email]> wrote:
>> >> On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson <[hidden email]> wrote=
>> :
>> >> > Bob Ippolito writes:
>> >> > =3DC2=3DA0> I only see this error on Mac OS X. I have not been able to=
>>  reprod=3D
>> >> uce in Linux.
>> >> > =3DC2=3DA0>
>> >> > =3DC2=3DA0> Here's an example, any number larger than 16#7ffffffffffff=
>> e00 wil=3D
>> >> l
>> >> > =3DC2=3DA0> cause this error.
>> >> > =3DC2=3DA0>
>> >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq=
>> :4]
>> >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true]
>> >> > =3DC2=3DA0>
>> >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G)
>> >> > =3DC2=3DA0> 1> trunc(16#7ffffffffffffdff * 1.0).
>> >> > =3DC2=3DA0> 9223372036854774784
>> >> > =3DC2=3DA0> 2> trunc(16#7ffffffffffffdff * 1.0).
>> >> > =3DC2=3DA0> 9223372036854774784
>> >> > =3DC2=3DA0> 3> trunc(16#7ffffffffffffe00 * 1.0).
>> >> > =3DC2=3DA0> 9223372036854775808
>> >> > =3DC2=3DA0> 4> trunc(16#7ffffffffffffe00 * 1.0).
>> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE a=
>> t
>> >> > =3DC2=3DA0> 0x19223372036854775808
>> >> > =3DC2=3DA0> 5> trunc(16#7ffffffffffffe00 * 1.0).
>> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE a=
>> t
>> >> > =3DC2=3DA0> 0x19223372036854775808
>> >> > =3DC2=3DA0> 6> io:format("~s~n", [os:cmd("uname -a")]).
>> >> > =3DC2=3DA0> Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat J=
>> an 29
>> >> > =3DC2=3DA0> 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
>> >> > =3DC2=3DA0>
>> >> > =3DC2=3DA0> Here's another example:
>> >> > =3DC2=3DA0>
>> >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq=
>> :4]
>> >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true]
>> >> > =3DC2=3DA0>
>> >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G)
>> >> > =3DC2=3DA0> 1> <<F/float>> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F).
>> >> > =3DC2=3DA0> 9223372036854775808
>> >> > =3DC2=3DA0> 2> <<F/float>> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F).
>> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE a=
>> t
>> >> > =3DC2=3DA0> 0x19223372036854775808
>> >> > =3DC2=3DA0> 3> <<F/float>> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F).
>> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE a=
>> t
>> >> > =3DC2=3DA0> 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. =3DC2=3DA0For that you should probably plant a break=
>> point
>> >> > 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 =C2=A0and 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.
>>
>> Not my terminal or email client, this is a bug in
>> erts_fp_check_init_error. It only allocates a 64 byte buffer for the
>> error message. The pointer address and the \r\n are eaten because the
>> buffer is too small to fit the whole error message. buf[64] is too
>> small... the format string itself is already 57 chars (including the
>> NULL).
>
> Ah yes. I did see your comment about the short buffer but failed
> to connect that with the strange message. The buffer needs to be at
> least (calculating..) 89 bytes, making it 96 bytes should suffice.
>
> This means that my comment about 0x1 and the wrong type SIGFPE
> handler was invalid. (0x1 is used as a fake PC value in that case.)
>
>> Maybe you missed it in my previous email, it's not 0x1, it is
>> 0x10025433. I showed that by breaking at the function that prints the
>> error.
>> Breakpoint 1, erts_fp_check_init_error (fpexnp=3D0x110f2528) at
>> sys/unix/sys_float.c:87
>> 87      {
>> (gdb) p (void*)*fpexnp
>> $1 =3D (void *) 0x10025433
>
> In your previous disassembly that pointed to a cvttsd2siq instruction.
> That can probably throw a SIGFPE, but I see similar code in a build on
> Linux, and there SIGFPE isn't thrown.
>
> If you attach gdb to a freshly started beam instance, let the process
> continue, and evaluate one of those expressions at the Erlang prompt,
> then gdb should wake up with a SIGFPE at that location.  At that point
> dump parts of the SSE2 state with:
>
> print $mxcsr (SSE control and status flags)
> print $xmm1 (the source operand in the failing SSE instruction)
>
> (If the first SIGFPE occurs elsewhere, disassemble that code first, then
> adjust the print $xmm1 to match that instruction's source operand.)

Program received signal EXC_ARITHMETIC, Arithmetic exception.
[Switching to process 14985]
double_to_integer [inlined] () at
/Users/bob/src/otp_src_R14B02/erts/emulator/beam/erl_bif_guard.c:301
301 d = x;            /* trunc */
(gdb) info frame
Stack level 0, frame at 0x10:
 rip = 0x10025433 in trunc_1 (beam/erl_bif_guard.c:301); saved rip 0x10025433
 called by frame at 0x0
 source language c.
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp in rsp
(gdb) disassemble 0x0000000010025433
[...]
0x0000000010025433 <trunc_1+371>: cvttsd2siq %xmm1,%rdx
[...]
(gdb) print $mxcsr
$1 = 6433
(gdb) print $xmm1
$2 = {
  v4_float = {0, 0, 448, 0},
  v2_double = {0, 9.2233720368547758e+18},
  v16_int8 = {0, 0, 0, 0, 0, 0, 0, 0, 67, -32, 0, 0, 0, 0, 0, 0},
  v8_int16 = {0, 0, 0, 0, 17376, 0, 0, 0},
  v4_int32 = {0, 0, 1138753536, 0},
  v2_int64 = {0, 4890909195324358656},
  uint128 = 57411
}
(gdb) print $rdx
$3 = 16

-bob
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs