From bduggan@REDACTED Tue Apr 1 01:30:47 2014 From: bduggan@REDACTED (Bernard Duggan) Date: Tue, 1 Apr 2014 10:30:47 +1100 Subject: [erlang-bugs] QLC boolean condition Message-ID: <5339FAA7.7040801@shoretel.com> Hi all, It looks like QLC doesn't quite handle boolean operators in its filters correctly. For the following code: ------------------- -module(qlc_bug). -include_lib("stdlib/include/qlc.hrl"). -compile(export_all). -record( rec, { a, b }). test() -> T = ets:new(test, [{keypos, 2}]), ets:insert(T, #rec{a = 1, b = 1}), ets:insert(T, #rec{a = 2, b = 2}), qlc:e(qlc:q([A || A <- ets:table(T), A#rec.a =:= 1 orelse (A#rec.a =:= 2 andalso A#rec.b =:= 1)])). ------------------- I would expect a call to test/0 to return [{rec, 1, 1}], since the second record ({rec, 2, 2}) should be excluded by the right hand side of the 'andalso'. However the returned value is [{rec,1,1},{rec,2,2}]. (Tested on R16B03). Cheers, Bernard ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. From vinoski@REDACTED Tue Apr 1 02:53:40 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Mon, 31 Mar 2014 20:53:40 -0400 Subject: [erlang-bugs] Minor issue: Bad arity display for crypto:hash_update in R16-B03-1 In-Reply-To: <007301cf4d1c$ec4b13c0$c4e13b40$@luxoft.com> References: <007301cf4d1c$ec4b13c0$c4e13b40$@luxoft.com> Message-ID: On Mon, Mar 31, 2014 at 4:08 PM, Alexei Dodon wrote: > When using deprecated crypto functions, warnings are displayed suggesting > use of recommended functions. > > Use of crypto:hash_update/3 is recommended in a warning message , but > arity of crypto:hash_update is 2 (not 3). > > > > Example: > > Erlang R16B03-1 (erts-5.10.4) [source] [async-threads:10] > [kernel-poll:false] > > > > Eshell V5.10.4 (abort with ^G) > > 1> c(to_reproduce). > > to_reproduce.erl:5: Warning: crypto:md5_init/0 is deprecated and will be > removed in in a future release; use crypto:hash_init/1 > > to_reproduce.erl:6: Warning: crypto:md5_update/2 is deprecated and will be > removed in in a future release; use crypto:hash_update/3 > > {ok,to_reproduce} > > 2> to_reproduce:start(). > > <<1,35,69,103,137,171,205,239,254,220,186,152,118,84,50, > > 16,64,0,0,0,0,0,0,0,83,111,109,101,68,...>> > > 3> crypto:hash > > hash/2 hash_final/1 hash_init/1 hash_update/2 > > 3> crypto:hash > Here's a fix: https://github.com/erlang/otp/pull/322 --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Tue Apr 1 10:05:54 2014 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 1 Apr 2014 10:05:54 +0200 Subject: [erlang-bugs] Incorrect matching of non-ASCII characters using \w regex in unicode mode In-Reply-To: <53357E66.7040006@online.nl> References: <53357E66.7040006@online.nl> Message-ID: <533A7362.10305@erlang.org> Hello, As far as I can tell this is a flaw/optimization in how PCRE works. You get the same behaviour in R16B03 for erlang. However in later versions of PCRE an option to deal with this has been introcudes called PCRE_UCP and in OTP 17.0 the version of PCRE used has been lifted to 8.33 which includes this option. So in OTP 17 use: 1> re:run("G?tterfunken", "\\W+", [{capture, all, list}, unicode, ucp]). nomatch 2> re:run("G?tterfunken", "\\w+", [{capture, all, list}, unicode, ucp]). {match,["G?tterfunken"]} 3> re:run("G?tterfunken", "\\W+", [{capture, all, list}, unicode]). {match,["?"]} 4> re:run("G?tterfunken", "\\w+", [{capture, all, list}, unicode]). {match,["G?tterfunken"]} It seems like the PCRE docs agree with the erlang docs for how \w and \W should be treated, but they also add that "although this may vary for characters in the range 128-255 when locale-specific matching is happening". Maybe that is the cause of the confusion? Lukas On 28/03/14 14:51, Peter Minten wrote: > re:run doesn't properly handle non-ASCII characters using unicode mode. > On R17-rc2: > > 1> re:run("G?tterfunken", "\\w+", [{capture, all, list}, unicode]). > {match,["G?tterfunken"]} > 2> re:run("G?tterfunken", "\\W+", [{capture, all, list}, unicode]). > {match,["?"]} > > Apparently ? is both a word and a non-word character. > > http://www.erlang.org/doc/man/re.html#regexp_syntax says: > > """In UTF-8 mode, characters with values greater than 128 never match > \d, \s, or \w, and always match \D, \S, and \W. This is true even when > Unicode character property support is available. These sequences retain > their original meanings from before UTF-8 support was available, mainly > for efficiency reasons.""" > > As I understand this a \w regex should never match ?. > > Greetings, > > Peter > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From hans.bolinder@REDACTED Tue Apr 1 12:54:25 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 1 Apr 2014 10:54:25 +0000 Subject: [erlang-bugs] QLC boolean condition In-Reply-To: <5339FAA7.7040801@shoretel.com> References: <5339FAA7.7040801@shoretel.com> Message-ID: <56466BD70414EA48969B4064696CF28C037C4265@ESESSMB207.ericsson.se> Hi, [Bernard Duggan:] > It looks like QLC doesn't quite handle boolean operators in its filters correctly. Thanks for the bug report. There is a fix in the upcoming Erlang/OTP 17.0 release, see commit 28d4b0c. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From magnus.mueller@REDACTED Wed Apr 2 12:39:11 2014 From: magnus.mueller@REDACTED (Magnus Mueller) Date: Wed, 2 Apr 2014 10:39:11 +0000 Subject: [erlang-bugs] httpc: function_clause crash in http_transport:close/2 Message-ID: Hello List, we detected an error in httpc. It happened in R16B01 on Mac OS X, but should be around in new versions as well if my argument below is valid. I could not reproduce the issue yet and think there is a race condition. The error occurred while requesting a page over http. I attached the error report at the end of the mail. ====== Preliminary Analysis `http_transport:close/2` crashes due to a function_clause error. As the socket argument of the function equals `{remote_close,Socket}`, and because this is run over http, we can be sure that the following `handle_info/2` clause was run before `terminate/2` was called: handle_info({tcp_closed, _}, #state{session = Session0} = State) -> Socket = Session0#session.socket, Session = Session0#session{socket = {remote_close, Socket}}, %% {stop, session_remotly_closed, State}; {stop, normal, State#state{session = Session}}; This leaves the question why the argument `SocketType` in the call to `http_transport:close/2` is `undefined`. The only reason I could think of was that the initial send request in `httpc_handler:connect_and_send_first_request/3` failed. If that happens, `SocketType` is not added to `#session{}`. Also, the field `#session.id` is `undefined`. The value of `#session.id` leads to the execution of the following `httpc_handler:terminate/2` clause: terminate(normal, #state{session = #session{id = undefined} = Session}) -> close_socket(Session); The call `close_socket/1` here then leads to the error reported below. ====== Order of events which might trigger the issue Summarizing, I think that the following order of events triggers the error report below: 1. A call to `httpc_handler:connect_and_send_first_request/3` 2. The socket is opened successfully, but closes immediately after that, which leads to a `{tcp_closed,Socket}` message being send to the handler process 3. The handler tries to send the initial request over the socket and fails, leaving `#session.socket_type` and `#session.id` undefined 4. The handler sends `{init_error,error_sending,_}` to itself. This message is BEHIND the `{tcp_closed,_}` message in the queue. 5. The handler enters its loop and processes `{tcp_closed,Socket}` 6. The `handle_info/2` call results in `{stop,normal,_}`. `#session.socket` is set to `{ remote_close,Socket}` 7. `terminate/2` is called and the clause which matches `#session.id=undefined` is chosen 8. This clause runs `httpc_handler:close_socket/1`, which then calls `http_transport:close_socket/2`. This last call fails then. ====== Possible Fix If the analysis is correct, fixing this problem should be possible by ensuring that `#session.socket_type` is not set to undefined when `#session.socket` is set. There are also two `terminate/2` clauses to handle initialization errors, but as far as I see they are not called here: %% Init error there is no socket to be closed. terminate(normal, #state{request = Request, session = {send_failed, AReason} = Reason} = State) -> ?hcrd("terminate", [{send_reason, AReason}, {request, Request}]), maybe_send_answer(Request, httpc_response:error(Request, Reason), State), ok; terminate(normal, #state{request = Request, session = {connect_failed, AReason} = Reason} = State) -> ?hcrd("terminate", [{connect_reason, AReason}, {request, Request}]), maybe_send_answer(Request, httpc_response:error(Request, Reason), State), ok; ====== Ending notes As noted in the beginning of the mail, I was not able to reproduce the error below. I tried to add `timer:sleep/1` calls to `httpc_handler` in order to force the order of events above, but that did not help either. Thus, I could be mistaken with my analysis above. I hope someone else can shed some light on this issu Regards, Magnus P.s. Here goes the lengthy error report: =ERROR REPORT==== 10-Mar-2014::16:34:36 === ** Generic server <0.12244.2> terminating ** Last message in was {tcp_closed,#Port<0.112265>} ** When Server state == {state, {request,#Ref<0.0.9.188247>,<0.11566.2>,0,http, {"127.0.0.1",63178}, "", "?",get, {http_request_h,undefined,"close",undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, "0",undefined,undefined,undefined, undefined,undefined,undefined,[]}, {[],[]}, {http_options,"HTTP/1.0",4700,true, {essl,[]}, undefined,false,4700,false}, "http://ip:port/", [],none,[],1394465676042,undefined, [{active,once}], false}, {session,undefined,undefined,undefined, {remote_close,#Port<0.112265>}, undefined,1,undefined,false}, undefined,undefined,undefined,undefined, {[],[]}, {[],[]}, undefined,[],nolimit,nolimit, {options, {undefined,[]}, {undefined,[]}, 0,0,0,120000,0,disabled,false,inet,default, default,[]}, {timers,[],undefined}, httpc_manager,inactive} ** Reason for termination == ** {function_clause,[{http_transport,close, [undefined, {remote_close,#Port<0.112265>}], [{file,"http_transport.erl"},{line,422}]}, {gen_server,terminate,6, [{file,"gen_server.erl"},{line,719}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]} From kostis@REDACTED Wed Apr 2 15:57:03 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 02 Apr 2014 15:57:03 +0200 Subject: [erlang-bugs] maps used as map keys crash BEAM compiler Message-ID: <533C172F.5060106@cs.ntua.gr> In playing with map support for native code we run into the following compiler bug (this refers to the current -- and supposedly frozen for 17.0, but I hope bug fixes are still possible to be included to it -- 'master' branch) -module(pmatch_map_key_bug). -export([foo/1]). foo(#{#{} := 42}) -> true; foo(_) -> false. $ erlc pmatch_map_key_bug.erl pmatch_map_key_bug.erl: internal error in core_module; crash reason: function_clause in function core_lib:literal_value/1 in call from v3_core:'-pattern_map_pairs/2-anonymous-0-'/3 in call from lists:mapfoldl/3 in call from v3_core:pattern_map_pairs/2 in call from v3_core:pattern/2 in call from v3_core:'-pattern_list/2-lc$^0/1-0-'/2 in call from v3_core:clause/2 in call from v3_core:clauses/2 I suggest the BEAM compiler should consistently make up its mind whether maps are literals or not. Kostis PS. Thanks to @margnus1 for the original bug report. PS2. Apologies if this ends up twice on the mailing list; sent from a different mail address first. From egil@REDACTED Wed Apr 2 16:49:34 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 2 Apr 2014 16:49:34 +0200 Subject: [erlang-bugs] maps used as map keys crash BEAM compiler In-Reply-To: <533C172F.5060106@cs.ntua.gr> References: <533C172F.5060106@cs.ntua.gr> Message-ID: <533C237E.3090103@erlang.org> Thanks for reporting! On 2014-04-02 15:57, Kostis Sagonas wrote: > In playing with map support for native code we run into the following > compiler bug (this refers to the current -- and supposedly frozen for > 17.0, but I hope bug fixes are still possible to be included to it -- > 'master' branch) > > -module(pmatch_map_key_bug). > -export([foo/1]). > > foo(#{#{} := 42}) -> true; > foo(_) -> false. > > $ erlc pmatch_map_key_bug.erl > pmatch_map_key_bug.erl: internal error in core_module; > crash reason: function_clause > > in function core_lib:literal_value/1 > in call from v3_core:'-pattern_map_pairs/2-anonymous-0-'/3 > in call from lists:mapfoldl/3 > in call from v3_core:pattern_map_pairs/2 > in call from v3_core:pattern/2 > in call from v3_core:'-pattern_list/2-lc$^0/1-0-'/2 > in call from v3_core:clause/2 > in call from v3_core:clauses/2 > > > I suggest the BEAM compiler should consistently make up its mind > whether maps are literals or not. > > Kostis > > PS. Thanks to @margnus1 for the original bug report. > PS2. Apologies if this ends up twice on the mailing list; sent from a > different mail address first. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From andrew@REDACTED Thu Apr 3 02:00:39 2014 From: andrew@REDACTED (Andrew Thompson) Date: Wed, 2 Apr 2014 20:00:39 -0400 Subject: [erlang-bugs] Race condition in cover.erl Message-ID: <20140403000038.GW24036@hijacked.us> I've been doing some pretty extreme coverage reporting lately in an effort to help understand the coverage provided by Basho's integration test suite riak_test. As part of that work I've seen, several times now, an error like this: 2014-04-02 15:47:23 =ERROR REPORT==== Error in process <0.80.0> on node 'riak_test@REDACTED' with exit value: {function_clause,[{cover,'-sync_compiled/2-lc$^0/1-0-',[ok],[{file,"cover.erl"},{line,1077}]},{cover,sync_compiled,2,[{file,"cover.erl"},{line,1077}]},{cover,main_process_loop,1,[{file,"cover.erl"},{line,819}]}]} However, this is *extremely* hard to reproduce with my use case, taking upwards of 15 hours, and it only happens on slower machines. I've added some debug prints, and the result of remote_call(Node,{remote,get_compiled}) is coming back as 'ok'. Looking at the code for that, we can see that is clearly impossible: https://github.com/erlang/otp/blob/maint/lib/tools/src/cover.erl#L893 #remote_state.compiled is always a list, so where is the 'ok' coming from? At first I thought the async reply from collect,remote was the source of the errant 'ok', but re-reading that code, it is using the 'from' syntax, so the collect,remote replies are going to a particular pid, not the registered cover ?SERVER. The problem remains, however, that cover.erl plays fast and loose with the mailbox, requests and replies are not tagged with a ref (like in gen_server) so it is possible for the receive in remote_call to get a reply for a request it did not make: https://github.com/erlang/otp/blob/maint/lib/tools/src/cover.erl#L570 I am pretty sure that is what is happening here, although I cannot spot the exact cause. Mismatched requests/replies could happen quiet frequently in this module, given that most of the commands simply return 'ok' anyway. I'm happy to put some more time into debugging and fixing this, but I need some more information on what I can and can't do. 1 - Can I change the messaging protocol in a backwards compatible way? Is running coverage across multiple nodes at once expected to work across OTP versions? Can I change the protocol if I keep things backwards compatible (by enumerating something on the spawned remotes to see if they can use the new protocol)? 2 - Why is this code not a gen_server? Is there some reason or is it just because of the age of the code? Would it be permissible to refactor cover.erl into 2 gen_servers (main and remote cover servers)? Andrew From Ingela.Anderton.Andin@REDACTED Thu Apr 3 11:26:41 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 3 Apr 2014 11:26:41 +0200 Subject: [erlang-bugs] httpc: function_clause crash in http_transport:close/2 In-Reply-To: References: Message-ID: <533D2951.7070609@ericsson.com> Hi! The following diff against current master should solve the problem. I have however not investigated if you can apply this directly to R16B01. diff --git a/lib/inets/src/http_client/httpc_handler.erl b/lib/inets/src/http_client/httpc_handler.erl index 88e08be..6e17678 100644 --- a/lib/inets/src/http_client/httpc_handler.erl +++ b/lib/inets/src/http_client/httpc_handler.erl @@ -1378,6 +1378,8 @@ case_insensitive_header(Str) -> activate_once(#session{socket = Socket, socket_type = SocketType}) -> http_transport:setopts(SocketType, Socket, [{active, once}]). +close_socket(#session{socket = {remote_close,_}}) -> + ok; close_socket(#session{socket = Socket, socket_type = SocketType}) -> http_transport:close(SocketType, Socket). Regards Ingela Erlang/OTP team - Ericsson AB On 04/02/2014 12:39 PM, Magnus Mueller wrote: > Hello List, > > we detected an error in httpc. It happened in R16B01 on Mac OS X, but should be around in new versions as well if my argument below is valid. I could not reproduce the issue yet and think there is a race condition. The error occurred while requesting a page over http. I attached the error report at the end of the mail. > > > ====== Preliminary Analysis > > `http_transport:close/2` crashes due to a function_clause error. As the socket argument of the function equals `{remote_close,Socket}`, and because this is run over http, we can be sure that the following `handle_info/2` clause was run before `terminate/2` was called: > > handle_info({tcp_closed, _}, #state{session = Session0} = State) -> > Socket = Session0#session.socket, > Session = Session0#session{socket = {remote_close, Socket}}, > %% {stop, session_remotly_closed, State}; > {stop, normal, State#state{session = Session}}; > > This leaves the question why the argument `SocketType` in the call to `http_transport:close/2` is `undefined`. The only reason I could think of was that the initial send request in `httpc_handler:connect_and_send_first_request/3` failed. If that happens, `SocketType` is not added to `#session{}`. Also, the field `#session.id` is `undefined`. The value of `#session.id` leads to the execution of the following `httpc_handler:terminate/2` clause: > > terminate(normal, > #state{session = #session{id = undefined} = Session}) -> > close_socket(Session); > > The call `close_socket/1` here then leads to the error reported below. > > > ====== Order of events which might trigger the issue > > Summarizing, I think that the following order of events triggers the error report below: > > 1. A call to `httpc_handler:connect_and_send_first_request/3` > 2. The socket is opened successfully, but closes immediately after that, which leads to a `{tcp_closed,Socket}` message being send to the handler process > 3. The handler tries to send the initial request over the socket and fails, leaving `#session.socket_type` and `#session.id` undefined > 4. The handler sends `{init_error,error_sending,_}` to itself. This message is BEHIND the `{tcp_closed,_}` message in the queue. > 5. The handler enters its loop and processes `{tcp_closed,Socket}` > 6. The `handle_info/2` call results in `{stop,normal,_}`. `#session.socket` is set to `{ remote_close,Socket}` > 7. `terminate/2` is called and the clause which matches `#session.id=undefined` is chosen > 8. This clause runs `httpc_handler:close_socket/1`, which then calls `http_transport:close_socket/2`. This last call fails then. > > ====== Possible Fix > > If the analysis is correct, fixing this problem should be possible by ensuring that `#session.socket_type` is not set to undefined when `#session.socket` is set. There are also two `terminate/2` clauses to handle initialization errors, but as far as I see they are not called here: > > %% Init error there is no socket to be closed. > terminate(normal, > #state{request = Request, > session = {send_failed, AReason} = Reason} = State) -> > ?hcrd("terminate", [{send_reason, AReason}, {request, Request}]), > maybe_send_answer(Request, > httpc_response:error(Request, Reason), > State), > ok; > > terminate(normal, > #state{request = Request, > session = {connect_failed, AReason} = Reason} = State) -> > ?hcrd("terminate", [{connect_reason, AReason}, {request, Request}]), > maybe_send_answer(Request, > httpc_response:error(Request, Reason), > State), > ok; > > ====== Ending notes > > As noted in the beginning of the mail, I was not able to reproduce the error below. I tried to add `timer:sleep/1` calls to `httpc_handler` in order to force the order of events above, but that did not help either. Thus, I could be mistaken with my analysis above. I hope someone else can shed some light on this issu > > Regards, Magnus > > P.s. Here goes the lengthy error report: > > =ERROR REPORT==== 10-Mar-2014::16:34:36 === > ** Generic server <0.12244.2> terminating > ** Last message in was {tcp_closed,#Port<0.112265>} > ** When Server state == {state, > {request,#Ref<0.0.9.188247>,<0.11566.2>,0,http, > {"127.0.0.1",63178}, > "", > "?",get, > {http_request_h,undefined,"close",undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > "0",undefined,undefined,undefined, > undefined,undefined,undefined,[]}, > {[],[]}, > {http_options,"HTTP/1.0",4700,true, > {essl,[]}, > undefined,false,4700,false}, > "http://ip:port/", > [],none,[],1394465676042,undefined, > [{active,once}], > false}, > {session,undefined,undefined,undefined, > {remote_close,#Port<0.112265>}, > undefined,1,undefined,false}, > undefined,undefined,undefined,undefined, > {[],[]}, > {[],[]}, > undefined,[],nolimit,nolimit, > {options, > {undefined,[]}, > {undefined,[]}, > 0,0,0,120000,0,disabled,false,inet,default, > default,[]}, > {timers,[],undefined}, > httpc_manager,inactive} > ** Reason for termination == > ** {function_clause,[{http_transport,close, > [undefined, > {remote_close,#Port<0.112265>}], > [{file,"http_transport.erl"},{line,422}]}, > {gen_server,terminate,6, > [{file,"gen_server.erl"},{line,719}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]} > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From magnus.mueller@REDACTED Thu Apr 3 11:41:06 2014 From: magnus.mueller@REDACTED (Magnus Mueller) Date: Thu, 3 Apr 2014 09:41:06 +0000 Subject: [erlang-bugs] httpc: function_clause crash in http_transport:close/2 Message-ID: <11cd63276c67435ea86ee6893e17ec20@DBXPR03MB511.eurprd03.prod.outlook.com> Hey Ingela, thanks for your quick response. I cannot apply the patch directly to R16B01, but it is simple enough to replicate. Magnus -----Urspr?ngliche Nachricht----- Von: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED] Im Auftrag von Ingela Anderton Andin Gesendet: Donnerstag, 3. April 2014 11:27 An: erlang-bugs@REDACTED Betreff: Re: [erlang-bugs] httpc: function_clause crash in http_transport:close/2 Hi! The following diff against current master should solve the problem. I have however not investigated if you can apply this directly to R16B01. diff --git a/lib/inets/src/http_client/httpc_handler.erl b/lib/inets/src/http_client/httpc_handler.erl index 88e08be..6e17678 100644 --- a/lib/inets/src/http_client/httpc_handler.erl +++ b/lib/inets/src/http_client/httpc_handler.erl @@ -1378,6 +1378,8 @@ case_insensitive_header(Str) -> activate_once(#session{socket = Socket, socket_type = SocketType}) -> http_transport:setopts(SocketType, Socket, [{active, once}]). +close_socket(#session{socket = {remote_close,_}}) -> + ok; close_socket(#session{socket = Socket, socket_type = SocketType}) -> http_transport:close(SocketType, Socket). Regards Ingela Erlang/OTP team - Ericsson AB On 04/02/2014 12:39 PM, Magnus Mueller wrote: > Hello List, > > we detected an error in httpc. It happened in R16B01 on Mac OS X, but should be around in new versions as well if my argument below is valid. I could not reproduce the issue yet and think there is a race condition. The error occurred while requesting a page over http. I attached the error report at the end of the mail. > > > ====== Preliminary Analysis > > `http_transport:close/2` crashes due to a function_clause error. As the socket argument of the function equals `{remote_close,Socket}`, and because this is run over http, we can be sure that the following `handle_info/2` clause was run before `terminate/2` was called: > > handle_info({tcp_closed, _}, #state{session = Session0} = State) -> > Socket = Session0#session.socket, > Session = Session0#session{socket = {remote_close, Socket}}, > %% {stop, session_remotly_closed, State}; > {stop, normal, State#state{session = Session}}; > > This leaves the question why the argument `SocketType` in the call to `http_transport:close/2` is `undefined`. The only reason I could think of was that the initial send request in `httpc_handler:connect_and_send_first_request/3` failed. If that happens, `SocketType` is not added to `#session{}`. Also, the field `#session.id` is `undefined`. The value of `#session.id` leads to the execution of the following `httpc_handler:terminate/2` clause: > > terminate(normal, > #state{session = #session{id = undefined} = Session}) -> > close_socket(Session); > > The call `close_socket/1` here then leads to the error reported below. > > > ====== Order of events which might trigger the issue > > Summarizing, I think that the following order of events triggers the error report below: > > 1. A call to `httpc_handler:connect_and_send_first_request/3` > 2. The socket is opened successfully, but closes immediately after > that, which leads to a `{tcp_closed,Socket}` message being send to the > handler process 3. The handler tries to send the initial request over the socket and fails, leaving `#session.socket_type` and `#session.id` undefined 4. The handler sends `{init_error,error_sending,_}` to itself. This message is BEHIND the `{tcp_closed,_}` message in the queue. > 5. The handler enters its loop and processes `{tcp_closed,Socket}` 6. > The `handle_info/2` call results in `{stop,normal,_}`. > `#session.socket` is set to `{ remote_close,Socket}` 7. `terminate/2` > is called and the clause which matches `#session.id=undefined` is chosen 8. This clause runs `httpc_handler:close_socket/1`, which then calls `http_transport:close_socket/2`. This last call fails then. > > ====== Possible Fix > > If the analysis is correct, fixing this problem should be possible by ensuring that `#session.socket_type` is not set to undefined when `#session.socket` is set. There are also two `terminate/2` clauses to handle initialization errors, but as far as I see they are not called here: > > %% Init error there is no socket to be closed. > terminate(normal, > #state{request = Request, > session = {send_failed, AReason} = Reason} = State) -> > ?hcrd("terminate", [{send_reason, AReason}, {request, Request}]), > maybe_send_answer(Request, > httpc_response:error(Request, Reason), > State), > ok; > > terminate(normal, > #state{request = Request, > session = {connect_failed, AReason} = Reason} = State) -> > ?hcrd("terminate", [{connect_reason, AReason}, {request, Request}]), > maybe_send_answer(Request, > httpc_response:error(Request, Reason), > State), > ok; > > ====== Ending notes > > As noted in the beginning of the mail, I was not able to reproduce the > error below. I tried to add `timer:sleep/1` calls to `httpc_handler` > in order to force the order of events above, but that did not help > either. Thus, I could be mistaken with my analysis above. I hope > someone else can shed some light on this issu > > Regards, Magnus > > P.s. Here goes the lengthy error report: > > =ERROR REPORT==== 10-Mar-2014::16:34:36 === > ** Generic server <0.12244.2> terminating > ** Last message in was {tcp_closed,#Port<0.112265>} > ** When Server state == {state, > {request,#Ref<0.0.9.188247>,<0.11566.2>,0,http, > {"127.0.0.1",63178}, > "", > "?",get, > {http_request_h,undefined,"close",undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > "0",undefined,undefined,undefined, > undefined,undefined,undefined,[]}, > {[],[]}, > {http_options,"HTTP/1.0",4700,true, > {essl,[]}, > undefined,false,4700,false}, > "http://ip:port/", > [],none,[],1394465676042,undefined, > [{active,once}], > false}, > {session,undefined,undefined,undefined, > {remote_close,#Port<0.112265>}, > undefined,1,undefined,false}, > undefined,undefined,undefined,undefined, > {[],[]}, > {[],[]}, > undefined,[],nolimit,nolimit, > {options, > {undefined,[]}, > {undefined,[]}, > 0,0,0,120000,0,disabled,false,inet,default, > default,[]}, > {timers,[],undefined}, > httpc_manager,inactive} > ** Reason for termination == > ** {function_clause,[{http_transport,close, > [undefined, > {remote_close,#Port<0.112265>}], > [{file,"http_transport.erl"},{line,422}]}, > {gen_server,terminate,6, > [{file,"gen_server.erl"},{line,719}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]} > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs From andreas@REDACTED Fri Apr 4 19:03:41 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Fri, 4 Apr 2014 19:03:41 +0200 Subject: [erlang-bugs] Fwd: Race condition in cover.erl In-Reply-To: <58912684E2630B45963406CF7D8C52581C396F9F@ESESSMB103.ericsson.se> References: <20140403000038.GW24036@hijacked.us> <58912684E2630B45963406CF7D8C52581C396F9F@ESESSMB103.ericsson.se> Message-ID: Thank you for the report and your initial investigation. We appreciate your offer to fix the issue and will come back with answers to your questions next week. Andreas Schumacher, Erlang/OTP, Ericsson AB -----Original Message----- From: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED] On Behalf Of Andrew Thompson Sent: den 3 april 2014 02:01 To: erlang-bugs@REDACTED Subject: [erlang-bugs] Race condition in cover.erl I've been doing some pretty extreme coverage reporting lately in an effort to help understand the coverage provided by Basho's integration test suite riak_test. As part of that work I've seen, several times now, an error like this: 2014-04-02 15:47:23 =ERROR REPORT==== Error in process <0.80.0> on node 'riak_test@REDACTED' with exit value: {function_clause,[{cover,'-sync_compiled/2-lc$^0/1-0-',[ok],[{file,"cover.erl"},{line,1077}]},{cover,sync_compiled,2,[{file,"cover.erl"},{line,1077}]},{cover,main_process_loop,1,[{file,"cover.erl"},{line,819}]}]} However, this is *extremely* hard to reproduce with my use case, taking upwards of 15 hours, and it only happens on slower machines. I've added some debug prints, and the result of remote_call(Node,{remote,get_compiled}) is coming back as 'ok'. Looking at the code for that, we can see that is clearly impossible: https://github.com/erlang/otp/blob/maint/lib/tools/src/cover.erl#L893 #remote_state.compiled is always a list, so where is the 'ok' coming from? At first I thought the async reply from collect,remote was the source of the errant 'ok', but re-reading that code, it is using the 'from' syntax, so the collect,remote replies are going to a particular pid, not the registered cover ?SERVER. The problem remains, however, that cover.erl plays fast and loose with the mailbox, requests and replies are not tagged with a ref (like in gen_server) so it is possible for the receive in remote_call to get a reply for a request it did not make: https://github.com/erlang/otp/blob/maint/lib/tools/src/cover.erl#L570 I am pretty sure that is what is happening here, although I cannot spot the exact cause. Mismatched requests/replies could happen quiet frequently in this module, given that most of the commands simply return 'ok' anyway. I'm happy to put some more time into debugging and fixing this, but I need some more information on what I can and can't do. 1 - Can I change the messaging protocol in a backwards compatible way? Is running coverage across multiple nodes at once expected to work across OTP versions? Can I change the protocol if I keep things backwards compatible (by enumerating something on the spawned remotes to see if they can use the new protocol)? 2 - Why is this code not a gen_server? Is there some reason or is it just because of the age of the code? Would it be permissible to refactor cover.erl into 2 gen_servers (main and remote cover servers)? Andrew _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.zegenhagen@REDACTED Mon Apr 7 10:13:16 2014 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Mon, 07 Apr 2014 10:13:16 +0200 Subject: [erlang-bugs] SNMP get-request failure Message-ID: <1396858396.24289.53.camel@ax-sze> Dear all, we have discovered at least one SNMP manager that composes get-requests like this: {pdu,'get-request',15,noError,0,[{varbind,,'INTEGER',0,1}]} Please note that the get-request does not contain 'NULL', 'NULL' as variabletype and value, but contains a valid type/value pair. To my knowledge, this is not forbidden. When the OID is not accessible (e.g. MAX-ACCESS is not-accessible or accessible-for-notify), the following response-PDU is generated: {pdu,'get-response',15,noError,0,[{varbind,,'INTEGER',noSuchInstance,1} Please not again that the variabletype is still the one from the original requests, e.g. the PDU processing in snmpa_agent:process_pdu/5 fails to update #varbind.variabletype when detecting errors. This response PDU fails to encode because of the ordering of the clauses in snmp_pdus:enc_value/2 which checks for basic BER types first, before considering known error atoms as values. The same problem does not exist when the instrumentation function for that object returns {noValue, Error} because the 'noValue' atom is copied to #varbind.variabletype in that case. A fix should probably: * reorder the clauses in snmp_pdus:enc_value/2, * overwrite #varbind.variabletype with 'NULL' or 'noValue' when detecting errors, * or do both of the above solutions. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From erlangsiri@REDACTED Mon Apr 7 11:28:14 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Mon, 7 Apr 2014 11:28:14 +0200 Subject: [erlang-bugs] Fwd: Race condition in cover.erl In-Reply-To: References: <20140403000038.GW24036@hijacked.us> <58912684E2630B45963406CF7D8C52581C396F9F@ESESSMB103.ericsson.se> Message-ID: Hi Andrew, we would really appreciate a fix for this issue. We think that cover should at least work across maintenance releases within the same major release, but we would also prefer a clean solution without the extra complexity that would be necessary for keeping the backwards compatibility. This means that we can only include this in the next major release, i.e. Erlang/OTP 18. I hope this is ok with you! I can't think of any good reason for not using gen_servers in cover, so please feel free to refactor the code using these behaviours. Best regards /siri 2014-04-04 19:03 GMT+02:00 Andreas Schumacher : > Thank you for the report and your initial investigation. We appreciate > your offer to fix the issue and will come back with answers to your > questions next week. > > Andreas Schumacher, Erlang/OTP, Ericsson AB > > > -----Original Message----- > From: erlang-bugs-bounces@REDACTED [mailto: > erlang-bugs-bounces@REDACTED] On Behalf Of Andrew Thompson > Sent: den 3 april 2014 02:01 > To: erlang-bugs@REDACTED > Subject: [erlang-bugs] Race condition in cover.erl > > I've been doing some pretty extreme coverage reporting lately in an effort > to help understand the coverage provided by Basho's integration test suite > riak_test. > > As part of that work I've seen, several times now, an error like this: > > 2014-04-02 15:47:23 =ERROR REPORT==== > Error in process <0.80.0> on node 'riak_test@REDACTED' with exit value: > > {function_clause,[{cover,'-sync_compiled/2-lc$^0/1-0-',[ok],[{file,"cover.erl"},{line,1077}]},{cover,sync_compiled,2,[{file,"cover.erl"},{line,1077}]},{cover,main_process_loop,1,[{file,"cover.erl"},{line,819}]}]} > > However, this is *extremely* hard to reproduce with my use case, taking > upwards of 15 hours, and it only happens on slower machines. > > I've added some debug prints, and the result of > remote_call(Node,{remote,get_compiled}) is coming back as 'ok'. > > Looking at the code for that, we can see that is clearly impossible: > > https://github.com/erlang/otp/blob/maint/lib/tools/src/cover.erl#L893 > > #remote_state.compiled is always a list, so where is the 'ok' coming from? > > At first I thought the async reply from collect,remote was the source of > the errant 'ok', but re-reading that code, it is using the 'from' > syntax, so the collect,remote replies are going to a particular pid, not > the registered cover ?SERVER. > > The problem remains, however, that cover.erl plays fast and loose with the > mailbox, requests and replies are not tagged with a ref (like in > gen_server) so it is possible for the receive in remote_call to get a > reply for a request it did not make: > > https://github.com/erlang/otp/blob/maint/lib/tools/src/cover.erl#L570 > > I am pretty sure that is what is happening here, although I cannot spot > the exact cause. Mismatched requests/replies could happen quiet frequently > in this module, given that most of the commands simply return 'ok' anyway. > > I'm happy to put some more time into debugging and fixing this, but I need > some more information on what I can and can't do. > > 1 - Can I change the messaging protocol in a backwards compatible way? > Is running coverage across multiple nodes at once expected to work > across OTP versions? Can I change the protocol if I keep things > backwards compatible (by enumerating something on the spawned > remotes to see if they can use the new protocol)? > > 2 - Why is this code not a gen_server? Is there some reason or is it > just because of the age of the code? Would it be permissible to > refactor cover.erl into 2 gen_servers (main and remote cover > servers)? > > Andrew > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aliaksiej.artamonau@REDACTED Mon Apr 7 23:28:18 2014 From: aliaksiej.artamonau@REDACTED (Aliaksey Artamonau) Date: Mon, 07 Apr 2014 14:28:18 -0700 Subject: [erlang-bugs] lost quotes in port arguments on Windows Message-ID: <53431872.3000000@gmail.com> Hi all, We've recently encountered a problem with application arguments being interpreted differently on Windows and on GNU/Linux. Basically if we pass something like "\"path\"" to our application, it's then correctly returned as string by application:get_env/2 function on GNU/Linux. On Windows though, it's being interpreted as an atom. Which causes problems if path happens to contain something that can't be part of unquoted atom (like colon character). After some investigation, I've come up with the following code snippet to demonstrate the root cause of our problem: (fun () -> P = open_port({spawn_executable, os:find_executable("erl")}, [exit_status, {line, 2000}, {args, ["-noshell", "-noinput", "-app", "test", "arg with\"\"double quotes in it", "-eval", "io:format([126,112,126,110], [init:get_argument(app)]), erlang:halt(0)."]}]), F = fun (R) -> receive {P, {data, {_, L}}} -> io:format("~s~n", [L]), R(R); {P, {exit_status, _}} -> ok end end, F(F) end)(). I just paste it into erl shell. If I run this on GNU/Linux with R16B03-1, I get this: {ok,[["test","arg with\"\"double quotes in it"]]} ok On Windows with the same Erlang version I get this: {ok,[["test","arg with\"double quotes in it"]]} ok Note that one of the quotes disappeared from the argument. Best regards, Aliaksey. From raimo+erlang-bugs@REDACTED Tue Apr 8 15:30:12 2014 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Tue, 8 Apr 2014 15:30:12 +0200 Subject: [erlang-bugs] SNMP get-request failure In-Reply-To: <1396858396.24289.53.camel@ax-sze> References: <1396858396.24289.53.camel@ax-sze> Message-ID: <20140408133012.GA31187@erix.ericsson.se> On Mon, Apr 07, 2014 at 10:13:16AM +0200, Stefan Zegenhagen wrote: > Dear all, > > we have discovered at least one SNMP manager that composes get-requests > like this: > > {pdu,'get-request',15,noError,0,[{varbind,,'INTEGER',0,1}]} > > Please note that the get-request does not contain 'NULL', 'NULL' as > variabletype and value, but contains a valid type/value pair. To my > knowledge, this is not forbidden. > > When the OID is not accessible (e.g. MAX-ACCESS is not-accessible or > accessible-for-notify), the following response-PDU is generated: > > {pdu,'get-response',15,noError,0,[{varbind,,'INTEGER',noSuchInstance,1} > > Please not again that the variabletype is still the one from the > original requests, e.g. the PDU processing in snmpa_agent:process_pdu/5 > fails to update #varbind.variabletype when detecting errors. > > This response PDU fails to encode because of the ordering of the clauses > in snmp_pdus:enc_value/2 which checks for basic BER types first, before > considering known error atoms as values. > > The same problem does not exist when the instrumentation function for > that object returns {noValue, Error} because the 'noValue' atom is > copied to #varbind.variabletype in that case. > > > A fix should probably: > * reorder the clauses in snmp_pdus:enc_value/2, > * overwrite #varbind.variabletype with 'NULL' or 'noValue' when > detecting errors, > * or do both of the above solutions. I'd say alternative 3: both. Moving the error atom clauses to the top in snmp_pdus:enc_value/2 should be sufficient, but the agent should ignore any types and values in the get-request and the manager should set them to 'NULL'; so pretending that the get-request contained 'NULL' for type and value ought to be a safe strategy. So we need to set #varbind.variabletype to 'NULL' in snmp_agent:check_all_table_vbs/4, snmp_agent:get_var_value_from_ivb/2 and snmp_agent:next_loop_varbinds/6 for #me.access == 'not-accessible', 'write-only' and 'accessible-for-notify' (note the reverse logic in the last function). I will write an internal ticket for this that will probably result in a patch for R16B03 and be included in 17.1. Thank you for an excellent problem report! > > > > Kind regards, > > -- > Dr. Stefan Zegenhagen > > arcutronix GmbH > Garbsener Landstr. 10 > 30419 Hannover > Germany > > Tel: +49 511 277-2734 > Fax: +49 511 277-2709 > Email: stefan.zegenhagen@REDACTED > Web: www.arcutronix.com > > *Synchronize the Ethernet* > > General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - > Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht > Hannover; Ust-Id: DE257551767. > > Please consider the environment before printing this message. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From rabbe.fogelholm@REDACTED Tue Apr 8 16:00:07 2014 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Tue, 8 Apr 2014 16:00:07 +0200 Subject: [erlang-bugs] A dialyzer option not described in the OTP documentation Message-ID: <534400E7.7050006@ericsson.com> With R16B02 `dialyzer -h' tells me that there is an option -Wno_undefined_callbacks. However, the online OTP documentation does not describe that particular option: http://www.erlang.org/doc/man/dialyzer.html BR / Rabbe Fogelholm, Ericsson, Stockholm From stefan.zegenhagen@REDACTED Tue Apr 8 16:01:24 2014 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Tue, 08 Apr 2014 16:01:24 +0200 Subject: [erlang-bugs] SNMP get-request failure In-Reply-To: <20140408133012.GA31187@erix.ericsson.se> References: <1396858396.24289.53.camel@ax-sze> <20140408133012.GA31187@erix.ericsson.se> Message-ID: <1396965684.24064.22.camel@ax-sze> Dear Raimo, > > I'd say alternative 3: both. > > Moving the error atom clauses to the top in snmp_pdus:enc_value/2 should > be sufficient, but the agent should ignore any types and values in > the get-request and the manager should set them to 'NULL'; so pretending > that the get-request contained 'NULL' for type and value ought to be > a safe strategy. > > So we need to set #varbind.variabletype to 'NULL' in > snmp_agent:check_all_table_vbs/4, snmp_agent:get_var_value_from_ivb/2 > and snmp_agent:next_loop_varbinds/6 for #me.access == > 'not-accessible', 'write-only' and 'accessible-for-notify' > (note the reverse logic in the last function). > > I will write an internal ticket for this that will probably result > in a patch for R16B03 and be included in 17.1. > > Thank you for an excellent problem report! Thank you for the fast response. I'm looking forward to the fix. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From lukas@REDACTED Tue Apr 8 17:50:04 2014 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 8 Apr 2014 17:50:04 +0200 Subject: [erlang-bugs] lost quotes in port arguments on Windows In-Reply-To: <53431872.3000000@gmail.com> References: <53431872.3000000@gmail.com> Message-ID: <53441AAC.8090902@erlang.org> Hello, Thanks for the bug report. Apparently there is some special code in the spawn_executable parts that mess things up by trying to be smart. Using spawn and handling the quoting yourself seems work better. I've written a patch for spawn_executable that fixes your problem, hopefully the tests will tell if I've managed to break something that depended on the current behaviour. Lukas On 07/04/14 23:28, Aliaksey Artamonau wrote: > Hi all, > > We've recently encountered a problem with application arguments being > interpreted differently on Windows and on GNU/Linux. Basically if we > pass something like "\"path\"" to our application, it's then correctly > returned as string by application:get_env/2 function on GNU/Linux. On > Windows though, it's being interpreted as an atom. Which causes > problems if path happens to contain something that can't be part of > unquoted atom (like colon character). After some investigation, I've > come up with the following code snippet to demonstrate the root cause > of our problem: > > (fun () -> > P = open_port({spawn_executable, os:find_executable("erl")}, > [exit_status, > {line, 2000}, > {args, ["-noshell", "-noinput", > "-app", "test", "arg with\"\"double > quotes in it", > "-eval", "io:format([126,112,126,110], > [init:get_argument(app)]), erlang:halt(0)."]}]), > > F = fun (R) -> > receive > {P, {data, {_, L}}} -> io:format("~s~n", > [L]), R(R); > {P, {exit_status, _}} -> ok > end > end, > F(F) > end)(). > > > I just paste it into erl shell. If I run this on GNU/Linux with > R16B03-1, I get this: > > {ok,[["test","arg with\"\"double quotes in it"]]} > ok > > > On Windows with the same Erlang version I get this: > > {ok,[["test","arg with\"double quotes in it"]]} > ok > > Note that one of the quotes disappeared from the argument. > > > Best regards, > Aliaksey. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From aronisstav@REDACTED Wed Apr 9 19:06:12 2014 From: aronisstav@REDACTED (Stavros Aronis) Date: Wed, 9 Apr 2014 19:06:12 +0200 Subject: [erlang-bugs] erlang:is_builtin(erlang,apply,3) = false Message-ID: Hello! Title says everything. Is this intentional? 1> erlang:is_builtin(erlang,apply,3). false Regards, Stavros PS: Apologies for just reporting this and not attempting a fix, but this seems to go deeper into C code than I am comfortable patching. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rohit12sh@REDACTED Thu Apr 10 03:04:22 2014 From: rohit12sh@REDACTED (rohit12sh .) Date: Wed, 9 Apr 2014 21:04:22 -0400 Subject: [erlang-bugs] Memory Leak in beam.smp Message-ID: I am using CouchDB which is based on Erlang. Recently I came across a bug in CouchDB which in-turn seems like a memory leak issue in NIF. I already have posted the issue to CouchDB community and thought of posting to Erlang community as well to see if this issue can be resolved in early next releases. Here is the link describing the complete use case: https://issues.apache.org/jira/browse/COUCHDB-2058 I have seen this issue from erlang version 5.8-5.10 so far. Please let me know if you have more questions. -- Regards, Rohit Sharma -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.muehmer@REDACTED Thu Apr 10 05:42:56 2014 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Thu, 10 Apr 2014 05:42:56 +0200 Subject: [erlang-bugs] otp_src_17.0.tar.gz: "make docs" fails in "system/doc/top" Message-ID: Yesterday I did a build with the new otp_src_17.0.tar.gz tarball using my script which served me quite well from R13Bxx to R17RC2, but this time it failed at "make docs": make[2]: Entering directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' make[2]: Nothing to be done for `docs'. make[2]: Leaving directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' make[2]: Entering directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' make[2]: Nothing to be done for `docs'. make[2]: Leaving directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' make[2]: Entering directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' make[2]: *** No rule to make target `../../README', needed by `docs'. Stop. make[2]: Leaving directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' make[1]: *** [docs] Error 2 make[1]: Leaving directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc' make: *** [docs] Error 2 I compared the 17.0 to the 17RC2 structure: it looks like the file "system/README" is missing. I could "fix" the build process with a "touch system/README"... not a real fix of course. Regards, Boris -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Thu Apr 10 08:09:28 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 10 Apr 2014 08:09:28 +0200 Subject: [erlang-bugs] otp_src_17.0.tar.gz: "make docs" fails in "system/doc/top" In-Reply-To: References: Message-ID: I think this has to do with that we deleted the system/README file on purpose because it did only contain useless outdated information. Apparently there is still some Makefile dependency which should not be there. So your quick fix with touch is ok, you will not miss anything interesting in the docs. /Kenneth , Erlang/OTP Ericsson Den 10 apr 2014 05:55 skrev "Boris M?hmer" : > Yesterday I did a build with the new otp_src_17.0.tar.gz tarball using my > script which served me quite well from R13Bxx to R17RC2, but this time it > failed at "make docs": > > > make[2]: Entering directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' > make[2]: Nothing to be done for `docs'. > make[2]: Leaving directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' > make[2]: Entering directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' > make[2]: Nothing to be done for `docs'. > make[2]: Leaving directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' > make[2]: Entering directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' > make[2]: *** No rule to make target `../../README', needed by `docs'. > Stop. > make[2]: Leaving directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' > make[1]: *** [docs] Error 2 > make[1]: Leaving directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc' > make: *** [docs] Error 2 > > > I compared the 17.0 to the 17RC2 structure: it looks like the file "system/README" > is missing. I could "fix" the build process with a "touch > system/README"... not a real fix of course. > > Regards, > Boris > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.muehmer@REDACTED Thu Apr 10 08:32:29 2014 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Thu, 10 Apr 2014 08:32:29 +0200 Subject: [erlang-bugs] otp_src_17.0.tar.gz: "make docs" fails in "system/doc/top" In-Reply-To: References: Message-ID: Should I provide an patch/pull request, or will You OTP guys do it? (I can't provide the patch right now, because I am pretty busy at the office right now...) Regards, Boris 2014-04-10 8:09 GMT+02:00 Kenneth Lundin : > I think this has to do with that we deleted > the system/README file on purpose because it did only contain useless > outdated information. Apparently there is still some Makefile dependency > which should not be there. > > So your quick fix with touch is ok, you will not miss anything interesting > in the docs. > > /Kenneth , Erlang/OTP Ericsson > Den 10 apr 2014 05:55 skrev "Boris M?hmer" : > >> Yesterday I did a build with the new otp_src_17.0.tar.gz tarball using my >> script which served me quite well from R13Bxx to R17RC2, but this time it >> failed at "make docs": >> >> >> make[2]: Entering directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' >> make[2]: Nothing to be done for `docs'. >> make[2]: Leaving directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' >> make[2]: Entering directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' >> make[2]: Nothing to be done for `docs'. >> make[2]: Leaving directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' >> make[2]: Entering directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' >> make[2]: *** No rule to make target `../../README', needed by `docs'. >> Stop. >> make[2]: Leaving directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' >> make[1]: *** [docs] Error 2 >> make[1]: Leaving directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc' >> make: *** [docs] Error 2 >> >> >> I compared the 17.0 to the 17RC2 structure: it looks like the file "system/README" >> is missing. I could "fix" the build process with a "touch >> system/README"... not a real fix of course. >> >> Regards, >> Boris >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.liden@REDACTED Thu Apr 10 08:41:49 2014 From: magnus.liden@REDACTED (Magnus Liden) Date: Thu, 10 Apr 2014 08:41:49 +0200 Subject: [erlang-bugs] otp_src_17.0.tar.gz: "make docs" fails in "system/doc/top" In-Reply-To: References: Message-ID: <53463D2D.8010101@ericsson.com> Hi Boris, Thanks for reporting, a fix is on the way. Regards, Magnus On Thu 10 Apr 2014 05:42:56 AM CEST, Boris M?hmer wrote: > Yesterday I did a build with the new otp_src_17.0.tar.gz tarball using > my script which served me quite well from R13Bxx to R17RC2, but this > time it failed at "make docs": > > > make[2]: Entering directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' > make[2]: Nothing to be done for `docs'. > make[2]: Leaving directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' > make[2]: Entering directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' > make[2]: Nothing to be done for `docs'. > make[2]: Leaving directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' > make[2]: Entering directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' > make[2]: *** No rule to make target `../../README', needed by `docs'. > Stop. > make[2]: Leaving directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' > make[1]: *** [docs] Error 2 > make[1]: Leaving directory > `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc' > make: *** [docs] Error 2 > > > I compared the 17.0 to the 17RC2 structure: it looks like the file > "system/README" is missing. I could "fix" the build process with a > "touch system/README"... not a real fix of course. > Regards, > Boris > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From magnus.liden@REDACTED Thu Apr 10 10:33:27 2014 From: magnus.liden@REDACTED (Magnus Liden) Date: Thu, 10 Apr 2014 10:33:27 +0200 Subject: [erlang-bugs] otp_src_17.0.tar.gz: "make docs" fails in "system/doc/top" In-Reply-To: <53463D2D.8010101@ericsson.com> References: <53463D2D.8010101@ericsson.com> Message-ID: <53465757.8090807@ericsson.com> Hi, A new tarball is available with md5: a5f78c1cf0eb7724de3a59babc1a28e5 Regards, Magnus On Thu 10 Apr 2014 08:41:49 AM CEST, Magnus Liden wrote: > Hi Boris, > Thanks for reporting, a fix is on the way. > > Regards, > Magnus > > On Thu 10 Apr 2014 05:42:56 AM CEST, Boris M?hmer wrote: >> Yesterday I did a build with the new otp_src_17.0.tar.gz tarball using >> my script which served me quite well from R13Bxx to R17RC2, but this >> time it failed at "make docs": >> >> >> make[2]: Entering directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' >> >> make[2]: Nothing to be done for `docs'. >> make[2]: Leaving directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual' >> >> make[2]: Entering directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' >> >> make[2]: Nothing to be done for `docs'. >> make[2]: Leaving directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples' >> >> make[2]: Entering directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' >> make[2]: *** No rule to make target `../../README', needed by `docs'. >> Stop. >> make[2]: Leaving directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' >> make[1]: *** [docs] Error 2 >> make[1]: Leaving directory >> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc' >> make: *** [docs] Error 2 >> >> >> I compared the 17.0 to the 17RC2 structure: it looks like the file >> "system/README" is missing. I could "fix" the build process with a >> "touch system/README"... not a real fix of course. >> Regards, >> Boris >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From boris.muehmer@REDACTED Thu Apr 10 13:44:33 2014 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Thu, 10 Apr 2014 13:44:33 +0200 Subject: [erlang-bugs] otp_src_17.0.tar.gz: "make docs" fails in "system/doc/top" In-Reply-To: <53465757.8090807@ericsson.com> References: <53463D2D.8010101@ericsson.com> <53465757.8090807@ericsson.com> Message-ID: Hello Magnus, glad to help... and thanx for the new tarball! Regards, Boris 2014-04-10 10:33 GMT+02:00 Magnus Liden : > Hi, > A new tarball is available with md5: a5f78c1cf0eb7724de3a59babc1a28e5 > > Regards, > Magnus > > > On Thu 10 Apr 2014 08:41:49 AM CEST, Magnus Liden wrote: > >> Hi Boris, >> Thanks for reporting, a fix is on the way. >> >> Regards, >> Magnus >> >> On Thu 10 Apr 2014 05:42:56 AM CEST, Boris M?hmer wrote: >> >>> Yesterday I did a build with the new otp_src_17.0.tar.gz tarball using >>> my script which served me quite well from R13Bxx to R17RC2, but this >>> time it failed at "make docs": >>> >>> >>> make[2]: Entering directory >>> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/ >>> reference_manual' >>> >>> make[2]: Nothing to be done for `docs'. >>> make[2]: Leaving directory >>> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/ >>> reference_manual' >>> >>> make[2]: Entering directory >>> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/ >>> programming_examples' >>> >>> make[2]: Nothing to be done for `docs'. >>> make[2]: Leaving directory >>> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/ >>> programming_examples' >>> >>> make[2]: Entering directory >>> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' >>> make[2]: *** No rule to make target `../../README', needed by `docs'. >>> Stop. >>> make[2]: Leaving directory >>> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top' >>> make[1]: *** [docs] Error 2 >>> make[1]: Leaving directory >>> `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc' >>> make: *** [docs] Error 2 >>> >>> >>> I compared the 17.0 to the 17RC2 structure: it looks like the file >>> "system/README" is missing. I could "fix" the build process with a >>> "touch system/README"... not a real fix of course. >>> Regards, >>> Boris >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Apr 10 15:32:50 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 10 Apr 2014 15:32:50 +0200 Subject: [erlang-bugs] Missing hyperlink for timer(3)? In-Reply-To: <530B23DB.6000408@ericsson.com> References: <52FDDDBE.10601@ericsson.com> <530B23DB.6000408@ericsson.com> Message-ID: Thanks for your report! This is now corrected and will be included in Erlang/OTP 17.1. /siri 2014-02-24 11:50 GMT+01:00 Rabbe Fogelholm : > In the OTP documentation, on the page http://www.erlang.org/doc/man/ > kernel_app.html , > there is the following text, > > Starts the timer_server if the parameter is true (see timer(3)). > > On the same page, a little further down, there is a "See also" with many > hyperlinks. > Perhaps there should be one for timer(3)? > > BR, > Rabbe Fogelholm > http://gp.internal.ericsson.com/?x500uid=ERARAFO > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Thu Apr 10 19:18:57 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Thu, 10 Apr 2014 19:18:57 +0200 Subject: [erlang-bugs] Encoding of IO devices when there is -noshell Message-ID: Hello OTP team, I am using Erlang 17.0 and I have noticed that, if -noshell is given, the encoding for IO devices are kept as latin: $ erl -eval 'io:format("~p", [io:getopts()]).' [{expand_fun,#Fun}, {echo,true}, {binary,false}, {encoding,latin1}] Setting the +fnu flag doesn't change the behaviour: $ erl +fnu -eval 'io:format("~p", [io:getopts()]).' [{expand_fun,#Fun}, {echo,true}, {binary,false}, {encoding,latin1}] I am pretty sure this behaviour is present in R16, but given the new direction taken in 17.0, I am not sure this is an actual bug or not. I am using Mac OS X Mountain Lion but this bug was also peer verified on Linux. Thank you! *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Thu Apr 10 19:54:22 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Thu, 10 Apr 2014 19:54:22 +0200 Subject: [erlang-bugs] standard_error IO device is not being set to unicode Message-ID: Hello OTP Team, I am using Erlang 17.0 and it seems the standard_error device is not being set to unicode. On a Mac OS X: 1> io:format("~p~n", ["jos?"]). "jos?" ok 2> io:format(standard_error, "~p~n", ["jos?"]). "jos?" ok If we inspect the standard_error process, we can see in the process dictionary that unicode is set to false: 3> process_info(whereis(standard_error), dictionary). {dictionary,[{unicode,false}]} Once I explicitly enable unicode, it works: 4> io:setopts(standard_error, [{unicode, true}]). ok 5> io:format(standard_error, "~p~n", ["jos?"]). "jos?" ok Thank you! PS: I found it interesting that the standard_error process does not accept the same options as the standard_io one: 6> io:setopts(standard_error, [{encoding, utf8}]). {error,enotsup} 7> io:setopts(standard_error, [{unicode, true}]). ok 8> io:setopts(standard_io, [{unicode, true}]). {error,enotsup} 9> io:setopts(standard_io, [{encoding, utf8}]). ok However this seems to be an "old" behaviour (it exists at least in R16 too). *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgud@REDACTED Thu Apr 10 19:55:13 2014 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 10 Apr 2014 19:55:13 +0200 Subject: [erlang-bugs] Encoding of IO devices when there is -noshell Message-ID: To not change that was intentional. But it might have been a bad choice, I got bitten by the same thing in escript today. I guess this can not change in 17.1 but maybe 18.0 Opinions? /Dan On Thu, Apr 10, 2014 at 7:18 PM, Jos? Valim wrote: > Hello OTP team, > > I am using Erlang 17.0 and I have noticed that, if -noshell is given, the > encoding for IO devices are kept as latin: > > $ erl -eval 'io:format("~p", [io:getopts()]).' > [{expand_fun,#Fun}, > {echo,true}, > {binary,false}, > {encoding,latin1}] > > Setting the +fnu flag doesn't change the behaviour: > > $ erl +fnu -eval 'io:format("~p", [io:getopts()]).' > [{expand_fun,#Fun}, > {echo,true}, > {binary,false}, > {encoding,latin1}] > > I am pretty sure this behaviour is present in R16, but given the new > direction taken in 17.0, I am not sure this is an actual bug or not. > > I am using Mac OS X Mountain Lion but this bug was also peer verified on > Linux. > > Thank you! > > *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 eric.pailleau@REDACTED Thu Apr 10 21:43:44 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Thu, 10 Apr 2014 21:43:44 +0200 Subject: [erlang-bugs] [R17.0] Can't compile : "RELEASES" missing Message-ID: <5346F470.6070302@wanadoo.fr> Hi, I tried to compile 17.0 on Ubuntu 13.04, doing './otp_build all' . ---8<-------------------------------------------- [...] make[2]: entrant dans le r?pertoire ? /home/eric/T?l?chargements/otp_src_17.0/erts/start_scripts ? GEN /home/eric/T?l?chargements/otp_src_17.0/erts/start_scripts/start_clean.rel GEN /home/eric/T?l?chargements/otp_src_17.0/erts/start_scripts/start_sasl.rel GEN /home/eric/T?l?chargements/otp_src_17.0/erts/start_scripts/start_all_example.rel GEN /home/eric/T?l?chargements/otp_src_17.0/erts/start_scripts/no_dot_erlang.rel GEN /home/eric/T?l?chargements/otp_src_17.0/erts/start_scripts/start_clean.script GEN /home/eric/T?l?chargements/otp_src_17.0/erts/start_scripts/start_sasl.boot GEN /home/eric/T?l?chargements/otp_src_17.0/erts/start_scripts/no_dot_erlang.boot GEN RELEASES.src mv: impossible d'?valuer ?RELEASES?: Aucun fichier ou dossier de ce type ---8<-------------------------------------------- in erts/start_scripts/Makefile, fails in target RELEASES.src, file 'RELEASES' is not created and then 'mv' fails. ---8<-------------------------------------------- RELEASES.src: $(gen_verbose)$(INSTALL_DIR) $(SS_TMP) $(V_at)( cd $(SS_TMP) && \ $(ERL) -noinput +B -eval 'release_handler:create_RELEASES("%ERL_ROOT%", "$(SS_ROOT)", "$(SS_ROOT)/start_sasl.rel", []), halt()') $(V_at)mv RELEASES RELEASES.src ---8<-------------------------------------------- Any idea ? regards From eric.pailleau@REDACTED Thu Apr 10 22:25:24 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Thu, 10 Apr 2014 22:25:24 +0200 Subject: [erlang-bugs] [R17.0] Can't compile : "RELEASES" missing In-Reply-To: <5346F470.6070302@wanadoo.fr> References: <5346F470.6070302@wanadoo.fr> Message-ID: <5346FE34.1060107@wanadoo.fr> Le 10/04/2014 21:43, PAILLEAU Eric a ?crit : > Hi, > I tried to compile 17.0 on Ubuntu 13.04, doing './otp_build all' . > > ---8<-------------------------------------------- > [...] > make[2]: entrant dans le r?pertoire ? > /home/eric/T?l?chargements/otp_src_17.0/erts/start_scripts ? Hello, I probably found the problem : Doing compilation in another directory without "?" in path works... But "T?l?chargements" is UTF-8 encoded, not Latin1 because when setting ISO-8859-1 in my shell profile, name is not displayed properly : "T??l??chargements". I suppose an UTF-8 path with non ascii characters does trouble somewhere ... Not blocking, but a pity with a full UTF-8 release, I suppose :) ... regards From samset@REDACTED Sat Apr 12 09:37:18 2014 From: samset@REDACTED (Samir Sow) Date: Sat, 12 Apr 2014 09:37:18 +0200 Subject: [erlang-bugs] ssl Message-ID: Hi, Still struggling with ssl. I decided to check what?s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc. Found an error erlang:size badarg, but could not understand if it?s a problem with the key/cert files or with the data sent by the client. The client was openssl s_client. Any help welcomed. Thx Samir {ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). ** exception exit: {{badarg, [{erlang,size, [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175, 58,145,197,219|...]], []}, {tls_record,get_tls_records_aux,2, [{file,"tls_record.erl"},{line,122}]}, {tls_connection,next_tls_record,2, [{file,"tls_connection.erl"},{line,484}]}, {tls_connection,handle_info,3, [{file,"tls_connection.erl"},{line,307}]}, {gen_fsm,handle_msg,7, [{file,"gen_fsm.erl"},{line,503}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]}, {gen_fsm,sync_send_all_state_event, [<0.105.0>,{start,infinity},infinity]}} in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242) in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649) in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97) in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84) From Ingela.Anderton.Andin@REDACTED Mon Apr 14 09:53:48 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Mon, 14 Apr 2014 09:53:48 +0200 Subject: [erlang-bugs] ssl In-Reply-To: References: Message-ID: <534B940C.3010507@ericsson.com> Hi! Which version of the ssl application are you using? Can you make a more complete example that fails so that I can run it too? We use openssl s_client in our test cases so it seems there is some special circumstances that makes this happen. The problem seems to be that the data from the peer is on list format instead of binary format. The packet option on the socket shall be emulated by ssl so the socket should always be in binary mode, but it seems it is not. Regards Ingela Erlang/OTP team - Ericssson AB On 04/12/2014 09:37 AM, Samir Sow wrote: > Hi, > > Still struggling with ssl. > I decided to check what?s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc. > Found an error erlang:size badarg, but could not understand if it?s a problem with the key/cert files or with the data sent by the client. > > The client was openssl s_client. > > Any help welcomed. Thx > > Samir > > {ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). > ** exception exit: {{badarg, > [{erlang,size, > [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175, > 58,145,197,219|...]], > []}, > {tls_record,get_tls_records_aux,2, > [{file,"tls_record.erl"},{line,122}]}, > {tls_connection,next_tls_record,2, > [{file,"tls_connection.erl"},{line,484}]}, > {tls_connection,handle_info,3, > [{file,"tls_connection.erl"},{line,307}]}, > {gen_fsm,handle_msg,7, > [{file,"gen_fsm.erl"},{line,503}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]}, > {gen_fsm,sync_send_all_state_event, > [<0.105.0>,{start,infinity},infinity]}} > in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242) > in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649) > in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97) > in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) > in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84) > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From samset@REDACTED Mon Apr 14 22:05:03 2014 From: samset@REDACTED (Samir Sow) Date: Mon, 14 Apr 2014 22:05:03 +0200 Subject: [erlang-bugs] ssl In-Reply-To: <534B940C.3010507@ericsson.com> References: <534B940C.3010507@ericsson.com> Message-ID: <2C1A946B-9188-4681-A36B-BB919608A8F8@wanadoo.fr> Hi, I?m using ssl-5.3.4 I?ve executed the step presented in the ?upgrade example? of the document : http://www.erlang.org/doc/apps/ssl/using_ssl.html except that i used openssl s_client to perform the client connect operation Thank you. Samir On 14 avr. 2014, at 09:53, Ingela Anderton Andin wrote: > Hi! > > Which version of the ssl application are you using? Can you make a more complete example that fails so that I can run it too? We use openssl s_client in our test cases so it seems there is some special circumstances that makes this happen. The problem seems to be that > the data from the peer is on list format instead of binary format. > The packet option on the socket shall be emulated by ssl so the socket > should always be in binary mode, but it seems it is not. > > Regards Ingela Erlang/OTP team - Ericssson AB > > On 04/12/2014 09:37 AM, Samir Sow wrote: >> Hi, >> >> Still struggling with ssl. >> I decided to check what?s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc. >> Found an error erlang:size badarg, but could not understand if it?s a problem with the key/cert files or with the data sent by the client. >> >> The client was openssl s_client. >> >> Any help welcomed. Thx >> >> Samir >> >> {ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). >> ** exception exit: {{badarg, >> [{erlang,size, >> [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175, >> 58,145,197,219|...]], >> []}, >> {tls_record,get_tls_records_aux,2, >> [{file,"tls_record.erl"},{line,122}]}, >> {tls_connection,next_tls_record,2, >> [{file,"tls_connection.erl"},{line,484}]}, >> {tls_connection,handle_info,3, >> [{file,"tls_connection.erl"},{line,307}]}, >> {gen_fsm,handle_msg,7, >> [{file,"gen_fsm.erl"},{line,503}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,239}]}]}, >> {gen_fsm,sync_send_all_state_event, >> [<0.105.0>,{start,infinity},infinity]}} >> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242) >> in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649) >> in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97) >> in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) >> in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84) >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From Ingela.Anderton.Andin@REDACTED Tue Apr 15 14:29:07 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 15 Apr 2014 14:29:07 +0200 Subject: [erlang-bugs] ssl In-Reply-To: <2C1A946B-9188-4681-A36B-BB919608A8F8@wanadoo.fr> References: <534B940C.3010507@ericsson.com> <2C1A946B-9188-4681-A36B-BB919608A8F8@wanadoo.fr> Message-ID: <534D2613.1080600@ericsson.com> Hi! On 04/14/2014 10:05 PM, Samir Sow wrote: > Hi, > > I?m using ssl-5.3.4 > > I?ve executed the step presented in the ?upgrade example? of the document : > http://www.erlang.org/doc/apps/ssl/using_ssl.html > > except that i used openssl s_client to perform the client connect operation Well that explains it, as the s_client is not performing an upgrade of the connection it is connecting with ssl from the start, and when the client start to send its handshake the server must be ready to receive it. You can still make your example work by setting {active, false} already on the listen socket so that the data will be left on the socket until the server process is is ready to receive it. (Accept socket inherits listen options and default is among others {active, true} and {mode, list}. In the upgrade scenario the server would do inet:setopts(Socket, [{active, false}]) before signaling to the client that it can now start the ssl handshake and then call ssl:ssl_accept. The ssl server process will emulate some inet options and internally set its own values, example socket mode will be set to binary. Regards Ingela Erlang/OTP Team - Ericsson AB > Thank you. > > Samir > > On 14 avr. 2014, at 09:53, Ingela Anderton Andin wrote: > >> Hi! >> >> Which version of the ssl application are you using? Can you make a more complete example that fails so that I can run it too? We use openssl s_client in our test cases so it seems there is some special circumstances that makes this happen. The problem seems to be that >> the data from the peer is on list format instead of binary format. >> The packet option on the socket shall be emulated by ssl so the socket >> should always be in binary mode, but it seems it is not. >> >> Regards Ingela Erlang/OTP team - Ericssson AB >> >> On 04/12/2014 09:37 AM, Samir Sow wrote: >>> Hi, >>> >>> Still struggling with ssl. >>> I decided to check what?s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc. >>> Found an error erlang:size badarg, but could not understand if it?s a problem with the key/cert files or with the data sent by the client. >>> >>> The client was openssl s_client. >>> >>> Any help welcomed. Thx >>> >>> Samir >>> >>> {ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). >>> ** exception exit: {{badarg, >>> [{erlang,size, >>> [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175, >>> 58,145,197,219|...]], >>> []}, >>> {tls_record,get_tls_records_aux,2, >>> [{file,"tls_record.erl"},{line,122}]}, >>> {tls_connection,next_tls_record,2, >>> [{file,"tls_connection.erl"},{line,484}]}, >>> {tls_connection,handle_info,3, >>> [{file,"tls_connection.erl"},{line,307}]}, >>> {gen_fsm,handle_msg,7, >>> [{file,"gen_fsm.erl"},{line,503}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,239}]}]}, >>> {gen_fsm,sync_send_all_state_event, >>> [<0.105.0>,{start,infinity},infinity]}} >>> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242) >>> in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649) >>> in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97) >>> in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) >>> in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84) >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From samset@REDACTED Tue Apr 15 22:06:29 2014 From: samset@REDACTED (Samir Sow) Date: Tue, 15 Apr 2014 22:06:29 +0200 Subject: [erlang-bugs] ssl In-Reply-To: <534D2613.1080600@ericsson.com> References: <534B940C.3010507@ericsson.com> <2C1A946B-9188-4681-A36B-BB919608A8F8@wanadoo.fr> <534D2613.1080600@ericsson.com> Message-ID: Hi, I?ve tried ok, ListenSocket} = gen_tcp:listen(9999, [{reuseaddr, true}, {active, false}]). But in this case, {ok, SSLSocket} = ssl:ssl_accept(ListenSocket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). does not return. Could you please, send me a working scenario ? Thank you. Sincerely On 15 avr. 2014, at 14:29, Ingela Anderton Andin wrote: > Hi! > > On 04/14/2014 10:05 PM, Samir Sow wrote: >> Hi, >> >> I?m using ssl-5.3.4 >> >> I?ve executed the step presented in the ?upgrade example? of the document : >> http://www.erlang.org/doc/apps/ssl/using_ssl.html >> >> except that i used openssl s_client to perform the client connect operation > > Well that explains it, as the s_client is not performing an upgrade of the connection it is connecting with ssl from the start, and when the client start to send its handshake the server must be ready to receive it. You can still make your example work by setting {active, false} already on the listen socket so that the data will be left on the socket until the server process is is ready to receive it. (Accept socket inherits listen options and default is among others {active, true} and {mode, list}. In the upgrade scenario the server would do inet:setopts(Socket, [{active, false}]) before signaling to the client that it can now start the ssl handshake and then call ssl:ssl_accept. > The ssl server process will emulate some inet options and internally set > its own values, example socket mode will be set to binary. > > Regards Ingela Erlang/OTP Team - Ericsson AB > > >> Thank you. >> >> Samir >> >> On 14 avr. 2014, at 09:53, Ingela Anderton Andin wrote: >> >>> Hi! >>> >>> Which version of the ssl application are you using? Can you make a more complete example that fails so that I can run it too? We use openssl s_client in our test cases so it seems there is some special circumstances that makes this happen. The problem seems to be that >>> the data from the peer is on list format instead of binary format. >>> The packet option on the socket shall be emulated by ssl so the socket >>> should always be in binary mode, but it seems it is not. >>> >>> Regards Ingela Erlang/OTP team - Ericssson AB >>> >>> On 04/12/2014 09:37 AM, Samir Sow wrote: >>>> Hi, >>>> >>>> Still struggling with ssl. >>>> I decided to check what?s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc. >>>> Found an error erlang:size badarg, but could not understand if it?s a problem with the key/cert files or with the data sent by the client. >>>> >>>> The client was openssl s_client. >>>> >>>> Any help welcomed. Thx >>>> >>>> Samir >>>> >>>> {ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). >>>> ** exception exit: {{badarg, >>>> [{erlang,size, >>>> [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175, >>>> 58,145,197,219|...]], >>>> []}, >>>> {tls_record,get_tls_records_aux,2, >>>> [{file,"tls_record.erl"},{line,122}]}, >>>> {tls_connection,next_tls_record,2, >>>> [{file,"tls_connection.erl"},{line,484}]}, >>>> {tls_connection,handle_info,3, >>>> [{file,"tls_connection.erl"},{line,307}]}, >>>> {gen_fsm,handle_msg,7, >>>> [{file,"gen_fsm.erl"},{line,503}]}, >>>> {proc_lib,init_p_do_apply,3, >>>> [{file,"proc_lib.erl"},{line,239}]}]}, >>>> {gen_fsm,sync_send_all_state_event, >>>> [<0.105.0>,{start,infinity},infinity]}} >>>> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242) >>>> in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649) >>>> in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97) >>>> in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) >>>> in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84) >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> > From Ingela.Anderton.Andin@REDACTED Wed Apr 16 10:22:29 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Wed, 16 Apr 2014 10:22:29 +0200 Subject: [erlang-bugs] ssl In-Reply-To: <534E3564.3010406@ericsson.com> References: <534E3564.3010406@ericsson.com> Message-ID: <534E3DC5.8010402@ericsson.com> -------- Original Message -------- Subject: Re: [erlang-bugs] ssl Date: Wed, 16 Apr 2014 09:46:44 +0200 From: Ingela Anderton Andin To: Samir Sow Hi! This works, and is equivalent of what you did in the first place! Erlang/OTP 17 [RELEASE CANDIDATE 2] [erts-6.0] [source-fa45816] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> ssl:start(). ok 2> {ok, ListenSocket} = gen_tcp:listen(9999, [{reuseaddr, true}, {active, false}]). {ok,#Port<0.776>} 3> {ok, Socket} = gen_tcp:accept(ListenSocket). {ok,#Port<0.777>} %%% Will return when you started the openssl client %% Do the upgrade 4> ssl:ssl_accept(Socket, [{cacertfile, "cacerts.pem"}, {certfile, "cert.pem"}, {keyfile, "key.pem"}]). {ok,{sslsocket,{gen_tcp,#Port<0.777>,tls_connection}, <0.48.0>}} In an another shell: bash> openssl s_client -host localhost -port 9999 Regards Ingela Erlang/OTP team - Ericsson AB On 04/15/2014 10:06 PM, Samir Sow wrote: > Hi, > > I?ve tried ok, ListenSocket} = gen_tcp:listen(9999, [{reuseaddr, true}, {active, false}]). > > But in this case, > {ok, SSLSocket} = ssl:ssl_accept(ListenSocket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). > does not return. > > Could you please, send me a working scenario ? > > Thank you. > > Sincerely > > On 15 avr. 2014, at 14:29, Ingela Anderton Andin wrote: > >> Hi! >> >> On 04/14/2014 10:05 PM, Samir Sow wrote: >>> Hi, >>> >>> I?m using ssl-5.3.4 >>> >>> I?ve executed the step presented in the ?upgrade example? of the document : >>> http://www.erlang.org/doc/apps/ssl/using_ssl.html >>> >>> except that i used openssl s_client to perform the client connect operation >> >> Well that explains it, as the s_client is not performing an upgrade of the connection it is connecting with ssl from the start, and when the clientstart to send its handshake the server must be ready to receive it. You can still make your example work by setting {active, false} already on the listen socket so that the data will be left on the socket until the server process is is ready to receive it. (Accept socket inherits listen options anddefault is among others {active, true} and {mode, list}. In the upgrade scenario the server would do inet:setopts(Socket, [{active, false}]) before signaling to the client that it can now start the ssl handshake and then call ssl:ssl_accept. >> The ssl server process will emulate some inet options and internally set >> its own values, example socket mode will be set to binary. >> >> Regards Ingela Erlang/OTP Team - Ericsson AB >> >> >>> Thank you. >>> >>> Samir >>> >>> On 14 avr. 2014, at 09:53, Ingela Anderton Andin wrote: >>> >>>> Hi! >>>> >>>> Which version of the ssl application are you using? Can you make a more complete example that fails so that I can run it too? We use openssl s_client in our test cases so it seems there is some special circumstances thatmakes this happen. The problem seems to be that >>>> the data from the peer is on list format instead of binary format. >>>> The packet option on the socket shall be emulated by ssl so the socket >>>> should always be in binary mode, but it seems it is not. >>>> >>>> Regards Ingela Erlang/OTP team - Ericssson AB >>>> >>>> On 04/12/2014 09:37 AM, Samir Sow wrote: >>>>> Hi, >>>>> >>>>> Still struggling with ssl. >>>>> I decided to check what?s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc. >>>>> Found an error erlang:size badarg, but could not understand if it?sa problem with the key/cert files or with the data sent by the client. >>>>> >>>>> The client was openssl s_client. >>>>> >>>>> Any help welcomed. Thx >>>>> >>>>> Samir >>>>> >>>>> {ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). >>>>> ** exception exit: {{badarg, >>>>> [{erlang,size, >>>>> [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175, >>>>> 58,145,197,219|...]], >>>>> []}, >>>>> {tls_record,get_tls_records_aux,2, >>>>> [{file,"tls_record.erl"},{line,122}]}, >>>>> {tls_connection,next_tls_record,2, >>>>> [{file,"tls_connection.erl"},{line,484}]}, >>>>> {tls_connection,handle_info,3, >>>>> [{file,"tls_connection.erl"},{line,307}]}, >>>>> {gen_fsm,handle_msg,7, >>>>> [{file,"gen_fsm.erl"},{line,503}]}, >>>>> {proc_lib,init_p_do_apply,3, >>>>> [{file,"proc_lib.erl"},{line,239}]}]}, >>>>> {gen_fsm,sync_send_all_state_event, >>>>> [<0.105.0>,{start,infinity},infinity]}} >>>>> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242) >>>>> in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649) >>>>> in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97) >>>>> in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) >>>>> in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84) >>>>> _______________________________________________ >>>>> erlang-bugs mailing list >>>>> erlang-bugs@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>> >>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> > From bjorn@REDACTED Wed Apr 16 12:53:25 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 16 Apr 2014 12:53:25 +0200 Subject: [erlang-bugs] [R17.0] Can't compile : "RELEASES" missing In-Reply-To: <5346FE34.1060107@wanadoo.fr> References: <5346F470.6070302@wanadoo.fr> <5346FE34.1060107@wanadoo.fr> Message-ID: On Thu, Apr 10, 2014 at 10:25 PM, PAILLEAU Eric wrote: > Le 10/04/2014 21:43, PAILLEAU Eric a ?crit : > I suppose an UTF-8 path with non ascii characters does trouble somewhere ... Yes, UTF-8 characters given in an -eval option are not properly handled. We will fix that in 17.1. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From shayan@REDACTED Thu Apr 17 19:56:46 2014 From: shayan@REDACTED (Shayan Pooya) Date: Thu, 17 Apr 2014 13:56:46 -0400 Subject: [erlang-bugs] Erlang 17 dialyzer issue with queue:queue(T). Message-ID: We currently use the nowarn_deprecated_type option to compile Disco with Erlang 17. I wanted to update the code to avoid using this option but I get an error message from dialyzer after updating one of the types from dict() to dict:dict(non_neg_integer) or dict:dict(). (error message at the end of this message, the change the results in this error is https://github.com/pooya/disco/commit/f857bde). Which basically says worker_throttle:state() does not match itself. disco_worker.erl:76: Invalid type specification for function disco_worker:init/1. The success typing is ({atom(),{#task_spec{jobname::'undefined' | [any(),...],stage::'undefined' | binary(),taskid::'undefined' | non_neg_integer(),tasknum::'undefined' | integer(),grouping::'group_all' | 'group_label' | 'group_node' | 'group_node_label' | 'split',group::{_,_},job_coord::'undefined' | pid(),jobenvs::'undefined' | [any()],worker::'undefined' | binary(),schedule::'local' | 'none' | 'remote' | 'undefined',input::'undefined' | [any()],save_outputs::'false' | 'true' | 'undefined',save_info::'undefined' | [any()]},#task_run{runid::'undefined' | non_neg_integer(),host::'none' | 'undefined' | [any(),...],failed_hosts::'undefined' | gb_sets:set(_),input::[any()]}}}) -> {'ok',#state{master::atom(),task::{{_,_,_,_,_,_,_,_,_,_,_,_,_,_},{_,_,_,_,_}},port::'none',worker_send::'none',error_output::'false',buffer::<<>>,parser::worker_protocol:state(),runtime::{'state','undefined' | [any(),...],{_,_},atom(),[any(),...],{_,_,_,_},{_,_,_},'false' | 'true' | 'undefined','undefined' | [any()],'none',gb_sets:set(_),[],gb_trees:tree(_,_),'none','none'},throttle::worker_throttle:state()}} -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Thu Apr 17 22:02:59 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 17 Apr 2014 22:02:59 +0200 Subject: [erlang-bugs] Erlang 17 dialyzer issue with queue:queue(T). In-Reply-To: References: Message-ID: <53503373.1060906@cs.ntua.gr> On 04/17/2014 07:56 PM, Shayan Pooya wrote: > I wanted to update the code to avoid using this option but I get an > error message from dialyzer after updating one of the types from dict() > to dict:dict(non_neg_integer) or dict:dict(). > (error message at the end of this message, the change the results in > this error is https://github.com/pooya/disco/commit/f857bde). > > Which basically says worker_throttle:state() does not match itself. The type dict:dict is a data structure that maps keys to values. I.e. it needs two type parameters and the 1-ary version of it does not make much sense. Kostis From shayan@REDACTED Thu Apr 17 22:20:12 2014 From: shayan@REDACTED (Shayan Pooya) Date: Thu, 17 Apr 2014 16:20:12 -0400 Subject: [erlang-bugs] Erlang 17 dialyzer issue with queue:queue(T). In-Reply-To: <53503373.1060906@cs.ntua.gr> References: <53503373.1060906@cs.ntua.gr> Message-ID: Thanks Kostis. In the email I was supposed to say queue:queue(non_neg_integer) or queue:queue(). The commit is using queue (not dict) and still seems like a bug in dialyzer in Erl 17. Regards. On Thu, Apr 17, 2014 at 4:02 PM, Kostis Sagonas wrote: > On 04/17/2014 07:56 PM, Shayan Pooya wrote: > >> I wanted to update the code to avoid using this option but I get an >> error message from dialyzer after updating one of the types from dict() >> to dict:dict(non_neg_integer) or dict:dict(). >> (error message at the end of this message, the change the results in >> this error is https://github.com/pooya/disco/commit/f857bde). >> >> Which basically says worker_throttle:state() does not match itself. >> > > The type dict:dict is a data structure that maps keys to values. I.e. it > needs two type parameters and the 1-ary version of it does not make much > sense. > > Kostis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.bolinder@REDACTED Wed Apr 23 15:14:03 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Wed, 23 Apr 2014 13:14:03 +0000 Subject: [erlang-bugs] Erlang 17 dialyzer issue with queue:queue(T). In-Reply-To: References: Message-ID: <56466BD70414EA48969B4064696CF28C037DB49B@ESESSMB207.ericsson.se> Hi, [Shayan Pooya:] > We currently use the nowarn_deprecated_type option to compile Disco > with Erlang 17. I wanted to update the code to avoid using this option > but I get an error message from dialyzer after updating one of the > types from dict() to dict:dict(non_neg_integer) or dict:dict(). (error > message at the end of this message, the change the results in this > error is https://github.com/pooya/disco/commit/f857bde). > > Which basically says worker_throttle:state() does not match itself. It's a bug, and I'll look into it as soon as possible. Thanks for reporting and best regards, Hans Bolinder, Erlang/OTP team, Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayan@REDACTED Wed Apr 23 15:18:49 2014 From: shayan@REDACTED (Shayan Pooya) Date: Wed, 23 Apr 2014 09:18:49 -0400 Subject: [erlang-bugs] Erlang 17 dialyzer issue with queue:queue(T). In-Reply-To: <56466BD70414EA48969B4064696CF28C037DB49B@ESESSMB207.ericsson.se> References: <56466BD70414EA48969B4064696CF28C037DB49B@ESESSMB207.ericsson.se> Message-ID: Thanks. I'd be happy to test whenever there is any patches available. On Wed, Apr 23, 2014 at 9:14 AM, Hans Bolinder wrote: > Hi, > > [Shayan Pooya:] > > > We currently use the nowarn_deprecated_type option to compile Disco > > with Erlang 17. I wanted to update the code to avoid using this option > > but I get an error message from dialyzer after updating one of the > > types from dict() to dict:dict(non_neg_integer) or dict:dict(). (error > > message at the end of this message, the change the results in this > > error is https://github.com/pooya/disco/commit/f857bde). > > > > Which basically says worker_throttle:state() does not match itself. > > It's a bug, and I'll look into it as soon as possible. > > Thanks for reporting and best regards, > > Hans Bolinder, Erlang/OTP team, Ericsson > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkjan@REDACTED Wed Apr 23 18:05:11 2014 From: dirkjan@REDACTED (Dirkjan Ochtman) Date: Wed, 23 Apr 2014 18:05:11 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' Message-ID: Building Erlang 17.0 on Gentoo systems (I am the packager there), there have been some problems: https://bugs.gentoo.org/show_bug.cgi?id=508366 make[4]: Entering directory '/var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/epmd/src' CC /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/obj/x86_64-pc-linux-gnu/epmd.o CC /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/obj/x86_64-pc-linux-gnu/epmd_srv.o CC /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/obj/x86_64-pc-linux-gnu/epmd_cli.o LD /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/bin/x86_64-pc-linux-gnu/epmd /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/obj/x86_64-pc-linux-gnu/epmd_srv.o: In function `run': epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' I looked at configure --help, but there doesn't seem to be anything about systemd in there. However, I found references to systemd in e.g. erts/configure.in. In Gentoo, we prefer to be explicit about supporting installed libraries, so I wonder if there could be a --disable/enable-systemd switch to configure, so that this can be explicitly stated at configure time. Cheers, Dirkjan From dszoboszlay@REDACTED Thu Apr 24 10:48:33 2014 From: dszoboszlay@REDACTED (=?iso-8859-1?Q?D=E1niel_Szoboszlay?=) Date: Thu, 24 Apr 2014 10:48:33 +0200 Subject: [erlang-bugs] Outdated docs file in ssl Message-ID: Hi, There?s an ssl/internal_doc/ssl-implementation.txt file in OTP which I think is very outdated and describes the old SSL implementation that has been dropped in OTP-7048. Shouldn?t this file be deleted as well? Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ingela.Anderton.Andin@REDACTED Thu Apr 24 11:31:12 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 24 Apr 2014 11:31:12 +0200 Subject: [erlang-bugs] Outdated docs file in ssl In-Reply-To: References: Message-ID: <5358D9E0.9080206@ericsson.com> Hi! On 04/24/2014 10:48 AM, D?niel Szoboszlay wrote: > Hi, > > There?s an ssl/internal_doc/ssl-implementation.txt file in OTP which I > think is very outdated and describes the old SSL implementation that has > been dropped in OTP-7048. > > Shouldn?t this file be deleted as well? Yes you are correct, this is outdated and of no use. I think it was missed as before git this was only an internal directory not visible to everyone. We should perhaps rethink what and how this is used. Regards Ingela Erlang/OTP team - Ericsson AB From lukas@REDACTED Thu Apr 24 12:30:22 2014 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 24 Apr 2014 12:30:22 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: References: Message-ID: <5358E7BE.9010606@erlang.org> Hello Dirkjan, I have no objection against adding --without-systemd to configure. However I feel that disabling it manually is a poor solution when what we really want is for configure to correctly detect that it is not possible to use systemd on your system. Would you mind sending the output of erts/config.log so that I can have a look at it? Lukas On 23/04/14 18:05, Dirkjan Ochtman wrote: > Building Erlang 17.0 on Gentoo systems (I am the packager there), > there have been some problems: > > https://bugs.gentoo.org/show_bug.cgi?id=508366 > > make[4]: Entering directory > '/var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/epmd/src' > CC /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/obj/x86_64-pc-linux-gnu/epmd.o > CC /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/obj/x86_64-pc-linux-gnu/epmd_srv.o > CC /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/obj/x86_64-pc-linux-gnu/epmd_cli.o > LD /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/bin/x86_64-pc-linux-gnu/epmd > /var/tmp/portage/dev-lang/erlang-17.0/work/otp_src_17.0/erts/obj/x86_64-pc-linux-gnu/epmd_srv.o: > In function `run': > epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' > > I looked at configure --help, but there doesn't seem to be anything > about systemd in there. However, I found references to systemd in e.g. > erts/configure.in. In Gentoo, we prefer to be explicit about > supporting installed libraries, so I wonder if there could be a > --disable/enable-systemd switch to configure, so that this can be > explicitly stated at configure time. > > Cheers, > > Dirkjan > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From ivan.martinez@REDACTED Thu Apr 24 14:01:14 2014 From: ivan.martinez@REDACTED (=?ISO-8859-1?Q?Iv=E1n_Mart=EDnez?=) Date: Thu, 24 Apr 2014 14:01:14 +0200 Subject: [erlang-bugs] "erl -name app" fails if hostname doesn't contain a dot Message-ID: Accordingly to the documentation, "erl -name app" should work by taking the domain from the hostame and naming the node "app@REDACTED". However, if the hostname doesn't contain a dot, like # hostname -f localhost then # erl -name app {error_logger,{{2014,4,24},{13,58,11}},"Can't set long node name!\nPlease check your configuration\n",[]} ... However, if the hostname contains a dot, like # hostname -f localhost.localdomain then # erl -name app Erlang R16B01 (erts-5.10.2) [source-bdf5300] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] ... This contradicts the fact # erl -name app@REDACTED always works. Thank you, Iv?n -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Thu Apr 24 15:33:17 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 24 Apr 2014 15:33:17 +0200 Subject: [erlang-bugs] "erl -name app" fails if hostname doesn't contain a dot In-Reply-To: References: Message-ID: <1398346397.5728.86.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, "hostname -f" should display the the FQDN (Fully Qualified Domain Name). A FQDN consists of a short host name and the DNS domain name. I think that only "localhost" is not correct. bengt On Thu, 2014-04-24 at 14:01 +0200, Iv?n Mart?nez wrote: > Accordingly to the documentation, "erl -name app" should work by > taking the domain from the hostame and naming the node "app@REDACTED". > However, if the hostname doesn't contain a dot, like > > > # hostname -f > > localhost > > > then > > > > # erl -name app > {error_logger,{{2014,4,24},{13,58,11}},"Can't set long node name! > \nPlease check your configuration\n",[]} > ... > > > However, if the hostname contains a dot, like > > > # hostname -f > > localhost.localdomain > > > then > > > # erl -name app > Erlang R16B01 (erts-5.10.2) [source-bdf5300] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > ... > > > This contradicts the fact > > > # erl -name app@REDACTED > > > always works. > > Thank you, > > Iv?n > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From essen@REDACTED Thu Apr 24 15:54:33 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 24 Apr 2014 15:54:33 +0200 Subject: [erlang-bugs] Incorrect specs documentation for common_test Message-ID: <53591799.7000308@ninenines.eu> There are a few functions and a few things in the documentation that say they return void() instead of ok or other things. For example the ct:comment/{1,2} functions. I notice that ct doesn't use typespecs so that might be why it didn't get noticed until now. If someone has nothing to do, have at it. :-) -- Lo?c Hoguin http://ninenines.eu From tristan.sloughter@REDACTED Thu Apr 24 04:38:20 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Wed, 24 Apr 2014 03:38:20 +0100 Subject: [erlang-bugs] Tristan Sloughter Message-ID: <74BD435FDE6CF497BE77ED0F58D52322@counteffectzmusic.com.au> http://www.paradisetourssocal.com/hvjhle/hjznpjnay.topab -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Fri Apr 25 11:28:46 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 25 Apr 2014 12:28:46 +0300 Subject: [erlang-bugs] ssh remote user authorized_keys Message-ID: <45325F1C-AAA5-45EF-A50A-7CDD4A291CE2@gmail.com> Hello, I?ve notice that Erlang SSH daemon do not expand the user_dir with the name of remote user, who tries to log-in. Thus a single instance of authorised_keys exist on the server for all users. Same time, there is undocumented user_dir_fun config option that takes a function which map remote user to its ?home? folder. The question is where is the bug? At documentation: http://www.erlang.org/doc/man/ssh.html user_dir_fun is not defined At ssh_file.erl: ? CLIP ? ssh_dir({remoteuser, User}, Opts) -> case proplists:get_value(user_dir_fun, Opts) of undefined -> case proplists:get_value(user_dir, Opts) of undefined -> default_user_dir(); Dir -> Dir end; FUN -> FUN(User) end; ? CLIP ? Best Regards, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.martinez@REDACTED Fri Apr 25 12:25:38 2014 From: ivan.martinez@REDACTED (=?ISO-8859-1?Q?Iv=E1n_Mart=EDnez?=) Date: Fri, 25 Apr 2014 12:25:38 +0200 Subject: [erlang-bugs] "erl -name app" fails if hostname doesn't contain a dot Message-ID: Thank you Bengt. I think it should allow "localhost". Not every computer is a server in a registered domain name, and in such situations, I don't think having no domain name is so uncommon. I'm using a Ubuntu-based distro and it didn't require setting a domain during installation, so I think it's likely that many people will have the same issue. I didn't have any issue with any other piece of software. Also, like I said, there is a misleading contradiction. If you decide that a FQDN is required, then "erl -name app@REDACTED" should fail. Iv?n ------------------------------ Message: 3 Date: Thu, 24 Apr 2014 15:33:17 +0200 From: Bengt Kleberg To: undisclosed-recipients:; Cc: Subject: Re: [erlang-bugs] "erl -name app" fails if hostname doesn't contain a dot Message-ID: <1398346397.5728.86.camel@REDACTED> Content-Type: text/plain; charset="ISO-8859-1" Greetings, "hostname -f" should display the the FQDN (Fully Qualified Domain Name). A FQDN consists of a short host name and the DNS domain name. I think that only "localhost" is not correct. bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-bugs@REDACTED Fri Apr 25 12:33:29 2014 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Fri, 25 Apr 2014 12:33:29 +0200 Subject: [erlang-bugs] "erl -name app" fails if hostname doesn't contain a dot In-Reply-To: References: Message-ID: <20140425103329.GA20398@erix.ericsson.se> On Fri, Apr 25, 2014 at 12:25:38PM +0200, Iv?n Mart?nez wrote: > Thank you Bengt. I think it should allow "localhost". Not every computer is > a server in a registered domain name, and in such situations, I don't think > having no domain name is so uncommon. I'm using a Ubuntu-based distro and > it didn't require setting a domain during installation, so I think it's > likely that many people will have the same issue. I didn't have any issue > with any other piece of software. For this situation you are supposed to use "erl -sname app" i.e explicitly use short host names. > Also, like I said, there is a misleading contradiction. If you decide that > a FQDN is required, then "erl -name app@REDACTED" should fail. > Iv?n > > ------------------------------ > > Message: 3 > Date: Thu, 24 Apr 2014 15:33:17 +0200 > From: Bengt Kleberg > To: undisclosed-recipients:; > Cc: > Subject: Re: [erlang-bugs] "erl -name app" fails if hostname doesn't > contain a dot > Message-ID: <1398346397.5728.86.camel@REDACTED> > Content-Type: text/plain; charset="ISO-8859-1" > > Greetings, > > "hostname -f" should display the the FQDN (Fully Qualified Domain Name). > A FQDN consists of a short host name and the DNS domain name. I think > that only "localhost" is not correct. > > > bengt > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From essen@REDACTED Sat Apr 26 21:00:15 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 26 Apr 2014 21:00:15 +0200 Subject: [erlang-bugs] erlang module not in sticky dir? Message-ID: <535C023F.4040008@ninenines.eu> A user got confused by pretty much this: % erl Erlang/OTP 17 [erts-6.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> l(erlang). {module,erlang} 2> l(gen_server). {error,sticky_directory} 3> =ERROR REPORT==== 26-Apr-2014::20:56:37 === Can't load module that resides in sticky dir For some reasons his erlang:apply/3 ended up not being a BIF anymore and instead called erlang:apply/3 in a loop because the file contains: apply(Mod, Name, Args) -> erlang:apply(Mod, Name, Args). The file had been recompiled and reloaded automatically using the sync application: https://github.com/rustyio/sync Details are not important. I suggest however making the preloaded Erlang modules be sticky by default to prevent awkward behavior such as this. -- Lo?c Hoguin http://ninenines.eu From james@REDACTED Mon Apr 28 00:00:24 2014 From: james@REDACTED (James Fish) Date: Sun, 27 Apr 2014 23:00:24 +0100 Subject: [erlang-bugs] Dialyzer crashes on empty map case pattern that can never match Message-ID: Dialyzer crashes when analysing a case clause with an empty map pattern when it is known that the pattern can never match. Minimal example: function(Tuple) when is_tuple(Tuple) -> case Tuple of #{} -> ok end. Result: dialyzer: Analysis failed with error: {{case_clause,#{}}, [{cerl_prettypr,lay_literal,2,[{file,"cerl_prettypr.erl"},{line,468}]}, {cerl_prettypr,lay_ann,2,[{file,"cerl_prettypr.erl"},{line,411}]}, {cerl_prettypr,format,2,[{file,"cerl_prettypr.erl"},{line,271}]}, {dialyzer_dataflow,format_patterns,1, [{file,"dialyzer_dataflow.erl"},{line,3351}]}, {dialyzer_dataflow,do_clause,6,[{file,"dialyzer_dataflow.erl"},{line,1245}]}, {dialyzer_dataflow,handle_clauses,9, [{file,"dialyzer_dataflow.erl"},{line,1177}]}, {dialyzer_dataflow,handle_case,3, [{file,"dialyzer_dataflow.erl"},{line,936}]}, {dialyzer_dataflow,do_clause,6, [{file,"dialyzer_dataflow.erl"},{line,1372}]}]} -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Mon Apr 28 10:59:59 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Mon, 28 Apr 2014 10:59:59 +0200 Subject: [erlang-bugs] Match error when mapping a list of maps with anonymous functions in the shell Message-ID: Hello folks, I've found a weird bug. I will just paste my shell contents because I cannot explain it: 1> lists:map(fun(X) -> X#{price := 0} end, [#{hello => 0, price => nil}]). ** exception error: no match of right hand side value #{hello => 0,price => nil} in function erl_eval:expr/5 (erl_eval.erl, line 248) in call from lists:map/2 (lists.erl, line 1237) 2> (fun(X) -> X#{price := 0} end)(#{hello => 0, price => nil}). #{hello => 0,price => 0} Snippet also available here: https://gist.github.com/josevalim/02cd7214d3173c5c73bc The first expression was not supposed to fail at all. This also fails only in the shell, the same snippet inside an .erl file works fine?. Using Erlang 17.0 on Mac OS X. Thank you! *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Apr 28 12:24:30 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 28 Apr 2014 12:24:30 +0200 Subject: [erlang-bugs] Match error when mapping a list of maps with anonymous functions in the shell In-Reply-To: References: Message-ID: <6207E54E-3569-495E-BB6F-12D21A9F35F0@gmail.com> Sweet. -- Anthony Ramine Le 28 avr. 2014 ? 10:59, Jos? Valim a ?crit : > I've found a weird bug. From egil@REDACTED Mon Apr 28 15:00:17 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 28 Apr 2014 15:00:17 +0200 Subject: [erlang-bugs] Match error when mapping a list of maps with anonymous functions in the shell In-Reply-To: <6207E54E-3569-495E-BB6F-12D21A9F35F0@gmail.com> References: <6207E54E-3569-495E-BB6F-12D21A9F35F0@gmail.com> Message-ID: <535E50E1.80505@erlang.org> On 2014-04-28 12:24, Anthony Ramine wrote: > Sweet. > Does this mean I should be expecting a patch or are you just happy there is a bug? =) From egil@REDACTED Mon Apr 28 15:01:12 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 28 Apr 2014 15:01:12 +0200 Subject: [erlang-bugs] Dialyzer crashes on empty map case pattern that can never match In-Reply-To: References: Message-ID: <535E5118.8030602@erlang.org> Thank you for reporting this. I'll have a look at it. // Bj?rn-Egil On 2014-04-28 00:00, James Fish wrote: > Dialyzer crashes when analysing a case clause with an empty map > pattern when it is known that the pattern can never match. > > Minimal example: > > function(Tuple) when is_tuple(Tuple) -> > case Tuple of #{} -> ok end. > > Result: > > dialyzer: Analysis failed with error: > {{case_clause,#{}}, > [{cerl_prettypr,lay_literal,2,[{file,"cerl_prettypr.erl"},{line,468}]}, > {cerl_prettypr,lay_ann,2,[{file,"cerl_prettypr.erl"},{line,411}]}, > {cerl_prettypr,format,2,[{file,"cerl_prettypr.erl"},{line,271}]}, > {dialyzer_dataflow,format_patterns,1, > [{file,"dialyzer_dataflow.erl"},{line,3351}]}, > {dialyzer_dataflow,do_clause,6,[{file,"dialyzer_dataflow.erl"},{line,1245}]}, > {dialyzer_dataflow,handle_clauses,9, > [{file,"dialyzer_dataflow.erl"},{line,1177}]}, > {dialyzer_dataflow,handle_case,3, > [{file,"dialyzer_dataflow.erl"},{line,936}]}, > {dialyzer_dataflow,do_clause,6, > [{file,"dialyzer_dataflow.erl"},{line,1372}]}]} > > > > _______________________________________________ > 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 Mon Apr 28 15:22:26 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 28 Apr 2014 15:22:26 +0200 Subject: [erlang-bugs] Match error when mapping a list of maps with anonymous functions in the shell In-Reply-To: <535E50E1.80505@erlang.org> References: <6207E54E-3569-495E-BB6F-12D21A9F35F0@gmail.com> <535E50E1.80505@erlang.org> Message-ID: <1A10CCD1-DAC4-442D-8974-2336231B6E5C@gmail.com> Will indeed take a look tonight. :) -- Anthony Ramine Le 28 avr. 2014 ? 15:00, Bj?rn-Egil Dahlberg a ?crit : > On 2014-04-28 12:24, Anthony Ramine wrote: >> Sweet. >> > Does this mean I should be expecting a patch or are you just happy there is a bug? =) > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From eric.pailleau@REDACTED Tue Apr 29 00:03:29 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 29 Apr 2014 00:03:29 +0200 Subject: [erlang-bugs] multiple -name argument Message-ID: <535ED031.7060105@wanadoo.fr> Hello, I passed by mistake two time -name argument with different values (or same value with same result), and no error, erl is running with node set to nonode@REDACTED !!! I wonder if this is really normal, and probably a possible dangerous and silent issue. Is there a valid reason for such behavior ? Do other erl arguments behave the same ? generally speaking, I expect that the last same argument is the one used by a program. I did not see anything related to this in 'erl' documentation, or missed it. Regard ---8<--------------------------------------------------------------------------- # erl -name titi@REDACTED -name toto@REDACTED Erlang/OTP 17 [erts-6.0] [source] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> node(). nonode@REDACTED 2> ---8<--------------------------------------------------------------------------- From n.oxyde@REDACTED Tue Apr 29 02:47:17 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 29 Apr 2014 02:47:17 +0200 Subject: [erlang-bugs] Match error when mapping a list of maps with anonymous functions in the shell In-Reply-To: <535E50E1.80505@erlang.org> References: <6207E54E-3569-495E-BB6F-12D21A9F35F0@gmail.com> <535E50E1.80505@erlang.org> Message-ID: Bug is present in erl_eval and in dbg_ieval. I think I also found another bug, which is present in the compiler: (X=#{})#{x => (fun (Y) -> X = Y end)(ok). This is not supposed to fail, right? Regards, -- Anthony Ramine Le 28 avr. 2014 ? 15:00, Bj?rn-Egil Dahlberg a ?crit : > On 2014-04-28 12:24, Anthony Ramine wrote: >> Sweet. >> > Does this mean I should be expecting a patch or are you just happy there is a bug? =) > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From dirkjan@REDACTED Tue Apr 29 09:00:53 2014 From: dirkjan@REDACTED (Dirkjan Ochtman) Date: Tue, 29 Apr 2014 09:00:53 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: References: Message-ID: (Lukas, thanks for your reply. I don't receive erlang-bugs email, so I'm responding to my own email instead of yours. CC'ing me on future email would be helpful. :)) On Wed, Apr 23, 2014 at 6:05 PM, Dirkjan Ochtman wrote: > I looked at configure --help, but there doesn't seem to be anything > about systemd in there. However, I found references to systemd in e.g. > erts/configure.in. In Gentoo, we prefer to be explicit about > supporting installed libraries, so I wonder if there could be a > --disable/enable-systemd switch to configure, so that this can be > explicitly stated at configure time. There's a build log here: https://508366.bugs.gentoo.org/attachment.cgi?id=375456 erts/config.log is here: https://bugs.gentoo.org/attachment.cgi?id=375958 A user also remarked on the fact that there seems to be a version disparity here: "From what I can tell, erlang tries to link against libsystemd-daemon, but systemd-212-r2 only creates libsystemd." Or perhaps this is caused by the way we build systemd on Gentoo. Anyway, from our point of view, automatic detection is really not what we want. We prefer to have explicit control over which parts we want, especially when those build-time options change what other packages the build depends on. Cheers, Dirkjan From lukas@REDACTED Tue Apr 29 10:21:05 2014 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 29 Apr 2014 10:21:05 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: References: Message-ID: <535F60F1.9030400@erlang.org> On 29/04/14 09:00, Dirkjan Ochtman wrote: > On Wed, Apr 23, 2014 at 6:05 PM, Dirkjan Ochtman wrote: >> I looked at configure --help, but there doesn't seem to be anything >> about systemd in there. However, I found references to systemd in e.g. >> erts/configure.in. In Gentoo, we prefer to be explicit about >> supporting installed libraries, so I wonder if there could be a >> --disable/enable-systemd switch to configure, so that this can be >> explicitly stated at configure time. > There's a build log here: > > https://508366.bugs.gentoo.org/attachment.cgi?id=375456 > > erts/config.log is here: > > https://bugs.gentoo.org/attachment.cgi?id=375958 > > A user also remarked on the fact that there seems to be a version > disparity here: "From what I can tell, erlang tries to link against > libsystemd-daemon, but systemd-212-r2 only creates libsystemd." Or > perhaps this is caused by the way we build systemd on Gentoo. Thanks for the extra info, the logs confirm my suspicion that only the systemd header was found, but the library was not. From what I understand there are a couple of different ways that you include support for systemd, and at the moment we only support the dynamic library way. > Anyway, from our point of view, automatic detection is really not what > we want. We prefer to have explicit control over which parts we want, > especially when those build-time options change what other packages > the build depends on. After thinking a bit more about it I agree with you. I'll disable it by default and fix the check so that also the lib check is done properly. The fix will be part of the Erlang/OTP 17.1 release. We do not have a test machine that uses systemd, would it be possibly for you to help me test the patch before I merge it into upstream git? Lukas From lukas@REDACTED Tue Apr 29 10:51:18 2014 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 29 Apr 2014 10:51:18 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: <535F60F1.9030400@erlang.org> References: <535F60F1.9030400@erlang.org> Message-ID: <535F6806.8020308@erlang.org> On 29/04/14 10:21, Lukas Larsson wrote: > We do not have a test machine that uses systemd, would it be possibly > for you to help me test the patch before I merge it into upstream git? > If you, or someone else, have a machine with systemd support, the branch to test can be found here: https://github.com/garazdawi/otp/tree/lukas/erts/autoconf-fixes Lukas From dirkjan@REDACTED Tue Apr 29 11:46:33 2014 From: dirkjan@REDACTED (Dirkjan Ochtman) Date: Tue, 29 Apr 2014 11:46:33 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: <535F6806.8020308@erlang.org> References: <535F60F1.9030400@erlang.org> <535F6806.8020308@erlang.org> Message-ID: On Tue, Apr 29, 2014 at 10:51 AM, Lukas Larsson wrote: > If you, or someone else, have a machine with systemd support, the branch to > test can be found here: > https://github.com/garazdawi/otp/tree/lukas/erts/autoconf-fixes Thanks! I've attached a revised ebuild + (only the systemd parts of) your patch to the bug and asked for feedback. Cheers, Dirkjan From Ingela.Anderton.Andin@REDACTED Tue Apr 29 12:14:34 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 29 Apr 2014 12:14:34 +0200 Subject: [erlang-bugs] ssh remote user authorized_keys In-Reply-To: <45325F1C-AAA5-45EF-A50A-7CDD4A291CE2@gmail.com> References: <45325F1C-AAA5-45EF-A50A-7CDD4A291CE2@gmail.com> Message-ID: <535F7B8A.2010107@ericsson.com> Hi! Will have to look into this and see what we can do to improve the situation. I have created a ticket to handle the issue. Regards Ingela Erlang/OTP Team - Ericsson AB On 04/25/2014 11:28 AM, Dmitry Kolesnikov wrote: > Hello, > > I?ve notice that Erlang SSH daemon do not expand the user_dir with the > name of remote user, who tries to log-in. Thus a single instance of > authorised_keys exist on the server for all users. Same time, there is > undocumented user_dir_fun config option that takes a function which map > remote user to its ?home? folder. > > The question is where is the bug? > > At documentation: http://www.erlang.org/doc/man/ssh.html user_dir_fun is > not defined > > At ssh_file.erl: > > ? CLIP ? > > ssh_dir({remoteuser, User}, Opts) -> > case proplists:get_value(user_dir_fun, Opts) of > undefined -> > case proplists:get_value(user_dir, Opts) of > undefined -> > default_user_dir(); > Dir -> > Dir > end; > FUN -> > FUN(User) > end; > > ? CLIP ? > > Best Regards, > Dmitry > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From mononcqc@REDACTED Tue Apr 29 15:08:03 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 29 Apr 2014 09:08:03 -0400 Subject: [erlang-bugs] Match error when mapping a list of maps with anonymous functions in the shell In-Reply-To: References: <6207E54E-3569-495E-BB6F-12D21A9F35F0@gmail.com> <535E50E1.80505@erlang.org> Message-ID: <20140429130802.GF68518@ferdair.local> On 04/29, Anthony Ramine wrote: > I think I also found another bug, which is present in the compiler: > > (X=#{})#{x => (fun (Y) -> X = Y end)(ok). > > This is not supposed to fail, right? I'd expect needing to close the map for this to work, or do you mean 'failing' as a hard crash or something? From egil@REDACTED Tue Apr 29 15:17:52 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 29 Apr 2014 15:17:52 +0200 Subject: [erlang-bugs] Match error when mapping a list of maps with anonymous functions in the shell In-Reply-To: <20140429130802.GF68518@ferdair.local> References: <6207E54E-3569-495E-BB6F-12D21A9F35F0@gmail.com> <535E50E1.80505@erlang.org> <20140429130802.GF68518@ferdair.local> Message-ID: <535FA680.7060005@erlang.org> On 2014-04-29 15:08, Fred Hebert wrote: > (X=#{})#{x => (fun (Y) -> X = Y end)(ok). I tested this, (X=#{})#{x => (fun (Y) -> X = Y end)(#{}) }. I think I see a scoping error with respect to X =( From eric.pailleau@REDACTED Tue Apr 29 21:26:01 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 29 Apr 2014 21:26:01 +0200 Subject: [erlang-bugs] multiple -name argument In-Reply-To: <535ED031.7060105@wanadoo.fr> References: <535ED031.7060105@wanadoo.fr> Message-ID: <535FFCC9.2030708@wanadoo.fr> Hello, I also note that -sname always win against -name if set both in arguments, whatever the sort order. erl -sname titi -name toto@REDACTED or erl -name toto@REDACTED -sname titi result in titi@{hostname} regards > > ---8<--------------------------------------------------------------------------- > > # erl -name titi@REDACTED -name toto@REDACTED > Erlang/OTP 17 [erts-6.0] [source] [smp:2:2] [async-threads:10] [hipe] > [kernel-poll:false] > > Eshell V6.0 (abort with ^G) > 1> node(). > nonode@REDACTED > 2> > ---8<--------------------------------------------------------------------------- From dirkjan@REDACTED Wed Apr 30 09:08:54 2014 From: dirkjan@REDACTED (Dirkjan Ochtman) Date: Wed, 30 Apr 2014 09:08:54 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: <535F6806.8020308@erlang.org> References: <535F60F1.9030400@erlang.org> <535F6806.8020308@erlang.org> Message-ID: On Tue, Apr 29, 2014 at 10:51 AM, Lukas Larsson wrote: > If you, or someone else, have a machine with systemd support, the branch to > test can be found here: > https://github.com/garazdawi/otp/tree/lukas/erts/autoconf-fixes At least one user has posted feedback on the Gentoo bug: Fails configure with systemd enabled: checking systemd/sd-daemon.h usability... yes checking systemd/sd-daemon.h presence... yes checking for systemd/sd-daemon.h... yes configure: error: in `/var/tmp/portage/dev-lang/erlang-17.0-r1/work/otp_src_17.0/erts': configure: error: --enable-systemd was given, but test for systemd failed Full config.log here: https://bugs.gentoo.org/attachment.cgi?id=376026 Cheers, Dirkjan From lukas@REDACTED Wed Apr 30 10:13:49 2014 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 30 Apr 2014 10:13:49 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: References: <535F60F1.9030400@erlang.org> <535F6806.8020308@erlang.org> Message-ID: <5360B0BD.9010308@erlang.org> Hello, On 30/04/14 09:08, Dirkjan Ochtman wrote: > On Tue, Apr 29, 2014 at 10:51 AM, Lukas Larsson wrote: >> If you, or someone else, have a machine with systemd support, the branch to >> test can be found here: >> https://github.com/garazdawi/otp/tree/lukas/erts/autoconf-fixes > At least one user has posted feedback on the Gentoo bug: > > Fails configure with systemd enabled: > > checking systemd/sd-daemon.h usability... yes > checking systemd/sd-daemon.h presence... yes > checking for systemd/sd-daemon.h... yes > configure: error: in > `/var/tmp/portage/dev-lang/erlang-17.0-r1/work/otp_src_17.0/erts': > configure: error: --enable-systemd was given, but test for systemd failed > > Full config.log here: https://bugs.gentoo.org/attachment.cgi?id=376026 The interesting pieces are in erts/config.log, not in the top config.log. Do you think you could get hold of that log? Lukas From peppe@REDACTED Wed Apr 30 12:05:11 2014 From: peppe@REDACTED (Peter Andersson) Date: Wed, 30 Apr 2014 12:05:11 +0200 Subject: [erlang-bugs] Incorrect specs documentation for common_test In-Reply-To: <53591799.7000308@ninenines.eu> References: <53591799.7000308@ninenines.eu> Message-ID: <5360CAD7.1070407@erlang.org> Hi Lo?c, This documentation feature was sometimes used, before typespecs became common, to say "return value has no meaning". I.e. void() wasn't a type reference as such. This is old and confusing documentation syntax, and should be updated. I'll have at it (since I have nothing to do)! :-D Thanks! Peter Ericsson AB, Erlang/OTP Lo?c Hoguin wrote: > There are a few functions and a few things in the documentation that say > they return void() instead of ok or other things. For example the > ct:comment/{1,2} functions. > > I notice that ct doesn't use typespecs so that might be why it didn't > get noticed until now. If someone has nothing to do, have at it. :-) > > From binarin@REDACTED Wed Apr 30 15:32:42 2014 From: binarin@REDACTED (Alexey Lebedeff) Date: Wed, 30 Apr 2014 17:32:42 +0400 Subject: [erlang-bugs] Negative integer literals as map keys Message-ID: Hi, As soon as I add unary minus anywhere in a map key, it breaks with "illegal map key" message: Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 3> #{ -1 => 1}. * 1: illegal map key 4> #{ {a, -1} => 1 }. * 1: illegal map key -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Wed Apr 30 16:09:34 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 30 Apr 2014 16:09:34 +0200 Subject: [erlang-bugs] Negative integer literals as map keys In-Reply-To: References: Message-ID: <5361041E.5030904@erlang.org> Yep, the linter is a bit harsh here. It's suppose to deny all non-value keys, which technically is what it does here .. but it is a bit harsh. I'll look at it. // Bj?rn-Egil On 2014-04-30 15:32, Alexey Lebedeff wrote: > Hi, > > As soon as I add unary minus anywhere in a map key, it breaks with > "illegal map key" message: > > Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > Eshell V6.0 (abort with ^G) > 3> #{ -1 => 1}. > * 1: illegal map key > 4> #{ {a, -1} => 1 }. > * 1: illegal map key > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.j.hakala@REDACTED Wed Apr 30 18:26:47 2014 From: jani.j.hakala@REDACTED (Jani Hakala) Date: Wed, 30 Apr 2014 19:26:47 +0300 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: <535F6806.8020308@erlang.org> (Lukas Larsson's message of "Tue, 29 Apr 2014 10:51:18 +0200") References: <535F60F1.9030400@erlang.org> <535F6806.8020308@erlang.org> Message-ID: <87vbtqu6k8.fsf@pingviini.dy.fi> Lukas Larsson writes: > If you, or someone else, have a machine with systemd support, the > branch to test can be found here: > https://github.com/garazdawi/otp/tree/lukas/erts/autoconf-fixes > I tested this branch in debian enviroment that had libsystemd-daemon-dev and libsystemd-daemon0 packages installed (systemd not actually in use as /sbin/init). Building went ok. Most of the binaries ended up being linked to libsystemd-daemon needlessly. It could be avoided: -------------- next part -------------- A non-text attachment was scrubbed... Name: otp-systemd.patch Type: text/x-diff Size: 1632 bytes Desc: not available URL: -------------- next part -------------- Or in some other way. Jani Hakala From michael@REDACTED Wed Apr 30 19:07:08 2014 From: michael@REDACTED (Michael Gebetsroither) Date: Wed, 30 Apr 2014 19:07:08 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: <87vbtqu6k8.fsf@pingviini.dy.fi> References: <535F60F1.9030400@erlang.org> <535F6806.8020308@erlang.org> <87vbtqu6k8.fsf@pingviini.dy.fi> Message-ID: <53612DBC.6070707@mgeb.org> On 2014-04-30 18:26, Jani Hakala wrote: > Lukas Larsson writes: Hi, >> If you, or someone else, have a machine with systemd support, the >> branch to test can be found here: >> https://github.com/garazdawi/otp/tree/lukas/erts/autoconf-fixes >> > I tested this branch in debian enviroment that had libsystemd-daemon-dev > and libsystemd-daemon0 packages installed (systemd not actually in use > as /sbin/init). Building went ok. > > Most of the binaries ended up being linked to libsystemd-daemon > needlessly. It could be avoided: >From systemd changelog: http://cgit.freedesktop.org/systemd/systemd/tree/NEWS > CHANGES WITH 209: > > * The APIs "sd-journal.h", "sd-login.h", "sd-id128.h", > "sd-daemon.h" are no longer found in individual libraries > libsystemd-journal.so, libsystemd-login.so, > libsystemd-id128.so, libsystemd-daemon.so. Instead, we have > merged them into a single library, libsystemd.so, which > provides all symbols. The reason for this is cyclic > dependencies, as these libraries tend to use each other's > symbols. > ... > -- Berlin, 2014-02-20 If one really need those old libraries there is --enable-compat-libs, BUT in changelog of version 210 it is stated: "Please make sure to use --enable-compat-libs only during a transitional period!" Thus you should really link to libsystemd. Michael Gebetsroither From michael@REDACTED Wed Apr 30 19:07:08 2014 From: michael@REDACTED (Michael Gebetsroither) Date: Wed, 30 Apr 2014 19:07:08 +0200 Subject: [erlang-bugs] epmd_srv.c:(.text+0x830): undefined reference to `sd_listen_fds' In-Reply-To: <87vbtqu6k8.fsf@pingviini.dy.fi> References: <535F60F1.9030400@erlang.org> <535F6806.8020308@erlang.org> <87vbtqu6k8.fsf@pingviini.dy.fi> Message-ID: <53612DBC.6070707@mgeb.org> On 2014-04-30 18:26, Jani Hakala wrote: > Lukas Larsson writes: Hi, >> If you, or someone else, have a machine with systemd support, the >> branch to test can be found here: >> https://github.com/garazdawi/otp/tree/lukas/erts/autoconf-fixes >> > I tested this branch in debian enviroment that had libsystemd-daemon-dev > and libsystemd-daemon0 packages installed (systemd not actually in use > as /sbin/init). Building went ok. > > Most of the binaries ended up being linked to libsystemd-daemon > needlessly. It could be avoided: >From systemd changelog: http://cgit.freedesktop.org/systemd/systemd/tree/NEWS > CHANGES WITH 209: > > * The APIs "sd-journal.h", "sd-login.h", "sd-id128.h", > "sd-daemon.h" are no longer found in individual libraries > libsystemd-journal.so, libsystemd-login.so, > libsystemd-id128.so, libsystemd-daemon.so. Instead, we have > merged them into a single library, libsystemd.so, which > provides all symbols. The reason for this is cyclic > dependencies, as these libraries tend to use each other's > symbols. > ... > -- Berlin, 2014-02-20 If one really need those old libraries there is --enable-compat-libs, BUT in changelog of version 210 it is stated: "Please make sure to use --enable-compat-libs only during a transitional period!" Thus you should really link to libsystemd. Michael Gebetsroither