From s.egner@REDACTED Mon Dec 3 17:15:30 2007 From: s.egner@REDACTED (Sebastian Egner) Date: Mon, 03 Dec 2007 17:15:30 +0100 Subject: [erlang-bugs] bug in Jinterface sending doubles? In-Reply-To: <46E7DD7B.8010909@specs.de> References: <46E7DD7B.8010909@specs.de> Message-ID: <47542BA2.9070500@specs.de> 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. From raimo+erlang-bugs@REDACTED Tue Dec 4 10:11:56 2007 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Tue, 4 Dec 2007 10:11:56 +0100 Subject: [erlang-bugs] bug in Jinterface sending doubles? In-Reply-To: <47542BA2.9070500@specs.de> References: <46E7DD7B.8010909@specs.de> <47542BA2.9070500@specs.de> Message-ID: <20071204091156.GA29012@erix.ericsson.se> 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... Anyway... the bug should be gone in R12B. On Mon, Dec 03, 2007 at 05:15:30PM +0100, Sebastian Egner wrote: > 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@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From s.egner@REDACTED Tue Dec 4 14:03:44 2007 From: s.egner@REDACTED (Sebastian Egner) Date: Tue, 04 Dec 2007 14:03:44 +0100 Subject: [erlang-bugs] bug in Jinterface sending doubles? In-Reply-To: <20071204091156.GA29012@erix.ericsson.se> References: <46E7DD7B.8010909@specs.de> <47542BA2.9070500@specs.de> <20071204091156.GA29012@erix.ericsson.se> Message-ID: <47555030.6070702@specs.de> 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); > 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... > > Anyway... the bug should be gone in R12B. > > > > On Mon, Dec 03, 2007 at 05:15:30PM +0100, Sebastian Egner wrote: > >> 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@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs >> > > -- Dr. Sebastian Egner Head of Software & Electronics Development SPECS GmbH Voltastr. 5 13355 Berlin Germany Phone: +49 (0)30 46 78 24 - 9210 Fax: +49 (0)30 46 42 083 E-Mail: s.egner@REDACTED Please visit www.specs.de SPECS - YOUR COMPETENT PARTNER IN SURFACE ANALYSIS ---------------------------------------------------- SPECS Gesellschaft f?r Oberfl?chenanalytik und Computertechnologie mbH, CEO: Reinhard Lembke Registered Office: Berlin Companies Commercial Register No.: 93 HRB 21390 Register Court: Charlottenburg ----------------------------------------------------- This e-mail contains confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From saleyn@REDACTED Wed Dec 5 01:56:07 2007 From: saleyn@REDACTED (Serge Aleynikov) Date: Tue, 04 Dec 2007 19:56:07 -0500 Subject: [erlang-bugs] bug in Jinterface sending doubles? In-Reply-To: <20071204091156.GA29012@erix.ericsson.se> References: <46E7DD7B.8010909@specs.de> <47542BA2.9070500@specs.de> <20071204091156.GA29012@erix.ericsson.se> Message-ID: <4755F727.6070805@gmail.com> 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". > > Apparently in Java 1.3 java.math.BigDecimal(double d) > changed behaviour to allow optional exponent sign. > Perhaps something else changed too... > > Anyway... the bug should be gone in R12B. > > > > On Mon, Dec 03, 2007 at 05:15:30PM +0100, Sebastian Egner wrote: >> 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@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs > From oavdeev@REDACTED Fri Dec 7 23:29:33 2007 From: oavdeev@REDACTED (Oleg Avdeev) Date: Sat, 8 Dec 2007 01:29:33 +0300 Subject: [erlang-bugs] Bug in binary append? Message-ID: <40738b950712071429m424ebccal1fb3fe13a0f8652e@mail.gmail.com> Hello, Seems that there's a bug in R12, while compiling %% % get_tail(Bin, Tail, Len) % Return last Len bytes of <> get_tail(Bin, Tail, Len) when size(Bin) + size(Tail) < Len-> <> ; get_tail(Bin, Tail, Len) when size(Bin) < Len -> L = size(Tail) - (Len - size(Bin)), <<_:L/binary, Tail1/binary>> = Tail, <>; get_tail(Bin, Tail, Len) -> S = size(Bin) - Len, case Bin of <<_:S/binary, NewTail:Len/binary>> -> NewTail; _ -> <> 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. Instruction: {bs_append,{f,0},{x,2},0,2,8,{x,1},{field_flags,[]},{x,2}} Error: {match_context,{x,1}}: In R11 this code compiles ok. Best Regards, Oleg. From bjorn@REDACTED Sat Dec 8 09:04:54 2007 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 08 Dec 2007 09:04:54 +0100 Subject: [erlang-bugs] Bug in binary append? In-Reply-To: <40738b950712071429m424ebccal1fb3fe13a0f8652e@mail.gmail.com> References: <40738b950712071429m424ebccal1fb3fe13a0f8652e@mail.gmail.com> Message-ID: "Oleg Avdeev" 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@@/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) -> ! btb_ensure_not_used([Src], I, Regs), btb_reaches_match_1(Is, btb_kill([Dst], Regs), D); ! btb_reaches_match_2([{bs_private_append,{f,0},_,_,Src,_,Dst}=I|Is], Regs, D) -> ! btb_ensure_not_used([Src], I, Regs), 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); -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From paul-trapexit@REDACTED Sun Dec 9 05:33:04 2007 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Sat, 8 Dec 2007 20:33:04 -0800 (PST) Subject: [erlang-bugs] mnesia-4.3.5 select continuation problem Message-ID: 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 reason: ------- {'EXIT',{function_clause,[{ets,repair_continuation, [{bug,{a,b},{a,'$1'},1,<<>>,[],0,0}, [{{'_',{a,'$1'},'_'},[],['$1']}]]}, {mnesia_lib,db_select_cont,3}, {rpc,local_call,3}, {mnesia,do_dirty_rpc,5}, {mnesia,select_cont,3}, {mnesia_tm,apply_fun,3}, {mnesia_tm,execute_transaction,5}, {selectbug,selector,2}]}} ------ the 3rd element is a tuple here. poking around i can see that the ets:select/3 call from mnesia_lib:db_select_init/4 is actually returning a continuation whose 3rd argument is not a list. this is now a BIF so i feel a bit stuck at this point. since it's a BIF here's some extra info: ------ pmineiro@REDACTED% erl -s erlang halt Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false] pmineiro@REDACTED% dpkg -s erlang-otp Package: erlang-otp Status: install ok installed Priority: optional Section: languages Installed-Size: 139084 Maintainer: None Architecture: darwin-i386 Source: erlang-otp Version: 11b-5-1 Depends: libncurses5-shlibs, unixodbc2-shlibs | unixodbc2-nox-shlibs, darwin (>= 8-1) Description: General-purpose programming language Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance. Erlang is used in several large telecommunication systems from Ericsson. The most popular implementation of Erlang is available as open source from the open source erlang site. . Web site: http://www.erlang.org/ . Maintainer: None BuildDependsOnly: Undefined pmineiro@REDACTED% uname -a Darwin paul-mineiros-computer.local 8.9.3 Darwin Kernel Version 8.9.3: Fri Apr 27 14:50:07 PDT 2007; root:xnu-792.19.5~2/RELEASE_I386 i386 i386 ------ thanks, -- p Optimism is an essential ingredient of innovation. How else can the individual favor change over security? -- Robert Noyce -------------- next part -------------- -module (selectbug). -export ([ showbug/0 ]). showbug () -> mnesia:start (), lists:foreach (fun ({ KeyPat, Type }) -> io:format ("~p ~p: ~p~n", [ KeyPat, Type, catch selector (KeyPat, Type) ]) end, [ { X, Y } || X <- [ { a, '$1' }, '$1' ], Y <- [ set, ordered_set, bag ] ]). selector (KeyPattern, Type) -> { atomic, ok } = mnesia:create_table (bug, [ { type, Type } ]), ok = mnesia:dirty_write ({ bug, { a, b }, c }), try { atomic, '$end_of_table' } = mnesia:transaction ( fun () -> { _Objects, Cont } = mnesia:select (bug, [ { { '_', KeyPattern, '_' }, [], [ '$1' ] } ], 1, read), % This causes aborted transaction mnesia:select (Cont) end) after mnesia:delete_table (bug) end. From paul-trapexit@REDACTED Sun Dec 9 05:51:12 2007 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Sat, 8 Dec 2007 20:51:12 -0800 (PST) Subject: [erlang-bugs] mnesia-4.3.5 select continuation problem In-Reply-To: References: Message-ID: 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@REDACTED% 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 @@ -88,7 +88,7 @@ % 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: > > ------- > 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 > reason: > > ------- > {'EXIT',{function_clause,[{ets,repair_continuation, > [{bug,{a,b},{a,'$1'},1,<<>>,[],0,0}, > [{{'_',{a,'$1'},'_'},[],['$1']}]]}, > {mnesia_lib,db_select_cont,3}, > {rpc,local_call,3}, > {mnesia,do_dirty_rpc,5}, > {mnesia,select_cont,3}, > {mnesia_tm,apply_fun,3}, > {mnesia_tm,execute_transaction,5}, > {selectbug,selector,2}]}} > ------ > > the 3rd element is a tuple here. > > poking around i can see that the ets:select/3 call from > mnesia_lib:db_select_init/4 is actually returning a continuation whose 3rd > argument is not a list. this is now a BIF so i feel a bit stuck at this > point. since it's a BIF here's some extra info: > > ------ > pmineiro@REDACTED% erl -s erlang halt > Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false] > > pmineiro@REDACTED% dpkg -s erlang-otp > Package: erlang-otp > Status: install ok installed > Priority: optional > Section: languages > Installed-Size: 139084 > Maintainer: None > Architecture: darwin-i386 > Source: erlang-otp > Version: 11b-5-1 > Depends: libncurses5-shlibs, unixodbc2-shlibs | unixodbc2-nox-shlibs, darwin (>= 8-1) > Description: General-purpose programming language > Erlang is a general-purpose programming language and runtime environment. > Erlang has built-in support for concurrency, distribution and fault > tolerance. Erlang is used in several large telecommunication systems > from Ericsson. The most popular implementation of Erlang is available as > open source from the open source erlang site. > . > Web site: http://www.erlang.org/ > . > Maintainer: None > BuildDependsOnly: Undefined > > pmineiro@REDACTED% uname -a > Darwin paul-mineiros-computer.local 8.9.3 Darwin Kernel Version 8.9.3: Fri Apr 27 14:50:07 PDT 2007; root:xnu-792.19.5~2/RELEASE_I386 i386 i386 > > ------ > > thanks, > > -- p > > Optimism is an essential ingredient of innovation. How else can the > individual favor change over security? > > -- Robert Noyce Optimism is an essential ingredient of innovation. How else can the individual favor change over security? -- Robert Noyce From md@REDACTED Sun Dec 9 09:08:04 2007 From: md@REDACTED (Maximillian Dornseif) Date: Sun, 9 Dec 2007 00:08:04 -0800 (PST) Subject: [erlang-bugs] Floating point exception (core dumped) in beam Message-ID: <14208305.post@talk.nabble.com> 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@REDACTED)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. From mikpe@REDACTED Sun Dec 9 15:58:10 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Sun, 9 Dec 2007 15:58:10 +0100 (MET) Subject: [erlang-bugs] Floating point exception (core dumped) in beam Message-ID: <200712091458.lB9EwACa018948@harpo.it.uu.se> 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@REDACTED)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. From md@REDACTED Sun Dec 9 21:39:37 2007 From: md@REDACTED (Maximillian Dornseif) Date: Sun, 9 Dec 2007 12:39:37 -0800 (PST) Subject: [erlang-bugs] Floating point exception (core dumped) in beam In-Reply-To: <200712091458.lB9EwACa018948@harpo.it.uu.se> References: <14208305.post@talk.nabble.com> <200712091458.lB9EwACa018948@harpo.it.uu.se> Message-ID: <14243025.post@talk.nabble.com> Mikael Pettersson-3 wrote: > > Which system is this? R11B-5? And the version of FreeBSD is what? > And the CPU is what? > FreeBSD airvent.XXX 5.4-RELEASE FreeBSD 5.4-RELEASE #1: Sat Aug 13 11:11:43 CEST 2005 root@REDACTED:/usr/src/sys/i386/compile/AIRVENT i386 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.20-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 3220963328 (3071 MB) avail memory = 3154833408 (3008 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 Erlang is compiled from "ports", labeled by FreeBSD as "erlang-r11b5,1". The tarball was named "otp_src_R11B-5" Configure says: checking for unreliable floating point execptions... reliable Mikael Pettersson-3 wrote: > > 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. > root@REDACTED:/usr/local/kernelE $ gdb /usr/local/lib/erlang/erts-5.5.5/bin/beam -c beam.core GNU gdb 6.1.1 [FreeBSD] 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 "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `beam'. Program terminated with signal 8, Arithmetic exception. Reading symbols from /lib/libutil.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.4 Reading symbols from /lib/libm.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.3 Reading symbols from /usr/lib/libpthread.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libc.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.5 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x281a731b in pthread_testcancel () from /usr/lib/libpthread.so.1 (gdb) where #0 0x281a731b in pthread_testcancel () from /usr/lib/libpthread.so.1 #1 0x2819f902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #2 0x00000000 in ?? () (gdb) thread apply all bt Thread 4 (LWP 101555): #0 0x281a72fb in pthread_testcancel () from /usr/lib/libpthread.so.1 #1 0x2819f902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #2 0x00000000 in ?? () Thread 3 (Thread 3 (runnable)): #0 0x0812320f in ethr_sigwait () #1 0x08124398 in erts_printf_double () #2 0x0809f423 in null_func () #3 0x0809f3a0 in null_func () #4 0x0809f2a4 in null_func () #5 0x0809f3a0 in null_func () #6 0x0809f7ed in erts_printf_term () #7 0x08123ffb in erts_printf_format () #8 0x08124697 in erts_printf () #9 0x080973d4 in display_1 () #10 0x080dc618 in process_main () #11 0x0807aa9d in erl_start () #12 0x08069047 in main () Thread 2 (Thread 2 (LWP 101265)): #0 0x281a72fb in pthread_testcancel () from /usr/lib/libpthread.so.1 #1 0x2819f902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #2 0x00000000 in ?? () Thread 1 (Thread 1 (LWP 101210)): #0 0x281a72fb in pthread_testcancel () from /usr/lib/libpthread.so.1 #1 0x2819f7fb in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #2 0x2819f1ca in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #3 0x2819f169 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #4 0x281a4bc9 in _pthread_cond_wait () from /usr/lib/libpthread.so.1 #5 0x281a4dee in pthread_cond_wait () from /usr/lib/libpthread.so.1 #6 0x081226a1 in ethr_cond_wait () #7 0x080f9e9a in erts_check_io_debug () #8 0x08122052 in ethr_install_exit_handler () #9 0x2819f902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #10 0x00000000 in ?? () #0 0x281a72fb in pthread_testcancel () from /usr/lib/libpthread.so.1 (gdb) info all-registers eax 0x17e 382 ecx 0x7 7 edx 0x0 0 ebx 0x281aa4bc 672834748 esp 0x88dff90 0x88dff90 ebp 0x88dffbc 0x88dffbc esi 0x81a8000 135954432 edi 0x8 8 eip 0x281a731b 0x281a731b eflags 0x206 518 cs 0x1f 31 ss 0x2f 47 ds 0x2f 47 es 0x2f 47 fs 0x2f 47 gs 0xaf 175 st0 0 (raw 0x00000000000000000000) st1 0 (raw 0x00000000000000000000) st2 0.920218317769467830657958984375 (raw 0x3ffeeb936d7c00000000) st3 17.484148037619888782501220703125 (raw 0x40038bdf8901a0000000) st4 0 (raw 0x00000000000000000000) st5 1 (raw 0x3fff8000000000000000) st6 2 (raw 0x40008000000000000000) st7 16.5 (raw 0x40038400000000000000) fctrl 0x1272 4722 fstat 0x4020 16416 ftag 0x0 0 fiseg 0x1f 31 fioff 0x81133c6 135345094 foseg 0x2f 47 fooff 0x81a8d0c 135957772 fop 0x1c9 457 xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = { 0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, ---Type to continue, or q to quit--- 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = { 0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = { 0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = { 0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = { 0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = { 0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = { 0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = { 0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} mxcsr 0x0 0 mm0 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm1 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm2 {uint64 = 0xeb936d7c00000000, v2_int32 = {0x0, 0xeb936d7c}, v4_int16 = {0x0, 0x0, 0x6d7c, 0xeb93}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x7c, 0x6d, 0x93, 0xeb}} mm3 {uint64 = 0x8bdf8901a0000000, v2_int32 = {0xa0000000, 0x8bdf8901}, v4_int16 = {0x0, 0xa000, 0x8901, 0x8bdf}, v8_int8 = {0x0, 0x0, 0x0, 0xa0, 0x1, 0x89, 0xdf, 0x8b}} mm4 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm5 {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000}, v4_int16 = {0x0, 0x0, 0x0, ---Type to continue, or q to quit--- 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x80}} mm6 {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000}, v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x80}} mm7 {uint64 = 0x8400000000000000, v2_int32 = {0x0, 0x84000000}, v4_int16 = {0x0, 0x0, 0x0, 0x8400}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x84}} (gdb) info float R7: Valid 0x40038400000000000000 +16.5 R6: Valid 0x40008000000000000000 +2 R5: Valid 0x3fff8000000000000000 +1 R4: Valid 0x00000000000000000000 +0 R3: Valid 0x40038bdf8901a0000000 +17.48414803761988878 R2: Valid 0x3ffeeb936d7c00000000 +0.9202183177694678307 R1: Valid 0x00000000000000000000 +0 =>R0: Valid 0x00000000000000000000 +0 Status Word: 0x4020 PE C3 TOP: 0 Control Word: 0x1272 DM UM PM PC: Double Precision (53-bits) RC: Round to nearest Tag Word: 0x0000 Instruction Pointer: 0x1f:0x081133c6 Operand Pointer: 0x2f:0x081a8d0c Opcode: 0xd9c9 Mikael Pettersson-3 wrote: > > It would also be helpful if you can provide a small self-contained > erlang module that triggers the bug. > Tthis happened on a production machine and fortunately the error occurred only during maintenance. So far I was unable to get a sufficiently small code and dataset to demonstrate it. The function which triggered the crash was this: update_pipeline({versandtermin, CId, Versandtermin}) -> Fun = fun() -> [PPEntry] = mnesia:read({provpipeline, CId}), NewAttributes = [{kernel_updated_at, calendar:universal_time()}| proplists:delete(versandtermin, PPEntry#provpipeline.attributes)], mnesia:write(PPEntry#provpipeline{attributes=[{versandtermin, Versandtermin}|NewAttributes]}), erlang:display({CId, mnesia:read({provpipeline, CId})}) end, mypl_db_util:transaction(Fun), ok. provpipeline is defined like this: % orders to be provisioned -record(provpipeline, {id, priority, % the higher the number the higher the priority orderlines, weigth, volume, status, % new, processing, provisioned tries, % how often we tried to find a match for that pick provisioninglists, % retrievallists and picklists attributes % propertylist }). volume usually contains floating point values. Interestingly I can use erlang:display/1 to trigger the issue: (mypl_produktion@REDACTED)2> mnesia:dirty_read({provpipeline, "931631"}). [{provpipeline,"931631", 5, [{191,"71575",[["gewicht",0],["auftragsposition",1]]}], 0, 0.00000e+0, new, 8, [], [{kernel_customer,"28000"}, {kernel_enqueued_at,{{2007,12,6},{20,51,18}}}, {auftragsnummer,"649496"}, {liefertermin,"2007-12-10"}]}] (mypl_produktion@REDACTED)3> erlang:display(mnesia:dirty_read({provpipeline, "931631"})). Floating point exception (core dumped) Regards Maximillian -- View this message in context: http://www.nabble.com/Floating-point-exception-%28core-dumped%29-in-beam-tp14208305p14243025.html Sent from the Erlang Bugs mailing list archive at Nabble.com. From mikpe@REDACTED Sun Dec 9 22:42:43 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Sun, 9 Dec 2007 22:42:43 +0100 (MET) Subject: [erlang-bugs] Floating point exception (core dumped) in beam Message-ID: <200712092142.lB9LghZD020911@harpo.it.uu.se> On Sun, 9 Dec 2007 12:39:37 -0800 (PST), Maximillian Dornseif wrote: > #0 0x281a731b in pthread_testcancel () from /usr/lib/libpthread.so.1 > > (gdb) where > #0 0x281a731b in pthread_testcancel () from /usr/lib/libpthread.so.1 > #1 0x2819f902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 > #2 0x00000000 in ?? () > > (gdb) thread apply all bt > Thread 4 (LWP 101555): > #0 0x281a72fb in pthread_testcancel () from /usr/lib/libpthread.so.1 > #1 0x2819f902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 > #2 0x00000000 in ?? () > > Thread 3 (Thread 3 (runnable)): > #0 0x0812320f in ethr_sigwait () > #1 0x08124398 in erts_printf_double () > #2 0x0809f423 in null_func () > #3 0x0809f3a0 in null_func () > #4 0x0809f2a4 in null_func () > #5 0x0809f3a0 in null_func () > #6 0x0809f7ed in erts_printf_term () > #7 0x08123ffb in erts_printf_format () > #8 0x08124697 in erts_printf () > #9 0x080973d4 in display_1 () > #10 0x080dc618 in process_main () > #11 0x0807aa9d in erl_start () > #12 0x08069047 in main () > > Thread 2 (Thread 2 (LWP 101265)): > #0 0x281a72fb in pthread_testcancel () from /usr/lib/libpthread.so.1 > #1 0x2819f902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 > #2 0x00000000 in ?? () > > Thread 1 (Thread 1 (LWP 101210)): > #0 0x281a72fb in pthread_testcancel () from /usr/lib/libpthread.so.1 > #1 0x2819f7fb in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 > #2 0x2819f1ca in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 > #3 0x2819f169 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 > #4 0x281a4bc9 in _pthread_cond_wait () from /usr/lib/libpthread.so.1 > #5 0x281a4dee in pthread_cond_wait () from /usr/lib/libpthread.so.1 > #6 0x081226a1 in ethr_cond_wait () > #7 0x080f9e9a in erts_check_io_debug () > #8 0x08122052 in ethr_install_exit_handler () > #9 0x2819f902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 > #10 0x00000000 in ?? () > #0 0x281a72fb in pthread_testcancel () from /usr/lib/libpthread.so.1 > > (gdb) info all-registers > eax 0x17e 382 > ecx 0x7 7 > edx 0x0 0 > ebx 0x281aa4bc 672834748 > esp 0x88dff90 0x88dff90 > ebp 0x88dffbc 0x88dffbc > esi 0x81a8000 135954432 > edi 0x8 8 > eip 0x281a731b 0x281a731b > eflags 0x206 518 The crash appears to happen at EIP 0x281a731b in pthread_testcancel(). Can you disassemble pthread_testcancel() up to and including the instruction at 0x281a731b? From dgud@REDACTED Mon Dec 10 13:49:53 2007 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 10 Dec 2007 13:49:53 +0100 Subject: [erlang-bugs] mnesia-4.3.5 select continuation problem In-Reply-To: References: Message-ID: <475D35F1.8060803@erix.ericsson.se> Thank you, it is indeed an ets bug. I filed a report with ID: OTP-7025 /Dan Paul Mineiro wrote: > 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@REDACTED% 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 > @@ -88,7 +88,7 @@ > % 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: >> >> ------- >> 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 >> reason: >> >> ------- >> {'EXIT',{function_clause,[{ets,repair_continuation, >> [{bug,{a,b},{a,'$1'},1,<<>>,[],0,0}, >> [{{'_',{a,'$1'},'_'},[],['$1']}]]}, >> {mnesia_lib,db_select_cont,3}, >> {rpc,local_call,3}, >> {mnesia,do_dirty_rpc,5}, >> {mnesia,select_cont,3}, >> {mnesia_tm,apply_fun,3}, >> {mnesia_tm,execute_transaction,5}, >> {selectbug,selector,2}]}} >> ------ >> >> the 3rd element is a tuple here. >> >> poking around i can see that the ets:select/3 call from >> mnesia_lib:db_select_init/4 is actually returning a continuation whose 3rd >> argument is not a list. this is now a BIF so i feel a bit stuck at this >> point. since it's a BIF here's some extra info: >> >> ------ >> pmineiro@REDACTED% erl -s erlang halt >> Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false] >> >> pmineiro@REDACTED% dpkg -s erlang-otp >> Package: erlang-otp >> Status: install ok installed >> Priority: optional >> Section: languages >> Installed-Size: 139084 >> Maintainer: None >> Architecture: darwin-i386 >> Source: erlang-otp >> Version: 11b-5-1 >> Depends: libncurses5-shlibs, unixodbc2-shlibs | unixodbc2-nox-shlibs, darwin (>= 8-1) >> Description: General-purpose programming language >> Erlang is a general-purpose programming language and runtime environment. >> Erlang has built-in support for concurrency, distribution and fault >> tolerance. Erlang is used in several large telecommunication systems >> from Ericsson. The most popular implementation of Erlang is available as >> open source from the open source erlang site. >> . >> Web site: http://www.erlang.org/ >> . >> Maintainer: None >> BuildDependsOnly: Undefined >> >> pmineiro@REDACTED% uname -a >> Darwin paul-mineiros-computer.local 8.9.3 Darwin Kernel Version 8.9.3: Fri Apr 27 14:50:07 PDT 2007; root:xnu-792.19.5~2/RELEASE_I386 i386 i386 >> >> ------ >> >> thanks, >> >> -- p >> >> Optimism is an essential ingredient of innovation. How else can the >> individual favor change over security? >> >> -- Robert Noyce > > Optimism is an essential ingredient of innovation. How else can the > individual favor change over security? > > -- Robert Noyce > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From dgud@REDACTED Mon Dec 10 17:19:03 2007 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 10 Dec 2007 17:19:03 +0100 Subject: [erlang-bugs] mnesia-4.3.5 select continuation problem In-Reply-To: <475D35F1.8060803@erix.ericsson.se> References: <475D35F1.8060803@erix.ericsson.se> Message-ID: <475D66F7.8030103@erix.ericsson.se> And Patrik^D^D^D the author says that your patch is correct, it will be included in the next release. /Dan Dan Gudmundsson wrote: > Thank you, it is indeed an ets bug. > I filed a report with ID: OTP-7025 > > /Dan > > Paul Mineiro wrote: >> 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@REDACTED% 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 >> @@ -88,7 +88,7 @@ >> % 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: >>> >>> ------- >>> 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 >>> reason: >>> >>> ------- >>> {'EXIT',{function_clause,[{ets,repair_continuation, >>> [{bug,{a,b},{a,'$1'},1,<<>>,[],0,0}, >>> [{{'_',{a,'$1'},'_'},[],['$1']}]]}, >>> {mnesia_lib,db_select_cont,3}, >>> {rpc,local_call,3}, >>> {mnesia,do_dirty_rpc,5}, >>> {mnesia,select_cont,3}, >>> {mnesia_tm,apply_fun,3}, >>> {mnesia_tm,execute_transaction,5}, >>> {selectbug,selector,2}]}} >>> ------ >>> >>> the 3rd element is a tuple here. >>> >>> poking around i can see that the ets:select/3 call from >>> mnesia_lib:db_select_init/4 is actually returning a continuation whose 3rd >>> argument is not a list. this is now a BIF so i feel a bit stuck at this >>> point. since it's a BIF here's some extra info: >>> >>> ------ >>> pmineiro@REDACTED% erl -s erlang halt >>> Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false] >>> >>> pmineiro@REDACTED% dpkg -s erlang-otp >>> Package: erlang-otp >>> Status: install ok installed >>> Priority: optional >>> Section: languages >>> Installed-Size: 139084 >>> Maintainer: None >>> Architecture: darwin-i386 >>> Source: erlang-otp >>> Version: 11b-5-1 >>> Depends: libncurses5-shlibs, unixodbc2-shlibs | unixodbc2-nox-shlibs, darwin (>= 8-1) >>> Description: General-purpose programming language >>> Erlang is a general-purpose programming language and runtime environment. >>> Erlang has built-in support for concurrency, distribution and fault >>> tolerance. Erlang is used in several large telecommunication systems >>> from Ericsson. The most popular implementation of Erlang is available as >>> open source from the open source erlang site. >>> . >>> Web site: http://www.erlang.org/ >>> . >>> Maintainer: None >>> BuildDependsOnly: Undefined >>> >>> pmineiro@REDACTED% uname -a >>> Darwin paul-mineiros-computer.local 8.9.3 Darwin Kernel Version 8.9.3: Fri Apr 27 14:50:07 PDT 2007; root:xnu-792.19.5~2/RELEASE_I386 i386 i386 >>> >>> ------ >>> >>> thanks, >>> >>> -- p >>> >>> Optimism is an essential ingredient of innovation. How else can the >>> individual favor change over security? >>> >>> -- Robert Noyce >> Optimism is an essential ingredient of innovation. How else can the >> individual favor change over security? >> >> -- Robert Noyce >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From aconchillo@REDACTED Tue Dec 11 12:41:48 2007 From: aconchillo@REDACTED (=?ISO-8859-1?Q?Aleix_Conchillo_Flaqu=E9?=) Date: Tue, 11 Dec 2007 12:41:48 +0100 Subject: [erlang-bugs] problem compiling percept in mac os x Message-ID: <21ED14B1-C382-4928-87F5-84DAADFBE2D5@gmail.com> Hi, I'm the maintainer of the erlang fink package. I just noticed an error while compiling the percept application: === Entering application percept make -f powerpc-apple-darwin9.1.0/Makefile TYPE=opt /usr/bin/install -c -d ../priv/lib/powerpc-apple-darwin9.1.0 gcc /sw/lib -bundle -flat_namespace -undefined suppress -o ../priv/lib/ powerpc-apple-darwin9.1.0/egd_drv.so ../priv/obj/powerpc-apple- darwin9.1.0/egd_port_driver.o ../priv/obj/powerpc-apple-darwin9.1.0/ egd_image.o ../priv/obj/powerpc-apple-darwin9.1.0/egd_coding.o -lutil - ldl -lm -L/sw/lib -lgd ld: in /sw/lib, can't map file, errno=22 collect2: ld returned 1 exit status make[4]: *** [../priv/lib/powerpc-apple-darwin9.1.0/egd_drv.so] Error 1 make[3]: *** [opt] Error 2 This is caused because the DED_LD_FLAG_RUNTIME_LIBRARY_PATH variable is set to empty in darwin, and this causes: $(LIBDIR)/egd_drv.so: $(EGD_DRV_OBJS) $(INSTALL_DIR) $(LIBDIR) $(LD) $(CC_R_OPT) $(LDFLAGS) -o $@ $^ $(LIBS) $(GD_LINK_LIB) to fail, because CC_R_OPT is set to CC_R_OPT = $(CC_R_FLAG)$(GD_LIBDIR) where CC_R_FLAG=@DED_LD_FLAG_RUNTIME_LIBRARY_PATH@ I have provided a patch for fink where CC_R_FLAG=-rpath. I guess you could provide a better and general fix for this. Thanks in advance. Aleix From md@REDACTED Wed Dec 12 08:09:53 2007 From: md@REDACTED (Maximillian Dornseif) Date: Tue, 11 Dec 2007 23:09:53 -0800 (PST) Subject: [erlang-bugs] Floating point exception (core dumped) in beam Message-ID: <14282109.post@talk.nabble.com> Mikael Pettersson-3 wrote: > > Can you disassemble pthread_testcancel() up to and including the > instruction > at 0x281a731b? > That was more than I thought. The full Output is available at http://static.23.nu/md/Pictures/diss-beam.txt , below is a clipped version. Regards Maximillian gdb) disassemble pthread_testcancel Dump of assembler code for function pthread_testcancel: 0x281a692c : push %ebp 0x281a692d : mov %esp,%ebp 0x281a692f : push %edi 0x281a6930 : push %esi 0x281a6931 : push %ebx 0x281a6932 : sub $0xc,%esp 0x281a6935 : call 0x281a693a 0x281a693a : pop %ebx 0x281a693b : add $0x3b82,%ebx 0x281a6941 : mov %gs:0x0,%edx 0x281a6948 : mov $0x0,%eax 0x281a694d : test %edx,%edx 0x281a694f : je 0x281a6954 ... 0x281a725e : ret 0x281a725f : nop 0x281a7260 : push %ebp 0x281a7261 : mov %esp,%ebp 0x281a7263 : push %ebx 0x281a7264 : sub $0x10,%esp 0x281a7267 : call 0x281a726c 0x281a726c : pop %ebx 0x281a726d : add $0x3250,%ebx 0x281a7273 : push $0x0 0x281a7275 : call 0x281a3bb8 0x281a727a : mov 0xfffffffc(%ebp),%ebx 0x281a727d : leave 0x281a727e : ret 0x281a727f : nop 0x281a7280 : push %ebx 0x281a7281 : call 0x281a7286 0x281a7286 : pop %ebx 0x281a7287 : add $0x3236,%ebx 0x281a728d : jmp 0x281a7638 0x281a7292 : mov %esi,%esi 0x281a7294 : mov $0xe8,%eax 0x281a7299 : int $0x80 0x281a729b : jb 0x281a7280 0x281a729d : ret 0x281a729e : nop 0x281a729f : nop 0x281a72a0 : push %ebx 0x281a72a1 : call 0x281a72a6 0x281a72a6 : pop %ebx 0x281a72a7 : add $0x3216,%ebx 0x281a72ad : jmp 0x281a7638 0x281a72b2 : mov %esi,%esi 0x281a72b4 : mov $0x17d,%eax ---Type to continue, or q to quit--- 0x281a72b9 : int $0x80 0x281a72bb : jb 0x281a72a0 0x281a72bd : ret 0x281a72be : nop 0x281a72bf : nop 0x281a72c0 : push %ebx 0x281a72c1 : call 0x281a72c6 0x281a72c6 : pop %ebx 0x281a72c7 : add $0x31f6,%ebx 0x281a72cd : jmp 0x281a7638 0x281a72d2 : mov %esi,%esi 0x281a72d4 : mov $0x17b,%eax 0x281a72d9 : int $0x80 0x281a72db : jb 0x281a72c0 0x281a72dd : ret 0x281a72de : nop 0x281a72df : nop 0x281a72e0 : push %ebx 0x281a72e1 : call 0x281a72e6 0x281a72e6 : pop %ebx 0x281a72e7 : add $0x31d6,%ebx 0x281a72ed : jmp 0x281a7638 0x281a72f2 : mov %esi,%esi 0x281a72f4 : mov $0x17f,%eax 0x281a72f9 : int $0x80 0x281a72fb : jb 0x281a72e0 0x281a72fd : ret 0x281a72fe : nop 0x281a72ff : nop 0x281a7300 : push %ebx 0x281a7301 : call 0x281a7306 0x281a7306 : pop %ebx 0x281a7307 : add $0x31b6,%ebx 0x281a730d : jmp 0x281a7638 0x281a7312 : mov %esi,%esi 0x281a7314 : mov $0x17e,%eax 0x281a7319 : int $0x80 0x281a731b : jb 0x281a7300 0x281a731d : ret 0x281a731e : nop 0x281a731f : nop 0x281a7320 : push %ebx 0x281a7321 : call 0x281a7326 0x281a7326 : pop %ebx 0x281a7327 : add $0x3196,%ebx 0x281a732d : jmp 0x281a7638 -- View this message in context: http://www.nabble.com/Floating-point-exception-%28core-dumped%29-in-beam-tp14208305p14282109.html Sent from the Erlang Bugs mailing list archive at Nabble.com. From mikpe@REDACTED Wed Dec 12 17:19:54 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 12 Dec 2007 17:19:54 +0100 Subject: [erlang-bugs] Floating point exception (core dumped) in beam In-Reply-To: <14282109.post@talk.nabble.com> References: <14282109.post@talk.nabble.com> Message-ID: <18272.2602.232208.754103@alkaid.it.uu.se> Maximillian Dornseif writes: > > > Mikael Pettersson-3 wrote: > > > > Can you disassemble pthread_testcancel() up to and including the > > instruction > > at 0x281a731b? > > > > That was more than I thought. The full Output is available at > http://static.23.nu/md/Pictures/diss-beam.txt , below is a clipped version. ... > 0x281a7312 : mov %esi,%esi > 0x281a7314 : mov $0x17e,%eax > 0x281a7319 : int $0x80 > 0x281a731b : jb 0x281a7300 > > 0x281a731d : ret The kernel reports SIGFPE on return from syscall 0x17e. This looks like a kernel or libc bug. Possibly the kernel expects FP exceptions to be masked and cannot handle user-space (BEAM) having enabled them. You can test that theory by editing erts/configure: find fpe-test.c in erts/configure, place a "return 1;" at the start of main(), run ./configure, ensure that it says that floating-point exceptions are unreliable, make the system, and run the test case again. If things now work then this system needs to be blacklisted (due to apparent kernel/libc bugs) from using FP exceptions. From md@REDACTED Wed Dec 12 21:48:01 2007 From: md@REDACTED (Maximillian Dornseif) Date: Wed, 12 Dec 2007 12:48:01 -0800 (PST) Subject: [erlang-bugs] Floating point exception (core dumped) in beam In-Reply-To: <18272.2602.232208.754103@alkaid.it.uu.se> References: <14208305.post@talk.nabble.com> <200712092142.lB9LghZD020911@harpo.it.uu.se> <14282109.post@talk.nabble.com> <18272.2602.232208.754103@alkaid.it.uu.se> Message-ID: <14303603.post@talk.nabble.com> Mikael Pettersson-3 wrote: > > The kernel reports SIGFPE on return from syscall 0x17e. > This looks like a kernel or libc bug. > > Possibly the kernel expects FP exceptions to be masked > and cannot handle user-space (BEAM) having enabled them. > You can test that theory by editing erts/configure: find > fpe-test.c in erts/configure, place a "return 1;" at the > start of main(), run ./configure, ensure that it says that > floating-point exceptions are unreliable, make the system, > and run the test case again. > I changed the configure script an got checking for unreliable floating point execptions... unreliable; testing in software instead I then compiled, installed an retried the testcase - and got the same issue and more or less the same coredump. Mikael Pettersson-3 wrote: > > If things now work then this > system needs to be blacklisted (due to apparent kernel/libc > bugs) from using FP exceptions. > I checked on FreeBSD 6.2 by copying the .beam files and the Mnedia directory to an Machine running FreeBSD 6.2 and I can't trigger the issue there. But maybe this is related to the CPU and not to the OS. $ uname -a FreeBSD boingball.XXX 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@REDACTED:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@REDACTED:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz (2259.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Features2=0x4400> real memory = 266862592 (254 MB) avail memory = 251543552 (239 MB) Regards Maximillian -- View this message in context: http://www.nabble.com/Floating-point-exception-%28core-dumped%29-in-beam-tp14208305p14303603.html Sent from the Erlang Bugs mailing list archive at Nabble.com. From mikpe@REDACTED Thu Dec 13 10:13:42 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 13 Dec 2007 10:13:42 +0100 Subject: [erlang-bugs] Floating point exception (core dumped) in beam In-Reply-To: <14303603.post@talk.nabble.com> References: <14208305.post@talk.nabble.com> <200712092142.lB9LghZD020911@harpo.it.uu.se> <14282109.post@talk.nabble.com> <18272.2602.232208.754103@alkaid.it.uu.se> <14303603.post@talk.nabble.com> Message-ID: <18272.63430.329535.901827@harpo.it.uu.se> Maximillian Dornseif writes: > > > Mikael Pettersson-3 wrote: > > > > The kernel reports SIGFPE on return from syscall 0x17e. > > This looks like a kernel or libc bug. > > > > Possibly the kernel expects FP exceptions to be masked > > and cannot handle user-space (BEAM) having enabled them. > > You can test that theory by editing erts/configure: find > > fpe-test.c in erts/configure, place a "return 1;" at the > > start of main(), run ./configure, ensure that it says that > > floating-point exceptions are unreliable, make the system, > > and run the test case again. > > > > I changed the configure script an got > > checking for unreliable floating point execptions... unreliable; testing in > software instead > > I then compiled, installed an retried the testcase - and got the same issue > and more or less the same coredump. > > > > Mikael Pettersson-3 wrote: > > > > If things now work then this > > system needs to be blacklisted (due to apparent kernel/libc > > bugs) from using FP exceptions. > > > > I checked on FreeBSD 6.2 by copying the .beam files and the Mnedia directory > to an Machine running FreeBSD 6.2 and I can't trigger the issue there. But > maybe this is related to the CPU and not to the OS. > > $ uname -a > FreeBSD boingball.XXX 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 > 10:40:27 UTC 2007 > root@REDACTED:/usr/obj/usr/src/sys/GENERIC i386 > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 > root@REDACTED:/usr/obj/usr/src/sys/GENERIC > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz (2259.15-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 The broken system runs 32-bit FreeBSD 5.4 on a P4 Xeon. The working system runs 32-bit FreeBSD 6.2 on a P4. It is most definitely FreeBSD 5.4 that's broken here, especially since the problem occurs even when BEAM doesn't enable and use FP exceptions. Unless someone (not me) is very very motivated to support FreeBSD 5.4, I don't think there is much any core Erlang developers can do about this problem. You should upgrade, or let the FreeBSD developers deal with it. From opfer@REDACTED Thu Dec 13 10:26:21 2007 From: opfer@REDACTED (Christian Faulhammer) Date: Thu, 13 Dec 2007 10:26:21 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] Message-ID: <20071213102621.0c7fa095@gentoo.org> Hi, I sent in this patch before but there was neither a reaction nor inclusion into 12B. So I resend it: This simple patch fixes compilation on x86_64 in Gentoo Linux and does no harm. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: erlang-10.2.6-export-TARGET.patch Type: text/x-patch Size: 242 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opfer@REDACTED Thu Dec 13 10:28:24 2007 From: opfer@REDACTED (Christian Faulhammer) Date: Thu, 13 Dec 2007 10:28:24 +0100 Subject: [erlang-bugs] Make build process more robust [resent] Message-ID: <20071213102824.5d40750c@gentoo.org> Hi, I sent in this patch before but there was neither a reaction nor inclusion into 12B. So I resend it: On failure the build should abort with an error code, this does not happen everywhere, the attached patch fixes one of them. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: erlang-11.2.5-build.patch Type: text/x-patch Size: 362 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opfer@REDACTED Thu Dec 13 10:29:50 2007 From: opfer@REDACTED (Christian Faulhammer) Date: Thu, 13 Dec 2007 10:29:50 +0100 Subject: [erlang-bugs] FreeBSD build fix [resent] Message-ID: <20071213102950.41df13a7@gentoo.org> Hi, I sent in this patch before but there was neither a reaction nor inclusion into 12B. So I resend it: FreeBSD above 6.2 had some problems in Gentoo/FBSD, while the attached patch fixes this. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: erlang-11.2.5-gethostbyname.patch Type: text/x-patch Size: 755 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikpe@REDACTED Thu Dec 13 10:53:30 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 13 Dec 2007 10:53:30 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <20071213102621.0c7fa095@gentoo.org> References: <20071213102621.0c7fa095@gentoo.org> Message-ID: <18273.282.215038.716802@harpo.it.uu.se> Christian Faulhammer writes: > Hi, > > I sent in this patch before but there was neither a reaction nor > inclusion into 12B. So I resend it: This simple patch fixes > compilation on x86_64 in Gentoo Linux and does no harm. > > V-Li > > -- > Christian Faulhammer, Gentoo Lisp project > , #gentoo-lisp on FreeNode > > > --- Makefile.in > +++ Makefile.in This is ambiguous. Please generate a standard patch that applies with 'patch -p1'. > @@ -85,7 +85,7 @@ > MAKE = @MAKE_PROG@ > > # This should be set to the target "arch-vendor-os" > -TARGET = @TARGET@ > +export TARGET = @TARGET@ > > # A BSD compatible install program > INSTALL = @INSTALL@ > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From ingela@REDACTED Thu Dec 13 11:03:42 2007 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 13 Dec 2007 11:03:42 +0100 Subject: [erlang-bugs] [Fwd: Re: Disabled ODBC support for x86_64] Message-ID: <4761037E.3020601@erix.ericsson.se> Jag gl?mde tydligen cc till erlang-bugs! m.v.h Ingela -------------- next part -------------- An embedded message was scrubbed... From: Ingela Anderton Andin Subject: Re: [erlang-bugs] Disabled ODBC support for x86_64 Date: Wed, 21 Nov 2007 11:47:31 +0100 Size: 1937 URL: From mikpe@REDACTED Thu Dec 13 11:46:45 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 13 Dec 2007 11:46:45 +0100 Subject: [erlang-bugs] Make build process more robust [resent] In-Reply-To: <20071213102824.5d40750c@gentoo.org> References: <20071213102824.5d40750c@gentoo.org> Message-ID: <18273.3477.782865.199398@harpo.it.uu.se> Christian Faulhammer writes: > Hi, > > I sent in this patch before but there was neither a reaction nor > inclusion into 12B. So I resend it: On failure the build should abort > with an error code, this does not happen everywhere, the attached patch > fixes one of them. > > V-Li > > -- > Christian Faulhammer, Gentoo Lisp project > , #gentoo-lisp on FreeNode > > > make sure errors actually get passed back up > > --- make/otp_subdir.m > +++ make/otp_subdir.mk > @@ -44,7 +44,7 @@ > if test -f $$d/ignore_config_record.inf; then \ > xflag=$$tflag ; \ > fi ; \ > - (cd $$d && $(MAKE) $$xflag $@) ; \ > + (cd $$d && $(MAKE) $$xflag $@) || exit $$? ; \ > fi ; \ > fi ; \ > done ; \ Normally I'd agree with you on this one, but the Erlang/OTP build is known to be shaky and to fail in some IMO obscure libraries in some environments. I wouldn't want the entire build to fail in these cases. Or do you volunteer to fix all build errors that result from this? From samuelrivas@REDACTED Thu Dec 13 12:17:53 2007 From: samuelrivas@REDACTED (Samuel Rivas) Date: Thu, 13 Dec 2007 12:17:53 +0100 Subject: [erlang-bugs] Missing links in interoperability tutorial Message-ID: <20071213111753.GA1503@lambdastream.com> Hi, It seems links to interoperablility tutorials are missing in online documentation. For example, in section 5.1: "The resulting Erlang program can be found in ." Regards -- Samuel From kenneth.lundin@REDACTED Thu Dec 13 16:48:55 2007 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 13 Dec 2007 16:48:55 +0100 Subject: [erlang-bugs] Missing links in interoperability tutorial In-Reply-To: <20071213111753.GA1503@lambdastream.com> References: <20071213111753.GA1503@lambdastream.com> Message-ID: Hi Samuel, Tanks for pointing out this error. We seem to have lost some information during our conversion fron sgml to xml as source format for the doc. Will be corrected in R12B-1. /Regards Kenneth On 12/13/07, Samuel Rivas wrote: > Hi, > > It seems links to interoperablility tutorials are missing in online > documentation. For example, in section 5.1: > > "The resulting Erlang program can be found in ." > > Regards > -- > Samuel > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From matthias@REDACTED Thu Dec 13 18:37:17 2007 From: matthias@REDACTED (Matthias Lang) Date: Thu, 13 Dec 2007 18:37:17 +0100 Subject: [erlang-bugs] typo in 'io' manpage Message-ID: <18273.28109.878949.671790@antilipe.corelatus.se> In R12-B, there's a new function documented in the io module, called columns/0. In the documentation (e.g. manpage, HTML, etc.) it's incorrectly documented as colums/0. Matthias From opfer@REDACTED Thu Dec 13 21:59:24 2007 From: opfer@REDACTED (Christian Faulhammer) Date: Thu, 13 Dec 2007 21:59:24 +0100 Subject: [erlang-bugs] Make build process more robust [resent] In-Reply-To: <18273.3477.782865.199398@harpo.it.uu.se> References: <20071213102824.5d40750c@gentoo.org> <18273.3477.782865.199398@harpo.it.uu.se> Message-ID: <20071213215924.27e2772e@gentoo.org> Mikael Pettersson : > Christian Faulhammer writes: > > Hi, > > > > I sent in this patch before but there was neither a reaction nor > > inclusion into 12B. So I resend it: On failure the build should > > abort with an error code, this does not happen everywhere, the > > attached patch fixes one of them. [...] > Normally I'd agree with you on this one, but the Erlang/OTP > build is known to be shaky and to fail in some IMO obscure > libraries in some environments. I wouldn't want the entire > build to fail in these cases. We had people report random runtime failures and we had a hard time to track it down....and since the inclusion of the patch in Gentoo we had no reports of build failures (and we are source based with lots of environments, though there might be more obscure environments were Erlang is deployed). But I also have no problem with maintaining it locally here. > Or do you volunteer to fix all build errors that result from this? Surely not. :) V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opfer@REDACTED Thu Dec 13 22:03:11 2007 From: opfer@REDACTED (Christian Faulhammer) Date: Thu, 13 Dec 2007 22:03:11 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <18273.282.215038.716802@harpo.it.uu.se> References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> Message-ID: <20071213220311.4e072987@gentoo.org> Mikael Pettersson : > This is ambiguous. Please generate a standard patch > that applies with 'patch -p1'. Better? V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: erlang-set-TARGET.patch Type: text/x-patch Size: 339 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikpe@REDACTED Thu Dec 13 23:58:46 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 13 Dec 2007 23:58:46 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <20071213220311.4e072987@gentoo.org> References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> <20071213220311.4e072987@gentoo.org> Message-ID: <18273.47398.507611.742289@harpo.it.uu.se> Christian Faulhammer writes: > Mikael Pettersson : > > > This is ambiguous. Please generate a standard patch > > that applies with 'patch -p1'. > > Better? Better. Now, could you please explain why this is needed? I.e., why does gentoo need this change while (apparently) everybody else Unix-like doesn't. Presumably something special is going on either with the TARGET thing or the export thing, but _what_? (I'm not trying to be rude here; patches must IMO be accompanied by technical explanations, otherwise we lose track of why things are done in certain ways.) > > V-Li > > -- > Christian Faulhammer, Gentoo Lisp project > , #gentoo-lisp on FreeNode > > > --- /tmp/Makefile.in.orig 2007-12-13 22:01:34.000000000 +0100 > +++ otp_src_R12B-0/Makefile.in 2007-12-13 22:01:44.000000000 +0100 > @@ -90,7 +90,7 @@ > MAKE = @MAKE_PROG@ > > # This should be set to the target "arch-vendor-os" > -TARGET = @TARGET@ > +export TARGET = @TARGET@ > > # A BSD compatible install program > INSTALL = @INSTALL@ From opfer@REDACTED Fri Dec 14 05:56:03 2007 From: opfer@REDACTED (Christian Faulhammer) Date: Fri, 14 Dec 2007 05:56:03 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <18273.47398.507611.742289@harpo.it.uu.se> References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> <20071213220311.4e072987@gentoo.org> <18273.47398.507611.742289@harpo.it.uu.se> Message-ID: <20071214055603.4af7dbe4@gentoo.org> Mikael Pettersson : > Christian Faulhammer writes: > > Mikael Pettersson : > > > This is ambiguous. Please generate a standard patch > > > that applies with 'patch -p1'. > > Better? > Better. > Now, could you please explain why this is needed? > I.e., why does gentoo need this change while (apparently) > everybody else Unix-like doesn't. To quote from the original bug report (in 2005, I was not around then): "no, that's a crappy 'fix' as is the current amd64 solution the reason for this is the build system doesnt setup TARGET properly configure.in sets TARGET to $host which comes from --host=... and this value is recorded in the toplevel Makefile ... when the generate target is run in the toplevel Makefile, it drops all settings and changes to erts/emulator which sources make/run_make.mk which sources make/target.mk which goes 'TARGET is not set, lets guess at it using config.guess' which then produces the garbage value 'sparc64-unknown-linux-gnu' and 'x86_64-unknown-linux-gnu'" > (I'm not trying to be rude here; patches must IMO > be accompanied by technical explanations, otherwise > we lose track of why things are done in certain > ways.) I hoped, my little patches would be crystal clear. :) V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sgolovan@REDACTED Fri Dec 14 09:18:45 2007 From: sgolovan@REDACTED (Sergei Golovan) Date: Fri, 14 Dec 2007 11:18:45 +0300 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <18273.47398.507611.742289@harpo.it.uu.se> References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> <20071213220311.4e072987@gentoo.org> <18273.47398.507611.742289@harpo.it.uu.se> Message-ID: On 12/14/07, Mikael Pettersson wrote: > > Now, could you please explain why this is needed? > I.e., why does gentoo need this change while (apparently) > everybody else Unix-like doesn't. In fact, erlang refuses (at least refused in the past) to build on certain architectures if included config.sub and config.guess files are used. The problem is that they are not the same and could give different results. In R12B-0 there are four such files, some of them are identical. I would better use the same config.guess and config.sub during all OTP build process and wouldn't export TARGET. otp_src_R12B-0% foreach i in `find . -name config.guess` ; do md5sum $i ; done c367ed8d821a2a557091b1e08789c64b ./lib/erl_interface/src/auxdir/config.guess 981c620f1adb2c5e5300b616af53c6b2 ./lib/common_test/priv/rx-1.5/config.guess 4369ba7115f309d6bc50d358eb2a8c98 ./lib/test_server/src/config.guess c367ed8d821a2a557091b1e08789c64b ./erts/autoconf/config.guess otp_src_R12B-0% foreach i in `find . -name config.sub` ; do md5sum $i ; done 46b5f22a89ce2f614252be61a5330b02 ./lib/erl_interface/src/auxdir/config.sub c42400b209293cedd01498f0e60a2c9d ./lib/common_test/priv/rx-1.5/config.sub 297d155d0ebe1c2209f4d3b6859d18ae ./lib/test_server/src/config.sub 297d155d0ebe1c2209f4d3b6859d18ae ./erts/autoconf/config.sub otp_src_R12B-0% Cheers! -- Sergei Golovan From opendev@REDACTED Fri Dec 14 13:15:00 2007 From: opendev@REDACTED (Joern) Date: Fri, 14 Dec 2007 13:15:00 +0100 Subject: [erlang-bugs] gen_server:reply/2 documentation Message-ID: <9e009ad0712140415l3f26d276m864a864cad5ecbac@mail.gmail.com> gen_server:reply/2 on R11B-5/win32 returns { Ref, Reply } instead of true rgs/joern -- From mikpe@REDACTED Fri Dec 14 13:39:00 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 14 Dec 2007 13:39:00 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> <20071213220311.4e072987@gentoo.org> <18273.47398.507611.742289@harpo.it.uu.se> Message-ID: <18274.31076.840770.891811@harpo.it.uu.se> Sergei Golovan writes: > On 12/14/07, Mikael Pettersson wrote: > > > > Now, could you please explain why this is needed? > > I.e., why does gentoo need this change while (apparently) > > everybody else Unix-like doesn't. > > In fact, erlang refuses (at least refused in the past) to build on > certain architectures if included config.sub and config.guess files > are used. The problem is that they are not the same and could give > different results. Were these build errors reported here? I don't remember hearing about this issue before. > In R12B-0 there are four such files, some of them are identical. I > would better use the same config.guess and config.sub during all OTP > build process and wouldn't export TARGET. > > otp_src_R12B-0% foreach i in `find . -name config.guess` ; do md5sum $i ; done > c367ed8d821a2a557091b1e08789c64b ./lib/erl_interface/src/auxdir/config.guess > 981c620f1adb2c5e5300b616af53c6b2 ./lib/common_test/priv/rx-1.5/config.guess > 4369ba7115f309d6bc50d358eb2a8c98 ./lib/test_server/src/config.guess > c367ed8d821a2a557091b1e08789c64b ./erts/autoconf/config.guess > otp_src_R12B-0% foreach i in `find . -name config.sub` ; do md5sum $i ; done > 46b5f22a89ce2f614252be61a5330b02 ./lib/erl_interface/src/auxdir/config.sub > c42400b209293cedd01498f0e60a2c9d ./lib/common_test/priv/rx-1.5/config.sub > 297d155d0ebe1c2209f4d3b6859d18ae ./lib/test_server/src/config.sub > 297d155d0ebe1c2209f4d3b6859d18ae ./erts/autoconf/config.sub I see. That is indeed a problem. I think the core OTP group needs to mandate the use of a single set of config.{guess,sub} files, e.g. the ones in erts/autoconf/, and then those other groups that "own" the offending components under lib/ need to migrate to the shared config.{guess,sub} ASAP. Anyone from Erlang/OTP listening here? /Mikael From mikpe@REDACTED Fri Dec 14 13:45:08 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 14 Dec 2007 13:45:08 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <20071214055603.4af7dbe4@gentoo.org> References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> <20071213220311.4e072987@gentoo.org> <18273.47398.507611.742289@harpo.it.uu.se> <20071214055603.4af7dbe4@gentoo.org> Message-ID: <18274.31444.887590.48856@harpo.it.uu.se> Christian Faulhammer writes: > Mikael Pettersson : > > > Christian Faulhammer writes: > > > Mikael Pettersson : > > > > This is ambiguous. Please generate a standard patch > > > > that applies with 'patch -p1'. > > > Better? > > Better. > > Now, could you please explain why this is needed? > > I.e., why does gentoo need this change while (apparently) > > everybody else Unix-like doesn't. > > To quote from the original bug report (in 2005, I was not around then): > "no, that's a crappy 'fix' as is the current amd64 solution > > the reason for this is the build system doesnt setup TARGET properly > > configure.in sets TARGET to $host which comes from --host=... and this > value is recorded in the toplevel Makefile ... > > when the generate target is run in the toplevel Makefile, it drops all > settings and changes to erts/emulator which sources make/run_make.mk > which sources make/target.mk which goes 'TARGET is not set, lets guess > at it using config.guess' which then produces the garbage value > 'sparc64-unknown-linux-gnu' and 'x86_64-unknown-linux-gnu'" The "garbage" being that you lose your -gentoo- marker? Or do you need to force TARGET to work around the issue of inconsistent config.{guess,sub} files in the source tree? (see Sergei Golovan's message today) Either way I now see the benefit of this change. /Mikael From david.koch@REDACTED Fri Dec 14 14:32:49 2007 From: david.koch@REDACTED (=?iso-8859-1?Q?david.koch@libertysurf.fr?=) Date: Fri, 14 Dec 2007 14:32:49 +0100 Subject: [erlang-bugs] =?iso-8859-1?q?REF=3A_Erlang_IDE_R12B0_I/O_troubles?= Message-ID: I upgraded to R12B0 (erl 5.6) but now under eclipse, every time some outputs are directed to the console, an error message happens. I downgraded to R11B5 and things return smooth... Is it a ErlIDE bug or a erl_io one ? http://erlide.sourceforge.net/ Kochise ------------------------ ALICE C'EST ENCORE MIEUX AVEC CANAL+ LE BOUQUET ! --------------- D?couvrez vite l'offre exclusive ALICEBOX et CANAL+ LE BOUQUET, en cliquant ici http://alicebox.fr Soumis ? conditions. From vladdu55@REDACTED Fri Dec 14 14:40:52 2007 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 14 Dec 2007 14:40:52 +0100 Subject: [erlang-bugs] REF: Erlang IDE R12B0 I/O troubles In-Reply-To: References: Message-ID: <95be1d3b0712140540u74d92decg1c5ad5e8ccff0c08@mail.gmail.com> Hi! On Dec 14, 2007 2:32 PM, david.koch@REDACTED wrote: > I upgraded to R12B0 (erl 5.6) but now under eclipse, every > time some outputs are directed to the console, an error > message happens. I downgraded to R11B5 and things return > smooth... Is it a ErlIDE bug or a erl_io one ? I didn't manage to test at all with R12B, but it might be so that some hacks I did might not work any longer... We will be checking out what is going on. Thanks for the report! best regards, Vlad From kenneth.lundin@REDACTED Fri Dec 14 15:18:19 2007 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Fri, 14 Dec 2007 15:18:19 +0100 Subject: [erlang-bugs] REF: Erlang IDE R12B0 I/O troubles In-Reply-To: <95be1d3b0712140540u74d92decg1c5ad5e8ccff0c08@mail.gmail.com> References: <95be1d3b0712140540u74d92decg1c5ad5e8ccff0c08@mail.gmail.com> Message-ID: It should be stated on the ErlIde pages that ErlIde currently requires Erlang R11B. We have not tested ErlIde at all together with R12B. /Kenneth Erlang/OTP team at Ericsson On 12/14/07, Vlad Dumitrescu wrote: > Hi! > > On Dec 14, 2007 2:32 PM, david.koch@REDACTED > wrote: > > I upgraded to R12B0 (erl 5.6) but now under eclipse, every > > time some outputs are directed to the console, an error > > message happens. I downgraded to R11B5 and things return > > smooth... Is it a ErlIDE bug or a erl_io one ? > > I didn't manage to test at all with R12B, but it might be so that some > hacks I did might not work any longer... > > We will be checking out what is going on. Thanks for the report! > > best regards, > Vlad > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From rickard.s.green@REDACTED Fri Dec 14 15:20:13 2007 From: rickard.s.green@REDACTED (Rickard Green) Date: Fri, 14 Dec 2007 15:20:13 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <18274.31076.840770.891811@harpo.it.uu.se> References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> <20071213220311.4e072987@gentoo.org> <18273.47398.507611.742289@harpo.it.uu.se> <18274.31076.840770.891811@harpo.it.uu.se> Message-ID: <4762911D.6020801@ericsson.com> We will make sure that all applications use the same versions of config.{guess,sub} in R12B-1. Christian: As I understand it, this will solve your problem. Am I right or wrong? I googled a bit for new config.{guess,sub} files to use, and think that we will use the ones part of the latest stable libtool. Anyone objects? BR, Rickard Green, Erlang/OTP, Ericsson AB. Mikael Pettersson wrote: > Sergei Golovan writes: > > On 12/14/07, Mikael Pettersson wrote: > > > > > > Now, could you please explain why this is needed? > > > I.e., why does gentoo need this change while (apparently) > > > everybody else Unix-like doesn't. > > > > In fact, erlang refuses (at least refused in the past) to build on > > certain architectures if included config.sub and config.guess files > > are used. The problem is that they are not the same and could give > > different results. > > Were these build errors reported here? I don't remember > hearing about this issue before. > > > In R12B-0 there are four such files, some of them are identical. I > > would better use the same config.guess and config.sub during all OTP > > build process and wouldn't export TARGET. > > > > otp_src_R12B-0% foreach i in `find . -name config.guess` ; do md5sum $i ; done > > c367ed8d821a2a557091b1e08789c64b ./lib/erl_interface/src/auxdir/config.guess > > 981c620f1adb2c5e5300b616af53c6b2 ./lib/common_test/priv/rx-1.5/config.guess > > 4369ba7115f309d6bc50d358eb2a8c98 ./lib/test_server/src/config.guess > > c367ed8d821a2a557091b1e08789c64b ./erts/autoconf/config.guess > > otp_src_R12B-0% foreach i in `find . -name config.sub` ; do md5sum $i ; done > > 46b5f22a89ce2f614252be61a5330b02 ./lib/erl_interface/src/auxdir/config.sub > > c42400b209293cedd01498f0e60a2c9d ./lib/common_test/priv/rx-1.5/config.sub > > 297d155d0ebe1c2209f4d3b6859d18ae ./lib/test_server/src/config.sub > > 297d155d0ebe1c2209f4d3b6859d18ae ./erts/autoconf/config.sub > > I see. That is indeed a problem. > I think the core OTP group needs to mandate the use of a single > set of config.{guess,sub} files, e.g. the ones in erts/autoconf/, > and then those other groups that "own" the offending components > under lib/ need to migrate to the shared config.{guess,sub} ASAP. > > Anyone from Erlang/OTP listening here? > > /Mikael > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From sgolovan@REDACTED Fri Dec 14 15:28:01 2007 From: sgolovan@REDACTED (Sergei Golovan) Date: Fri, 14 Dec 2007 17:28:01 +0300 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <4762911D.6020801@ericsson.com> References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> <20071213220311.4e072987@gentoo.org> <18273.47398.507611.742289@harpo.it.uu.se> <18274.31076.840770.891811@harpo.it.uu.se> <4762911D.6020801@ericsson.com> Message-ID: On 12/14/07, Rickard Green wrote: > We will make sure that all applications use the same versions of > config.{guess,sub} in R12B-1. > > Christian: As I understand it, this will solve your problem. Am I right > or wrong? In fact, it won't (as fas as I understand). Christian explicitly supplies --host argument when builds OTP. But this --host isn't propagated somwhere deeper where a guess from config.guess is used. > > I googled a bit for new config.{guess,sub} files to use, and think that > we will use the ones part of the latest stable libtool. Anyone objects? I think it's reasonable. -- Sergei Golovan From rickard.s.green@REDACTED Fri Dec 14 15:27:25 2007 From: rickard.s.green@REDACTED (Rickard Green) Date: Fri, 14 Dec 2007 15:27:25 +0100 Subject: [erlang-bugs] [Fwd: Re: Make build process more robust [resent]] Message-ID: <476292CD.80309@ericsson.com> Forgot to cc erlang-bugs... -------- Original Message -------- Subject: Re: [erlang-bugs] Make build process more robust [resent] Date: Fri, 14 Dec 2007 15:26:13 +0100 From: Rickard Green Organization: Ericsson AB To: Christian Faulhammer References: <20071213102824.5d40750c@REDACTED> Thanks for the patch we'll include it in R12-1. BR, Rickard Green, Erlang/OTP, Ericsson AB. Christian Faulhammer wrote: > * PGP Signed by an unknown key: 12/13/2007 at 10:28:24 AM > Hi, > > I sent in this patch before but there was neither a reaction nor > inclusion into 12B. So I resend it: On failure the build should abort > with an error code, this does not happen everywhere, the attached patch > fixes one of them. > > V-Li > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From david.koch@REDACTED Fri Dec 14 15:35:00 2007 From: david.koch@REDACTED (=?iso-8859-1?Q?david.koch@libertysurf.fr?=) Date: Fri, 14 Dec 2007 15:35:00 +0100 Subject: [erlang-bugs] =?iso-8859-1?q?REF=3A_Erlang_IDE_R12B0_I/O_troubles?= Message-ID: It is stated that it is no more R10B compatible, meaning only R11B and up will works... I expected R12B to work as well. However do not feel upset by my bug report, it's mostly directed towards ErlIDE's author, as I don't think it's OTP team's fault. Pehaps giving a better IO mechanism to fetch erlang's console buffer from a remote process (such Eclipse's ErlIDE) would be an idea to implement, so that no more "risky tricky" would be necessary to perform the task... Kochise ---------- Initial Header ----------- From : "Kenneth Lundin" To : "Vlad Dumitrescu" Cc : "david.koch@REDACTED" , erlang-bugs Date : Fri, 14 Dec 2007 15:18:19 +0100 Subject : Re: [erlang-bugs] REF: Erlang IDE R12B0 I/O troubles It should be stated on the ErlIde pages that ErlIde currently requires Erlang R11B. We have not tested ErlIde at all together with R12B. /Kenneth Erlang/OTP team at Ericsson On 12/14/07, Vlad Dumitrescu wrote: > Hi! > > On Dec 14, 2007 2:32 PM, david.koch@REDACTED > wrote: > > I upgraded to R12B0 (erl 5.6) but now under eclipse, every > > time some outputs are directed to the console, an error > > message happens. I downgraded to R11B5 and things return > > smooth... Is it a ErlIDE bug or a erl_io one ? > > I didn't manage to test at all with R12B, but it might be so that some > hacks I did might not work any longer... > > We will be checking out what is going on. Thanks for the report! > > best regards, > Vlad > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > ------------------------ ALICE C'EST ENCORE MIEUX AVEC CANAL+ LE BOUQUET ! --------------- D?couvrez vite l'offre exclusive ALICEBOX et CANAL+ LE BOUQUET, en cliquant ici http://alicebox.fr Soumis ? conditions. From mikpe@REDACTED Fri Dec 14 15:40:43 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 14 Dec 2007 15:40:43 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <4762911D.6020801@ericsson.com> References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> <20071213220311.4e072987@gentoo.org> <18273.47398.507611.742289@harpo.it.uu.se> <18274.31076.840770.891811@harpo.it.uu.se> <4762911D.6020801@ericsson.com> Message-ID: <18274.38379.236962.112708@harpo.it.uu.se> Rickard Green writes: > We will make sure that all applications use the same versions of > config.{guess,sub} in R12B-1. > > Christian: As I understand it, this will solve your problem. Am I right > or wrong? I can't answer the gentoo issues, but I think you should also include the patch to export TARGET so the user can override it. Even if all components use the same config.{guess,sub}, that one will not set up correct vendor strings for environments that upstream libtool doesn't know about. (And yes, I have one such environment right here, on my ARM boxes.) /Mikael From rickard.s.green@REDACTED Fri Dec 14 16:08:00 2007 From: rickard.s.green@REDACTED (Rickard Green) Date: Fri, 14 Dec 2007 16:08:00 +0100 Subject: [erlang-bugs] Build fix for some architectures: x86_64 e.g. [resent] In-Reply-To: <18274.38379.236962.112708@harpo.it.uu.se> References: <20071213102621.0c7fa095@gentoo.org> <18273.282.215038.716802@harpo.it.uu.se> <20071213220311.4e072987@gentoo.org> <18273.47398.507611.742289@harpo.it.uu.se> <18274.31076.840770.891811@harpo.it.uu.se> <4762911D.6020801@ericsson.com> <18274.38379.236962.112708@harpo.it.uu.se> Message-ID: <47629C50.3080001@ericsson.com> We'll include the 'export TARGET' as well. BR, Rickard Green, Erlang/OTP, Ericsson AB. Mikael Pettersson wrote: > Rickard Green writes: > > We will make sure that all applications use the same versions of > > config.{guess,sub} in R12B-1. > > > > Christian: As I understand it, this will solve your problem. Am I right > > or wrong? > > I can't answer the gentoo issues, but I think you should also > include the patch to export TARGET so the user can override it. > Even if all components use the same config.{guess,sub}, that > one will not set up correct vendor strings for environments > that upstream libtool doesn't know about. > > (And yes, I have one such environment right here, on my ARM boxes.) > > /Mikael > Sergei Golovan wrote: > On 12/14/07, Rickard Green wrote: >> We will make sure that all applications use the same versions of >> config.{guess,sub} in R12B-1. >> >> Christian: As I understand it, this will solve your problem. Am I right >> or wrong? > > In fact, it won't (as fas as I understand). Christian explicitly > supplies --host argument when builds OTP. But this --host isn't > propagated somwhere deeper where a guess from config.guess is used. > >> I googled a bit for new config.{guess,sub} files to use, and think that >> we will use the ones part of the latest stable libtool. Anyone objects? > > I think it's reasonable. > From danie@REDACTED Sat Dec 15 04:36:07 2007 From: danie@REDACTED (Daniel Schutte) Date: Sat, 15 Dec 2007 05:36:07 +0200 Subject: [erlang-bugs] R12B-0 SSL Build Error on Centos / Redha Message-ID: <200712150536.08405.danie@erlfinsys.net> Erlang R12B-0 Centos 5.0 OpenSSL 0.9.8g 19 Oct 2007 2.6.18-8.1.15.el5 #1 SMP Mon Oct 22 08:32:28 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux On executing the following command - the following error occurs: gcc -Wl,-R/usr/local/lib -g -O2 -I/home/olympus/src/otp_src_R12B-0/erts/x86_64-\ unknown-linux-gnu ? ?-D_GNU_SOURCE -o ../priv/bin/x86_64-unknown-linux-gnu/ssl_\ esock ../priv/obj/x86_64-unknown-linux-gnu/esock.o ../priv/obj/x86_64-unknown-l\ inux-gnu/debuglog.o ../priv/obj/x86_64-unknown-linux-gnu/esock_poll.o ../priv/o\ bj/x86_64-unknown-linux-gnu/esock_osio.o ../priv/obj/x86_64-unknown-linux-gnu/e\ sock_utils.o ../priv/obj/x86_64-unknown-linux-gnu/esock_posix_str.o ../priv/obj\ /x86_64-unknown-linux-gnu/esock_openssl.o -lutil -ldl -lm ? -L/usr/local/lib -l\ ssl -lcrypto Error: /home/olympus/src/otp_src_R12B-0/lib/ssl/c_src/esock_openssl.c:909: undefined reference to `SSL_CTX_set_info_callback' collect2: ld returned 1 exit status make[4]: *** [../priv/bin/x86_64-unknown-linux-gnu/ssl_esock] Error 1 in the file esock_openssl.c line 909 I commented out the following function - and then it compiles correctly and I have not experianced any problems with SSL yet :) ? ?/* info callback */ ? ? // if (debug) ? ? // ?SSL_CTX_set_info_callback(ctx, info_callback); From fredrik.svahn@REDACTED Sun Dec 16 23:41:25 2007 From: fredrik.svahn@REDACTED (Fredrik Svahn) Date: Sun, 16 Dec 2007 23:41:25 +0100 Subject: [erlang-bugs] Slow process dictionary Message-ID: There seems to be something strange going on in the process dictionary in R12B-0. Operations which would take a tenth of a second in R11B-5 can now take more than 30 seconds. Please see test program below. Archictecture and OS: Linux laptop 2.6.24-rc1 #4 SMP Wed Oct 31 20:35:25 CET 2007 x86_64 AMD Turion(tm) 64 X2 Mobile Technology TL-60 AuthenticAMD GNU/Linux Erlang environment: Erlang (BEAM) emulator version 5.6 [source] [64-bit] [smp:2] [async-threads:0] [hipe] [kernel-poll:false] Thanks to Isaac Gouy for pointing out the differences between R11B-5 and R12B-0. The same problem can be found e.g. on the nsieve benchmark on the Computer Language Shootout on Intel P4/Gentoo ( http://shootout.alioth.debian.org/gp4/benchmark.php?test=nsieve&lang=hipe&id=0 ). BR /Fredrik Svahn --- $ otp_src_R11B-5/bin/erl -noshell -noinput -run test main 100000 {31993,ok} {98370,ok} $ otp_src_R11B-5/bin/erl -noshell -noinput -run test main 110000 {35415,ok} {104100,ok} --- $ erlc test.erl $ erl -noshell -noinput -run test main 100000 {100002,ok} {3575867,ok} $ erl -noshell -noinput -run test main 110000 {107884,ok} {33342695,ok} -module(test). -export([main/1, dict/1, reverse_dict/2]). main([Arg]) -> N=list_to_integer(Arg), io:format("~p~n",[timer:tc(?MODULE, reverse_dict, [N, 0])]), erase(), io:format("~p~n",[timer:tc(?MODULE, dict, [N])]), erlang:halt(0). reverse_dict(M, M) -> ok; reverse_dict(M, I) -> put(M, 0), reverse_dict(M, I+1). dict(1) -> ok; dict(M) -> put(M, 0), dict(M-1). -------------- next part -------------- An HTML attachment was scrubbed... URL: From opfer@REDACTED Mon Dec 17 08:09:48 2007 From: opfer@REDACTED (Christian Faulhammer) Date: Mon, 17 Dec 2007 08:09:48 +0100 Subject: [erlang-bugs] Dynamical link of SSL Message-ID: <20071217080948.2e526e61@gentoo.org> Hi, first off: Thanks for the productive reaction on my little patches. Secondly: Is there a specific reason SSL is not built dynamically in erts? (SSL_DYNAMIC_ONLY in configure.) We have several problems on hardened boxes and in connection with SSL support in ejabberd with it (text relocations)...but maybe there are severe reasons to deactivate that. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sgolovan@REDACTED Mon Dec 17 09:31:05 2007 From: sgolovan@REDACTED (Sergei Golovan) Date: Mon, 17 Dec 2007 11:31:05 +0300 Subject: [erlang-bugs] Dynamical link of SSL In-Reply-To: <20071217080948.2e526e61@gentoo.org> References: <20071217080948.2e526e61@gentoo.org> Message-ID: On 12/17/07, Christian Faulhammer wrote: > > Secondly: Is there a specific reason SSL is not built dynamically in > erts? (SSL_DYNAMIC_ONLY in configure.) We have several problems on > hardened boxes and in connection with SSL support in > ejabberd with it (text relocations)...but maybe there are severe reasons > to deactivate that. A short reason can be found in http://www.erlang.org/download/otp_src_R11B-5.readme (find OTP-6680). But I'd say that the real problem is that it's impossible (or I couldn't find a way) to enable dynamic linking without patching configure scripts. A minimal patch can be found at http://svn.berlios.de/wsvn/erlang-pkg/erlang/trunk/debian/patches/75dynamicssl.diff?op=file&rev=0&sc=0 but I don't think it's suitable for main Erlang/OTP distribution because it changes default behavior. -- Sergei Golovan From opfer@REDACTED Mon Dec 17 09:57:40 2007 From: opfer@REDACTED (Christian Faulhammer) Date: Mon, 17 Dec 2007 09:57:40 +0100 Subject: [erlang-bugs] Dynamical link of SSL In-Reply-To: References: <20071217080948.2e526e61@gentoo.org> Message-ID: <20071217095740.281706bc@gentoo.org> "Sergei Golovan" : > On 12/17/07, Christian Faulhammer wrote: > > > > Secondly: Is there a specific reason SSL is not built dynamically in > > erts? (SSL_DYNAMIC_ONLY in configure.) We have several problems on > > hardened boxes and in connection with SSL support in > > ejabberd with it (text relocations)...but maybe there are severe > > reasons to deactivate that. > A short reason can be found in > http://www.erlang.org/download/otp_src_R11B-5.readme (find OTP-6680). Ok, thanks for the pointer. > But I'd say that the real problem is that it's impossible (or I > couldn't find a way) to enable dynamic linking without patching > configure scripts. A minimal patch can be found at > http://svn.berlios.de/wsvn/erlang-pkg/erlang/trunk/debian/patches/75dynamicssl.diff?op=file&rev=0&sc=0 > but I don't think it's suitable for main Erlang/OTP distribution > because it changes default behavior. In what way does it change default behaviour (we already use that fix in Gentoo)? Because ejabberd won't work in our environment without dynamical linking. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From adam@REDACTED Mon Dec 17 16:08:31 2007 From: adam@REDACTED (Adam Lindberg) Date: Mon, 17 Dec 2007 16:08:31 +0100 Subject: [erlang-bugs] Chapter 12 in Erlang Reference Manual missing Message-ID: <6344005f0712170708i7d513d48k9e89984962e5099b@mail.gmail.com> Hi, Chapter 12 "Compilation and Code Loading" is missing from the Erlang Reference Manual available at erlang.org/doc. Instead the module documentation for the code module is linked to. Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Tue Dec 18 08:45:15 2007 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 18 Dec 2007 08:45:15 +0100 Subject: [erlang-bugs] Slow process dictionary In-Reply-To: References: Message-ID: "Fredrik Svahn" writes: > There seems to be something strange going on in the process dictionary in > R12B-0. > > Operations which would take a tenth of a second in R11B-5 can now take more > than 30 seconds. Please see test program below. Thanks for the bug report. We have found the cause for the problem and will fix it in R12B-1. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From fredrik.svahn@REDACTED Wed Dec 19 23:01:19 2007 From: fredrik.svahn@REDACTED (Fredrik Svahn) Date: Wed, 19 Dec 2007 23:01:19 +0100 Subject: [erlang-bugs] bug in bs_put_integer Message-ID: Seems similar to the bug reported by Oleg Avdeev on Dec 7, although it does not seem like the patch provided then solves this problem. Program compiles with R11B-5 but not with R12B-0. Problem: --------- $ erlc test2.erl test2: function f/1+10: Internal consistency check failed - please report this bug. Instruction: {bs_put_integer,{f,0}, {integer,8}, 1, {field_flags,[unsigned,big]}, {x,0}} Error: {match_context,{x,0}}: Test program: -------------- -module(test2). -export([f/1]). f(<<"A", H/binary>>) -> <<"B", H>>. BR /Fredrik Svahn -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Thu Dec 20 09:01:40 2007 From: vances@REDACTED (Vance Shipley) Date: Thu, 20 Dec 2007 03:01:40 -0500 Subject: [erlang-bugs] systools problem with resource file syntax Message-ID: <20071220080140.GB483@little-black-book.motivity.ca> If an application resource file contains an included application the included application should automatically be included in a release package which has including application listed in it's release resource file. The documentation for the release resource file lists the alternative form {Application, AppVsn, IncApps}: "IncApps = [atom()] is a list of applications that are included by an application included in the release. The list must be a subset of the included applications specified in the application resource file (Application.app) and overrides this value. Defaults to the empty list." In R12B-0 if the included application is not listed in the release resource file, or is only in an IncApps list, the error "Undefined applications" is returned. -Vance From bjorn@REDACTED Thu Dec 20 11:33:23 2007 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 20 Dec 2007 11:33:23 +0100 Subject: [erlang-bugs] bug in bs_put_integer In-Reply-To: References: Message-ID: "Fredrik Svahn" writes: > Seems similar to the bug reported by Oleg Avdeev on Dec 7, although it does > not seem like the patch provided then solves this problem. Program compiles > with R11B-5 but not with R12B-0. Thanks! Yes, a similar bug. I did look for more bugs when I prepared that patch, but I didn't realize that bs_put_integer could be passed a binary. We will correct the problem in R12B-1. Since the program will fail at run-time, I suppose that I don't need to post a patch. /Bjorn > Problem: > --------- > > $ erlc test2.erl > test2: function f/1+10: > Internal consistency check failed - please report this bug. > Instruction: {bs_put_integer,{f,0}, > {integer,8}, > 1, > {field_flags,[unsigned,big]}, > {x,0}} > Error: {match_context,{x,0}}: > > > Test program: > -------------- > -module(test2). > -export([f/1]). > > f(<<"A", H/binary>>) -> <<"B", H>>. > > > BR /Fredrik Svahn > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From fredrik.svahn@REDACTED Thu Dec 20 12:11:07 2007 From: fredrik.svahn@REDACTED (Fredrik Svahn) Date: Thu, 20 Dec 2007 12:11:07 +0100 Subject: [erlang-bugs] bug in bs_put_integer In-Reply-To: References: Message-ID: Thanks. No patch needed, I noticed the badarg and modified the real program accordingly. Just out of curiosity, does this imply that the above is something that will typically generate an error at compile time instead of at run time in R12B-1? Or will you handle it as a binary when the compiler is sure that is a binary and not the default integer type? It is probably a common beginners mistake to forget the TypeSpecifier. BR /Fredrik On 20 Dec 2007 11:33:23 +0100, Bjorn Gustavsson wrote: > "Fredrik Svahn" writes: > > > Seems similar to the bug reported by Oleg Avdeev on Dec 7, although it > does > > not seem like the patch provided then solves this problem. Program > compiles > > with R11B-5 but not with R12B-0. > > Thanks! > > Yes, a similar bug. I did look for more bugs when I prepared that patch, > but > I didn't realize that bs_put_integer could be passed a binary. > > We will correct the problem in R12B-1. Since the program will fail at > run-time, > I suppose that I don't need to post a patch. > > /Bjorn > > > Problem: > > --------- > > > > $ erlc test2.erl > > test2: function f/1+10: > > Internal consistency check failed - please report this bug. > > Instruction: {bs_put_integer,{f,0}, > > {integer,8}, > > 1, > > {field_flags,[unsigned,big]}, > > {x,0}} > > Error: {match_context,{x,0}}: > > > > > > Test program: > > -------------- > > -module(test2). > > -export([f/1]). > > > > f(<<"A", H/binary>>) -> <<"B", H>>. > > > > > > BR /Fredrik Svahn > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Thu Dec 20 12:29:08 2007 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 20 Dec 2007 12:29:08 +0100 Subject: [erlang-bugs] bug in bs_put_integer In-Reply-To: References: Message-ID: "Fredrik Svahn" writes: > Just out of curiosity, does this imply that the above is something that will > typically generate an error at compile time instead of at run time in > R12B-1? Or will you handle it as a binary when the compiler is sure that is > a binary and not the default integer type? It is probably a common beginners > mistake to forget the TypeSpecifier. Short answer: It will still be an error at run-time in R12B-1. There will probably not be a warning at compile time in R12B-1. In future releases, the compiler will probably generate more warnings for mistakes with binaries. It might not happen in R12B-1, since there is currently no filename/line number information available in the compiler pass (beam_bsm) that could easily detect the discrepancy. (Also, only a very limited class of errors would be discovered, while others would go unnoticed.) What we want to do is to incorporate a type analysis pass into the compiler, and use the result of the pass both for better optimizations and better warnings. It is unlikely to happen in R12B-1. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From erlang@REDACTED Sun Dec 23 19:20:34 2007 From: erlang@REDACTED (Dominic Williams) Date: Sun, 23 Dec 2007 19:20:34 +0100 Subject: [erlang-bugs] Double evaluation when using weird record syntax Message-ID: <476EA6F2.9050902@dominicwilliams.net> Hello, The compiler seems to generate a double evaluation in the following case: -module(double_evaluation). -export([run/0]). -record(r, {f}). maker(F) -> io:format("maker(~p)~n",[F]), #r{f=F}. run()-> (maker(1))#r{f=0}, (maker(2))#r{}. % maker/1 called twice Eshell V5.5.4 (abort with ^G) 1> c(double_evaluation). {ok,double_evaluation} 2> double_evaluation:run(). maker(1) maker(2) maker(2) {r,2} I am not even sure what it should mean to use #r{} after an expression with nothing between the braces, but this turned up in some production code, and the double evaluation appeared sometime after R8, causing a new bug in our system. Regards, Dominic Williams http://dominicwilliams.net ---- From hans.bolinder@REDACTED Thu Dec 27 15:17:46 2007 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 27 Dec 2007 15:17:46 +0100 Subject: [erlang-bugs] Double evaluation when using weird record syntax In-Reply-To: <476EA6F2.9050902@dominicwilliams.net> References: <476EA6F2.9050902@dominicwilliams.net> Message-ID: <18291.46090.888979.464062@gargle.gargle.HOWL> [Dominic Williams:] > The compiler seems to generate a double evaluation in the > following case: > > -module(double_evaluation). > -export([run/0]). > -record(r, {f}). > > maker(F) -> > io:format("maker(~p)~n",[F]), > #r{f=F}. > > run()-> > (maker(1))#r{f=0}, > (maker(2))#r{}. % maker/1 called twice Thanks for the bug report. The following patch should solve the problem: *** /usr/local/otp/releases/otp_beam_solaris8_r12b_patched/lib/stdlib-1.15/src/erl_expand_records.erl Tue Dec 4 16:55:18 2007 --- erl_expand_records.erl Thu Dec 27 14:59:36 2007 *************** *** 602,608 **** %% Try to be intelligent about which method of updating record to use. {Update,St} = if ! Nu =:= 0 -> {R,St2}; %No fields updated Nu =< Nc -> %Few fields updated {record_setel(Var, Name, Fs, Us), St2}; true -> %The wide area inbetween --- 602,608 ---- %% Try to be intelligent about which method of updating record to use. {Update,St} = if ! Nu =:= 0 -> {Var,St2}; %No fields updated Nu =< Nc -> %Few fields updated {record_setel(Var, Name, Fs, Us), St2}; true -> %The wide area inbetween There should be a test of the record type even if there are no updated fields. The patch below, which solves that problem, might not be included in any R12B release since it is not backwards compatible. For instance, "(#r2{})#r{}" will generate a 'badrecord' exception. Best regards, Hans Bolinder, Erlang/OTP team *** /usr/local/otp/releases/otp_beam_solaris8_r12b_patched/lib/stdlib-1.15/src/erl_expand_records.erl Tue Dec 4 16:55:18 2007 --- erl_expand_records.erl Thu Dec 27 14:31:46 2007 *************** *** 602,621 **** %% Try to be intelligent about which method of updating record to use. {Update,St} = if ! Nu =:= 0 -> {R,St2}; %No fields updated Nu =< Nc -> %Few fields updated {record_setel(Var, Name, Fs, Us), St2}; ! true -> %The wide area inbetween ! record_match(Var, Name, Fs, Us, St2) end, ! {{block,element(2, R),Pre ++ [{match,Line,Var,R},Update]},St}. %% record_match(Record, RecordName, [RecDefField], [Update], State) %% Build a 'case' expression to modify record fields. ! record_match(R, Name, Fs, Us, St0) -> {Ps,News,St1} = record_upd_fs(Fs, Us, St0), - Lr = element(2, hd(Us)), {{'case',Lr,R, [{clause,Lr,[{tuple,Lr,[{atom,Lr,Name} | Ps]}],[], [{tuple,Lr,[{atom,Lr,Name} | News]}]}, --- 602,621 ---- %% Try to be intelligent about which method of updating record to use. {Update,St} = if ! Nu =:= 0 -> ! record_match(Var, Name, Line, Fs, Us, St2); Nu =< Nc -> %Few fields updated {record_setel(Var, Name, Fs, Us), St2}; ! true -> %The wide area inbetween ! record_match(Var, Name, element(2, hd(Us)), Fs, Us, St2) end, ! {{block,Line,Pre ++ [{match,Line,Var,R},Update]},St}. %% record_match(Record, RecordName, [RecDefField], [Update], State) %% Build a 'case' expression to modify record fields. ! record_match(R, Name, Lr, Fs, Us, St0) -> {Ps,News,St1} = record_upd_fs(Fs, Us, St0), {{'case',Lr,R, [{clause,Lr,[{tuple,Lr,[{atom,Lr,Name} | Ps]}],[], [{tuple,Lr,[{atom,Lr,Name} | News]}]}, From hans.bolinder@REDACTED Thu Dec 27 16:32:35 2007 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 27 Dec 2007 16:32:35 +0100 Subject: [erlang-bugs] typo in 'io' manpage In-Reply-To: <18273.28109.878949.671790@antilipe.corelatus.se> References: <18273.28109.878949.671790@antilipe.corelatus.se> Message-ID: <18291.50579.28467.303085@gargle.gargle.HOWL> [Matthias Lang:] > In R12-B, there's a new function documented in the io module, called > columns/0. In the documentation (e.g. manpage, HTML, etc.) it's > incorrectly documented as colums/0. Thanks for pointing it out. Best regards, Hans Bolinder, Erlang/OTP team From hans.bolinder@REDACTED Thu Dec 27 16:35:36 2007 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 27 Dec 2007 16:35:36 +0100 Subject: [erlang-bugs] gen_server:reply/2 documentation In-Reply-To: <9e009ad0712140415l3f26d276m864a864cad5ecbac@mail.gmail.com> References: <9e009ad0712140415l3f26d276m864a864cad5ecbac@mail.gmail.com> Message-ID: <18291.50760.298316.798515@gargle.gargle.HOWL> [Joern:] > gen_server:reply/2 on R11B-5/win32 returns > > { Ref, Reply } > > instead of > > true Thanks for pointing it out. The documentation should state that the return value is to be ignored. Best regards, Hans Bolinder, Erlang/OTP team