headers
Sebastian Egner | 3 Dec 2007 17:15
Picon

bug in Jinterface sending doubles?

Hello!

There seems to be a bug in Jinterface (from R11B-5) related to sending 
doubles from a Java node to an Erlang node:

=ERROR REPORT==== 3-Dec-2007::16:56:35 ===
Got invalid data on distribution channel, offending packet is: 
<<112,131,104,4,97,6,103,100,0,19,115,112,101,99,115,112,108,97,110,64,103,111,108,100,115,116,111,110,101,0,0,0,1,0,0,0,0,1,100,0,0,100,0,2,102,103,131,104,3,100,0,9,36,103,101,110,95,99,97,108,108,104,2,103,100,0,19,115,112,101,99,115,112,108,97,110,64,103,111,108,100,115,116,111,110,101,0,0,0,1,0,0,0,0,1,114,0,3,100,0,19,115,112,101,99,115,112,108,97,110,64,103,111,108,100,115,116,111,110,101,1,0,0,0,13,0,0,0,0,0,0,0,0,104,3,100,0,7,115,101,116,95,118,97,108,100,0,7,117,101,110,101,114,103,121,99,48,69,45,50,48,101,43,48,48,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>>

My guess is that the offending value, the notorious (double)0.0, is not 
properly encoded by OtpOutputStream.write_double():

 > io:format("~s~n", [TheStuffAboveAsAListOfAsciiValues]).
"blabla...uenergyc0E-20e+00...moreblabla"

Sebastian.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 3 comments |
headers
Raimo Niskanen | 4 Dec 2007 10:11
Picon
Picon

Re: bug in Jinterface sending doubles?

Indeed there is (a bug).

In the upcoming R12B release, Jinterface has been updated to
use IEEE term format for Erlang marshalled data, so this
bug should have vanished. We also now have at least one
test case that echoes 0.0 (and other interesting floats)
from Erlang via Jinterface.

We had no such test case in R11B-5, and that was bad.

The Jinterface code used java.math.BigDecimal and
java.text.DecimalFormat to do the old (daft) marshalling
that was based on C:s sprintf("%.20e", ...).
It was written for Java 1.2.

You seem to have run into a borderline case where
	d = roughly(0.0);
	BigDecimal b = new BigDecimal(d);
	b.signum() returns 0
	b = b.setScale(20,BigDecimal.ROUND_HALF_EVEN);
	b.toString() returns "0E-20" even though
	             b.signum() returned 0 above
So, since signum() is 0 b should be zero but
toString() returns "0E-20" with setScale(20,...)
sugessting v is just almost zero. toString() was
supposed to return "0.00000000000000000000".

Apparently in  Java 1.3 java.math.BigDecimal(double d)
changed behaviour to allow optional exponent sign.
Perhaps something else changed too...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sebastian Egner | 4 Dec 2007 14:03
Picon

Re: bug in Jinterface sending doubles?

Hello!

Thanks for fixing it. Looking forward to R12, and using the following 
kludge until then:

    return OtpErlangDouble(value == 0 ? 1.0e-20 : value);

Cheers,

Sebastian.

Raimo Niskanen wrote:
> Indeed there is (a bug).
>
> In the upcoming R12B release, Jinterface has been updated to
> use IEEE term format for Erlang marshalled data, so this
> bug should have vanished. We also now have at least one
> test case that echoes 0.0 (and other interesting floats)
> from Erlang via Jinterface.
>
> We had no such test case in R11B-5, and that was bad.
>
> The Jinterface code used java.math.BigDecimal and
> java.text.DecimalFormat to do the old (daft) marshalling
> that was based on C:s sprintf("%.20e", ...).
> It was written for Java 1.2.
>
> You seem to have run into a borderline case where
> 	d = roughly(0.0);
> 	BigDecimal b = new BigDecimal(d);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Serge Aleynikov | 5 Dec 2007 01:56
Picon

Re: bug in Jinterface sending doubles?

Did the ei get updated with IEEE format for doubles as well?  It's quite 
a waste to have them presently encoded using 32 bytes or more...

Raimo Niskanen wrote:
> Indeed there is (a bug).
> 
> In the upcoming R12B release, Jinterface has been updated to
> use IEEE term format for Erlang marshalled data, so this
> bug should have vanished. We also now have at least one
> test case that echoes 0.0 (and other interesting floats)
> from Erlang via Jinterface.
> 
> We had no such test case in R11B-5, and that was bad.
> 
> The Jinterface code used java.math.BigDecimal and
> java.text.DecimalFormat to do the old (daft) marshalling
> that was based on C:s sprintf("%.20e", ...).
> It was written for Java 1.2.
> 
> You seem to have run into a borderline case where
> 	d = roughly(0.0);
> 	BigDecimal b = new BigDecimal(d);
> 	b.signum() returns 0
> 	b = b.setScale(20,BigDecimal.ROUND_HALF_EVEN);
> 	b.toString() returns "0E-20" even though
> 	             b.signum() returned 0 above
> So, since signum() is 0 b should be zero but
> toString() returns "0E-20" with setScale(20,...)
> sugessting v is just almost zero. toString() was
> supposed to return "0.00000000000000000000".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oleg Avdeev | 7 Dec 2007 23:29
Picon
Favicon

Bug in binary append?

Hello,

Seems that there's a bug in R12, while compiling

%%
% get_tail(Bin, Tail, Len)
% Return last Len bytes of <<Bin, Tail>>
get_tail(Bin, Tail, Len) when size(Bin) + size(Tail) < Len->
    <<Tail/binary, Bin/binary>>
    ;

get_tail(Bin, Tail, Len) when size(Bin) < Len ->
    L = size(Tail) - (Len - size(Bin)),
    <<_:L/binary, Tail1/binary>> = Tail,
    <<Tail1/binary, Bin/binary>>;

get_tail(Bin, Tail, Len) ->
        S = size(Bin) - Len,
        case Bin of
            <<_:S/binary, NewTail:Len/binary>> ->
                NewTail;
            _ ->
                <<Tail/binary, Bin/binary>>
        end.

I get an error

$ erlc -W r12_test.erl
r12_test: function get_tail/3+29:
  Internal consistency check failed - please report this bug.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bjorn Gustavsson | 8 Dec 2007 09:04
Picon
Picon

Re: Bug in binary append?

"Oleg Avdeev" <oavdeev <at> acm.org> writes:

> Hello,
> 
> Seems that there's a bug in R12, while compiling

Thanks for the bug report.

The following patch fixes the problem.

/Bjorn

*** lib/compiler/src/beam_bsm.erl <at>  <at> /OTP_R12B    Mon Nov 26 20:01:52 2007
--- lib/compiler/src/beam_bsm.erl       Sat Dec  8 08:21:27 2007
***************
*** 269,277 ****
      btb_reaches_match_1(Is, btb_kill([Dst], Regs), D);
  btb_reaches_match_2([{bs_init_bits,{f,0},_,_,_,_,Dst}|Is], Regs, D) ->
      btb_reaches_match_1(Is, btb_kill([Dst], Regs), D);
! btb_reaches_match_2([{bs_append,{f,0},_,_,_,_,_,_,Dst}|Is], Regs, D) ->
      btb_reaches_match_1(Is, btb_kill([Dst], Regs), D);
! btb_reaches_match_2([{bs_private_append,{f,0},_,_,_,_,Dst}|Is], Regs, D) ->
      btb_reaches_match_1(Is, btb_kill([Dst], Regs), D);
  btb_reaches_match_2([{bs_put_integer,{f,0},_,_,_,_}|Is], Regs, D) ->
      btb_reaches_match_1(Is, Regs, D);
--- 269,279 ----
      btb_reaches_match_1(Is, btb_kill([Dst], Regs), D);
  btb_reaches_match_2([{bs_init_bits,{f,0},_,_,_,_,Dst}|Is], Regs, D) ->
      btb_reaches_match_1(Is, btb_kill([Dst], Regs), D);
! btb_reaches_match_2([{bs_append,{f,0},_,_,_,_,Src,_,Dst}=I|Is], Regs, D) ->
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Mineiro | 9 Dec 2007 05:33

mnesia-4.3.5 select continuation problem

mnesia:select/4 and mnesia:select/1 are failing with ordered set tables
and a tuple key pattern.  a little module demonstrating the effect is
attached, the output (on my machine) is:

-------
21> c (selectbug), selectbug:showbug ().
{a,'$1'} set: {atomic,'$end_of_table'}
{a,'$1'} ordered_set: {'EXIT',
                          {{badmatch,
                               {aborted,
                                   {badarg,
                                       [ram_copies,
                                        {bug,{a,b},{a,'$1'},1,<<>>,[],0,0},
                                        [{{'_',{a,'$1'},'_'},[],['$1']}]]}}},
                           [{selectbug,selector,2},
                            {selectbug,'-showbug/0-fun-0-',1},
                            {lists,foreach,2},
                            {erl_eval,do_apply,5},
                            {shell,exprs,6},
                            {shell,eval_loop,3}]}}
{a,'$1'} bag: {atomic,'$end_of_table'}
'$1' set: {atomic,'$end_of_table'}
'$1' ordered_set: {atomic,'$end_of_table'}
'$1' bag: {atomic,'$end_of_table'}
ok
-------

looking at things, it looks like ets:repair_continuation/2 is expecting
a list in the 3rd element of the first argument.  i put an io:format on
the { badrpc, Reason } clause of mnesia:do_dirty_rpc/5 to print out the
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Mineiro | 9 Dec 2007 05:51

Re: mnesia-4.3.5 select continuation problem

by the way, my immediate problem goes away if i just remove the offending
guard (so i'm good for today!).  however i have no idea if this is the
correct way to fix the problem.

-------
pmineiro <at> paul-mineiros-computer-8% diff -u ets.erl.orig ets.erl
--- ets.erl.orig        2007-12-08 20:48:53.000000000 -0800
+++ ets.erl     2007-12-08 20:48:55.000000000 -0800
 <at>  <at>  -88,7 +88,7  <at>  <at> 
 % ordered_set
 repair_continuation(Untouched = {Table,Lastkey,L1,N2,Bin,L2,N3,N4}, MS)
when
 (is_atom(Table) or is_integer(Table)),
-is_list(L1),
+%is_list(L1),
 is_integer(N2),
 is_binary(Bin),
 size(Bin) =:= 0,

-------

-- p

On Sat, 8 Dec 2007, Paul Mineiro wrote:

> mnesia:select/4 and mnesia:select/1 are failing with ordered set tables
> and a tuple key pattern.  a little module demonstrating the effect is
> attached, the output (on my machine) is:
>
> -------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Maximillian Dornseif | 9 Dec 2007 09:08
Picon
Gravatar

Floating point exception (core dumped) in beam


I wonder how to debug something like this (on FreeBSD):

Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [hipe]

Eshell V5.5.5  (abort with ^G)
(mypl_produktion <at> airvent)1>
mypl_provpipeline:update_pipeline({versandtermin, "931631", "2007-10-14"}).
Floating point exception (core dumped)

Am I correct to assume that this is an Error in the Emulator and not in my
code? Where to start looking?

Regards

Maximillian
--

-- 
View this message in context: http://www.nabble.com/Floating-point-exception-%28core-dumped%29-in-beam-tp14208305p14208305.html
Sent from the Erlang Bugs mailing list archive at Nabble.com.

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |
headers
Mikael Pettersson | 9 Dec 2007 15:58
Picon
Picon
Favicon

Re: Floating point exception (core dumped) in beam

On Sun, 9 Dec 2007 00:08:04 -0800 (PST), Maximillian Dornseif wrote:
> I wonder how to debug something like this (on FreeBSD):
> 
> Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [hipe]
> 
> Eshell V5.5.5  (abort with ^G)
> (mypl_produktion <at> airvent)1>
> mypl_provpipeline:update_pipeline({versandtermin, "931631", "2007-10-14"}).
> Floating point exception (core dumped)
> 
> 
> Am I correct to assume that this is an Error in the Emulator and not in my
> code? Where to start looking?

Which system is this? R11B-5? And the version of FreeBSD is what?
And the CPU is what?

Beam should never crash due to an FP exception.

The first step is to run gdb on the core dump and display the
current context (stack trace and registers).
If you don't have a core dump, you can attach gdb to the beam
process before the error, and then trigger the error.

When you built the system, did ./configure detect "reliable
floating-point exceptions" or not?

It would also be helpful if you can provide a small self-contained
erlang module that triggers the bug.
_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |

Gmane