From xramtsov@REDACTED Fri Nov 1 04:49:03 2013 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Fri, 01 Nov 2013 13:49:03 +1000 Subject: [erlang-bugs] Broken file:file_info/1 In-Reply-To: <52728687.5090500@ninenines.eu> References: <52728687.5090500@ninenines.eu> Message-ID: <527324AF.5060806@gmail.com> On 01.11.2013 02:34, Lo?c Hoguin wrote: > ** exception error: undefined function erlang:nif_error/1 > This is quite funny, by the way: 1> erlang:nif_error(undef). ** exception error: undefined function erlang:nif_error/1 erlang:nif_error/1 tells us it doesn't exist :) From n.oxyde@REDACTED Fri Nov 1 12:29:14 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 1 Nov 2013 12:29:14 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <524D636B.4080508@erlang.org> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> Message-ID: <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> Ping? This is still ? Status: Author ? in the Development page. -- Anthony Ramine Le 3 oct. 2013 ? 14:30, Henrik Nord a ?crit : > I will move it into the que > Thank you for your contribution! From lukas@REDACTED Fri Nov 1 17:50:43 2013 From: lukas@REDACTED (Lukas Larsson) Date: Fri, 1 Nov 2013 17:50:43 +0100 Subject: [erlang-bugs] Problem with _create_dirs and erl_compile_flags.h In-Reply-To: <526E9F2E.5060508@erlang.org> References: <526E9F2E.5060508@erlang.org> Message-ID: <5273DBE3.8090402@erlang.org> Hello, I believe I have found the problem. Could you please try the fix[1] and see if it solves your problem? Lukas [1]: https://github.com/garazdawi/otp/tree/lukas/erts/make_deps_fixes On 28/10/13 18:30, Lukas Larsson wrote: > Hello, > > Just letting you know that I have seen this. It is somewhere on my > todo list to fix :) > > Lukas > > On 19/10/13 13:13, Anthony Ramine wrote: >> Hello, >> >> Johan Vikman (Cc'd) reported a bug on kerl [1] when building R16B02 >> and I can reproduce it on latest maint too. Apparently there is a >> problem in one of the makefiles where >> `x86_64-apple-darwin12.5.0/opt/plain` (e.g. where binary objects are >> built) does not exist prior to calling `utils/make_compiler_flags` to >> produce the `erl_compile_flags.h` file. >> >> can't open >> x86_64-apple-darwin12.5.0/opt/plain/erl_compile_flags.h for writing >> at utils/make_compiler_flags line 65. >> >> I don't understand how the `_create_dirs` machinery works so I report >> the bug here. >> >> Regards, >> >> [1] https://github.com/spawngrid/kerl/issues/51 >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From mamuelle@REDACTED Sun Nov 3 17:33:23 2013 From: mamuelle@REDACTED (Magnus =?UTF-8?B?TcO8bGxlcg==?=) Date: Sun, 3 Nov 2013 17:33:23 +0100 Subject: [erlang-bugs] Regression? No warning on unused variable in try part of try..catch Message-ID: <20131103173323.f400a31f0b1574b1d52c3aac@informatik.hu-berlin.de> Hello, R16B02 does not output a warning when a variable within try..catch is unused. Example: -module(try_catch). -export([no_warning/0]). no_warning() -> try X = 1 catch _:_ -> ok end. $ erlc try_catch.erl evnu@REDACTED:~/src/erlang/otp/bugs/R16B02 $ echo $? 0 In R15B03, a warning is written: $ erlc try_catch.erl try_catch.erl:5: Warning: variable 'X' is unused I tried the above with the `master` branch as well: $ git log --oneline | head -n1 69a0e01 Merge branch 'maint $ bin/erl Erlang R17A (erts-5.11) [source-69a0e01] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.11 (abort with ^G) 1> c("../bugs/R16B02/try_catch.erl"). {ok,try_catch} Magnus From essen@REDACTED Mon Nov 4 16:09:58 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 04 Nov 2013 16:09:58 +0100 Subject: [erlang-bugs] hipe:help_options() dupe option Message-ID: <5277B8C6.9070803@ninenines.eu> Hello, Just want to point out that icode_range option is repeated in both o2 and o3 (which includes o2) when you run hipe:help_options(). o2 = [icode_range|_] ++ o1, o3 = [{regalloc,coalescing},icode_range] ++ o2. I'm guessing this isn't on purpose. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From shino.shun@REDACTED Tue Nov 5 15:45:03 2013 From: shino.shun@REDACTED (Shunichi Shinohara) Date: Tue, 5 Nov 2013 23:45:03 +0900 Subject: [erlang-bugs] release_handler error in upgrading slim release Message-ID: I try to make rebar work with slim release at https://github.com/rebar/rebar/pull/52 . Almost all goes well, but in upgrading in slim release environment an error occurs and fails. (R16B02, Linux) To simplify step to reproduce, I created repository which has rebar binary and some configuration files. https://github.com/shino/slim-upgrade-sample Steps to reproduce: 0. Clone the repository and cd to it. git clone https://github.com/shino/slim-upgrade-sample.git 1. Generate version 1 and 2 of releases and upgrade package between them. The script generate.sh in the repo does this work. 2. Boot the node with release version 1 and try to unpack the upgrade package. 3. The following error occurs. > release_handler:unpack_release("sample_2"). {error,{enoent, "/opt/shino/scm/slim-upgrade-sample/sample/rel/sample_1/releases/sample_2.rel"}} "/opt/shino/scm/slim-upgrade-sample/sample/rel/sample_1/" is root directory of slim release generated by reltool. The file "sample_2.rel" which release_handler complains not-found goes under the "releases" directory of Erlang/OTP which execute the node. Quick look of source code, release_handler seems to assume "releases" directory exists just under root directory (it's appropriate for normal, non-slim release). - extract_rel_file/2: Extract rel file in tar ball under root directory. https://github.com/erlang/otp/blob/OTP_R16B02/lib/sasl/src/release_handler.erl#L835 - check_rel/3,4: Try rel file under releases directory of slim release. https://github.com/erlang/otp/blob/OTP_R16B02/lib/sasl/src/release_handler.erl#L836 P.S. Sorry that steps to reproduce contain non-OTP, rebar related things. I hope rebar is not related the error because of release_handler's code above. Best Regards, Shino From tristan.sloughter@REDACTED Tue Nov 5 16:55:18 2013 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Tue, 05 Nov 2013 07:55:18 -0800 Subject: [erlang-bugs] release_handler error in upgrading slim release In-Reply-To: References: Message-ID: <1383666918.29973.43307189.300E040C@webmail.messagingengine.com> I don't think there is any bug here but just how systools works, and how picky it is. I'd suggest looking at relx and these 2 examples of making upgrades with it: https://github.com/extend/elevators https://github.com/blt/beat/ And http://learnyousomeerlang.com/relups On Tue, Nov 5, 2013, at 06:45 AM, Shunichi Shinohara wrote: > I try to make rebar work with slim release at > https://github.com/rebar/rebar/pull/52 . > Almost all goes well, but in upgrading in slim release environment > an error occurs and fails. (R16B02, Linux) > > To simplify step to reproduce, I created repository which has > rebar binary and some configuration files. > https://github.com/shino/slim-upgrade-sample > > Steps to reproduce: > 0. Clone the repository and cd to it. > git clone https://github.com/shino/slim-upgrade-sample.git > 1. Generate version 1 and 2 of releases and upgrade package between > them. The script generate.sh in the repo does this work. > 2. Boot the node with release version 1 and try to unpack the upgrade > package. > 3. The following error occurs. > > release_handler:unpack_release("sample_2"). > {error,{enoent, > "/opt/shino/scm/slim-upgrade-sample/sample/rel/sample_1/releases/sample_2.rel"}} > > "/opt/shino/scm/slim-upgrade-sample/sample/rel/sample_1/" is root > directory > of slim release generated by reltool. > The file "sample_2.rel" which release_handler complains not-found goes > under the "releases" directory of Erlang/OTP which execute the node. > Quick look of source code, release_handler seems to assume "releases" > directory > exists just under root directory (it's appropriate for normal, > non-slim release). > > - extract_rel_file/2: Extract rel file in tar ball under root directory. > https://github.com/erlang/otp/blob/OTP_R16B02/lib/sasl/src/release_handler.erl#L835 > - check_rel/3,4: Try rel file under releases directory of slim release. > https://github.com/erlang/otp/blob/OTP_R16B02/lib/sasl/src/release_handler.erl#L836 > > P.S. > Sorry that steps to reproduce contain non-OTP, rebar related things. > I hope rebar is not related the error because of release_handler's code > above. > > Best Regards, > Shino > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From shino.shun@REDACTED Wed Nov 6 02:47:00 2013 From: shino.shun@REDACTED (Shunichi Shinohara) Date: Wed, 6 Nov 2013 10:47:00 +0900 Subject: [erlang-bugs] release_handler error in upgrading slim release In-Reply-To: <1383666918.29973.43307189.300E040C@webmail.messagingengine.com> References: <1383666918.29973.43307189.300E040C@webmail.messagingengine.com> Message-ID: Tristan, Thank you very much for information. I will check the examples and relx. On Wed, Nov 6, 2013 at 12:55 AM, Tristan Sloughter wrote: > I don't think there is any bug here but just how systools works, and how > picky it is. > > I'd suggest looking at relx and these 2 examples of making upgrades with > it: > > https://github.com/extend/elevators > https://github.com/blt/beat/ > > And http://learnyousomeerlang.com/relups > > On Tue, Nov 5, 2013, at 06:45 AM, Shunichi Shinohara wrote: >> I try to make rebar work with slim release at >> https://github.com/rebar/rebar/pull/52 . >> Almost all goes well, but in upgrading in slim release environment >> an error occurs and fails. (R16B02, Linux) >> >> To simplify step to reproduce, I created repository which has >> rebar binary and some configuration files. >> https://github.com/shino/slim-upgrade-sample >> >> Steps to reproduce: >> 0. Clone the repository and cd to it. >> git clone https://github.com/shino/slim-upgrade-sample.git >> 1. Generate version 1 and 2 of releases and upgrade package between >> them. The script generate.sh in the repo does this work. >> 2. Boot the node with release version 1 and try to unpack the upgrade >> package. >> 3. The following error occurs. >> > release_handler:unpack_release("sample_2"). >> {error,{enoent, >> "/opt/shino/scm/slim-upgrade-sample/sample/rel/sample_1/releases/sample_2.rel"}} >> >> "/opt/shino/scm/slim-upgrade-sample/sample/rel/sample_1/" is root >> directory >> of slim release generated by reltool. >> The file "sample_2.rel" which release_handler complains not-found goes >> under the "releases" directory of Erlang/OTP which execute the node. >> Quick look of source code, release_handler seems to assume "releases" >> directory >> exists just under root directory (it's appropriate for normal, >> non-slim release). >> >> - extract_rel_file/2: Extract rel file in tar ball under root directory. >> https://github.com/erlang/otp/blob/OTP_R16B02/lib/sasl/src/release_handler.erl#L835 >> - check_rel/3,4: Try rel file under releases directory of slim release. >> https://github.com/erlang/otp/blob/OTP_R16B02/lib/sasl/src/release_handler.erl#L836 >> >> P.S. >> Sorry that steps to reproduce contain non-OTP, rebar related things. >> I hope rebar is not related the error because of release_handler's code >> above. >> >> Best Regards, >> Shino >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs From anton.ryabkov@REDACTED Wed Nov 6 02:09:31 2013 From: anton.ryabkov@REDACTED (Anton Ryabkov) Date: Wed, 6 Nov 2013 08:09:31 +0700 Subject: [erlang-bugs] mnesia:dirty_update_counter return ok instead of integer Message-ID: Hello, on Erlang R16B02 (also in previous versions) I've found that mnesia:dirty_update_counter return 'ok' instead of integer when I subscribed on detailed events for the "update counter's" table. Example: 1> mnesia:start(). ok 2> mnesia:create_table(update_counter_table, [{ram_copies, [node()]}, {attributes, [key, counter]}]). {atomic,ok} 3> mnesia:dirty_update_counter(update_counter_table, key1, 1). 1 4> mnesia:dirty_update_counter(update_counter_table, key1, 1). 2 5> mnesia:dirty_update_counter(update_counter_table, key1, 1). 3 6> mnesia:subscribe({table, update_counter_table, detailed}). {ok,nonode@REDACTED} 7> mnesia:dirty_update_counter(update_counter_table, key2, 1). ok 8> mnesia:dirty_update_counter(update_counter_table, key2, 1). ok 9> mnesia:dirty_update_counter(update_counter_table, key2, 1). ok I have chaned code of mnesia and found that in mnesia_tm:1790 catched error with reason: {function_clause, [{mnesia_subscr,what, [update_counter_table, {dirty,<0.33.0>}, {update_counter_table,key1,10}, write, [{update_counter_table,key1,9}]], [{file,"mnesia_subscr.erl"},{line,188}]}, {mnesia_subscr,report_table_event,6, [{file,"mnesia_subscr.erl"},{line,172}]}, {mnesia_tm,commit_update,6, [{file,"mnesia_tm.erl"},{line,1865}]}, {mnesia_tm,do_update_op,3, [{file,"mnesia_tm.erl"},{line,1833}]}, {mnesia_tm,do_update,4,[{file,"mnesia_tm.erl"},{line,1790}]}, {mnesia_tm,do_commit,3,[{file,"mnesia_tm.erl"},{line,1782}]}, {mnesia_tm,async_send_dirty,6, [{file,"mnesia_tm.erl"},{line,1994}]}, {mnesia_tm,dirty,2,[{file,"mnesia_tm.erl"},{line,1077}]}]}. The problem in the mnesia_subscr, It try prepare event for update_counter like for write, but doesn't expect that Old row value may be NOT undefined (like in case with update_counter). Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Tue Nov 5 13:05:22 2013 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Tue, 5 Nov 2013 13:05:22 +0100 Subject: [erlang-bugs] bug in HiPE for <<_/utf8,...>> In-Reply-To: Message-ID: <21112.57090.251605.190607@gargle.gargle.HOWL> On Mon Sep 9 16:20:38 CEST 2013, Sebastian Egner wrote: > Hi, > > There seems to be a Heisenbug in HiPE related to matching <<_/utf8,...>>. > > After a long and bloody fight, we have been able to isolate the problem to the degree > that it is sufficiently reproducible. See details below. > > We strongly suspect that the problem is a genuine bug related to the binary matching > and the garbage collector. Whether the bug is hit depends on the memory contents > of previously allocated heap-allocated binaries. > > Best regards, > Johannes Weissl and Sebastian Egner. > > -- > > Details: > - The program 'crash.erl' loads a JSON sample file. Then it parses the file again and again, > and after a wildly varying number of iterations (100-100000) the parser fails. > - To run the program, execute "crash_it" in a directory containing "crash.erl" and "data.jsn". > When the bug is hit, the program stops. This takes several seconds to minutes. > - The problem manifests itself when <<"0123...">> does not match <<_/utf8,_/binary>> > in the function crash:check_utf8_binary/1. (The program aborts with an exception exit.) > - Surprisingly, we have not been able to reduce the program even more. > In particular, when randomize_memory/0 is not called, the problem is much less frequent. > - The bug is present in R13B02, R14B04, R16B01, "maint" (2f28245) and master (45eaf81). > - The bug is present under MacOSX (10.8.4), Debian GNU/Linux and a Linux in an ARM emulator. > This indicates that the bug is not related to the operating system platform. > - We have run the program in Valgrind and found conditionals that depend on uninitialised > values. Refer to "valgrind.out" for details. Confirmed, I can reproduce the crash with R16B02 on Linux/x86_64 (Fedora). /Mikael From dgud@REDACTED Wed Nov 6 17:28:07 2013 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 6 Nov 2013 17:28:07 +0100 Subject: [erlang-bugs] mnesia:dirty_update_counter return ok instead of integer In-Reply-To: References: Message-ID: Ok thanks, will have a look at it Den 6 nov 2013 11:42 skrev "Anton Ryabkov" : > Hello, > > on Erlang R16B02 (also in previous versions) I've found that > mnesia:dirty_update_counter return 'ok' instead of integer when I > subscribed on detailed events for the "update counter's" table. > > Example: > > 1> mnesia:start(). > ok > 2> mnesia:create_table(update_counter_table, [{ram_copies, [node()]}, > {attributes, [key, counter]}]). > {atomic,ok} > 3> mnesia:dirty_update_counter(update_counter_table, key1, 1). > 1 > 4> mnesia:dirty_update_counter(update_counter_table, key1, 1). > 2 > 5> mnesia:dirty_update_counter(update_counter_table, key1, 1). > 3 > > 6> mnesia:subscribe({table, update_counter_table, detailed}). > {ok,nonode@REDACTED} > 7> mnesia:dirty_update_counter(update_counter_table, key2, 1). > ok > 8> mnesia:dirty_update_counter(update_counter_table, key2, 1). > ok > 9> mnesia:dirty_update_counter(update_counter_table, key2, 1). > ok > > I have chaned code of mnesia and found that in mnesia_tm:1790 catched > error with reason: > > {function_clause, > [{mnesia_subscr,what, > [update_counter_table, > {dirty,<0.33.0>}, > {update_counter_table,key1,10}, > write, > [{update_counter_table,key1,9}]], > [{file,"mnesia_subscr.erl"},{line,188}]}, > {mnesia_subscr,report_table_event,6, > [{file,"mnesia_subscr.erl"},{line,172}]}, > {mnesia_tm,commit_update,6, > [{file,"mnesia_tm.erl"},{line,1865}]}, > {mnesia_tm,do_update_op,3, > [{file,"mnesia_tm.erl"},{line,1833}]}, > {mnesia_tm,do_update,4,[{file,"mnesia_tm.erl"},{line,1790}]}, > {mnesia_tm,do_commit,3,[{file,"mnesia_tm.erl"},{line,1782}]}, > {mnesia_tm,async_send_dirty,6, > [{file,"mnesia_tm.erl"},{line,1994}]}, > {mnesia_tm,dirty,2,[{file,"mnesia_tm.erl"},{line,1077}]}]}. > > > The problem in the mnesia_subscr, It try prepare event for update_counter > like for write, but doesn't expect that Old row value may be NOT undefined > (like in case with update_counter). > > Anton > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Thu Nov 7 20:10:22 2013 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 07 Nov 2013 11:10:22 -0800 Subject: [erlang-bugs] ct should depend on sasl Message-ID: <527BE59E.9060208@gmail.com> Hi, sasl is a missing dependency here https://github.com/erlang/otp/blob/maint/lib/common_test/src/common_test.app.src#L64 due to the usage of error_logger from here https://github.com/erlang/otp/blob/maint/lib/common_test/src/ct_hooks.erl#L39 Thanks, Michael From henrik@REDACTED Mon Nov 11 15:42:37 2013 From: henrik@REDACTED (Henrik Nord) Date: Mon, 11 Nov 2013 15:42:37 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> Message-ID: <5280ECDD.3020001@erlang.org> Its moving forward as we speak. Thank you for your contribution! On 2013-11-01 12:29, Anthony Ramine wrote: > Ping? This is still ? Status: Author ? in the Development page. > -- /Henrik Nord Erlang/OTP From yusong.gao@REDACTED Wed Nov 13 04:28:37 2013 From: yusong.gao@REDACTED (Yusong Gao) Date: Wed, 13 Nov 2013 11:28:37 +0800 Subject: [erlang-bugs] badmatch error when use cpu_sup in high load server Message-ID: Hello, I got a badmatch error when use cpu_sup in high load server. {{badmatch,{more,"~d",24,[164,6.017000e+01,1.002000e+02,1.223600e+02]}},[{cpu_sup,get_uint32_measurement,2,[{file,"cpu_sup.erl"},{line,226}]},{cpu_sup,measurement_server_loop,1,[{file,"cpu_sup.erl"},{line,585}]}]} I read the code, and when /proc/loadavg is 252.64 163.23 74.37 127/4840 18828, "{ok,D} = file:read(F,24)" gets 252.64 163.23 74.37 127/, and it is not enough for io_lib:fread("~f ~f ~f ~d/~d", D). so changing 24 to 48 may be a good idea. Yusong Gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostiamalikov@REDACTED Wed Nov 13 05:05:00 2013 From: kostiamalikov@REDACTED (Constantin Malikov) Date: Wed, 13 Nov 2013 11:05:00 +0700 Subject: [erlang-bugs] BugReport_syntax_tools_invalid_number_string Message-ID: Hello , friends. I want to tell you about a bug in Erlang: I have differences between result of using methods map() and input data. I attached simple sample, where you can see this differences. 1) For getitng syntax tree input: _______________________________________________________________________ {ok, Forms} = epp:parse_file("example.erl", [], []). _______________________________________________________________________ You get this: _______________________________________________________________________ {ok,[{attribute,1,file,{"example.erl",1}}, {attribute,1,module,example}, {attribute,3,export,[{handle_event,2}]}, {function,5,handle_event,2, [{clause,5, [{var,5,'_'},{var,5,'_'}], [], [{cons,6, {tuple,6,[]}, {cons,7,{nil,7},{cons,8,{...},...}}}]}]}, {eof,9}]} _______________________________________________________________________ 2) Then input: _______________________________________________________________________ io:format("~p~n",[Forms]). _______________________________________________________________________ You get this: _______________________________________________________________________ [{attribute,1,file,{"example.erl",1}}, {attribute,1,module,example}, {attribute,3,export,[{handle_event,2}]}, {function,5,handle_event,2, [{clause,5, [{var,5,'_'},{var,5,'_'}], [], [{cons,6, {tuple,6,[]}, {cons,7, {nil,7}, {cons,8, {cons,8,{atom,8,asd},{cons,8,{atom,8,asd},{nil,8}}}, {nil,8}}}}]}]}, {eof,9}] ok _______________________________________________________________________ 3) Then input: _______________________________________________________________________ Form = {function,5,handle_event,2, [{clause,5, [{var,5,'_'},{var,5,'_'}], [], [{cons,6, {tuple,6,[]}, {cons,7, {nil,7}, {cons,8, {cons,8,{atom,8,asd},{cons,8,{atom,8,asd},{nil,8}}}, {nil,8}}}}]}]}. _______________________________________________________________________ You get: _______________________________________________________________________{function,5,handle_event,2, [{clause,5, [{var,5,'_'},{var,5,'_'}], [], [{cons,6, {tuple,6,[]}, {cons,7, {nil,7}, {cons,8, {cons,8,{atom,8,asd},{cons,8,...}}, {nil,8}}}}]}]} _______________________________________________________________________ 4) Now, I will try to traverse the data via erl_syntax_lib:map(): _______________________________________________________________________ erl_syntax_lib:map(fun (El) -> io:format("~p~n", [erl_syntax:revert(El)]), El end, Form). _______________________________________________________________________ You get: ____________________________________________ {atom,5,handle_event} {var,5,'_'} {var,5,'_'} {tuple,6,[]} {nil,7} {atom,8,asd} {atom,8,asd} {cons,8,{atom,8,asd},{cons,8,{atom,8,asd},{nil,8}}} {cons,6, {tuple,6,[]}, {cons,6, {nil,7}, {cons,6, {cons,8,{atom,8,asd},{cons,8,{atom,8,asd},{nil,8}}}, {nil,8}}}} {clause,5, [{var,5,'_'},{var,5,'_'}], [], [{cons,6, {tuple,6,[]}, {cons,6, {nil,7}, {cons,6, {cons,8,{atom,8,asd},{cons,8,{atom,8,asd},{nil,8}}}, {nil,8}}}}]} {function,5,handle_event,2, [{clause,5, [{var,5,'_'},{var,5,'_'}], [], [{cons,6, {tuple,6,[]}, {cons,6, {nil,7}, {cons,6, {cons,8,{atom,8,asd},{cons,8,{atom,8,asd},{nil,8}}}, {nil,8}}}}]}]} {tree,function, {attr,5,[],none}, {func, {tree,atom,{attr,5,[],none},handle_event}, [{tree,clause, {attr,5,[],none}, {clause, [{var,5,'_'},{var,5,'_'}], none, [{tree,list, {attr,6,[],none}, {list, [{tuple,6,[]},{nil,7},{tree,list,{...},...}], {nil,8}}}]}}]}} _______________________________________________________________________ Part of initial datas is: _______________________________________________________________________ [{cons,6, {tuple,6,[]}, {cons,7, {nil,7}, {cons,8, {cons,8,{atom,8,asd},{cons,8,{atom,8,asd},{nil,8}}}, {nil,8}}}}] _______________________________________________________________________ But i get: _______________________________________________________________________ [{cons,6, {tuple,6,[]}, {cons,6, {nil,7}, {cons,6, {cons,8,{atom,8,asd},{cons,8,{atom,8,asd},{nil,8}}}, {nil,8}}}}] _______________________________________________________________________ Unexpected change original: ?{cons,7,? to ?{cons,6,? and ?{cons,8,? to ?{cons,6,?. Tested by Erlang 16B02 syntax_tools-1.6.11, and R15B02, syntax_tools-1.6.9 __________________________example.erl____________________________________-module(example). -export([handle_event/2]). handle_event( _, _) -> [ {}, [], [asd,asd] ]. _______________________________________________________________________ With best regards, Malikov Constantin, software developer, Eltex. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: syntax_tools_invalid_number_string.tar.gz Type: application/x-gzip Size: 21369 bytes Desc: not available URL: From magnus@REDACTED Wed Nov 13 13:38:59 2013 From: magnus@REDACTED (Magnus Henoch) Date: Wed, 13 Nov 2013 12:38:59 +0000 Subject: [erlang-bugs] eunit_surefire doesn't ensure proper UTF-8 encoding Message-ID: <87r4ak1noc.fsf@mia.config> Compile the following module and run eunit_xml_encoding_bug:doit() from an Erlang shell: -module(eunit_xml_encoding_bug). -compile(export_all). -include_lib("eunit/include/eunit.hrl"). doit() -> eunit:test(?MODULE, [{report, {eunit_surefire,[]}}]). my_test_() -> ?_test(io:format([128,10])). This creates a file called TEST-eunit_xml_encoding_bug.xml which claims to be in UTF-8 (its first line is '') but contains an improperly encoded character. Most XML tools will refuse to do anything with such an XML file. For example xmllint says: $ xmllint /tmp/TEST-eunit_xml_encoding_bug.xml /tmp/TEST-eunit_xml_encoding_bug.xml:4: parser error : Input is not proper UTF-8, indicate encoding ! And opening the file in Firefox yields: XML Parsing Error: not well-formed Location: file:///tmp/TEST-eunit_xml_encoding_bug.xml Line Number 4, Column 17: I came across this problem when running a Quickcheck property inside Eunit. The Quickcheck property would output random binary data with io:format("~p"), and sometimes that would end up being high bytes which were valid Latin-1 but invalid UTF-8. As eunit_surefire declares its output files to be in UTF-8 encoding, I think it should check that the contents of etc are properly encoded, and if not do something about it, e.g. convert from Latin-1 to UTF-8 or insert replacement characters (U+FFFD). Regards, Magnus From n.oxyde@REDACTED Thu Nov 14 13:26:42 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 14 Nov 2013 13:26:42 +0100 Subject: [erlang-bugs] Rewrite merge of clause variable tables (in case, try, etc) Message-ID: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> Hello, I have finally got around fixing the two regressions reported in R16B02 with regard to unused variable warnings. The fix was more complicated than what I expected it to be. git fetch https://github.com/nox/otp.git fix-exporting-rules https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules.patch Regards, -- Anthony Ramine From fredrik@REDACTED Fri Nov 15 08:59:21 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 15 Nov 2013 08:59:21 +0100 Subject: [erlang-bugs] [erlang-patches] Rewrite merge of clause variable tables (in case, try, etc) In-Reply-To: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> References: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> Message-ID: <5285D459.2060807@erlang.org> On 11/14/2013 01:26 PM, Anthony Ramine wrote: > Hello, > > I have finally got around fixing the two regressions reported in R16B02 with regard to unused variable warnings. > > The fix was more complicated than what I expected it to be. > > git fetch https://github.com/nox/otp.git fix-exporting-rules > > https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules > https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules.patch > > Regards, > Hello Anthony, I've fetched your patch and assigned it to be reviewed. Thanks for contribution, -- BR Fredrik Gustafsson Erlang OTP Team From samuelrivas@REDACTED Fri Nov 15 09:42:44 2013 From: samuelrivas@REDACTED (Samuel) Date: Fri, 15 Nov 2013 09:42:44 +0100 Subject: [erlang-bugs] eunit_surefire doesn't ensure proper UTF-8 encoding In-Reply-To: <87r4ak1noc.fsf@mia.config> References: <87r4ak1noc.fsf@mia.config> Message-ID: We have seen this in the past, but we fixed it in our own surefire rebar plugin. If I remember right, the problem is not in eunit_surefire.erl but in eunit itself. Below some information I dug out of my emal (unfortunately I never found time to produce a proper patch for this: ------ I am pretty sure the patch https://github.com/richcarl/eunit/commit/9f505f1b8881f44c1e5d37df005533b2af6d6a7e does not solve the right problem. As far as I can understand, the output is already in binary state when it reaches the eunit_surefile code, which means that it is already encoded. The patch seems to work because the encoding happened to be latin1 (by coincidence) and then re-encoding to UTF8 works. The root issue seems to be in eunit_proc, that ignores the encoding of the io_requests and then buffer_to_binary just does list_to_binary. The patch seems to work because it does the right thing for codepoints between 127 and 255, as they are the same as the latin1 encoding for them. Thus they get properly encoded to utf-8 when writing the xml file, but will probably fail if the binary passed to eunit_surefile were properly encoded in utf-8. There is a major issue with that, and is that eunit_proc will crash if any test outputs a codepoint higher than 255, I think I have a proper fix for that but I haven't had the time to test it thoroughly yet. When fixed, the surefile report must be written in raw again, as the binaries should be utf8 encoded already. Next patch makes it work again, but is a hack, as it assumes the strings to be unicode in the list form and utf8 in the binary form (which I guess is true in current OTP implementation): -buffer_to_binary(Buf) -> list_to_binary(lists:reverse(Buf)). +buffer_to_binary(Buf) -> unicode:characters_to_binary(lists:reverse(Buf)). As an example, the attached suite causes this when run: > eunit_unicode_crash:test(). =ERROR REPORT==== 27-Aug-2012::14:26:49 === Error in process <0.78.0> with exit value: {badarg,[{erlang,list_to_binary,[[[[1013],"\n"]]],[]},{eunit_proc,buffer_to_binary,1,[{file,"eunit_proc.erl"},{line,276}]},{eunit_proc,group_leader_loop,3,[{file,"eunit_proc.erl"},{line,600}]}]} eunit_unicode_crash: unicode_test (module 'eunit_unicode_crash')...*skipped* undefined *unexpected termination of test process* ::{badarg,[{erlang,list_to_binary,[[[[1013],"\n"]]],[]}, {eunit_proc,buffer_to_binary,1, [{file,"eunit_proc.erl"},{line,276}]}, {eunit_proc,group_leader_loop,3, [{file,"eunit_proc.erl"},{line,600}]}]} On 13 November 2013 13:38, Magnus Henoch wrote: > Compile the following module and run eunit_xml_encoding_bug:doit() from > an Erlang shell: > > -module(eunit_xml_encoding_bug). > > -compile(export_all). > > -include_lib("eunit/include/eunit.hrl"). > > doit() -> > eunit:test(?MODULE, [{report, {eunit_surefire,[]}}]). > > my_test_() -> > ?_test(io:format([128,10])). > > This creates a file called TEST-eunit_xml_encoding_bug.xml which claims > to be in UTF-8 (its first line is '') > but contains an improperly encoded character. Most XML tools will > refuse to do anything with such an XML file. For example xmllint says: > > $ xmllint /tmp/TEST-eunit_xml_encoding_bug.xml > /tmp/TEST-eunit_xml_encoding_bug.xml:4: parser error : Input is not proper UTF-8, indicate encoding ! > > And opening the file in Firefox yields: > > XML Parsing Error: not well-formed > Location: file:///tmp/TEST-eunit_xml_encoding_bug.xml > Line Number 4, Column 17: > > I came across this problem when running a Quickcheck property inside > Eunit. The Quickcheck property would output random binary data with > io:format("~p"), and sometimes that would end up being high bytes which > were valid Latin-1 but invalid UTF-8. > > As eunit_surefire declares its output files to be in UTF-8 encoding, I > think it should check that the contents of etc are properly > encoded, and if not do something about it, e.g. convert from Latin-1 to > UTF-8 or insert replacement characters (U+FFFD). > > Regards, > Magnus > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: eunit_unicode_crash.erl Type: text/x-erlang Size: 147 bytes Desc: not available URL: From daimon@REDACTED Fri Nov 15 10:46:05 2013 From: daimon@REDACTED (Masatake Daimon) Date: Fri, 15 Nov 2013 18:46:05 +0900 Subject: [erlang-bugs] R16B02: Dialyzer consumes too much, if not infinite, amount of memory for some apps Message-ID: <5285ED5D.90209@ymir.co.jp> Hello, I'm using R16B02 on 64-bit Linux. When building PLT, Dialyzer consumes too much memory that even reaches to 1.5 GiB for some applications: > % (ulimit -v 1572864; dialyzer --build_plt --output_plt syntax_tools.plt --statistics --apps syntax_tools) > Creating PLT syntax_tools.plt ... > compile (+0.02s): 1.10s ( 9 modules) > clean (+0.00s): 0.02s > remote (+0.05s): 1.56s > order (+0.01s): 0.06s > typesig (+0.00s): > Crash dump was written to: erl_crash.dump > eheap_alloc: Cannot allocate 123210440 bytes of memory (of type "heap"). Prologue of the crash dump: > =erl_crash_dump:0.2 > Fri Nov 15 17:07:48 2013 > Slogan: eheap_alloc: Cannot allocate 123210440 bytes of memory (of type "heap"). > System version: Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] > Compiled: Thu Nov 14 19:14:45 2013 > Taints: > Atoms: 12021 > =memory > total: 722308232 > processes: 498144488 > processes_used: 497536304 > system: 224163744 > atom: 339441 > atom_used: 322213 > binary: 607984 > code: 6600866 > ets: 213161040 The process with the largest heap (259 MiB): > =proc:<0.283.0> > State: Garbing > Spawned as: erlang:apply/2 > Last scheduled in for: erl_types:t_has_var/1 > Spawned by: <0.31.0> > Started: Fri Nov 15 17:07:38 2013 > Message queue length: 0 > Number of heap fragments: 0 > Heap fragment data: 0 > Link list: [<0.31.0>] > Reductions: 55265641 > Stack+heap: 15401305 > OldHeap: 18481566 > Heap unused: 220 > OldHeap unused: 18481566 > Memory: 271063808 > Program counter: 0x00002b0ab308ba08 (erl_types:t_has_var/1 + 8) > CP: 0x0000000000000000 (invalid) Second-largest (192 MiB): > =proc:<0.347.0> > State: Scheduled > Spawned as: erlang:apply/2 > Current call: erl_types:'-t_limit_k/2-lc$^0/1-2-'/2 > Spawned by: <0.31.0> > Started: Fri Nov 15 17:07:38 2013 > Message queue length: 0 > Number of heap fragments: 0 > Heap fragment data: 0 > Link list: [<0.31.0>] > Reductions: 33155719 > Stack+heap: 2984878 > OldHeap: 22177879 > Heap unused: 2071396 > OldHeap unused: 8568663 > Memory: 201302904 > Program counter: 0x00002b0ab30b7e78 (erl_types:'-t_limit_k/2-lc$^0/1-2-'/2 + 8) > CP: 0x00002b0ab30b7f90 (erl_types:'-t_limit_k/2-lc$^0/1-2-'/2 + 288) > arity = 2 Third-largest (Only 10 MiB) > =proc:<0.31.0> > State: Waiting > Spawned as: erlang:apply/2 > Spawned by: <0.29.0> > Started: Fri Nov 15 17:07:36 2013 > Message queue length: 10512 > Number of heap fragments: 0 > Heap fragment data: 0 > Link list: [<0.29.0>, <0.32.0>, <0.246.0>, <0.248.0>, <0.249.0>,<0.247.0>, <0.52.0>, <0.283.0>, <0.284.0>, <0.347.0>, <0.349.0>, <0.348.0>, <0.285.0>, <0.256.0>, <0.383.0>, <0.414.0>, <0.400.0>, <0.384.0>, <0.534.0>, <0.537.0>, <0.535.0>, <0.549.0>, <0.551.0>, <0.550.0>, <0.538.0>, <0.444.0>, <0.350.0>, <0.588.0>, <0.592.0>, <0.589.0>, <0.595.0>, <0.608.0>, <0.597.0>, <0.593.0>, <0.613.0>, <0.618.0>, <0.624.0>, <0.623.0>, <0.614.0>, <0.609.0>, <0.626.0>, <0.628.0>, <0.627.0>, <0.630.0>, <0.633.0>, <0.636.0>, <0.631.0>, <0.629.0>, <0.667.0>, <0.666.0>, <0.678.0>, <0.673.0>, <0.668.0>, <0.655.0>, <0.625.0>, <0.552.0>, <0.693.0>, <0.699.0>, <0.695.0>, <0.711.0>, <0.709.0>, <0.703.0>, <0.714.0>, <0.716.0>, <0.715.0>, <0.720.0>, <0.719.0>, <0.717.0>, <0.712.0>, <0.722.0>, <0.726.0>, <0.727.0>, <0.725.0>, <0.732.0>, <0.746.0>, <0.735.0>, <0.729.0>, <0.721.0>, <0.756.0>, <0.755.0>, <0.758.0>, <0.759.0>, <0.757.0>, <0.772.0>, <0.770.0>, <0.776.0>, <0.774.0>, <0.773.0>, <0.768.0>, <0.779.0>, <0.784.0>, <0.781.0>, <0.790.0>, <0.795.0>, <0.793.0>, <0.785.0>, <0.777.0>, <0.830.0>, <0.822.0>, <0.835.0>, <0.833.0>,<0.856.0>, <0.868.0>, <0.866.0>, <0.865.0>, <0.874.0>, <0.873.0>, <0.869.0>, <0.841.0>, <0.816.0>, <0.747.0>, <0.680.0>] > Reductions: 5876487 > Stack+heap: 318187 > OldHeap: 999631 > Heap unused: 172595 > OldHeap unused: 722724 > Memory: 10884200 > Program counter: 0x00002b0aaf561be0 (dialyzer_coordinator:collect_result/1 + 208) > CP: 0x0000000000000000 (invalid) > arity = 0 So I suspected either erl_types:t_has_var/1 or erl_types:t_limit_k/2 (or both) are entering into an infinite recursion but I couldn't find a small example code to reproduce the problem. Any ideas? Thanks, Masatake Daimon From n.oxyde@REDACTED Fri Nov 15 11:21:59 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 15 Nov 2013 11:21:59 +0100 Subject: [erlang-bugs] Fix some uninitialized pointers in crypto Message-ID: <04D5B4C2-33AD-41B8-BE0C-B29F2B9E4B69@gmail.com> Hello, There are some initialized pointers in crypto that may cause free() to be called on arbitrary values. git fetch https://github.com/nox/otp.git crypto-uninitialized-vars https://github.com/nox/otp/compare/crypto-uninitialized-vars https://github.com/nox/otp/compare/crypto-uninitialized-vars.patch Regards, -- Anthony Ramine From mjtruog@REDACTED Sat Nov 16 04:28:47 2013 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 15 Nov 2013 19:28:47 -0800 Subject: [erlang-bugs] app file documentation of included_applications Message-ID: <5286E66F.3020400@gmail.com> Hi, The documentation at: http://www.erlang.org/doc/man/app.html For included_applications says: "All applications which are included by this application. When this application is started, all included application will automatically be loaded, but not started, by the application controller. It is assumed that the topmost supervisor of the included application is started by a supervisor of this application." What it does not say, is that all the application dependencies of the included_applications are started automatically for you. While that handling of included_applications makes sense, it would be good to make explicit in the documentation, so people aren't led to believe they must start included_application dependencies manually (or so that they don't use included_applications if they do want to start the whole application manually). Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Sat Nov 16 11:22:07 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 16 Nov 2013 11:22:07 +0100 Subject: [erlang-bugs] R16B02: Dialyzer consumes too much, if not infinite, amount of memory for some apps In-Reply-To: <5285ED5D.90209@ymir.co.jp> References: <5285ED5D.90209@ymir.co.jp> Message-ID: <5287474F.4040303@cs.ntua.gr> On 11/15/2013 10:46 AM, Masatake Daimon wrote: > I'm using R16B02 on 64-bit Linux. When building PLT, Dialyzer consumes > too much memory that even reaches to 1.5 GiB for some applications: >> % (ulimit -v 1572864; dialyzer --build_plt --output_plt >> syntax_tools.plt --statistics --apps syntax_tools) >> Creating PLT syntax_tools.plt ... >> compile (+0.02s): 1.10s ( 9 modules) >> clean (+0.00s): 0.02s >> remote (+0.05s): 1.56s >> order (+0.01s): 0.06s >> typesig (+0.00s): >> Crash dump was written to: erl_crash.dump >> eheap_alloc: Cannot allocate 123210440 bytes of memory (of type "heap"). > .... > > So I suspected either erl_types:t_has_var/1 or erl_types:t_limit_k/2 (or > both) are entering into an infinite recursion but I couldn't find a > small example code to reproduce the problem. Any ideas? As far as I know, the functions you mention (or any other functions in Dialyzer for that matter) are not entering an infinite loop. It's true that for the analysis of modules that contain deeply recursive types, such as those in syntax_tools, Dialyzer needs some GBs to run (*) but I think that this should not really be a problem in any reasonable machine that one can buy these days. Sorry but Dialyzer was never meant to run on Raspberry Pis. Kostis (*) I was curious so I tried to see how much memory is needed: To build a PLT for syntax_tools you need approx. 1.7GBs on 32-bit machines and 3.1GBs on 64-bit machines. From n.oxyde@REDACTED Sat Nov 16 13:27:23 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 16 Nov 2013 13:27:23 +0100 Subject: [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing Message-ID: Hello, I have trying to fix a bug for a while without success so I post it here. t(Bin1) -> case Bin1 of <<>> -> ok; Bin2 -> case Bin1 of <<0>> -> ok; _ -> Bin2 end end. In the following function, sys_core_fold fails to see that Bin2 is an alias of Bin1 and does not emit a bs_context_to_binary, making beam_validator crash quite violently: t: function t/1+17: Internal consistency check failed - please report this bug. Instruction: return Error: {match_context,{x,0}}: Regards, -- Anthony Ramine From n.oxyde@REDACTED Sat Nov 16 13:58:51 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 16 Nov 2013 13:58:51 +0100 Subject: [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: References: Message-ID: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Finally I may have found one. Tell me where I should write tests for that and I will add them. git fetch https://github.com/nox/otp.git core-clause-subst https://github.com/nox/otp/compare/erlang:maint...core-clause-subst https://github.com/nox/otp/compare/erlang:maint...core-clause-subst.patch Regards, -- Anthony Ramine Le 16 nov. 2013 ? 13:27, Anthony Ramine a ?crit : > Hello, > > I have trying to fix a bug for a while without success so I post it here. > > t(Bin1) -> > case Bin1 of > <<>> -> ok; > Bin2 -> > case Bin1 of > <<0>> -> ok; > _ -> Bin2 > end > end. > > In the following function, sys_core_fold fails to see that Bin2 is an alias of Bin1 and does not emit a bs_context_to_binary, making beam_validator crash quite violently: > > t: function t/1+17: > Internal consistency check failed - please report this bug. > Instruction: return > Error: {match_context,{x,0}}: > > Regards, > > -- > Anthony Ramine > From inigo.sola@REDACTED Sun Nov 17 18:40:44 2013 From: inigo.sola@REDACTED (=?ISO-8859-1?Q?I=F1igo_Sola_N=FA=F1ez?=) Date: Sun, 17 Nov 2013 18:40:44 +0100 Subject: [erlang-bugs] Compiling errors and warnings on OSX 10.9 (Mavericks) Message-ID: When I compile Erlang on Mac OSX 10.9 (Mavericks) I get several deprecated warnings. For example: *crypto.c:3588:2: warning: 'SHA384' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]* *crypto.c:3611:5: warning: 'SHA384_Update' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]* And then I get an error and compilation stops: *odbcserver.c:118:10: fatal error: 'sql.h' file not found* -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Nov 17 21:36:20 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 17 Nov 2013 21:36:20 +0100 Subject: [erlang-bugs] Compiling errors and warnings on OSX 10.9 (Mavericks) In-Reply-To: References: Message-ID: <0BD8D764-C18A-4200-9F43-BEF929143D63@gmail.com> Bundled OpenSSL in Mavericks is deprecated, install your own version. unixodbc is not bundled in Mavericks anymore, install it or skip odbc. -- Anthony Ramine Le 17 nov. 2013 ? 18:40, I?igo Sola N??ez a ?crit : > When I compile Erlang on Mac OSX 10.9 (Mavericks) I get several deprecated warnings. For example: > > crypto.c:3588:2: warning: 'SHA384' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations] > > crypto.c:3611:5: warning: 'SHA384_Update' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations] > > > And then I get an error and compilation stops: > > odbcserver.c:118:10: fatal error: 'sql.h' file not found > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From mjtruog@REDACTED Sun Nov 17 21:52:48 2013 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 17 Nov 2013 12:52:48 -0800 Subject: [erlang-bugs] Documentation of erlang:monitor/2 Message-ID: <52892CA0.8070805@gmail.com> In the types defined for http://www.erlang.org/doc/man/erlang.html#monitor-2 Item = pid() | Module | {Module, Node} Module = module() should be Item = pid() | RegName | {RegName, Node} RegName = atom() From daimon@REDACTED Mon Nov 18 02:55:28 2013 From: daimon@REDACTED (Masatake Daimon) Date: Mon, 18 Nov 2013 10:55:28 +0900 Subject: [erlang-bugs] R16B02: Dialyzer consumes too much, if not infinite, amount of memory for some apps In-Reply-To: <5287474F.4040303@cs.ntua.gr> References: <5285ED5D.90209@ymir.co.jp> <5287474F.4040303@cs.ntua.gr> Message-ID: <52897390.9020304@ymir.co.jp> On 11/16/13 19:22, Kostis Sagonas wrote: > On 11/15/2013 10:46 AM, Masatake Daimon wrote: >> I'm using R16B02 on 64-bit Linux. When building PLT, Dialyzer consumes >> too much memory that even reaches to 1.5 GiB for some applications: >>> % (ulimit -v 1572864; dialyzer --build_plt --output_plt >>> syntax_tools.plt --statistics --apps syntax_tools) >>> Creating PLT syntax_tools.plt ... >>> compile (+0.02s): 1.10s ( 9 modules) >>> clean (+0.00s): 0.02s >>> remote (+0.05s): 1.56s >>> order (+0.01s): 0.06s >>> typesig (+0.00s): >>> Crash dump was written to: erl_crash.dump >>> eheap_alloc: Cannot allocate 123210440 bytes of memory (of type"heap"). >> .... > > It's true that for the analysis of modules that contain deeply recursive > types, such as those in syntax_tools, Dialyzer needs some GBs to run (*) > but I think that this should not really be a problem in any reasonable > machine that one can buy these days. Sorry but Dialyzer was never meant > to run on Raspberry Pis. > > Kostis > > (*) I was curious so I tried to see how much memory is needed: To build > a PLT for syntax_tools you need approx. 1.7GBs on 32-bit machines and > 3.1GBs on 64-bit machines. Thanks for your reply, but why Dialyzer needs that much memory in the first place? Even though machines with 8 GiB RAM is not uncommon these days, consuming 3.1 GiB for PLT looks hardly reasonable to me. From kostis@REDACTED Mon Nov 18 09:09:42 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 18 Nov 2013 09:09:42 +0100 Subject: [erlang-bugs] R16B02: Dialyzer consumes too much, if not infinite, amount of memory for some apps In-Reply-To: <52897390.9020304@ymir.co.jp> References: <5285ED5D.90209@ymir.co.jp> <5287474F.4040303@cs.ntua.gr> <52897390.9020304@ymir.co.jp> Message-ID: <5289CB46.6010101@cs.ntua.gr> On 11/18/2013 02:55 AM, Masatake Daimon wrote: >> It's true that for the analysis of modules that contain deeply recursive >> types, such as those in syntax_tools, Dialyzer needs some GBs to run (*) >> but I think that this should not really be a problem in any reasonable >> machine that one can buy these days. Sorry but Dialyzer was never meant >> to run on Raspberry Pis. >> >> Kostis >> >> (*) I was curious so I tried to see how much memory is needed: To build >> a PLT for syntax_tools you need approx. 1.7GBs on 32-bit machines and >> 3.1GBs on 64-bit machines. > > Thanks for your reply, but why Dialyzer needs that much memory in the > first place? Even though machines with 8 GiB RAM is not uncommon these > days, consuming 3.1 GiB for PLT looks hardly reasonable to me. As I wrote, these modules contain functions with deeply recursive types whose explicit representation, up to some depth, requires much memory. That's the nature of explicit representation of recursive types and that's the best we could do given that consuming lots of memory up to a point is not a problem these days (for most people/applications). If it somehow is a problem for you, feel free to improve on what the tool does. We welcome patches. Best, Kostis From n.oxyde@REDACTED Mon Nov 18 11:52:53 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 18 Nov 2013 11:52:53 +0100 Subject: [erlang-bugs] Properly let floating-point instructions through in the BEAM compiler Message-ID: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> Hello, The compiler shouldn't crash when fed an already-optimised BEAM assembly file. git fetch https://github.com/nox/otp.git beam-fp-insts https://github.com/nox/otp/compare/beam-fp-insts https://github.com/nox/otp/compare/beam-fp-insts.patch Regards, -- Anthony Ramine From bgustavsson@REDACTED Mon Nov 18 12:58:38 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 18 Nov 2013 12:58:38 +0100 Subject: [erlang-bugs] Properly let floating-point instructions through in the BEAM compiler In-Reply-To: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> References: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> Message-ID: On Mon, Nov 18, 2013 at 11:52 AM, Anthony Ramine wrote: > Hello, > > The compiler shouldn't crash when fed an already-optimised BEAM assembly > file. > > git fetch https://github.com/nox/otp.git beam-fp-insts > > https://github.com/nox/otp/compare/beam-fp-insts > https://github.com/nox/otp/compare/beam-fp-insts.patch > > I am very picky with good coverage of the compiler code. If coverage is good to begin with, it is easy to see when the coverage gets worse that some optimization is no longer being applied. Suggestion: Include the following one-line change in your patch and fix the remaining problems: diff --git a/lib/compiler/test/compile_SUITE.erl b/lib/compiler/test/compile_SUITE.erl index be01ea7..4e2753d 100644 --- a/lib/compiler/test/compile_SUITE.erl +++ b/lib/compiler/test/compile_SUITE.erl @@ -794,7 +794,7 @@ do_asm(Beam, Outdir) -> {ok,Fd} = file:open(AsmFile, [write]), beam_listing:module(Fd, Asm), ok = file:close(Fd), - case compile:file(AsmFile, [from_asm,no_postopt,binary,report]) of + case compile:file(AsmFile, [from_asm,binary,report]) of {ok,M,_} -> ok = file:delete(AsmFile); Other -> /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Nov 18 13:41:16 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 18 Nov 2013 13:41:16 +0100 Subject: [erlang-bugs] Properly let floating-point instructions through in the BEAM compiler In-Reply-To: References: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> Message-ID: <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> I owe you a beer for that tip, I should have thought to grep for no_postopt in the code. I have just found another discrepancy with regard to allocate and init by recompiling sofs. -- Anthony Ramine Le 18 nov. 2013 ? 12:58, Bj?rn Gustavsson a ?crit : > Suggestion: Include the following one-line change in your patch and > fix the remaining problems: From fredrik@REDACTED Mon Nov 18 14:25:53 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 18 Nov 2013 14:25:53 +0100 Subject: [erlang-bugs] Fix some uninitialized pointers in crypto In-Reply-To: <04D5B4C2-33AD-41B8-BE0C-B29F2B9E4B69@gmail.com> References: <04D5B4C2-33AD-41B8-BE0C-B29F2B9E4B69@gmail.com> Message-ID: <528A1561.9050502@erlang.org> On 11/15/2013 11:21 AM, Anthony Ramine wrote: > Hello, > > There are some initialized pointers in crypto that may cause free() to be called on arbitrary values. > > git fetch https://github.com/nox/otp.git crypto-uninitialized-vars > > https://github.com/nox/otp/compare/crypto-uninitialized-vars > https://github.com/nox/otp/compare/crypto-uninitialized-vars.patch > > Regards, > Hello Anthony, I've fetched your patch and assigned it to be reviewed by responsible developers. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From lukas@REDACTED Mon Nov 18 14:56:39 2013 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 18 Nov 2013 14:56:39 +0100 Subject: [erlang-bugs] Documentation of erlang:monitor/2 In-Reply-To: <52892CA0.8070805@gmail.com> References: <52892CA0.8070805@gmail.com> Message-ID: <528A1C97.7010408@erlang.org> Hello, Thanks for the bug report. The fix will be part of the next maintainance release. Lukas On 17/11/13 21:52, Michael Truog wrote: > In the types defined for http://www.erlang.org/doc/man/erlang.html#monitor-2 > > Item = pid() | Module | {Module, Node} > Module = module() > > should be > > Item = pid() | RegName | {RegName, Node} > RegName = atom() > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From jose.valim@REDACTED Tue Nov 19 12:49:38 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Tue, 19 Nov 2013 12:49:38 +0100 Subject: [erlang-bugs] Expensive module miss when code path cache is enabled Message-ID: Hello OTP team, I was experimenting with Erlang's code path cache and I have found that some operations actually become quite slower when the code path cache is enabled. In particular, code:ensure_loaded/1 becomes an order of magnitude slower when the module is not loaded and does not exist in any code path. By inspecting the code_server source code, I have noticed that this line is responsible for the slow down: https://github.com/erlang/otp/blob/fb0006c937e284cefe5217d4c2a4b45ff7dfb758/lib/kernel/src/code_server.erl#L1341 Basically, every time we can't find a module, the whole code path is rehashed. The slow down will be even bigger for larger code paths. I tried blaming the line above with no success. Removing the line also does not introduce failures into the code_SUITE so I am unsure if this behaviour is by design or not. The only use case I can think for this behaviour is to be able to load beam files that are added to code paths *after* the code path was added to the code server but it seems an arguable behaviour considering its effects on a module miss. I may be missing something obvious that justifies the current behaviour and, if so, I believe we should at least document it. I will be glad to send a patch if the OTP team agrees with it. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgud@REDACTED Tue Nov 19 13:08:16 2013 From: dgud@REDACTED (Dan Gudmundsson) Date: Tue, 19 Nov 2013 13:08:16 +0100 Subject: [erlang-bugs] Expensive module miss when code path cache is enabled Message-ID: I guess the blame is mine, and I agree that "feature" is questionable. The idea was that the cache should behave as the non-cached variant as much as possible. And in the non-cached variant the whole code path is searched and the cache could be updated as well. Since the patch is trivial, can you add it and we will bring up to discussion internally and here if someone has an opinion. /Dan On Tue, Nov 19, 2013 at 12:49 PM, Jos? Valim < jose.valim@REDACTED> wrote: > Hello OTP team, > > I was experimenting with Erlang's code path cache and I have found that > some operations actually become quite slower when the code path cache is > enabled. > In particular, code:ensure_loaded/1 becomes an order of magnitude slower > when the module is not loaded and does not exist in any code path. > > By inspecting the code_server source code, I have noticed that this line > is responsible for the slow down: > > > https://github.com/erlang/otp/blob/fb0006c937e284cefe5217d4c2a4b45ff7dfb758/lib/kernel/src/code_server.erl#L1341 > > Basically, every time we can't find a module, the whole code path is > rehashed. The slow down will be even bigger for larger code paths. > > I tried blaming the line above with no success. Removing the line also > does not introduce failures into the code_SUITE so I am unsure if this > behaviour is by design or not. The only use case I can think for this > behaviour is to be able to load beam files that are added to code paths > *after* the code path was added to the code server but it seems an arguable > behaviour considering its effects on a module miss. > > I may be missing something obvious that justifies the current behaviour > and, if so, I believe we should at least document it. I will be glad to > send a patch if the OTP team agrees with it. > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Nov 19 20:11:50 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 19 Nov 2013 20:11:50 +0100 Subject: [erlang-bugs] Let the compiler understand its own BEAM output In-Reply-To: <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> References: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> Message-ID: <600B8BEF-C89C-42CC-A74B-C5166D233774@gmail.com> I?ve made a new more general branch with other fixes: git fetch https://github.com/nox/otp.git asm-reentrant https://github.com/nox/otp/compare/erlang:maint...asm-reentrant https://github.com/nox/otp/compare/erlang:maint...asm-reentrant.patch This also tests for BEAM output recompilation in both compilation_SUITE and compile_SUITE. Regards, -- Anthony Ramine Le 18 nov. 2013 ? 13:41, Anthony Ramine a ?crit : > I owe you a beer for that tip, I should have thought to grep for no_postopt in the code. > > I have just found another discrepancy with regard to allocate and init by recompiling sofs. > > -- > Anthony Ramine > > Le 18 nov. 2013 ? 12:58, Bj?rn Gustavsson a ?crit : > >> Suggestion: Include the following one-line change in your patch and >> fix the remaining problems: > From n.oxyde@REDACTED Tue Nov 19 21:34:19 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 19 Nov 2013 21:34:19 +0100 Subject: [erlang-bugs] [erlang-patches] Rewrite merge of clause variable tables (in case, try, etc) In-Reply-To: <5285D459.2060807@erlang.org> References: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> <5285D459.2060807@erlang.org> Message-ID: <210241A2-EEA2-4523-B949-B1493F2EC3E8@gmail.com> I?ve changed a little the way I modified vtunsafe. Please refetch. -- Anthony Ramine Le 15 nov. 2013 ? 08:59, Fredrik a ?crit : > On 11/14/2013 01:26 PM, Anthony Ramine wrote: >> Hello, >> >> I have finally got around fixing the two regressions reported in R16B02 with regard to unused variable warnings. >> >> The fix was more complicated than what I expected it to be. >> >> git fetch https://github.com/nox/otp.git fix-exporting-rules >> >> https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules >> https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules.patch >> >> Regards, >> > Hello Anthony, > I've fetched your patch and assigned it to be reviewed. > Thanks for contribution, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From edwardt.tril@REDACTED Tue Nov 19 23:21:17 2013 From: edwardt.tril@REDACTED (What Name) Date: Tue, 19 Nov 2013 17:21:17 -0500 Subject: [erlang-bugs] OTP r16 B02 with --disable-hipe options misses SKIP under hipe source folder, so hioe will compiles Message-ID: under centos 6.4 64 bit compile from source downloaded from erlang solutions. There are a lot of problems with raw source compilation on centos 6.4 64 bit that, would someone do a comprehensive tests on this quality of this version on source compilation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.demidenko@REDACTED Thu Nov 21 02:41:43 2013 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Thu, 21 Nov 2013 08:41:43 +0700 Subject: [erlang-bugs] SSH-daemon freezing while call io:getopts() and io:setopts() Message-ID: Hello, friends. I have a trouble with using shell in the ssh-daemon, when I call the function io:getopts() and io:setopts([{echo, false}, {encoding, latin1}]). Tested by Erlang 16B02, ssh 2.1.8 and R15B02, ssh 2.1.1 How can i see, in the ssh_cli.erl module, handle_msg metod no function for processing param ({Group, set_unicode_state, Arg}, State) and ({Group, get_unicode_state}, State). My patch for fixing: --- ssh-2.1.1/src/ssh_cli.erl 2013-10-26 14:25:26.000000000 +++ ssh-2.1.2/src/ssh_cli.erl 2013-10-26 14:18:18.000000000 @@ -159,12 +159,20 @@ %%-------------------------------------------------------------------- handle_msg({ssh_channel_up, ChannelId, ConnectionManager}, #state{channel = ChannelId, cm = ConnectionManager} = State) -> {ok, State}; +handle_msg({Group, set_unicode_state, _Arg}, State) -> + Group ! {self(), set_unicode_state, false}, + {ok, State}; + +handle_msg({Group, get_unicode_state}, State) -> + Group ! {self(), get_unicode_state, false}, + {ok, State}; + handle_msg({Group, Req}, #state{group = Group, buf = Buf, pty = Pty, cm = ConnectionManager, channel = ChannelId} = State) -> {Chars, NewBuf} = io_request(Req, Buf, Pty), write_chars(ConnectionManager, ChannelId, Chars), {ok, State#state{buf = NewBuf}}; Also I attached simple sample, where you can see this problem. To run it, compile ssh_shell.erl and ssh_manager.erl and invoke "ssh_manager:start_link()" method to run ssh-daemon. (you need generate personal keys for used it) Then run ssh-client on terminal to localhost on port 7777, after entering the password ?test?, enter the command "echo_on" or "echo_off". You can see that there is a delay when calling functions io:getopts() and io:setopts([{echo, false}, {encoding, latin1}]). -- --------------------------------------------- With best regards, Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh_delay_test.tar.gz Type: application/x-gzip Size: 3311 bytes Desc: not available URL: From alex.demidenko@REDACTED Thu Nov 21 03:51:44 2013 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Thu, 21 Nov 2013 09:51:44 +0700 Subject: [erlang-bugs] SSH-daemon invalid column calculation at ssh_cli:delete_chars() Message-ID: Hello, friends. How can I see, in the ssh_cli.erl module, delete_chars method incorrectly calculate variable "NewCol". I can offer the option of a patch that fixes this problem. The person who is responsible for supporting ssh has the discretion to take it as it is, or can make own fix. Tested by Erlang 16B02, ssh 2.1.8 and R15B02, ssh 2.1.1 hurd@REDACTED:~/Documents/Erlang/reports/ssh_expand_test$ cat ssh.patch --- ssh-2.1.1/src/ssh_cli.erl 2013-10-26 14:25:26.000000000 +++ ssh-2.1.2/src/ssh_cli.erl 2013-10-26 14:18:18.000000000 @@ -311,13 +319,14 @@ NewBufTail = nthtail(N, BufTail), M = move_cursor(Col + length(NewBufTail) + N, Col, Tty), {[NewBufTail, lists:duplicate(N, $ ) | M], {Buf, NewBufTail, Col}}; delete_chars(N, {Buf, BufTail, Col}, Tty) -> % N < 0 NewBuf = nthtail(-N, Buf), - NewCol = Col + N, + NewCol = case Col + N of V when V >= 0 -> V; _ -> 0 end, M1 = move_cursor(Col, NewCol, Tty), M2 = move_cursor(NewCol + length(BufTail) - N, NewCol, Tty), {[M1, BufTail, lists:duplicate(-N, $ ) | M2], {NewBuf, BufTail, NewCol}}. %%% Window change, redraw the current line (and clear out after it I attached simple sample, where you can see this problem. To run it, compile ssh_manager.erl and invoke "ssh_manager:start()" method to run ssh-daemon. Then run simple ssh-client on terminal to localhost on port 9999, and entering the password "test". (you need put keys in .ssh folder) Below example show trouble with the display of available commands when you press Tab. At the command prompt "ssh_app:" _____________________________________________________ 1> ssh_app: _____________________________________________________ Press tab. _____________________________________________________ 1> ssh_app: module_info/0 module_info/1 start/2 stop/1 1> ssh_app: _____________________________________________________ You will see the line below "module_info/0 module_info/1 start/2 stop/1," and below that "ssh_app:". Everything is wonderful. Yet. Do the following: Go to the new line (Press enter) and enter a space as long as the input field team did not go on the line below . _____________________________________________________ 1> _____________________________________________________ Enter "ssh_app:" _____________________________________________________ 1> ssh_app: _____________________________________________________ Press tab. _____________________________________________________ 1> ssh_app: 1> ssh_app: _____________________________________________________ You will see that the tab has not worked. The string "module_info/0 module_info/1 start/2 stop/1" was not withdrawn. This is not good. You still can do the following: Go to the new line (press the button enter) and enter a space as long as the input field team did not go on 2 lines below. _____________________________________________________ 1> _____________________________________________________ Enter "ssh_app:". ____________________________________________________ 1> ssh_app: _____________________________________________________ Press tab. _____________________________________________________ 1> 1> ssh_app: _____________________________________________________ You will see that the tab has not worked. The string "module_info/0 module_info/1 start/2 stop/1" was not withdrawn. This is not good. -- --------------------------------------------- With best regards, Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh_expand_test.tar.gz Type: application/x-gzip Size: 5857 bytes Desc: not available URL: From Ingela.Anderton.Andin@REDACTED Thu Nov 21 09:45:25 2013 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 21 Nov 2013 09:45:25 +0100 Subject: [erlang-bugs] SSH-daemon freezing while call io:getopts() and io:setopts() In-Reply-To: References: Message-ID: <528DC825.4010202@ericsson.com> Hello! Yes this is now a known problem. I have for the upcoming release done a big rewrite of ssh to deal with some timing related issues, but this is a remaining problem. I had also noticed that failing to handle this message was part of the problem. We will investigate if this is the whole solution. Thank for you report. Regards Ingela Erlang/OTP team - Ericsson AB On 11/21/2013 02:41 AM, Alexander Demidenko wrote: > Hello, friends. > > I have a trouble with using shell in the ssh-daemon, when I call the > function io:getopts() and io:setopts([{echo, false}, {encoding, latin1}]). > > Tested by Erlang 16B02, ssh 2.1.8 and R15B02, ssh 2.1.1 > > > How can i see, in the ssh_cli.erl module, handle_msg metod no function > for processing param ({Group, set_unicode_state, Arg}, State) and > ({Group, get_unicode_state}, State). > > My patch for fixing: > > --- ssh-2.1.1/src/ssh_cli.erl2013-10-26 14:25:26.000000000 > +++ ssh-2.1.2/src/ssh_cli.erl2013-10-26 14:18:18.000000000 > @@ -159,12 +159,20 @@ > %%-------------------------------------------------------------------- > handle_msg({ssh_channel_up, ChannelId, ConnectionManager}, > #state{channel = ChannelId, > cm = ConnectionManager} = State) -> > {ok, State}; > +handle_msg({Group, set_unicode_state, _Arg}, State) -> > + Group ! {self(), set_unicode_state, false}, > + {ok, State}; > + > +handle_msg({Group, get_unicode_state}, State) -> > + Group ! {self(), get_unicode_state, false}, > + {ok, State}; > + > handle_msg({Group, Req}, #state{group = Group, buf = Buf, pty = Pty, > cm = ConnectionManager, > channel = ChannelId} = State) -> > {Chars, NewBuf} = io_request(Req, Buf, Pty), > write_chars(ConnectionManager, ChannelId, Chars), > {ok, State#state{buf = NewBuf}}; > > Also I attached simple sample, where you can see this problem. To run > it, compile ssh_shell.erl and ssh_manager.erl and invoke > "ssh_manager:start_link()" method to run ssh-daemon. (you need generate > personal keys for used it) Then run ssh-client on terminal to localhost > on port 7777, after entering the password ?test?, enter the command > "echo_on" or "echo_off". > > You can see that there is a delay when calling functions io:getopts() > and io:setopts([{echo, false}, {encoding, latin1}]). > > > -- > --------------------------------------------- > With best regards, > Alexander. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From henrik@REDACTED Thu Nov 21 11:25:20 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 21 Nov 2013 11:25:20 +0100 Subject: [erlang-bugs] [erlang-patches] SSH-daemon invalid column calculation at ssh_cli:delete_chars() In-Reply-To: References: Message-ID: <528DDF90.8070508@erlang.org> Hi Alexander! I have created a pull request for this to make sure it will get into the system and assigned to the proper team etc. Thank you for your contribution! On 2013-11-21 03:51, Alexander Demidenko wrote: > Hello, friends. > > How can I see, in the ssh_cli.erl module, delete_chars method > incorrectly calculate variable "NewCol". > > I can offer the option of a patch that fixes this problem. > The person who is responsible for supporting ssh has the discretion to > take it as it is, or can make own fix. > Tested by Erlang 16B02, ssh 2.1.8 and R15B02, ssh 2.1.1 > > hurd@REDACTED:~/Documents/Erlang/reports/ssh_expand_test$ cat ssh.patch > --- ssh-2.1.1/src/ssh_cli.erl2013-10-26 14:25:26.000000000 > +++ ssh-2.1.2/src/ssh_cli.erl2013-10-26 14:18:18.000000000 > @@ -311,13 +319,14 @@ > NewBufTail = nthtail(N, BufTail), > M = move_cursor(Col + length(NewBufTail) + N, Col, Tty), > {[NewBufTail, lists:duplicate(N, $ ) | M], > {Buf, NewBufTail, Col}}; > delete_chars(N, {Buf, BufTail, Col}, Tty) -> % N < 0 > NewBuf = nthtail(-N, Buf), > - NewCol = Col + N, > + NewCol = case Col + N of V when V >= 0 -> V; _ -> 0 end, > M1 = move_cursor(Col, NewCol, Tty), > M2 = move_cursor(NewCol + length(BufTail) - N, NewCol, Tty), > {[M1, BufTail, lists:duplicate(-N, $ ) | M2], > {NewBuf, BufTail, NewCol}}. > %%% Window change, redraw the current line (and clear out after it > > > I attached simple sample, where you can see this problem. > To run it, compile ssh_manager.erl and invoke "ssh_manager:start()" > method to run ssh-daemon. > Then run simple ssh-client on terminal to localhost on port 9999, and > entering the password "test". > (you need put keys in .ssh folder) > Below example show trouble with the display of available commands when > you press Tab. > > At the command prompt "ssh_app:" > _____________________________________________________ > 1> ssh_app: > _____________________________________________________ > > Press tab. > _____________________________________________________ > 1> ssh_app: > module_info/0 module_info/1 start/2 stop/1 > 1> ssh_app: > _____________________________________________________ > > You will see the line below "module_info/0 module_info/1 start/2 > stop/1," and below that "ssh_app:". > Everything is wonderful. Yet. > > Do the following: Go to the new line (Press enter) and enter a space > as long as the input field team did not go on the line below . > _____________________________________________________ > 1> > _____________________________________________________ > > Enter "ssh_app:" > > _____________________________________________________ > 1> > ssh_app: > _____________________________________________________ > > Press tab. > _____________________________________________________ > 1> > ssh_app: > 1> > ssh_app: > _____________________________________________________ > > You will see that the tab has not worked. The string "module_info/0 > module_info/1 start/2 stop/1" was not withdrawn. > This is not good. > > You still can do the following: Go to the new line (press the button > enter) and enter a space as long as the input field team did not go on > 2 lines below. > _____________________________________________________ > 1> > _____________________________________________________ > > Enter "ssh_app:". > ____________________________________________________ > 1> > ssh_app: > _____________________________________________________ > > Press tab. > > _____________________________________________________ > 1> > 1> > > ssh_app: > _____________________________________________________ > > You will see that the tab has not worked. The string "module_info/0 > module_info/1 start/2 stop/1" was not withdrawn. This is not good. > > -- > --------------------------------------------- > With best regards, > Alexander. > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From hello@REDACTED Sun Nov 24 13:51:16 2013 From: hello@REDACTED (Adam Lindberg) Date: Sun, 24 Nov 2013 13:51:16 +0100 Subject: [erlang-bugs] SSH undef using with no user interaction and missing authorized key Message-ID: <1385297476.32308.51392189.49B153D8@webmail.messagingengine.com> Hi! Using SSH in Erlang R16B02, trying to connect to localhost on OS X 10.9, using [{user_dir, ...}, {user_interaction, false}] produces an undef error because ssh_no_io does not have the function yes_no/2. The error cannot be produced by using only {user_interaction, false}. authorized_keys are not set up on this machine, so the login (without {user_dir, ...} is of course unsuccessful. Cheers, Adam Full output: Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [dtrace] Eshell V5.10.3 (abort with ^G) 1> ssh:start(). ok 2> {ok, Conn} = ssh:connect("localhost", 22, [{user_interaction, false}]). ** exception error: no match of right hand side value {error, "Unable to connect using the available authentication methods"} 3> {ok, Conn} = ssh:connect("localhost", 22, [{user_dir, "/Users/username"}, {user_interaction, false}]). ** exception error: no match of right hand side value {error,"Internal error"} 4> =ERROR REPORT==== 24-Nov-2013::13:09:17 === Erlang ssh connection handler failed with reason: undef , Stacktace: [{ssh_no_io,yes_no, ["New host localhost accept", {ssh,client, {"localhost",{{0,0,0,0,0,0,0,1},22}}, {2,0}, {2,0}, "SSH-2.0-Erlang","SSH-2.0-OpenSSH_6.2", <<...big binary...>>, <<...big binary...>>, {alg,'diffie-hellman-group1-sha1','ssh-rsa', 'hmac-sha1','hmac-sha1','aes128-cbc', 'aes128-cbc',none,none,none,none}, undefined,undefined,ssh_file,ssh_no_io,none, undefined,0,none,undefined,0,none,undefined,8, undefined,none,undefined,8,undefined,none, undefined,none,undefined,none,none,true, infinity,undefined,undefined,undefined, [{address,"localhost"}, {port,22}, {user_pid,<0.57.0>}, {host,"localhost"}, {idle_time,infinity}, {user_interaction,false}, {user_dir,"/Users/alind"}], 2,2, {{...big integer..., ...big integer...}, {2, ...big integer...}}, undefined,undefined,undefined,false, "publickey,keyboard-interactive,password", undefined,undefined, ["ssh-rsa","ssh-dss"], false}], []}, {ssh_transport,known_host_key,3, [{file,"ssh_transport.erl"},{line,489}]}, {ssh_transport,handle_kexdh_reply,2, [{file,"ssh_transport.erl"},{line,354}]}, {ssh_connection_handler,key_exchange,2, [{file,"ssh_connection_handler.erl"}, {line,242}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}] please report this to erlang-bugs@REDACTED From Ingela.Anderton.Andin@REDACTED Mon Nov 25 10:26:41 2013 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Mon, 25 Nov 2013 10:26:41 +0100 Subject: [erlang-bugs] SSH undef using with no user interaction and missing authorized key In-Reply-To: <1385297476.32308.51392189.49B153D8@webmail.messagingengine.com> References: <1385297476.32308.51392189.49B153D8@webmail.messagingengine.com> Message-ID: <529317D1.2080003@ericsson.com> Hi! Yes it looks like ssh_no_io.erl have several arity problems. Following patch should solve the problem! diff --git a/lib/ssh/src/ssh_no_io.erl b/lib/ssh/src/ssh_no_io.erl index 9f83506..825a0d4 100644 --- a/lib/ssh/src/ssh_no_io.erl +++ b/lib/ssh/src/ssh_no_io.erl @@ -24,27 +24,27 @@ -module(ssh_no_io). -include("ssh_transport.hrl"). --export([yes_no/1, read_password/1, read_line/1, format/2]). +-export([yes_no/2, read_password/2, read_line/2, format/2]). -yes_no(_Prompt) -> +yes_no(_, _) -> throw({{no_io_allowed, yes_no}, #ssh_msg_disconnect{code = ?SSH_DISCONNECT_SERVICE_NOT_AVAILABLE, description = "User interaction is not allowed", language = "en"}}). -read_password(_Prompt) -> +read_password(_, _) -> throw({{no_io_allowed, read_password}, #ssh_msg_disconnect{code = ?SSH_DISCONNECT_SERVICE_NOT_AVAILABLE, description = "User interaction is not allowed", language = "en"}}). -read_line(_Prompt) -> +read_line(_, _) -> throw({{no_io_allowed, read_line}, #ssh_msg_disconnect{code = ?SSH_DISCONNECT_SERVICE_NOT_AVAILABLE, description = "User interaction is not allowed", language = "en"}} ). Regards Ingela Erlang/OTP Team - Ericsson AB On 11/24/2013 01:51 PM, Adam Lindberg wrote: > Hi! > > Using SSH in Erlang R16B02, trying to connect to localhost on OS X 10.9, > using [{user_dir, ...}, {user_interaction, false}] produces an undef > error because ssh_no_io does not have the function yes_no/2. The error > cannot be produced by using only {user_interaction, false}. > authorized_keys are not set up on this machine, so the login (without > {user_dir, ...} is of course unsuccessful. > > Cheers, > Adam > > > Full output: > > Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:4:4] > [async-threads:10] [hipe] [kernel-poll:false] [dtrace] > > Eshell V5.10.3 (abort with ^G) > 1> ssh:start(). > ok > 2> {ok, Conn} = ssh:connect("localhost", 22, [{user_interaction, > false}]). > ** exception error: no match of right hand side value {error, > "Unable to > connect using the > available > authentication > methods"} > 3> {ok, Conn} = ssh:connect("localhost", 22, [{user_dir, > "/Users/username"}, {user_interaction, false}]). > ** exception error: no match of right hand side value {error,"Internal > error"} > 4> > =ERROR REPORT==== 24-Nov-2013::13:09:17 === > Erlang ssh connection handler failed with reason: undef > , Stacktace: [{ssh_no_io,yes_no, > ["New host localhost accept", > {ssh,client, > {"localhost",{{0,0,0,0,0,0,0,1},22}}, > {2,0}, > {2,0}, > "SSH-2.0-Erlang","SSH-2.0-OpenSSH_6.2", > <<...big binary...>>, > <<...big binary...>>, > {alg,'diffie-hellman-group1-sha1','ssh-rsa', > 'hmac-sha1','hmac-sha1','aes128-cbc', > 'aes128-cbc',none,none,none,none}, > undefined,undefined,ssh_file,ssh_no_io,none, > undefined,0,none,undefined,0,none,undefined,8, > undefined,none,undefined,8,undefined,none, > undefined,none,undefined,none,none,true, > infinity,undefined,undefined,undefined, > [{address,"localhost"}, > {port,22}, > {user_pid,<0.57.0>}, > {host,"localhost"}, > {idle_time,infinity}, > {user_interaction,false}, > {user_dir,"/Users/alind"}], > 2,2, > {{...big integer..., > ...big integer...}, > {2, > ...big integer...}}, > undefined,undefined,undefined,false, > "publickey,keyboard-interactive,password", > undefined,undefined, > ["ssh-rsa","ssh-dss"], > false}], > []}, > {ssh_transport,known_host_key,3, > [{file,"ssh_transport.erl"},{line,489}]}, > {ssh_transport,handle_kexdh_reply,2, > [{file,"ssh_transport.erl"},{line,354}]}, > {ssh_connection_handler,key_exchange,2, > [{file,"ssh_connection_handler.erl"}, > {line,242}]}, > {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}] > please report this to erlang-bugs@REDACTED > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From erlangsiri@REDACTED Mon Nov 25 12:01:12 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Mon, 25 Nov 2013 12:01:12 +0100 Subject: [erlang-bugs] release_handler error in upgrading slim release In-Reply-To: References: Message-ID: Hi Shino, release_handler is not explicitly "slim-release aware", since this is a reltool mechanism. (And also, it is only experimental.) I think, however, that you can solve your problem by unpacking your tar file manually and then using release_handler:set_unpacked/2 instead of release_handler:unpack_release/1. /siri 2013/11/5 Shunichi Shinohara > I try to make rebar work with slim release at > https://github.com/rebar/rebar/pull/52 . > Almost all goes well, but in upgrading in slim release environment > an error occurs and fails. (R16B02, Linux) > > To simplify step to reproduce, I created repository which has > rebar binary and some configuration files. > https://github.com/shino/slim-upgrade-sample > > Steps to reproduce: > 0. Clone the repository and cd to it. > git clone https://github.com/shino/slim-upgrade-sample.git > 1. Generate version 1 and 2 of releases and upgrade package between > them. The script generate.sh in the repo does this work. > 2. Boot the node with release version 1 and try to unpack the upgrade > package. > 3. The following error occurs. > > release_handler:unpack_release("sample_2"). > {error,{enoent, > > "/opt/shino/scm/slim-upgrade-sample/sample/rel/sample_1/releases/sample_2.rel"}} > > "/opt/shino/scm/slim-upgrade-sample/sample/rel/sample_1/" is root directory > of slim release generated by reltool. > The file "sample_2.rel" which release_handler complains not-found goes > under the "releases" directory of Erlang/OTP which execute the node. > Quick look of source code, release_handler seems to assume "releases" > directory > exists just under root directory (it's appropriate for normal, > non-slim release). > > - extract_rel_file/2: Extract rel file in tar ball under root directory. > > https://github.com/erlang/otp/blob/OTP_R16B02/lib/sasl/src/release_handler.erl#L835 > - check_rel/3,4: Try rel file under releases directory of slim release. > > https://github.com/erlang/otp/blob/OTP_R16B02/lib/sasl/src/release_handler.erl#L836 > > P.S. > Sorry that steps to reproduce contain non-OTP, rebar related things. > I hope rebar is not related the error because of release_handler's code > above. > > Best Regards, > Shino > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.ryabkov@REDACTED Tue Nov 26 03:46:20 2013 From: anton.ryabkov@REDACTED (Anton Ryabkov) Date: Tue, 26 Nov 2013 09:46:20 +0700 Subject: [erlang-bugs] try ... catch hidden compile warning Message-ID: Hello, on Erlang R16B02 I've found that try ... catch constraction hidden compile warning: "variable 'Sth' is unused". On Erlang R15B02 warning exists. The sample at the attach. When I complile by Erlang R15B02 I have two warnings: Eshell V5.9.1 (abort with ^G) 1> c(no_warning). no_warning.erl:10: Warning: variable 'STh' is unused no_warning.erl:22: Warning: variable 'STh' is unused {ok,no_warning} But when I compile by Erlang R16B02 I have only one warning: Eshell V5.10.3 (abort with ^G) 1> c(no_warning). no_warning.erl:22: Warning: variable 'STh' is unused {ok,no_warning} Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: no_warning.erl Type: text/x-erlang Size: 393 bytes Desc: not available URL: From n.oxyde@REDACTED Tue Nov 26 11:47:31 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 26 Nov 2013 11:47:31 +0100 Subject: [erlang-bugs] try ... catch hidden compile warning In-Reply-To: References: Message-ID: <5F8775AD-784B-46B2-84EC-25A14B734E36@gmail.com> This is fixed by one of my patches currently in review. -- Anthony Ramine Le 26 nov. 2013 ? 03:46, Anton Ryabkov a ?crit : > Hello, > > on Erlang R16B02 I've found that try ... catch constraction hidden compile warning: "variable 'Sth' is unused". On Erlang R15B02 warning exists. The sample at the attach. When I complile by Erlang R15B02 I have two warnings: > Eshell V5.9.1 (abort with ^G) > 1> c(no_warning). > no_warning.erl:10: Warning: variable 'STh' is unused > no_warning.erl:22: Warning: variable 'STh' is unused > {ok,no_warning} > > But when I compile by Erlang R16B02 I have only one warning: > Eshell V5.10.3 (abort with ^G) > 1> c(no_warning). > no_warning.erl:22: Warning: variable 'STh' is unused > {ok,no_warning} > > Anton > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From fly@REDACTED Wed Nov 27 10:22:39 2013 From: fly@REDACTED (Fred Youhanaie) Date: Wed, 27 Nov 2013 09:22:39 +0000 Subject: [erlang-bugs] no documentation for module_info and get_module_info Message-ID: <5295B9DF.3090409@anydata.co.uk> Hi I came across this thread from five years ago: http://erlang.org/pipermail/erlang-questions/2008-October/038848.html Was a bug report raised? If not, I'd like to raise one please :-) 1. erlang:get_module_info/1 and erlang:get_module_info/2 need to be documented in the ERTS manual. 2. The documentation for module_info/0 and module_info/1 need to clarify that they will always return info for the current version of a loaded module, rather than the version that is active for the caller. 3. Can #2 above be fixed so that it returns data related to the active module, rather than the current version? Many thanks Fred From n.oxyde@REDACTED Wed Nov 27 11:27:49 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 27 Nov 2013 11:27:49 +0100 Subject: [erlang-bugs] no documentation for module_info and get_module_info In-Reply-To: <5295B9DF.3090409@anydata.co.uk> References: <5295B9DF.3090409@anydata.co.uk> Message-ID: <10D245D5-4A2E-43B9-81B3-6BB48FB07792@gmail.com> Replied inline. -- Anthony Ramine Le 27 nov. 2013 ? 10:22, Fred Youhanaie a ?crit : > Hi > > I came across this thread from five years ago: > > http://erlang.org/pipermail/erlang-questions/2008-October/038848.html > > Was a bug report raised? If not, I'd like to raise one please :-) > > 1. erlang:get_module_info/1 and erlang:get_module_info/2 need to be > documented in the ERTS manual. Why would you put it in the public documentation when it is an implementation detail (cf. for example the comment about module_info in ops.tab [1])? Why not call M:module_info()? > 2. The documentation for module_info/0 and module_info/1 need to clarify > that they will always return info for the current version of a loaded > module, rather than the version that is active for the caller. > > 3. Can #2 above be fixed so that it returns data related to the active > module, rather than the current version? 2 and 3 may be a problem in the context of calling module_info directly as a local function from the very same module. If you call foo:module_info from the module bar, it would make absolutely no sense to return anything else but the current version. But then again, if your application depends on this, you are probably doing something really unusual. > Many thanks > > Fred Regards, [1] https://github.com/erlang/otp/blob/maint/erts/emulator/beam/ops.tab#L35-L39 From robert.virding@REDACTED Wed Nov 27 12:39:33 2013 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 27 Nov 2013 12:39:33 +0100 (CET) Subject: [erlang-bugs] no documentation for module_info and get_module_info In-Reply-To: <10D245D5-4A2E-43B9-81B3-6BB48FB07792@gmail.com> References: <5295B9DF.3090409@anydata.co.uk> <10D245D5-4A2E-43B9-81B3-6BB48FB07792@gmail.com> Message-ID: <1212030937.66376.1385552373395.JavaMail.zimbra@erlang-solutions.com> Comment to a comment further down. Robert ----- Original Message ----- > From: "Anthony Ramine" > > Replied inline. > > -- > Anthony Ramine > > Le 27 nov. 2013 ? 10:22, Fred Youhanaie a ?crit : > > > Hi > > > > I came across this thread from five years ago: > > > > http://erlang.org/pipermail/erlang-questions/2008-October/038848.html > > > > Was a bug report raised? If not, I'd like to raise one please :-) > > > > 1. erlang:get_module_info/1 and erlang:get_module_info/2 need to be > > documented in the ERTS manual. > > Why would you put it in the public documentation when it is an implementation > detail (cf. for example the comment about module_info in ops.tab [1])? Why > not call M:module_info()? I agree there is no reason to document these. They are internal and there is never any reason to call them. > > 2. The documentation for module_info/0 and module_info/1 need to clarify > > that they will always return info for the current version of a loaded > > module, rather than the version that is active for the caller. > > > > 3. Can #2 above be fixed so that it returns data related to the active > > module, rather than the current version? > > 2 and 3 may be a problem in the context of calling module_info directly as a > local function from the very same module. If you call foo:module_info from > the module bar, it would make absolutely no sense to return anything else > but the current version. I agree here. Doing a fully qualified call to a function in a module always gives you the current version so calling foo:module_info() should behave the same way. In the same vein using erlang:get_module_info/1/2 should also behave in the same way and give the current version otherwise you could get some really weird and inconsistent behaviour. For example if you call it from within the module foo you would get the "active" version for the caller, but what if you are in a function in another module which has been called from module foo? Which version would you get then, the current version or the "active" version you are "in"? Convoluted I know, but things like this need to be decided, and preferably consistent. However, doing a local call to module_info should give you the active version, which it doesn't today. The module_info/1/2 don't simply return a pre-built data structure but do call erlang:get_module_info/1/2 which is the root of the problem. Back in the (really) old days we did generate the data structure at compile time so this wasn't a problem. Though I can't remember anyone actually calling module_info locally. > But then again, if your application depends on this, you are probably doing > something really unusual. > > > Many thanks > > > > Fred > > Regards, > > [1] > https://github.com/erlang/otp/blob/maint/erts/emulator/beam/ops.tab#L35-L39 From fly@REDACTED Wed Nov 27 12:43:31 2013 From: fly@REDACTED (Fred Youhanaie) Date: Wed, 27 Nov 2013 11:43:31 +0000 Subject: [erlang-bugs] no documentation for module_info and get_module_info In-Reply-To: <10D245D5-4A2E-43B9-81B3-6BB48FB07792@gmail.com> References: <5295B9DF.3090409@anydata.co.uk> <10D245D5-4A2E-43B9-81B3-6BB48FB07792@gmail.com> Message-ID: <5295DAE3.7090205@anydata.co.uk> in-line ... On 27/11/13 10:27, Anthony Ramine wrote: > Replied inline. > >Le 27 nov. 2013 ? 10:22, Fred Youhanaie a ?crit : > ... > >> 1. erlang:get_module_info/1 and erlang:get_module_info/2 need to be >> documented in the ERTS manual. > >Why would you put it in the public documentation when it is an implementation detail (cf. for example the comment about module_info in ops.tab [1])? Why not call M:module_info()? Although the original intention was to improve the implementation, nevertheless, it can provide useful functionality for other uses, provided that it is stable and safe to use. If it's not meant to be used publicly, then the documentation should say so. Lack of documentation will not stop others from blindly using it! >> 2. The documentation for module_info/0 and module_info/1 need to clarify >> that they will always return info for the current version of a loaded >> module, rather than the version that is active for the caller. >> >> 3. Can #2 above be fixed so that it returns data related to the active >> module, rather than the current version? > >2 and 3 may be a problem in the context of calling module_info directly as a local function from the very same module. If you call foo:module_info from the module bar, it would make absolutely no sense to return anything else but the current version. On the contrary, module_info, as opposed to M:module_info, should behave in the same way as other functions. If not, then either it should be fixed or the exceptional behaviour documented. >But then again, if your application depends on this, you are probably doing something really unusual. There is nothing unusual about introspection within dynamic/scripting languages. In one particular case this means that I cannot rely on the Vsn attribute to give me the correct version when there are two versions of the module loaded. f. From fly@REDACTED Wed Nov 27 13:28:43 2013 From: fly@REDACTED (Fred Youhanaie) Date: Wed, 27 Nov 2013 12:28:43 +0000 Subject: [erlang-bugs] no documentation for module_info and get_module_info In-Reply-To: <1212030937.66376.1385552373395.JavaMail.zimbra@erlang-solutions.com> References: <5295B9DF.3090409@anydata.co.uk> <10D245D5-4A2E-43B9-81B3-6BB48FB07792@gmail.com> <1212030937.66376.1385552373395.JavaMail.zimbra@erlang-solutions.com> Message-ID: <5295E57B.6010706@anydata.co.uk> in-line On 27/11/13 11:39, Robert Virding wrote: > Comment to a comment further down. > > Robert > > ----- Original Message ----- >> From: "Anthony Ramine" >> >> Replied inline. >> >> -- >> Anthony Ramine >> >> Le 27 nov. 2013 ? 10:22, Fred Youhanaie a ?crit : >> >>> Hi >>> >>> I came across this thread from five years ago: >>> >>> http://erlang.org/pipermail/erlang-questions/2008-October/038848.html >>> >>> Was a bug report raised? If not, I'd like to raise one please :-) >>> >>> 1. erlang:get_module_info/1 and erlang:get_module_info/2 need to be >>> documented in the ERTS manual. >> >> Why would you put it in the public documentation when it is an implementation >> detail (cf. for example the comment about module_info in ops.tab [1])? Why >> not call M:module_info()? > > I agree there is no reason to document these. They are internal and there is never any reason to call them. > Well, judging by the related thread on erlang-questions, the internal functions are known and publicly accessible. So, perhaps the documentation can be a DO NOT USE notice! >>> 2. The documentation for module_info/0 and module_info/1 need to clarify >>> that they will always return info for the current version of a loaded >>> module, rather than the version that is active for the caller. >>> >>> 3. Can #2 above be fixed so that it returns data related to the active >>> module, rather than the current version? >> >> 2 and 3 may be a problem in the context of calling module_info directly as a >> local function from the very same module. If you call foo:module_info from >> the module bar, it would make absolutely no sense to return anything else >> but the current version. > > I agree here. Doing a fully qualified call to a function in a module always gives you the current version so calling foo:module_info() should behave the same way. In the same vein using erlang:get_module_info/1/2 should also behave in the same way and give the current version otherwise you could get some really weird and inconsistent behaviour. For example if you call it from within the module foo you would get the "active" version for the caller, but what if you are in a function in another module which has been called from module foo? Which version would you get then, the current version or the "active" version you are "in"? Convoluted I know, but things like this need to be decided, and preferably consistent. > > However, doing a local call to module_info should give you the active version, which it doesn't today. The module_info/1/2 don't simply return a pre-built data structure but do call erlang:get_module_info/1/2 which is the root of the problem. Back in the (really) old days we did generate the data structure at compile time so this wasn't a problem. Though I can't remember anyone actually calling module_info locally. > Yes, and my query all along has been about the local call (mis)behaviour, which needs to be fixed or documented. Although not used before, module_info/0/1 and perhaps even the BIF counterparts, can be useful introspection tools. Programmers today tend to leverage what is available to them in all sorts of ways :-) Cheers f. From a-grk@REDACTED Thu Nov 28 14:19:38 2013 From: a-grk@REDACTED (Alex Peshkov) Date: Thu, 28 Nov 2013 17:19:38 +0400 Subject: [erlang-bugs] R16B02 asn1 encoding issue Message-ID: <6B4665B5-72CC-4887-B9A6-4C8B796F41A4@yandex.ru> Hello, I have the ASN1 file containing the following lines: AppConfig ::= SEQUENCE OF AppRuntimeParameter AppRuntimeParameter ::= CHOICE { debug-level INTEGER, listen-port INTEGER (1..65535), ... } When I compile this ASN1 file with asn1ct:compile(?AppUpstream.asn1", [ber_bin, undec_rest, optimize]) and Erlang R15B01 - I get a AppUpstream.erl file with the following code for handling ?AppConfig?: 'enc_AppConfig'(Val) -> 'enc_AppConfig'(Val, [<<48>>]). ' enc_AppConfig'({?AppConfig',Val}, TagIn) -> 'enc_AppConfig'(Val, TagIn); 'enc_AppConfig'(Val, TagIn) -> {EncBytes,EncLen} = 'enc_AppConfig_components'(Val,[],0), ?RT_BER:encode_tags(TagIn, EncBytes, EncLen). 'enc_AppConfig_components'([], AccBytes, AccLen) -> {lists:reverse(AccBytes),AccLen}; When I compile the same ASN1 file with asn1ct:compile(?AppUpstream.asn1", [ber, undec_rest]) and Erlang R16B02 (the ?optimize? option is not necessary anymore and ?ber_bin' is replaced with ?ber? according to http://www.erlang.org/doc/man/asn1ct.html) I get the following code for handling ?AppConfig?: 'enc_AppConfig'(Val) -> 'enc_AppConfig'(Val, [<<48>>]). 'enc_AppConfig'(Val, TagIn) -> {EncBytes,EncLen} = 'enc_AppConfig_components'(Val,[],0), encode_tags(TagIn, EncBytes, EncLen). This part of code is omitted by erlang asn1 compiler: ' enc_AppConfig'({?AppConfig',Val}, TagIn) -> 'enc_AppConfig'(Val, TagIn); and I get function_clause error during asn1ct:encode call. From bgustavsson@REDACTED Thu Nov 28 17:15:53 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 28 Nov 2013 17:15:53 +0100 Subject: [erlang-bugs] R16B02 asn1 encoding issue In-Reply-To: <6B4665B5-72CC-4887-B9A6-4C8B796F41A4@yandex.ru> References: <6B4665B5-72CC-4887-B9A6-4C8B796F41A4@yandex.ru> Message-ID: On Thu, Nov 28, 2013 at 2:19 PM, Alex Peshkov wrote: > [...] This part of code is omitted by erlang asn1 compiler: > ' enc_AppConfig'({?AppConfig',Val}, TagIn) -> > 'enc_AppConfig'(Val, TagIn); > > and I get function_clause error during asn1ct:encode call. > The use of {Type,Val} has long been obsolete, and it didn't work in all back-ends in R15. In R16, we have removed the old back-ends and removed all support for {Type,Val}. So what you need is to stop using {'AppConfig',Val} and only use Val. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: