From tim@REDACTED Mon Jan 2 02:26:03 2012 From: tim@REDACTED (Tim Stewart) Date: Sun, 01 Jan 2012 20:26:03 -0500 Subject: [erlang-patches] Remove hipe_ceach from hipe.app.src to fix reltool-generated release startup Message-ID: <4F0107AB.6000108@stoo.org> Hello erlang-patches! hipe_ceach.erl has disappeared, but is still referred to from hipe.app.src, causing reltool-generated releases crash when they cannot find the module. git fetch git://github.com/timclassic/otp.git no_hipe_ceach https://github.com/timclassic/otp/compare/erlang:maint...no_hipe_ceach https://github.com/timclassic/otp/compare/erlang:maint...no_hipe_ceach.patch -TimS -- Tim Stewart From kostis@REDACTED Mon Jan 2 10:54:41 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 02 Jan 2012 11:54:41 +0200 Subject: [erlang-patches] Remove hipe_ceach from hipe.app.src to fix reltool-generated release startup In-Reply-To: <4F0107AB.6000108@stoo.org> References: <4F0107AB.6000108@stoo.org> Message-ID: <4F017EE1.9000809@cs.ntua.gr> On 01/02/12 03:26, Tim Stewart wrote: > Hello erlang-patches! > > hipe_ceach.erl has disappeared, but is still referred to from > hipe.app.src, causing reltool-generated releases crash when they > cannot find the module. > > git fetch git://github.com/timclassic/otp.git no_hipe_ceach > > https://github.com/timclassic/otp/compare/erlang:maint...no_hipe_ceach > https://github.com/timclassic/otp/compare/erlang:maint...no_hipe_ceach.patch Thanks for noticing this. The patch is ok to be included as is in the maintainance branch. Kostis From juanjo@REDACTED Tue Jan 3 05:21:24 2012 From: juanjo@REDACTED (Juan Jose Comellas) Date: Tue, 3 Jan 2012 01:21:24 -0300 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release Message-ID: The default value for 'start_phases' in .app files should be [], but it is incorrectly set to 'undefined' when?generating a release. This happens when?the original .app file does not set a value for 'start_phases' explicitly. The reltool application defines its own copy of a record to handle .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that has different default values than the one used by systools (#application{}, defined in lib/sasl/src/systools.hrl). In particular, the 'start_phases' entry is assumed by all of OTP to be [] when it is not explicitly set but?reltool sets it to 'undefined' by default. This causes badmatch errors?when trying to generate release upgrades. Without this patch, all of the rebar examples that generate release upgrades that I've found on the web will fail. The bug was introduced in R14A. git fetch?git://github.com/jcomellas/otp.git jc-fix-default-start-phases Juanjo From henrik@REDACTED Tue Jan 3 12:01:28 2012 From: henrik@REDACTED (Henrik Nord) Date: Tue, 3 Jan 2012 12:01:28 +0100 Subject: [erlang-patches] [PATCH] Fix SCTP multihoming for IPv6 In-Reply-To: <1325275858-13477-1-git-send-email-tomas.abrahamsson@gmail.com> References: <1325275858-13477-1-git-send-email-tomas.abrahamsson@gmail.com> Message-ID: <4F02E008.9060500@erlang.org> Thank you for the patch! Its now included in 'pu' On 12/30/2011 09:10 PM, Tomas Abrahamsson wrote: > Setting several ip addresses for an SCTP socket worked for IPv4, but > for IPv6 the call to gen_sctp:open/1 failed with badarg. > --- > erts/emulator/drivers/common/inet_drv.c | 12 +++--- > lib/kernel/test/gen_sctp_SUITE.erl | 64 ++++++++++++++++++++++++++++++- > 2 files changed, 68 insertions(+), 8 deletions(-) > > diff --git a/erts/emulator/drivers/common/inet_drv.c b/erts/emulator/drivers/common/inet_drv.c > index eeaa4d2..f712653 100644 > --- a/erts/emulator/drivers/common/inet_drv.c > +++ b/erts/emulator/drivers/common/inet_drv.c > @@ -10111,8 +10111,9 @@ static ErlDrvSSizeT packet_inet_ctl(ErlDrvData e, unsigned int cmd, char* buf, > /* Construct the list of addresses we bind to. The curr limit is > 256 addrs. Buff structure: Flags(1), ListItem,...: > */ > - struct sockaddr addrs[256]; > + inet_address addrs[256]; > char* curr; > + char* addr_dest; > int add_flag, n, rflag; > > if (!IS_SCTP(desc)) > @@ -10122,6 +10123,7 @@ static ErlDrvSSizeT packet_inet_ctl(ErlDrvData e, unsigned int cmd, char* buf, > add_flag = get_int8(curr); > curr++; > > + addr_dest = (char *)addrs; > for(n=0; n< 256&& curr< buf+len; n++) > { > /* List item format: Port(2), IP(4|16) -- compatible with > @@ -10132,16 +10134,14 @@ static ErlDrvSSizeT packet_inet_ctl(ErlDrvData e, unsigned int cmd, char* buf, > if (curr == NULL) > return ctl_error(EINVAL, rbuf, rsize); > > - /* Now: we need to squeeze "tmp" into the size of "sockaddr", > - which is smaller than "tmp" for IPv6 (extra IN6 info will > - be cut off): */ > - memcpy(addrs + n,&tmp, sizeof(struct sockaddr)); > + memcpy(addr_dest,&tmp, alen); > + addr_dest += alen; > } > /* Make the real flags: */ > rflag = add_flag ? SCTP_BINDX_ADD_ADDR : SCTP_BINDX_REM_ADDR; > > /* Invoke the call: */ > - if (p_sctp_bindx(desc->s, addrs, n, rflag)< 0) > + if (p_sctp_bindx(desc->s, (struct sockaddr *)addrs, n, rflag)< 0) > return ctl_error(sock_errno(), rbuf, rsize); > > desc->state = INET_STATE_BOUND; > diff --git a/lib/kernel/test/gen_sctp_SUITE.erl b/lib/kernel/test/gen_sctp_SUITE.erl > index 8f490b6..6d6b154 100644 > --- a/lib/kernel/test/gen_sctp_SUITE.erl > +++ b/lib/kernel/test/gen_sctp_SUITE.erl > @@ -31,14 +31,16 @@ > [basic/1, > api_open_close/1,api_listen/1,api_connect_init/1,api_opts/1, > xfer_min/1,xfer_active/1,def_sndrcvinfo/1,implicit_inet6/1, > - basic_stream/1, xfer_stream_min/1, peeloff/1, buffers/1]). > + basic_stream/1, xfer_stream_min/1, peeloff/1, buffers/1, > + open_multihoming_ipv4_socket/1, open_multihoming_ipv6_socket/1]). > > suite() -> [{ct_hooks,[ts_install_cth]}]. > > all() -> > [basic, api_open_close, api_listen, api_connect_init, > api_opts, xfer_min, xfer_active, def_sndrcvinfo, implicit_inet6, > - basic_stream, xfer_stream_min, peeloff, buffers]. > + basic_stream, xfer_stream_min, peeloff, buffers, > + open_multihoming_ipv4_socket, open_multihoming_ipv6_socket]. > > groups() -> > []. > @@ -1329,3 +1331,61 @@ match_unless_solaris(A, B) -> > {unix,sunos} -> B; > _ -> A = B > end. > + > +open_multihoming_ipv4_socket(doc) -> > + "Test opening a multihoming ipv4 socket"; > +open_multihoming_ipv4_socket(suite) -> > + []; > +open_multihoming_ipv4_socket(Config) when is_list(Config) -> > + ?line Hostname = ok(inet:gethostname()), > + ?line HostAddrIPv4 = ok(inet:getaddr(Hostname, inet)), > + ?line S = ok(gen_sctp:open(0, [{ip,HostAddrIPv4},{ip,{127,0,0,1}}])), > + ?line ok = gen_sctp:listen(S, true), > + ?line setup_connection(S, HostAddrIPv4, inet), > + ?line ok = gen_sctp:close(S). > + > +open_multihoming_ipv6_socket(doc) -> > + "Test opening a multihoming ipv6 socket"; > +open_multihoming_ipv6_socket(suite) -> > + []; > +open_multihoming_ipv6_socket(Config) when is_list(Config) -> > + ?line Hostname = ok(inet:gethostname()), > + ?line LoopbackIPv6 = {0,0,0,0,0,0,0,1}, > + ?line > + case inet:getaddr(Hostname, inet6) of > + {ok,HostAddrIPv6} when HostAddrIPv6 =/= LoopbackIPv6 -> > + ?line > + case is_good_ipv6_address(HostAddrIPv6) of > + true -> > + ?line io:format("using ipv6 addresses ~p and ~p~n", > + [HostAddrIPv6, LoopbackIPv6]), > + ?line S = ok(gen_sctp:open( > + 0, [{ip,HostAddrIPv6}, > + {ip,LoopbackIPv6}, inet6])), > + ?line ok = gen_sctp:listen(S, true), > + ?line setup_connection(S, HostAddrIPv6, inet6), > + ?line ok = gen_sctp:close(S); > + false -> > + {skip,"Need 2 good IPv6 addresses"} > + end; > + {ok,HostAddrIPv6} when HostAddrIPv6 =:= LoopbackIPv6 -> > + {skip,"Need 2 different IPv6 addresses, found only ::1"}; > + {error,eafnosupport} -> > + {skip,"Can not look up IPv6 address"} > + end. > + > +is_good_ipv6_address({0,0,0,0,0,16#ffff,_,_}) -> false; %% ipv4 mapped > +is_good_ipv6_address({16#fe80,_,_,_,_,_,_,_}) -> false; %% link-local > +is_good_ipv6_address(_) -> true. > + > +setup_connection(S1, Addr, IpFamily) -> > + ?line P1 = ok(inet:port(S1)), > + ?line S2 = ok(gen_sctp:open(0, [IpFamily])), > + ?line P2 = ok(inet:port(S2)), > + ?line #sctp_assoc_change{state=comm_up} = > + ok(gen_sctp:connect(S2, Addr, P1, [])), > + ?line case ok(gen_sctp:recv(S1)) of > + {Addr,P2,[],#sctp_assoc_change{state=comm_up}} -> > + ok > + end, > + ?line ok = gen_sctp:close(S2). -- /Henrik Nord Erlang/OTP From henrik@REDACTED Tue Jan 3 12:06:28 2012 From: henrik@REDACTED (Henrik Nord) Date: Tue, 3 Jan 2012 12:06:28 +0100 Subject: [erlang-patches] Fixes value returned by mnesia_loader:do_get_disc_copy2/4 In-Reply-To: <20111231192635.GB28849@viper.local> References: <20111231192635.GB28849@viper.local> Message-ID: <4F02E134.6070401@erlang.org> Thank you. I have now included this in 'pu' On 12/31/2011 08:26 PM, Ricardo Catalinas Jim?nez wrote: > Returns the same value for `mnesia_loader:disc_load_table/2' as > `mnesia_loader:net_load_table/4' if a table copy can not be found. > > This patch was stuck as a pull request in GitHub (authored by Uwe Dauernheim): > https://github.com/erlang/otp/pull/16 Yea after the comment there, I hoped he would send it in this way if he wanted it to be included. > > Please fetch: > git fetch git://github.com/jimenezrick/otp.git fix-return-do_get_disc_copy2 > > Review here: > https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-return-do_get_disc_copy2 > https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-return-do_get_disc_copy2.patch > > > Regards -- /Henrik Nord Erlang/OTP From henrik@REDACTED Tue Jan 3 12:08:02 2012 From: henrik@REDACTED (Henrik Nord) Date: Tue, 3 Jan 2012 12:08:02 +0100 Subject: [erlang-patches] Remove hipe_ceach from hipe.app.src to fix reltool-generated release startup In-Reply-To: <4F017EE1.9000809@cs.ntua.gr> References: <4F0107AB.6000108@stoo.org> <4F017EE1.9000809@cs.ntua.gr> Message-ID: <4F02E192.8000802@erlang.org> Thank you for the patch, and thank you Kostis for the review :D I will include it if all tests pass as expected. for now its in 'pu' On 01/02/2012 10:54 AM, Kostis Sagonas wrote: > On 01/02/12 03:26, Tim Stewart wrote: >> Hello erlang-patches! >> >> hipe_ceach.erl has disappeared, but is still referred to from >> hipe.app.src, causing reltool-generated releases crash when they >> cannot find the module. >> >> git fetch git://github.com/timclassic/otp.git no_hipe_ceach >> >> https://github.com/timclassic/otp/compare/erlang:maint...no_hipe_ceach >> https://github.com/timclassic/otp/compare/erlang:maint...no_hipe_ceach.patch >> > > Thanks for noticing this. The patch is ok to be included as is in the > maintainance branch. > > Kostis > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Tue Jan 3 12:15:02 2012 From: henrik@REDACTED (Henrik Nord) Date: Tue, 3 Jan 2012 12:15:02 +0100 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: Message-ID: <4F02E336.2090501@erlang.org> Thank you, I have included this in 'pu' On 01/03/2012 05:21 AM, Juan Jose Comellas wrote: > The default value for 'start_phases' in .app files should be [], but > it is incorrectly set to 'undefined' when generating a release. This > happens when the original .app file does not set a value for > 'start_phases' explicitly. > > The reltool application defines its own copy of a record to handle > .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that > has different default values than the one used by systools > (#application{}, defined in lib/sasl/src/systools.hrl). In particular, > the 'start_phases' entry is assumed by all of OTP to be [] when it is > not explicitly set but reltool sets it to 'undefined' by default. This > causes badmatch errors when trying to generate release upgrades. > > Without this patch, all of the rebar examples that generate release > upgrades that I've found on the web will fail. The bug was introduced > in R14A. > > git fetch git://github.com/jcomellas/otp.git jc-fix-default-start-phases > > Juanjo > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From ulf@REDACTED Tue Jan 3 12:22:19 2012 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 3 Jan 2012 12:22:19 +0100 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: Message-ID: Hmm, there's an old catch here. Someone will have to hollar if it is no longer relevant - but if it isn't, some documentation patch is called for. In http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 StartType defines the type of start: normal if it's a normal startup. normal also if the application is distributed and started at the current node due to a failover from another node, and the application specification key start_phases == undefined. {takeover,Node} if the application is distributed and started at the current node due to a takeover from Node, either because application:takeover/2 has been called or because the current node has higher priority than Node. {failover,Node} if the application is distributed and started at the current node due to a failover from Node, and the application specification key start_phases /= undefined. Note that StartType = {failover, Node} is only used if start_phases /= undefined. I will guess that it is for this reason that start_phases is actually set to undefined as default. If it isn't, it was a happy coincidence, since it actually preserves backward compatibility. This particular oddity was introduced many years ago, in the 90s - possibly even before Erlang was released as Open Source, so the legacy argument may not be that relevant. OTOH, I don't think many people use the start_phases attribute, so even new code might break if the Mod:start/2 function is suddenly called with a StartType that was never seen before. BR, Ulf W On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: > The default value for 'start_phases' in .app files should be [], but > it is incorrectly set to 'undefined' when generating a release. This > happens when the original .app file does not set a value for > 'start_phases' explicitly. > > The reltool application defines its own copy of a record to handle > .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that > has different default values than the one used by systools > (#application{}, defined in lib/sasl/src/systools.hrl). In particular, > the 'start_phases' entry is assumed by all of OTP to be [] when it is > not explicitly set but reltool sets it to 'undefined' by default. This > causes badmatch errors when trying to generate release upgrades. > > Without this patch, all of the rebar examples that generate release > upgrades that I've found on the web will fail. The bug was introduced > in R14A. > > git fetch git://github.com/jcomellas/otp.git jc-fix-default-start-phases > > Juanjo > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Tue Jan 3 12:47:24 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 03 Jan 2012 12:47:24 +0100 Subject: [erlang-patches] spelling fixes Message-ID: <4F02EACC.8040408@gmail.com> Correct spelling of "registered" in various places in the source code git fetch git://github.com/richcarl/otp.git spell-registered /Richard From henrik@REDACTED Tue Jan 3 12:56:22 2012 From: henrik@REDACTED (Henrik Nord) Date: Tue, 3 Jan 2012 12:56:22 +0100 Subject: [erlang-patches] spelling fixes In-Reply-To: <4F02EACC.8040408@gmail.com> References: <4F02EACC.8040408@gmail.com> Message-ID: <4F02ECE6.4080201@erlang.org> Thank you, patch included in 'pu' On 01/03/2012 12:47 PM, Richard Carlsson wrote: > Correct spelling of "registered" in various places in the source code > > git fetch git://github.com/richcarl/otp.git spell-registered > > /Richard > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Tue Jan 3 16:20:20 2012 From: henrik@REDACTED (Henrik Nord) Date: Tue, 3 Jan 2012 16:20:20 +0100 Subject: [erlang-patches] [PATCH] erts: fix error handling in bif erlang:start_timer/3 In-Reply-To: References: Message-ID: <4F031CB4.2010101@erlang.org> We will not include this patch as it conflict with how Erlang normally behaves when working with dead processes. Thank you for the contribution. On 12/28/2011 08:56 AM, Jovi Zhang wrote: > > From 18612f43f0c8a6f217806c22c9f9bec8b0de4b26 Mon Sep 17 00:00:00 2001 > From: Jovi Zhang > Date: Wed, 21 Dec 2011 03:26:03 +0800 > Subject: [PATCH] erts: fix error handling in bif erlang:start_timer/3 > > See below, When recevier pid is non-exist, start_timer/3 return a > valid internal Ref, this is wrong, erlang should return badarg instead. > > Eshell V5.9 (abort with ^G) > 1> A = erlang:start_timer(100*1000, pid(0, 9999, 0), {none}). > Ref<0.0.0.29> > 2> erlang:read_timer(A). > false > 3> > --- > erts/emulator/beam/erl_bif_timer.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/erts/emulator/beam/erl_bif_timer.c > b/erts/emulator/beam/erl_bif_timer.c > index a922a33..7bd2b8e 100644 > --- a/erts/emulator/beam/erl_bif_timer.c > +++ b/erts/emulator/beam/erl_bif_timer.c > @@ -414,7 +414,7 @@ setup_bif_timer(Uint32 xflags, > rp = erts_pid2proc(c_p, ERTS_PROC_LOCK_MAIN, > receiver, ERTS_PROC_LOCK_MSGQ); > if (!rp) > - return ref; > + return THE_NON_VALUE; > } > > if (timeout< ERTS_ALC_MIN_LONG_LIVED_TIME) { > -- > 1.7.2.3 > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanjo@REDACTED Tue Jan 3 21:22:30 2012 From: juanjo@REDACTED (Juan Jose Comellas) Date: Tue, 3 Jan 2012 17:22:30 -0300 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: Message-ID: I can make the change and add it to the branch I created, but the question is: should I? I'm not really that well informed about the history of this value. All I can say is that the parts that care about the 'start_phases' entry in reltool and systools assume that it will be an empty list when it is not set and fail otherwise. Let me know if I have to modify my patch to make it acceptable for inclusion in OTP. Juanjo On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger wrote: > > Hmm, there's an old catch here. Someone will have to hollar if it is no > longer relevant - but if it isn't, some documentation patch is called for. > > In?http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 > > StartType?defines the type of start: > > normal?if it's a normal startup. > normal?also if the application is distributed and started at the current > node due to a failover from another node, and the application specification > key?start_phases == undefined. > {takeover,Node}?if the application is distributed and started at the current > node due to a takeover from?Node, either because?application:takeover/2?has > been called or because the current node has higher priority than?Node. > {failover,Node}?if the application is distributed and started at the current > node due to a failover from?Node, and the application specification > key?start_phases /= undefined. > > Note that StartType = {failover, Node} is only used if start_phases /= > undefined. I will guess that it is for this reason that start_phases is > actually set to undefined as default. If it isn't, it was a happy > coincidence, since it actually preserves backward compatibility. > > This particular oddity was introduced many years ago, in the 90s - possibly > even before Erlang was released as Open Source, so the legacy argument may > not be that relevant. > > OTOH, I don't think many people use the start_phases attribute, so even new > code might break if the Mod:start/2 function is suddenly called with a > StartType that was never seen before. > > BR, > Ulf W > > > On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: > > The default value for 'start_phases' in .app files should be [], but > it is incorrectly set to 'undefined' when?generating a release. This > happens when?the original .app file does not set a value for > 'start_phases' explicitly. > > The reltool application defines its own copy of a record to handle > .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that > has different default values than the one used by systools > (#application{}, defined in lib/sasl/src/systools.hrl). In particular, > the 'start_phases' entry is assumed by all of OTP to be [] when it is > not explicitly set but?reltool sets it to 'undefined' by default. This > causes badmatch errors?when trying to generate release upgrades. > > Without this patch, all of the rebar examples that generate release > upgrades that I've found on the web will fail. The bug was introduced > in R14A. > > git fetch?git://github.com/jcomellas/otp.git jc-fix-default-start-phases > > Juanjo > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From ulf@REDACTED Tue Jan 3 21:31:45 2012 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 3 Jan 2012 21:31:45 +0100 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: Message-ID: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> Not my call. I can well understand if the reasons behind the special treatment of 'start_phases' have been forgotten by those maintaining the code. A closer analysis might reveal whether backward compatibility has already been sufficiently compromised that it is now time to Make It Right (?). Even the old AXD 301 project, for which the oddity was introduced in the first place, took the first opportunity to make the code fully compatible with the new semantics. BR, Ulf W On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: > I can make the change and add it to the branch I created, but the > question is: should I? I'm not really that well informed about the > history of this value. All I can say is that the parts that care about > the 'start_phases' entry in reltool and systools assume that it will > be an empty list when it is not set and fail otherwise. > > Let me know if I have to modify my patch to make it acceptable for > inclusion in OTP. > > Juanjo > > > On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger wrote: >> >> Hmm, there's an old catch here. Someone will have to hollar if it is no >> longer relevant - but if it isn't, some documentation patch is called for. >> >> In http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 >> >> StartType defines the type of start: >> >> normal if it's a normal startup. >> normal also if the application is distributed and started at the current >> node due to a failover from another node, and the application specification >> key start_phases == undefined. >> {takeover,Node} if the application is distributed and started at the current >> node due to a takeover from Node, either because application:takeover/2 has >> been called or because the current node has higher priority than Node. >> {failover,Node} if the application is distributed and started at the current >> node due to a failover from Node, and the application specification >> key start_phases /= undefined. >> >> Note that StartType = {failover, Node} is only used if start_phases /= >> undefined. I will guess that it is for this reason that start_phases is >> actually set to undefined as default. If it isn't, it was a happy >> coincidence, since it actually preserves backward compatibility. >> >> This particular oddity was introduced many years ago, in the 90s - possibly >> even before Erlang was released as Open Source, so the legacy argument may >> not be that relevant. >> >> OTOH, I don't think many people use the start_phases attribute, so even new >> code might break if the Mod:start/2 function is suddenly called with a >> StartType that was never seen before. >> >> BR, >> Ulf W >> >> >> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: >> >> The default value for 'start_phases' in .app files should be [], but >> it is incorrectly set to 'undefined' when generating a release. This >> happens when the original .app file does not set a value for >> 'start_phases' explicitly. >> >> The reltool application defines its own copy of a record to handle >> .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that >> has different default values than the one used by systools >> (#application{}, defined in lib/sasl/src/systools.hrl). In particular, >> the 'start_phases' entry is assumed by all of OTP to be [] when it is >> not explicitly set but reltool sets it to 'undefined' by default. This >> causes badmatch errors when trying to generate release upgrades. >> >> Without this patch, all of the rebar examples that generate release >> upgrades that I've found on the web will fail. The bug was introduced >> in R14A. >> >> git fetch git://github.com/jcomellas/otp.git jc-fix-default-start-phases >> >> Juanjo >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> From carlsson.richard@REDACTED Tue Jan 3 22:11:47 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 03 Jan 2012 22:11:47 +0100 Subject: [erlang-patches] allow use of proplists in supervisor start specs Message-ID: <4F036F13.8040506@gmail.com> The formats of the supervisor flags (the 3-tuple {one_for_one, Restarts, Time}) and the child specifications (6-tuples {name, etc., etc.}) are annoyingly hard both to read and write. This patch makes it possible to pass lists of options instead, and sets useful defaults for most fields. This also opens for the possibility to add more flags both to supervisors and children in the future. git fetch git://github.com/richcarl/otp.git proplist-child-spec For example: init() SupFlags = [{period,10}], Child = [{name, foo}, {start, {M,F,A}}] {ok, {SupFlags, [Child]}}. This gets you a one-for-one supervisor with a particular restart time period, and a single child with default behaviour. The name and start options are required. The supervisor flag defaults are: strategy = one_for_one intensity = 10 period = 30 I.e., one-for-one supervision and at most 10 restarts in the last 30 seconds. This restart frequency seems like a useful default; let me know if you think some other numbers would be significantly better. The child spec defaults are: restart_type = permanent shutdown = 2000 child_type = worker modules = [M], where M is the module in the start MFA Finally, there is a new function supervisor:get_childspec(Sup, Child) which can be used to get the full child specification (as a list) needed to restart the same child or another child like it. Note that the documentation has not been updated as part of this patch. /Richard From carlsson.richard@REDACTED Tue Jan 3 23:55:25 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 03 Jan 2012 23:55:25 +0100 Subject: [erlang-patches] delayed child restart with incremental back-off Message-ID: <4F03875D.1020504@gmail.com> Asynchronous delayed child restart with incremental back-off Use a queue instead of a list to track restarts (avoiding linear time complexity), and delay restarting of children incrementally from min_delay (at least 1 ms) up to max_delay if an immediate restart fails. The maximum number of restarts is still decided by the intensity/period parameters, but this makes it possible to control how fast (or slow) restarts will happen. git fetch git://github.com/richcarl/otp.git supervisor-restart-delay This fixes the problem when a supervisor tries to restart a crashed child but for various reasons (in particular, because modern Erlang on a multicore machine has way more concurrency going on) some resources that were held by the dead process have not been released quite yet - this can happen even with a simple registered name - and thus the restart fails, and immediately fails again, and again, until the supervisor gives up and shuts down; this can *bring down the whole node*, because the restart attempts get exhausted within an extremenly short time period, even if you have multiple supervisors. Usually, waiting for just a millisecond is enough to let the resource be released so the process can restart, but sometimes a bit longer is needed. This patch implements an incremental back-off which starts at 1 ms and is capped at 1 second between restart attempts. These parameters are currently hard-coded, but that could change if my supervisor options patch is accepted. The delay is handled asynchronously, so the supervisor is not unresponsive while a restart is delayed. /Richard From ulf@REDACTED Wed Jan 4 00:50:51 2012 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 4 Jan 2012 00:50:51 +0100 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: <4F036F13.8040506@gmail.com> References: <4F036F13.8040506@gmail.com> Message-ID: Sounds good. My personal preference is MaxR = 3, MaxT = 10, which is slightly more aggressive. For one thing, if you have, say, 3 levels - top supervisor, a few supervisors underneath, and some workers, and they all have MaxR = 10, you will suffer 1000 restarts before a complete escalation. With MaxR=3, you will have 27, which would be excessive, but not ridiculous. Granted, you should always think through your restart limits for deeper trees. BR, Ulf W On 3 Jan 2012, at 22:11, Richard Carlsson wrote: > The formats of the supervisor flags (the 3-tuple {one_for_one, Restarts, Time}) and the child specifications (6-tuples {name, etc., etc.}) are annoyingly hard both to read and write. This patch makes it possible to pass lists of options instead, and sets useful defaults for most fields. This also opens for the possibility to add more flags both to supervisors and children in the future. > > git fetch git://github.com/richcarl/otp.git proplist-child-spec > > For example: > > init() > SupFlags = [{period,10}], > Child = [{name, foo}, {start, {M,F,A}}] > {ok, {SupFlags, [Child]}}. > > This gets you a one-for-one supervisor with a particular restart time period, and a single child with default behaviour. The name and start options are required. > > The supervisor flag defaults are: > > strategy = one_for_one > intensity = 10 > period = 30 > > I.e., one-for-one supervision and at most 10 restarts in the last 30 seconds. This restart frequency seems like a useful default; let me know if you think some other numbers would be significantly better. > > The child spec defaults are: > restart_type = permanent > shutdown = 2000 > child_type = worker > modules = [M], where M is the module in the start MFA > > Finally, there is a new function supervisor:get_childspec(Sup, Child) which can be used to get the full child specification (as a list) needed to restart the same child or another child like it. > > Note that the documentation has not been updated as part of this patch. > > /Richard > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From mjtruog@REDACTED Wed Jan 4 02:00:37 2012 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 03 Jan 2012 17:00:37 -0800 Subject: [erlang-patches] delayed child restart with incremental back-off In-Reply-To: <4F03875D.1020504@gmail.com> References: <4F03875D.1020504@gmail.com> Message-ID: <4F03A4B5.2090404@gmail.com> On 01/03/2012 02:55 PM, Richard Carlsson wrote: > Asynchronous delayed child restart with incremental back-off > > Use a queue instead of a list to track restarts (avoiding linear time complexity), and delay restarting of children incrementally from min_delay (at least 1 ms) up to max_delay if an immediate restart fails. The maximum number of restarts is still decided by the intensity/period parameters, but this makes it possible to control how fast (or slow) restarts will happen. > > git fetch git://github.com/richcarl/otp.git supervisor-restart-delay > > This fixes the problem when a supervisor tries to restart a crashed child but for various reasons (in particular, because modern Erlang on a multicore machine has way more concurrency going on) some resources that were held by the dead process have not been released quite yet - this can happen even with a simple registered name - and thus the restart fails, and immediately fails again, and again, until the supervisor gives up and shuts down; this can *bring down the whole node*, because the restart attempts get exhausted within an extremenly short time period, even if you have multiple supervisors. Usually, waiting for just a millisecond is enough to let the resource be released so the process can restart, but sometimes a bit longer is needed. This patch implements an incremental back-off which starts at 1 ms and is capped at 1 second between restart attempts. These parameters are currently hard-coded, but that could change if my supervisor options patch is accepted. The > delay is handled asynchronously, so the supervisor is not unresponsive while a restart is delayed. Isn't this a feature that would hide errors, since all resources should be freed within a behavior terminate function? The supervisor controls how long the terminate function could take, and that provides a maximum time in-between restarts. However, if you allow the time in-between restarts to grow, it seems like you would just be hiding errors with the resources that should have been freed, but were not due to buggy code. So, it seems like this feature would be contrary to a "fail fast" mentality. From carlsson.richard@REDACTED Wed Jan 4 12:02:29 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 04 Jan 2012 12:02:29 +0100 Subject: [erlang-patches] delayed child restart with incremental back-off In-Reply-To: <4F03A4B5.2090404@gmail.com> References: <4F03875D.1020504@gmail.com> <4F03A4B5.2090404@gmail.com> Message-ID: <4F0431C5.9030300@gmail.com> On 01/04/2012 02:00 AM, Michael Truog wrote: > On 01/03/2012 02:55 PM, Richard Carlsson wrote: >> Asynchronous delayed child restart with incremental back-off >> >> Use a queue instead of a list to track restarts (avoiding linear >> time complexity), and delay restarting of children incrementally >> from min_delay (at least 1 ms) up to max_delay if an immediate >> restart fails. The maximum number of restarts is still decided by >> the intensity/period parameters, but this makes it possible to >> control how fast (or slow) restarts will happen. > > Isn't this a feature that would hide errors, since all resources > should be freed within a behavior terminate function? The supervisor > controls how long the terminate function could take, and that > provides a maximum time in-between restarts. However, if you allow > the time in-between restarts to grow, it seems like you would just be > hiding errors with the resources that should have been freed, but > were not due to buggy code. So, it seems like this feature would be > contrary to a "fail fast" mentality. The behaviour terminate function is alas not always called, depending on the nature of the crash. And there are other things that can delay the freeing of a resource; for example, the OS could hold on to a port for a brief time, preventing a TCP server from restarting. I think that user code should indeed fail fast, but supervisors are a different matter. A supervisor which does 1000 restart attempts in the blink of an eye and then gives up and crashes the node is indeed a way to fail fast and spectacularly, but is probably not what the programmer expected when he said "retry at most 1000 times". So I think that the supervisor should support delays between restart attempts. A question is of course what the defaults should be: starting at 1 ms seems good, but where should the backoff be capped by default? As much as 1 second between attempts, or perhaps as low as 10 ms? (If you set the cap to 0, you get the old behaviour.) /Richard From per@REDACTED Wed Jan 4 13:59:59 2012 From: per@REDACTED (Per Hedeland) Date: Wed, 4 Jan 2012 13:59:59 +0100 (CET) Subject: [erlang-patches] Fix for bogus {error, enfile} from gen_tcp:accept/1, 2 Message-ID: <201201041259.q04CxxMK004323@pluto.hedeland.org> Hello, CC'ing erlang-questions since this bug has caused some confused discussions in the past, with well-meaning info from people (including me) that know something about what ENFILE means mostly adding to the confusion. The R12B-0 release README says: OTP-6968 If open_port fails because all available ports are already in use, it will now throw a system_limit exception instead of an enfile exception. (enfile might still be thrown if the operating system would return ENFILE.) Which is great (and it shouldn't have been enfile in the first place), but gen_tcp:accept/1,2 which is probably the most common cause of running out of (Erlang) ports has continued to return {error, enfile} when the actual problem is that all ports are in use. The problem is a bit elusive, since at least on Unix, the port table is sized based on the OS process file descriptor limit - i.e. you may well get {error, emfile} (note the 'm'!:-) before you run out of ports - unless you have driver instances that use ports without using file descriptors. So: Fix returned error from gen_tcp:accept/1,2 when running out of ports The {error, enfile} return value is badly misleading and confusing for this case, since the Posix ENFILE errno value has a well-defined meaning that has nothing to do with Erlang ports. The fix changes the return value to {error, system_limit}, which is consistent with e.g. various file(3) functions. inet:format_error/1 has also been updated to support system_limit in the same manner as file:format_error/1. git fetch git://github.com/perhedeland/otp.git fix_enfile (Hoping that I didn't mess up the git stuff.:-) --Per Hedeland per@REDACTED From henrik@REDACTED Wed Jan 4 15:25:40 2012 From: henrik@REDACTED (Henrik Nord) Date: Wed, 4 Jan 2012 15:25:40 +0100 Subject: [erlang-patches] Fix for bogus {error, enfile} from gen_tcp:accept/1, 2 In-Reply-To: <201201041259.q04CxxMK004323@pluto.hedeland.org> References: <201201041259.q04CxxMK004323@pluto.hedeland.org> Message-ID: <4F046164.2020508@erlang.org> Thank you for the contribution! I have included your patch in 'pu' On 01/04/2012 01:59 PM, Per Hedeland wrote: > git fetch git://github.com/perhedeland/otp.git fix_enfile -- /Henrik Nord Erlang/OTP From henrik@REDACTED Wed Jan 4 16:17:53 2012 From: henrik@REDACTED (Henrik Nord) Date: Wed, 4 Jan 2012 16:17:53 +0100 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: <4F036F13.8040506@gmail.com> References: <4F036F13.8040506@gmail.com> Message-ID: <4F046DA1.1040903@erlang.org> Hi I would like to include this patch, however it must be completed with documentation and tests. Thank you for the contribution! On 01/03/2012 10:11 PM, Richard Carlsson wrote: > The formats of the supervisor flags (the 3-tuple {one_for_one, > Restarts, Time}) and the child specifications (6-tuples {name, etc., > etc.}) are annoyingly hard both to read and write. This patch makes it > possible to pass lists of options instead, and sets useful defaults > for most fields. This also opens for the possibility to add more flags > both to supervisors and children in the future. > > git fetch git://github.com/richcarl/otp.git proplist-child-spec > > For example: > > init() > SupFlags = [{period,10}], > Child = [{name, foo}, {start, {M,F,A}}] > {ok, {SupFlags, [Child]}}. > > This gets you a one-for-one supervisor with a particular restart time > period, and a single child with default behaviour. The name and start > options are required. > > The supervisor flag defaults are: > > strategy = one_for_one > intensity = 10 > period = 30 > > I.e., one-for-one supervision and at most 10 restarts in the last 30 > seconds. This restart frequency seems like a useful default; let me > know if you think some other numbers would be significantly better. > > The child spec defaults are: > restart_type = permanent > shutdown = 2000 > child_type = worker > modules = [M], where M is the module in the start MFA > > Finally, there is a new function supervisor:get_childspec(Sup, Child) > which can be used to get the full child specification (as a list) > needed to restart the same child or another child like it. > > Note that the documentation has not been updated as part of this patch. > > /Richard > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From mjtruog@REDACTED Wed Jan 4 18:27:57 2012 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 04 Jan 2012 09:27:57 -0800 Subject: [erlang-patches] delayed child restart with incremental back-off In-Reply-To: <4F0431C5.9030300@gmail.com> References: <4F03875D.1020504@gmail.com> <4F03A4B5.2090404@gmail.com> <4F0431C5.9030300@gmail.com> Message-ID: <4F048C1D.9000905@gmail.com> On 01/04/2012 03:02 AM, Richard Carlsson wrote: > On 01/04/2012 02:00 AM, Michael Truog wrote: >> On 01/03/2012 02:55 PM, Richard Carlsson wrote: >>> Asynchronous delayed child restart with incremental back-off >>> >>> Use a queue instead of a list to track restarts (avoiding linear >>> time complexity), and delay restarting of children incrementally >>> from min_delay (at least 1 ms) up to max_delay if an immediate >>> restart fails. The maximum number of restarts is still decided by >>> the intensity/period parameters, but this makes it possible to >>> control how fast (or slow) restarts will happen. >> >> Isn't this a feature that would hide errors, since all resources >> should be freed within a behavior terminate function? The supervisor >> controls how long the terminate function could take, and that >> provides a maximum time in-between restarts. However, if you allow >> the time in-between restarts to grow, it seems like you would just be >> hiding errors with the resources that should have been freed, but >> were not due to buggy code. So, it seems like this feature would be >> contrary to a "fail fast" mentality. > > The behaviour terminate function is alas not always called, depending on the nature of the crash. And there are other things that can delay the freeing of a resource; for example, the OS could hold on to a port for a brief time, preventing a TCP server from restarting. I think that user code should indeed fail fast, but supervisors are a different matter. A supervisor which does 1000 restart attempts in the blink of an eye and then gives up and crashes the node is indeed a way to fail fast and spectacularly, but is probably not what the programmer expected when he said "retry at most 1000 times". > > So I think that the supervisor should support delays between restart attempts. A question is of course what the defaults should be: starting at 1 ms seems good, but where should the backoff be capped by default? As much as 1 second between attempts, or perhaps as low as 10 ms? (If you set the cap to 0, you get the old behaviour.) > I am not a decision maker with Erlang/OTP, but this patch just bothered me since it seems like solving a concurrency problem by inserting a sleep statement, which I have always thought is a wrong approach (to a synchronous/blocking problem). I think it is better to solve the problems which prevents any resources from being cleaned-up quickly, since the only time a terminate function will not be called is with the kill exit exception, so the terminate function would not be called because of a higher-level failure which makes it irrelevant. I agree that having a supervisor doing 1000 restarts immediately can be a concern for any programmer, but this just doesn't seem like a good approach to the problem (to me), since you are increasing the complexity in the middle of the critical supervision structure with what reduces to a sleep statement used to solve a concurrency problem. From carlsson.richard@REDACTED Thu Jan 5 15:23:37 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 05 Jan 2012 15:23:37 +0100 Subject: [erlang-patches] disk_log_h module Message-ID: <4F05B269.2060303@gmail.com> A handler module called disk_log_h, written by Martin Bj?rklund and Magnus Fr?berg, was submitted to OTP a long (long) time ago along with a patch to the main disk_log module that added a bunch of callback functions needed by disk_log_h. But for some reason, only the patch was included in OTP, and not the module (perhaps someone just forgot to add it to the repository). In any case, we at Klarna (and Bluetail/Tail-F) have been using this module for years, and it would be good if it could be distributed with OTP as intended. Quoting from the comment in the module header: "gen_event handler for disk_log. The process which owns the log is the gen_event process, thus no extra process communcation overhead is involved. The alternative is to let the gen_event process send the message to a disk_log process, which then sends it to disk. In this case, the disk_log process is avoided. This module is intended to replace log_mf_h.erl." git fetch git://github.com/richcarl/otp.git disk_log_h /Richard From juanjo@REDACTED Thu Jan 5 16:04:10 2012 From: juanjo@REDACTED (Juan Jose Comellas) Date: Thu, 5 Jan 2012 12:04:10 -0300 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> Message-ID: Would it be an option to modify the function that validates the value assigned to 'start_phases' so that 'undefined' is considered an acceptable value? The relevant line is: https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 Juanjo On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger wrote: > > Not my call. > > I can well understand if the reasons behind the special treatment of 'start_phases' have been forgotten by those maintaining the code. > > A closer analysis might reveal whether backward compatibility has already been sufficiently compromised that it is now time to Make It Right (?). > > Even the old AXD 301 project, for which the oddity was introduced in the first place, took the first opportunity to make the code fully compatible with the new semantics. > > BR, > Ulf W > > On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: > >> I can make the change and add it to the branch I created, but the >> question is: should I? I'm not really that well informed about the >> history of this value. All I can say is that the parts that care about >> the 'start_phases' entry in reltool and systools assume that it will >> be an empty list when it is not set and fail otherwise. >> >> Let me know if I have to modify my patch to make it acceptable for >> inclusion in OTP. >> >> Juanjo >> >> >> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger wrote: >>> >>> Hmm, there's an old catch here. Someone will have to hollar if it is no >>> longer relevant - but if it isn't, some documentation patch is called for. >>> >>> In http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 >>> >>> StartType defines the type of start: >>> >>> normal if it's a normal startup. >>> normal also if the application is distributed and started at the current >>> node due to a failover from another node, and the application specification >>> key start_phases == undefined. >>> {takeover,Node} if the application is distributed and started at the current >>> node due to a takeover from Node, either because application:takeover/2 has >>> been called or because the current node has higher priority than Node. >>> {failover,Node} if the application is distributed and started at the current >>> node due to a failover from Node, and the application specification >>> key start_phases /= undefined. >>> >>> Note that StartType = {failover, Node} is only used if start_phases /= >>> undefined. I will guess that it is for this reason that start_phases is >>> actually set to undefined as default. If it isn't, it was a happy >>> coincidence, since it actually preserves backward compatibility. >>> >>> This particular oddity was introduced many years ago, in the 90s - possibly >>> even before Erlang was released as Open Source, so the legacy argument may >>> not be that relevant. >>> >>> OTOH, I don't think many people use the start_phases attribute, so even new >>> code might break if the Mod:start/2 function is suddenly called with a >>> StartType that was never seen before. >>> >>> BR, >>> Ulf W >>> >>> >>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: >>> >>> The default value for 'start_phases' in .app files should be [], but >>> it is incorrectly set to 'undefined' when generating a release. This >>> happens when the original .app file does not set a value for >>> 'start_phases' explicitly. >>> >>> The reltool application defines its own copy of a record to handle >>> .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that >>> has different default values than the one used by systools >>> (#application{}, defined in lib/sasl/src/systools.hrl). In particular, >>> the 'start_phases' entry is assumed by all of OTP to be [] when it is >>> not explicitly set but reltool sets it to 'undefined' by default. This >>> causes badmatch errors when trying to generate release upgrades. >>> >>> Without this patch, all of the rebar examples that generate release >>> upgrades that I've found on the web will fail. The bug was introduced >>> in R14A. >>> >>> git fetch git://github.com/jcomellas/otp.git jc-fix-default-start-phases >>> >>> Juanjo >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> > From ulf@REDACTED Thu Jan 5 16:06:07 2012 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 5 Jan 2012 16:06:07 +0100 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> Message-ID: <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> I would suggest that the special handling of {start_phases, undefined} be removed, and documentation updated accordingly. But this is a decision that OTP will have to make. BR, Ulf W On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote: > Would it be an option to modify the function that validates the value > assigned to 'start_phases' so that 'undefined' is considered an > acceptable value? The relevant line is: > > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 > > Juanjo > > > On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger wrote: >> >> Not my call. >> >> I can well understand if the reasons behind the special treatment of 'start_phases' have been forgotten by those maintaining the code. >> >> A closer analysis might reveal whether backward compatibility has already been sufficiently compromised that it is now time to Make It Right (?). >> >> Even the old AXD 301 project, for which the oddity was introduced in the first place, took the first opportunity to make the code fully compatible with the new semantics. >> >> BR, >> Ulf W >> >> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: >> >>> I can make the change and add it to the branch I created, but the >>> question is: should I? I'm not really that well informed about the >>> history of this value. All I can say is that the parts that care about >>> the 'start_phases' entry in reltool and systools assume that it will >>> be an empty list when it is not set and fail otherwise. >>> >>> Let me know if I have to modify my patch to make it acceptable for >>> inclusion in OTP. >>> >>> Juanjo >>> >>> >>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger wrote: >>>> >>>> Hmm, there's an old catch here. Someone will have to hollar if it is no >>>> longer relevant - but if it isn't, some documentation patch is called for. >>>> >>>> In http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 >>>> >>>> StartType defines the type of start: >>>> >>>> normal if it's a normal startup. >>>> normal also if the application is distributed and started at the current >>>> node due to a failover from another node, and the application specification >>>> key start_phases == undefined. >>>> {takeover,Node} if the application is distributed and started at the current >>>> node due to a takeover from Node, either because application:takeover/2 has >>>> been called or because the current node has higher priority than Node. >>>> {failover,Node} if the application is distributed and started at the current >>>> node due to a failover from Node, and the application specification >>>> key start_phases /= undefined. >>>> >>>> Note that StartType = {failover, Node} is only used if start_phases /= >>>> undefined. I will guess that it is for this reason that start_phases is >>>> actually set to undefined as default. If it isn't, it was a happy >>>> coincidence, since it actually preserves backward compatibility. >>>> >>>> This particular oddity was introduced many years ago, in the 90s - possibly >>>> even before Erlang was released as Open Source, so the legacy argument may >>>> not be that relevant. >>>> >>>> OTOH, I don't think many people use the start_phases attribute, so even new >>>> code might break if the Mod:start/2 function is suddenly called with a >>>> StartType that was never seen before. >>>> >>>> BR, >>>> Ulf W >>>> >>>> >>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: >>>> >>>> The default value for 'start_phases' in .app files should be [], but >>>> it is incorrectly set to 'undefined' when generating a release. This >>>> happens when the original .app file does not set a value for >>>> 'start_phases' explicitly. >>>> >>>> The reltool application defines its own copy of a record to handle >>>> .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that >>>> has different default values than the one used by systools >>>> (#application{}, defined in lib/sasl/src/systools.hrl). In particular, >>>> the 'start_phases' entry is assumed by all of OTP to be [] when it is >>>> not explicitly set but reltool sets it to 'undefined' by default. This >>>> causes badmatch errors when trying to generate release upgrades. >>>> >>>> Without this patch, all of the rebar examples that generate release >>>> upgrades that I've found on the web will fail. The bug was introduced >>>> in R14A. >>>> >>>> git fetch git://github.com/jcomellas/otp.git jc-fix-default-start-phases >>>> >>>> Juanjo >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> >>>> >> From carlsson.richard@REDACTED Thu Jan 5 20:06:09 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 05 Jan 2012 20:06:09 +0100 Subject: [erlang-patches] delayed child restart with incremental back-off In-Reply-To: <4F048C1D.9000905@gmail.com> References: <4F03875D.1020504@gmail.com> <4F03A4B5.2090404@gmail.com> <4F0431C5.9030300@gmail.com> <4F048C1D.9000905@gmail.com> Message-ID: <4F05F4A1.9080407@gmail.com> On 01/04/2012 06:27 PM, Michael Truog wrote: > I am not a decision maker with Erlang/OTP, but this patch just > bothered me since it seems like solving a concurrency problem by > inserting a sleep statement, which I have always thought is a wrong > approach (to a synchronous/blocking problem). I think it is better > to solve the problems which prevents any resources from being > cleaned-up quickly, since the only time a terminate function will not > be called is with the kill exit exception, so the terminate function > would not be called because of a higher-level failure which makes it > irrelevant. I agree that having a supervisor doing 1000 restarts > immediately can be a concern for any programmer, but this just > doesn't seem like a good approach to the problem (to me), since you > are increasing the complexity in the middle of the critical > supervision structure with what reduces to a sleep statement used to > solve a concurrency problem. In general, yes, synchronization issues should not be solved naively by sleeping. But the restart problem depends on a race condition that the programmer has no control over. Regardless of whether the terminate callback gets called, shared resources by definition live outside the process that allocates them. (This includes locally registered names, even though their allocation is done by the gen_server code and the freeing is implicit when the process dies.) In a multicore environment, this means that the freeing is not instantaneous, but can be handled by a thread on one CPU (and might not even be scheduled yet, or is waiting on a lock) while the supervisor is running in another thread on another CPU and has already proceeded to try to restart the worker, which will fail since there is currently no mimimum delay at all between attemtps and the limit is reached before the freeing thread has had time to run. In some cases (ethernet, locks, database transactions, ...) a simple delay and retry is the best solution, and I think supervision is such a case. In order to solve it in the user code, you'd have to program very defensively and make sure to implement your own retry loops for each point in the code where you try to grab a resource. That's not the "let it crash" way (and you'd still be solving the problem by sleeping). It's also nice to be able to see the occurrence of such repeated attempts in the logs, which lets you locate the issues and see if you can do something to avoid them. Definitely better than seeing a row of 100 failed restarts all with the same timestamp, after which the supervisor gave up and the node died. Of course it is sensitive to make changes in the supervisor code, so this change obviously needs proper reviewing and testing, but hopefully, it will then "just work" and solve this basic restart issue for all users forever. While it is being evaluated, one could set the default upper limit for delays to zero, so that supervisors in existing code behave exactly as before; with the supervisor proplists patch I posted, it would then be possible to activate delayed restarts on selected supervisors in new code. Eventually, you could change this to make delayed restarts (with some tried and trusted back-off parameters) be the default in OTP. /Richard From uwe@REDACTED Fri Jan 6 19:41:28 2012 From: uwe@REDACTED (Uwe Dauernheim) Date: Fri, 6 Jan 2012 19:41:28 +0100 Subject: [erlang-patches] Redirect compiler output to stderr (standard_error) were appropriate In-Reply-To: References: Message-ID: Hej, currently it is not possible to separate informative output from warnings and errors without parsing the compiler return value yourself, which might lead to inconsistent output formats. Furthermore, tools like Rebar that call the Erlang compiler can't provide this separation either without the same disadvantages. This patch redirects compile warnings and errors from various tools (compiler, eunit, escript, cover) to stderr (standard_error) to allow a stream output separation and to suppress informative output. git fetch git://github.com/djui/otp.git stderr-for-compile-errors https://github.com/djui/otp/compare/stderr-for-compile-errors https://github.com/djui/otp/compare/stderr-for-compile-errors.patch /Uwe From uwe@REDACTED Fri Jan 6 19:36:00 2012 From: uwe@REDACTED (Uwe Dauernheim) Date: Fri, 6 Jan 2012 19:36:00 +0100 Subject: [erlang-patches] Redirect compiler output to stderr (standard_error) were appropriate Message-ID: Hej, currently it is not possible to separate informative output from warnings and errors without parsing the compiler return value yourself, which might lead to inconsistent output formats. Furthermore, tools like Rebar that call the Erlang compiler can't provide this separation either without the same disadvantages. This patch redirects compile warnings and errors from various tools (compiler, eunit, escript, cover) to stderr (standard_error) to allow a stream output separation and to suppress informative output. git fetch git://github.com/djui/otp.git stderr-for-compile-errors https://github.com/djui/otp/compare/stderr-for-compile-errors https://github.com/djui/otp/compare/stderr-for-compile-errors.patch /Uwe From pguyot@REDACTED Sat Jan 7 11:48:25 2012 From: pguyot@REDACTED (Paul Guyot) Date: Sat, 7 Jan 2012 11:48:25 +0100 Subject: [erlang-patches] Extend erlang:port_info/1, 2 to show the OS pid of a spawned process Message-ID: Hello, The above-mentioned patch was submitted by Matthias Lang in August 2010. It has been cooking in pu and was dropped in January 2011. I could not find in archives any discussion about why it was dropped. http://erlang.org/pipermail/erlang-patches/2010-August/001311.html http://erlang.org/pipermail/erlang-patches/2010-August/001313.html http://erlang.org/pipermail/erlang-patches/2011-January/001828.html This patch proves very useful to us and we have been using it for more than a year on production servers running FreeBSD as well as development machines running MacOS X (Matthias mentions he tested it on Linux). Could you please re-consider it? To ease the inclusion of the patch, I did update it to base it on master, added documentation, updated types, and fixed dialyzer's test accordingly. (I am not sure if master is the proper base for this case). You can fetch the updated version from github: git fetch git://github.com/pguyot/otp.git add-os-pid-to-port-info https://github.com/pguyot/otp/commit/1acd27e159506b662f3b4222ba4c5820b463588a Regards, Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From henrik@REDACTED Mon Jan 9 11:01:46 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 9 Jan 2012 11:01:46 +0100 Subject: [erlang-patches] Extend erlang:port_info/1, 2 to show the OS pid of a spawned process In-Reply-To: References: Message-ID: <4F0ABB0A.4070003@erlang.org> Hmm yes this is strange. according to my notes about the patch, we are waiting for tests and documentation for this. But I can not find a email asking for it, but I do find it to be in the dropped patches list. on the other hand, I was not working here when this all happened, and the person who did is not working here now. So back to the patch, I will consider it if someone is willing to add tests and documentation for it. Unless it was dropped due to other reasons than missing tests/docs. On 01/07/2012 11:48 AM, Paul Guyot wrote: > Hello, > > The above-mentioned patch was submitted by Matthias Lang in August 2010. > It has been cooking in pu and was dropped in January 2011. I could not find in archives any discussion about why it was dropped. > > http://erlang.org/pipermail/erlang-patches/2010-August/001311.html > http://erlang.org/pipermail/erlang-patches/2010-August/001313.html > http://erlang.org/pipermail/erlang-patches/2011-January/001828.html > > This patch proves very useful to us and we have been using it for more than a year on production servers running FreeBSD as well as development machines running MacOS X (Matthias mentions he tested it on Linux). > > Could you please re-consider it? > > To ease the inclusion of the patch, I did update it to base it on master, added documentation, updated types, and fixed dialyzer's test accordingly. (I am not sure if master is the proper base for this case). > > You can fetch the updated version from github: > > git fetch git://github.com/pguyot/otp.git add-os-pid-to-port-info > https://github.com/pguyot/otp/commit/1acd27e159506b662f3b4222ba4c5820b463588a > > Regards, > > Paul -- /Henrik Nord Erlang/OTP From pguyot@REDACTED Mon Jan 9 12:07:27 2012 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 9 Jan 2012 12:07:27 +0100 Subject: [erlang-patches] Extend erlang:port_info/1, 2 to show the OS pid of a spawned process In-Reply-To: <4F0ABB0A.4070003@erlang.org> References: <4F0ABB0A.4070003@erlang.org> Message-ID: <275F49D5-2BDC-4990-B40E-6DA9D3D9C2E5@kallisys.net> Le 9 janv. 2012 ? 11:01, Henrik Nord a ?crit : > Hmm yes this is strange. > according to my notes about the patch, we are waiting for tests and documentation for this. > > But I can not find a email asking for it, but I do find it to be in the dropped patches list. > on the other hand, I was not working here when this all happened, and the person who did is not working here now. > > So back to the patch, I will consider it if someone is willing to add tests and documentation for it. Unless it was dropped due to other reasons than missing tests/docs. I did add documentation and fixed dialyzer-related tests, but I could not find any test specifically on erlang:port_info/1,2. Where would you like me to add such a test? Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From henrik@REDACTED Mon Jan 9 14:40:17 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 9 Jan 2012 14:40:17 +0100 Subject: [erlang-patches] Extend erlang:port_info/1, 2 to show the OS pid of a spawned process In-Reply-To: <275F49D5-2BDC-4990-B40E-6DA9D3D9C2E5@kallisys.net> References: <4F0ABB0A.4070003@erlang.org> <275F49D5-2BDC-4990-B40E-6DA9D3D9C2E5@kallisys.net> Message-ID: <4F0AEE41.9040301@erlang.org> erts/emulator/test/port_bif_SUITE.erl There is tests for port_info in here. On 01/09/2012 12:07 PM, Paul Guyot wrote: > Le 9 janv. 2012 ? 11:01, Henrik Nord a ?crit : > >> Hmm yes this is strange. >> according to my notes about the patch, we are waiting for tests and documentation for this. >> >> But I can not find a email asking for it, but I do find it to be in the dropped patches list. >> on the other hand, I was not working here when this all happened, and the person who did is not working here now. >> >> So back to the patch, I will consider it if someone is willing to add tests and documentation for it. Unless it was dropped due to other reasons than missing tests/docs. > I did add documentation and fixed dialyzer-related tests, but I could not find any test specifically on erlang:port_info/1,2. > Where would you like me to add such a test? > > Paul -- /Henrik Nord Erlang/OTP From pguyot@REDACTED Mon Jan 9 15:21:31 2012 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 9 Jan 2012 15:21:31 +0100 Subject: [erlang-patches] Extend erlang:port_info/1, 2 to show the OS pid of a spawned process In-Reply-To: <4F0AEE41.9040301@erlang.org> References: <4F0ABB0A.4070003@erlang.org> <275F49D5-2BDC-4990-B40E-6DA9D3D9C2E5@kallisys.net> <4F0AEE41.9040301@erlang.org> Message-ID: Le 9 janv. 2012 ? 14:40, Henrik Nord a ?crit : > erts/emulator/test/port_bif_SUITE.erl > > There is tests for port_info in here. Thank you. You will find a test for this feature here: git fetch git://github.com/pguyot/otp.git add-os-pid-to-port-info https://github.com/pguyot/otp/commit/336d1d1d65fa7d75ebe6341a9aa2b7966a8e8052 As I simply amended the commit, the patch is still limited to a single commit. Please let me know if you need anything else to consider this patch for inclusion. Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From erlangsiri@REDACTED Wed Jan 11 11:45:42 2012 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 11 Jan 2012 11:45:42 +0100 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> Message-ID: Sorry for the delay, but finally I have had a look at this.... As far as I can see the empty list used as default for #application.start_phase in systools.hrl will *never* come out in a real instance of the #application record. The fields of this record gets its values in systools_make:parse_application/4 (from get_items/2 -> check_item/2) - which will give the start_phases field the value 'undefined' if there is no start_phases entry in the .app file. The only way start_phases can get the value [] here is if there is a {start_phases,[]} entry in the .app file, but this has nothing to do with the default value. I agree of course that systools.hrl is a bit misleading by stating a default value which is never used... reltool_server on the other hand does use the default value from reltool.hrl file when parsing - but (and this might be the real bug) reltool_target does the opposite operation - i.e. it takes information from #app_info records and generates app specifications where it takes the value of the start_phases field in the record and inserts it directly as a {start_phases,Phases} entry in the app specification. It then seems like this is written to a .app file during target installation. I am not 100% sure of this (and why), so any objections would be good... But anyway, if this is the case - there might be .app files containing {start_phases,undefined} in the target installation from reltool... And this can never be parsed by systools!!! Could this be what happens in your case, Juan? If so, I think the best correction of this would be to let reltool_target insert a {start_phases,Phases} entry in the app specification only if Phases=/=undefined... What do you think? Regards /siri 2012/1/5 Ulf Wiger > > I would suggest that the special handling of {start_phases, undefined} be > removed, and documentation updated accordingly. > > But this is a decision that OTP will have to make. > > BR, > Ulf W > > On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote: > > > Would it be an option to modify the function that validates the value > > assigned to 'start_phases' so that 'undefined' is considered an > > acceptable value? The relevant line is: > > > > > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 > > > > Juanjo > > > > > > On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger wrote: > >> > >> Not my call. > >> > >> I can well understand if the reasons behind the special treatment of > 'start_phases' have been forgotten by those maintaining the code. > >> > >> A closer analysis might reveal whether backward compatibility has > already been sufficiently compromised that it is now time to Make It Right > (?). > >> > >> Even the old AXD 301 project, for which the oddity was introduced in > the first place, took the first opportunity to make the code fully > compatible with the new semantics. > >> > >> BR, > >> Ulf W > >> > >> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: > >> > >>> I can make the change and add it to the branch I created, but the > >>> question is: should I? I'm not really that well informed about the > >>> history of this value. All I can say is that the parts that care about > >>> the 'start_phases' entry in reltool and systools assume that it will > >>> be an empty list when it is not set and fail otherwise. > >>> > >>> Let me know if I have to modify my patch to make it acceptable for > >>> inclusion in OTP. > >>> > >>> Juanjo > >>> > >>> > >>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger wrote: > >>>> > >>>> Hmm, there's an old catch here. Someone will have to hollar if it is > no > >>>> longer relevant - but if it isn't, some documentation patch is called > for. > >>>> > >>>> In > http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 > >>>> > >>>> StartType defines the type of start: > >>>> > >>>> normal if it's a normal startup. > >>>> normal also if the application is distributed and started at the > current > >>>> node due to a failover from another node, and the application > specification > >>>> key start_phases == undefined. > >>>> {takeover,Node} if the application is distributed and started at the > current > >>>> node due to a takeover from Node, either because > application:takeover/2 has > >>>> been called or because the current node has higher priority than Node. > >>>> {failover,Node} if the application is distributed and started at the > current > >>>> node due to a failover from Node, and the application specification > >>>> key start_phases /= undefined. > >>>> > >>>> Note that StartType = {failover, Node} is only used if start_phases /= > >>>> undefined. I will guess that it is for this reason that start_phases > is > >>>> actually set to undefined as default. If it isn't, it was a happy > >>>> coincidence, since it actually preserves backward compatibility. > >>>> > >>>> This particular oddity was introduced many years ago, in the 90s - > possibly > >>>> even before Erlang was released as Open Source, so the legacy > argument may > >>>> not be that relevant. > >>>> > >>>> OTOH, I don't think many people use the start_phases attribute, so > even new > >>>> code might break if the Mod:start/2 function is suddenly called with a > >>>> StartType that was never seen before. > >>>> > >>>> BR, > >>>> Ulf W > >>>> > >>>> > >>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: > >>>> > >>>> The default value for 'start_phases' in .app files should be [], but > >>>> it is incorrectly set to 'undefined' when generating a release. This > >>>> happens when the original .app file does not set a value for > >>>> 'start_phases' explicitly. > >>>> > >>>> The reltool application defines its own copy of a record to handle > >>>> .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that > >>>> has different default values than the one used by systools > >>>> (#application{}, defined in lib/sasl/src/systools.hrl). In particular, > >>>> the 'start_phases' entry is assumed by all of OTP to be [] when it is > >>>> not explicitly set but reltool sets it to 'undefined' by default. This > >>>> causes badmatch errors when trying to generate release upgrades. > >>>> > >>>> Without this patch, all of the rebar examples that generate release > >>>> upgrades that I've found on the web will fail. The bug was introduced > >>>> in R14A. > >>>> > >>>> git fetch git://github.com/jcomellas/otp.gitjc-fix-default-start-phases > >>>> > >>>> Juanjo > >>>> _______________________________________________ > >>>> erlang-patches mailing list > >>>> erlang-patches@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-patches > >>>> > >>>> > >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanjo@REDACTED Wed Jan 11 18:42:52 2012 From: juanjo@REDACTED (Juan Jose Comellas) Date: Wed, 11 Jan 2012 14:42:52 -0300 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> Message-ID: Siri, what you mention is exactly what was happening. I did all my tests with rebar and what I experienced was that after performing a 'rebar generate' reltool creates all the .app files in the release with 'start_phases' set as 'undefined'. Here's an example: %% app generated at {2012,1,11} {14,17,10} {application,sasl, [{description,"SASL CXC 138 11"}, {vsn,"2.2"}, {id,[]}, {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, overload,rb,rb_format_supp,release_handler, release_handler_1,sasl,sasl_report,sasl_report_file_h, sasl_report_tty_h,si,si_sasl_supp,systools, systools_lib,systools_make,systools_rc, systools_relup]}, {registered,[sasl_sup,alarm_handler,overload,release_handler]}, {applications,[kernel,stdlib]}, {included_applications,[]}, {env,[{sasl_error_logger,tty},{errlog_type,all}]}, {start_phases,undefined}, {maxT,infinity}, {maxP,infinity}, {mod,{sasl,[]}}]}. The problem is that once you try to run 'rebar generate-upgrade' you get all kinds of badmatch errors because the function that validates the 'start_phases' entry in the generated .app files does not allow it to be set to 'undefined'. Here's the relevant line: https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 My thought was to set the 'start_phases' field to [] by default in the #app_info record (in lib/reltool/src/reltool.hrl) to avoid this problem. What you proposed (not adding the 'start_phases' entry if it is set to 'undefined') is equally valid. Also, another option would be to allow 'undefined' to be a valid value in the line I referenced from Github above. This seems to have been broken for over a year, and from what I can see it was impossible to automatically generate releases and release upgrades without triggering this error (at least with rebar). Juanjo On Wed, Jan 11, 2012 at 7:45 AM, Siri Hansen wrote: > Sorry for the delay, but finally I have had a look at this.... > > As far as I can see the empty list used as default > for?#application.start_phase?in systools.hrl will *never* come out in a real > instance of the #application record. The fields of this record gets its > values in systools_make:parse_application/4 ?(from get_items/2 -> > check_item/2) - which will give the start_phases field the value 'undefined' > if there is no start_phases entry in the .app file. The only way > start_phases can get the value [] here is if there is a {start_phases,[]} > entry in the .app file, but this has nothing to do with the default value. > > I agree of course that systools.hrl is a bit misleading by stating a default > value which is never used... > > reltool_server on the other hand does use the default value from reltool.hrl > file when parsing - but (and this might be the real bug) reltool_target does > the opposite operation - i.e. it takes information from #app_info records > and generates app specifications where it takes the value of the > start_phases field in the record and inserts it directly as a > {start_phases,Phases} entry in the app specification. It then seems like > this is written to a .app file during target installation. I am not 100% > sure of this (and why), so any objections would be good... But anyway, if > this is the case - there might be .app files containing > {start_phases,undefined} in the target installation from reltool... And this > can never be parsed by systools!!! > > Could this be what happens in your case, Juan? > > If so, I think the best correction of this would be to let reltool_target > insert a {start_phases,Phases} entry in the app specification only if > Phases=/=undefined... What do you think? > > Regards > /siri > > > > 2012/1/5 Ulf Wiger >> >> >> I would suggest that the special handling of {start_phases, undefined} be >> removed, and documentation updated accordingly. >> >> But this is a decision that OTP will have to make. >> >> BR, >> Ulf W >> >> On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote: >> >> > Would it be an option to modify the function that validates the value >> > assigned to 'start_phases' so that 'undefined' is considered an >> > acceptable value? The relevant line is: >> > >> > >> > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 >> > >> > Juanjo >> > >> > >> > On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger wrote: >> >> >> >> Not my call. >> >> >> >> I can well understand if the reasons behind the special treatment of >> >> 'start_phases' have been forgotten by those maintaining the code. >> >> >> >> A closer analysis might reveal whether backward compatibility has >> >> already been sufficiently compromised that it is now time to Make It Right >> >> (?). >> >> >> >> Even the old AXD 301 project, for which the oddity was introduced in >> >> the first place, took the first opportunity to make the code fully >> >> compatible with the new semantics. >> >> >> >> BR, >> >> Ulf W >> >> >> >> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: >> >> >> >>> I can make the change and add it to the branch I created, but the >> >>> question is: should I? I'm not really that well informed about the >> >>> history of this value. All I can say is that the parts that care about >> >>> the 'start_phases' entry in reltool and systools assume that it will >> >>> be an empty list when it is not set and fail otherwise. >> >>> >> >>> Let me know if I have to modify my patch to make it acceptable for >> >>> inclusion in OTP. >> >>> >> >>> Juanjo >> >>> >> >>> >> >>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger wrote: >> >>>> >> >>>> Hmm, there's an old catch here. Someone will have to hollar if it is >> >>>> no >> >>>> longer relevant - but if it isn't, some documentation patch is called >> >>>> for. >> >>>> >> >>>> In >> >>>> http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 >> >>>> >> >>>> StartType defines the type of start: >> >>>> >> >>>> normal if it's a normal startup. >> >>>> normal also if the application is distributed and started at the >> >>>> current >> >>>> node due to a failover from another node, and the application >> >>>> specification >> >>>> key start_phases == undefined. >> >>>> {takeover,Node} if the application is distributed and started at the >> >>>> current >> >>>> node due to a takeover from Node, either because >> >>>> application:takeover/2 has >> >>>> been called or because the current node has higher priority than >> >>>> Node. >> >>>> {failover,Node} if the application is distributed and started at the >> >>>> current >> >>>> node due to a failover from Node, and the application specification >> >>>> key start_phases /= undefined. >> >>>> >> >>>> Note that StartType = {failover, Node} is only used if start_phases >> >>>> /= >> >>>> undefined. I will guess that it is for this reason that start_phases >> >>>> is >> >>>> actually set to undefined as default. If it isn't, it was a happy >> >>>> coincidence, since it actually preserves backward compatibility. >> >>>> >> >>>> This particular oddity was introduced many years ago, in the 90s - >> >>>> possibly >> >>>> even before Erlang was released as Open Source, so the legacy >> >>>> argument may >> >>>> not be that relevant. >> >>>> >> >>>> OTOH, I don't think many people use the start_phases attribute, so >> >>>> even new >> >>>> code might break if the Mod:start/2 function is suddenly called with >> >>>> a >> >>>> StartType that was never seen before. >> >>>> >> >>>> BR, >> >>>> Ulf W >> >>>> >> >>>> >> >>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: >> >>>> >> >>>> The default value for 'start_phases' in .app files should be [], but >> >>>> it is incorrectly set to 'undefined' when generating a release. This >> >>>> happens when the original .app file does not set a value for >> >>>> 'start_phases' explicitly. >> >>>> >> >>>> The reltool application defines its own copy of a record to handle >> >>>> .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that >> >>>> has different default values than the one used by systools >> >>>> (#application{}, defined in lib/sasl/src/systools.hrl). In >> >>>> particular, >> >>>> the 'start_phases' entry is assumed by all of OTP to be [] when it is >> >>>> not explicitly set but reltool sets it to 'undefined' by default. >> >>>> This >> >>>> causes badmatch errors when trying to generate release upgrades. >> >>>> >> >>>> Without this patch, all of the rebar examples that generate release >> >>>> upgrades that I've found on the web will fail. The bug was introduced >> >>>> in R14A. >> >>>> >> >>>> git fetch git://github.com/jcomellas/otp.git >> >>>> jc-fix-default-start-phases >> >>>> >> >>>> Juanjo >> >>>> _______________________________________________ >> >>>> erlang-patches mailing list >> >>>> erlang-patches@REDACTED >> >>>> http://erlang.org/mailman/listinfo/erlang-patches >> >>>> >> >>>> >> >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > From erlangsiri@REDACTED Thu Jan 12 09:58:42 2012 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 12 Jan 2012 09:58:42 +0100 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> Message-ID: Ok, thanks! Then I think that we will go for the solution where reltool_target:gen_app does not add the start_phases entry if #app_info.start_phases==undefined. And the default value for #app_info.start_phases shall still be 'undefined'. This will keep the backwards compatibility. Will you do the change, Juan? Regards /siri 2012/1/11 Juan Jose Comellas > Siri, what you mention is exactly what was happening. I did all my > tests with rebar and what I experienced was that after performing a > 'rebar generate' reltool creates all the .app files in the release > with 'start_phases' set as 'undefined'. Here's an example: > > %% app generated at {2012,1,11} {14,17,10} > {application,sasl, > [{description,"SASL CXC 138 11"}, > {vsn,"2.2"}, > {id,[]}, > {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, > overload,rb,rb_format_supp,release_handler, > > release_handler_1,sasl,sasl_report,sasl_report_file_h, > sasl_report_tty_h,si,si_sasl_supp,systools, > systools_lib,systools_make,systools_rc, > systools_relup]}, > > {registered,[sasl_sup,alarm_handler,overload,release_handler]}, > {applications,[kernel,stdlib]}, > {included_applications,[]}, > {env,[{sasl_error_logger,tty},{errlog_type,all}]}, > {start_phases,undefined}, > {maxT,infinity}, > {maxP,infinity}, > {mod,{sasl,[]}}]}. > > The problem is that once you try to run 'rebar generate-upgrade' you > get all kinds of badmatch errors because the function that validates > the 'start_phases' entry in the generated .app files does not allow it > to be set to 'undefined'. Here's the relevant line: > > > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 > > My thought was to set the 'start_phases' field to [] by default in the > #app_info record (in lib/reltool/src/reltool.hrl) to avoid this > problem. What you proposed (not adding the 'start_phases' entry if it > is set to 'undefined') is equally valid. Also, another option would be > to allow 'undefined' to be a valid value in the line I referenced from > Github above. > > This seems to have been broken for over a year, and from what I can > see it was impossible to automatically generate releases and release > upgrades without triggering this error (at least with rebar). > > Juanjo > > > On Wed, Jan 11, 2012 at 7:45 AM, Siri Hansen wrote: > > Sorry for the delay, but finally I have had a look at this.... > > > > As far as I can see the empty list used as default > > for #application.start_phase in systools.hrl will *never* come out in a > real > > instance of the #application record. The fields of this record gets its > > values in systools_make:parse_application/4 (from get_items/2 -> > > check_item/2) - which will give the start_phases field the value > 'undefined' > > if there is no start_phases entry in the .app file. The only way > > start_phases can get the value [] here is if there is a {start_phases,[]} > > entry in the .app file, but this has nothing to do with the default > value. > > > > I agree of course that systools.hrl is a bit misleading by stating a > default > > value which is never used... > > > > reltool_server on the other hand does use the default value from > reltool.hrl > > file when parsing - but (and this might be the real bug) reltool_target > does > > the opposite operation - i.e. it takes information from #app_info records > > and generates app specifications where it takes the value of the > > start_phases field in the record and inserts it directly as a > > {start_phases,Phases} entry in the app specification. It then seems like > > this is written to a .app file during target installation. I am not 100% > > sure of this (and why), so any objections would be good... But anyway, if > > this is the case - there might be .app files containing > > {start_phases,undefined} in the target installation from reltool... And > this > > can never be parsed by systools!!! > > > > Could this be what happens in your case, Juan? > > > > If so, I think the best correction of this would be to let reltool_target > > insert a {start_phases,Phases} entry in the app specification only if > > Phases=/=undefined... What do you think? > > > > Regards > > /siri > > > > > > > > 2012/1/5 Ulf Wiger > >> > >> > >> I would suggest that the special handling of {start_phases, undefined} > be > >> removed, and documentation updated accordingly. > >> > >> But this is a decision that OTP will have to make. > >> > >> BR, > >> Ulf W > >> > >> On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote: > >> > >> > Would it be an option to modify the function that validates the value > >> > assigned to 'start_phases' so that 'undefined' is considered an > >> > acceptable value? The relevant line is: > >> > > >> > > >> > > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 > >> > > >> > Juanjo > >> > > >> > > >> > On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger wrote: > >> >> > >> >> Not my call. > >> >> > >> >> I can well understand if the reasons behind the special treatment of > >> >> 'start_phases' have been forgotten by those maintaining the code. > >> >> > >> >> A closer analysis might reveal whether backward compatibility has > >> >> already been sufficiently compromised that it is now time to Make It > Right > >> >> (?). > >> >> > >> >> Even the old AXD 301 project, for which the oddity was introduced in > >> >> the first place, took the first opportunity to make the code fully > >> >> compatible with the new semantics. > >> >> > >> >> BR, > >> >> Ulf W > >> >> > >> >> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: > >> >> > >> >>> I can make the change and add it to the branch I created, but the > >> >>> question is: should I? I'm not really that well informed about the > >> >>> history of this value. All I can say is that the parts that care > about > >> >>> the 'start_phases' entry in reltool and systools assume that it will > >> >>> be an empty list when it is not set and fail otherwise. > >> >>> > >> >>> Let me know if I have to modify my patch to make it acceptable for > >> >>> inclusion in OTP. > >> >>> > >> >>> Juanjo > >> >>> > >> >>> > >> >>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger > wrote: > >> >>>> > >> >>>> Hmm, there's an old catch here. Someone will have to hollar if it > is > >> >>>> no > >> >>>> longer relevant - but if it isn't, some documentation patch is > called > >> >>>> for. > >> >>>> > >> >>>> In > >> >>>> > http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 > >> >>>> > >> >>>> StartType defines the type of start: > >> >>>> > >> >>>> normal if it's a normal startup. > >> >>>> normal also if the application is distributed and started at the > >> >>>> current > >> >>>> node due to a failover from another node, and the application > >> >>>> specification > >> >>>> key start_phases == undefined. > >> >>>> {takeover,Node} if the application is distributed and started at > the > >> >>>> current > >> >>>> node due to a takeover from Node, either because > >> >>>> application:takeover/2 has > >> >>>> been called or because the current node has higher priority than > >> >>>> Node. > >> >>>> {failover,Node} if the application is distributed and started at > the > >> >>>> current > >> >>>> node due to a failover from Node, and the application specification > >> >>>> key start_phases /= undefined. > >> >>>> > >> >>>> Note that StartType = {failover, Node} is only used if start_phases > >> >>>> /= > >> >>>> undefined. I will guess that it is for this reason that > start_phases > >> >>>> is > >> >>>> actually set to undefined as default. If it isn't, it was a happy > >> >>>> coincidence, since it actually preserves backward compatibility. > >> >>>> > >> >>>> This particular oddity was introduced many years ago, in the 90s - > >> >>>> possibly > >> >>>> even before Erlang was released as Open Source, so the legacy > >> >>>> argument may > >> >>>> not be that relevant. > >> >>>> > >> >>>> OTOH, I don't think many people use the start_phases attribute, so > >> >>>> even new > >> >>>> code might break if the Mod:start/2 function is suddenly called > with > >> >>>> a > >> >>>> StartType that was never seen before. > >> >>>> > >> >>>> BR, > >> >>>> Ulf W > >> >>>> > >> >>>> > >> >>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: > >> >>>> > >> >>>> The default value for 'start_phases' in .app files should be [], > but > >> >>>> it is incorrectly set to 'undefined' when generating a release. > This > >> >>>> happens when the original .app file does not set a value for > >> >>>> 'start_phases' explicitly. > >> >>>> > >> >>>> The reltool application defines its own copy of a record to handle > >> >>>> .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) > that > >> >>>> has different default values than the one used by systools > >> >>>> (#application{}, defined in lib/sasl/src/systools.hrl). In > >> >>>> particular, > >> >>>> the 'start_phases' entry is assumed by all of OTP to be [] when it > is > >> >>>> not explicitly set but reltool sets it to 'undefined' by default. > >> >>>> This > >> >>>> causes badmatch errors when trying to generate release upgrades. > >> >>>> > >> >>>> Without this patch, all of the rebar examples that generate release > >> >>>> upgrades that I've found on the web will fail. The bug was > introduced > >> >>>> in R14A. > >> >>>> > >> >>>> git fetch git://github.com/jcomellas/otp.git > >> >>>> jc-fix-default-start-phases > >> >>>> > >> >>>> Juanjo > >> >>>> _______________________________________________ > >> >>>> erlang-patches mailing list > >> >>>> erlang-patches@REDACTED > >> >>>> http://erlang.org/mailman/listinfo/erlang-patches > >> >>>> > >> >>>> > >> >> > >> > >> _______________________________________________ > >> erlang-patches mailing list > >> erlang-patches@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-patches > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Jan 12 10:24:31 2012 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 12 Jan 2012 10:24:31 +0100 Subject: [erlang-patches] delayed child restart with incremental back-off In-Reply-To: <4F05F4A1.9080407@gmail.com> References: <4F03875D.1020504@gmail.com> <4F03A4B5.2090404@gmail.com> <4F0431C5.9030300@gmail.com> <4F048C1D.9000905@gmail.com> <4F05F4A1.9080407@gmail.com> Message-ID: Hi Richard! Sorry for the long silence! We will discuss this on our next technical board meeting and get back to you with our decision as soon as possible. Regards /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimenezrick@REDACTED Thu Jan 12 13:25:15 2012 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Thu, 12 Jan 2012 13:25:15 +0100 Subject: [erlang-patches] Adds missing spaces in xmerl doc Message-ID: <20120112122515.GB2033@viper.local> Please fetch: git fetch git://github.com/jimenezrick/otp.git spaces-xmerl-doc Review here: https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:spaces-xmerl-doc https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:spaces-xmerl-doc.patch Regards -- Ricardo (http://r.untroubled.be/) From juanjo@REDACTED Thu Jan 12 20:30:35 2012 From: juanjo@REDACTED (Juan Jose Comellas) Date: Thu, 12 Jan 2012 16:30:35 -0300 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> Message-ID: Siri, I have made the change. You can review it here: https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases And you can fetch the changes with: git fetch git://github.com/jcomellas/otp.git jc-omit-undefined-start_phases I am recompiling the maint branch with this change and I intend to test generating a release upgrade with it, but it's going to take a while. Juanjo On Thu, Jan 12, 2012 at 5:58 AM, Siri Hansen wrote: > Ok, thanks! > Then I think that we will go for the solution where reltool_target:gen_app > does not add the start_phases entry if #app_info.start_phases==undefined. > And the default value for #app_info.start_phases shall still be 'undefined'. > This will keep the backwards compatibility. > > Will you do the change, Juan? > > Regards > /siri > > > 2012/1/11 Juan Jose Comellas >> >> Siri, what you mention is exactly what was happening. I did all my >> tests with rebar and what I experienced was that after performing a >> 'rebar generate' reltool creates all the .app files in the release >> with 'start_phases' set as 'undefined'. Here's an example: >> >> %% app generated at {2012,1,11} {14,17,10} >> {application,sasl, >> ? ? ? ? ? ? [{description,"SASL ?CXC 138 11"}, >> ? ? ? ? ? ? ?{vsn,"2.2"}, >> ? ? ? ? ? ? ?{id,[]}, >> ? ? ? ? ? ? ?{modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, >> ? ? ? ? ? ? ? ? ? ? ? ?overload,rb,rb_format_supp,release_handler, >> >> ?release_handler_1,sasl,sasl_report,sasl_report_file_h, >> ? ? ? ? ? ? ? ? ? ? ? ?sasl_report_tty_h,si,si_sasl_supp,systools, >> ? ? ? ? ? ? ? ? ? ? ? ?systools_lib,systools_make,systools_rc, >> ? ? ? ? ? ? ? ? ? ? ? ?systools_relup]}, >> >> ?{registered,[sasl_sup,alarm_handler,overload,release_handler]}, >> ? ? ? ? ? ? ?{applications,[kernel,stdlib]}, >> ? ? ? ? ? ? ?{included_applications,[]}, >> ? ? ? ? ? ? ?{env,[{sasl_error_logger,tty},{errlog_type,all}]}, >> ? ? ? ? ? ? ?{start_phases,undefined}, >> ? ? ? ? ? ? ?{maxT,infinity}, >> ? ? ? ? ? ? ?{maxP,infinity}, >> ? ? ? ? ? ? ?{mod,{sasl,[]}}]}. >> >> The problem is that once you try to run 'rebar generate-upgrade' you >> get all kinds of badmatch errors because the function that validates >> the 'start_phases' entry in the generated .app files does not allow it >> to be set to 'undefined'. Here's the relevant line: >> >> >> https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 >> >> My thought was to set the 'start_phases' field to [] by default in the >> #app_info record (in lib/reltool/src/reltool.hrl) to avoid this >> problem. What you proposed (not adding ?the 'start_phases' entry if it >> is set to 'undefined') is equally valid. Also, another option would be >> to allow 'undefined' to be a valid value in the line I referenced from >> Github above. >> >> This seems to have been broken for over a year, and from what I can >> see it was impossible to automatically generate releases and release >> upgrades without triggering this error (at least with rebar). >> >> Juanjo >> >> >> On Wed, Jan 11, 2012 at 7:45 AM, Siri Hansen wrote: >> > Sorry for the delay, but finally I have had a look at this.... >> > >> > As far as I can see the empty list used as default >> > for?#application.start_phase?in systools.hrl will *never* come out in a >> > real >> > instance of the #application record. The fields of this record gets its >> > values in systools_make:parse_application/4 ?(from get_items/2 -> >> > check_item/2) - which will give the start_phases field the value >> > 'undefined' >> > if there is no start_phases entry in the .app file. The only way >> > start_phases can get the value [] here is if there is a >> > {start_phases,[]} >> > entry in the .app file, but this has nothing to do with the default >> > value. >> > >> > I agree of course that systools.hrl is a bit misleading by stating a >> > default >> > value which is never used... >> > >> > reltool_server on the other hand does use the default value from >> > reltool.hrl >> > file when parsing - but (and this might be the real bug) reltool_target >> > does >> > the opposite operation - i.e. it takes information from #app_info >> > records >> > and generates app specifications where it takes the value of the >> > start_phases field in the record and inserts it directly as a >> > {start_phases,Phases} entry in the app specification. It then seems like >> > this is written to a .app file during target installation. I am not 100% >> > sure of this (and why), so any objections would be good... But anyway, >> > if >> > this is the case - there might be .app files containing >> > {start_phases,undefined} in the target installation from reltool... And >> > this >> > can never be parsed by systools!!! >> > >> > Could this be what happens in your case, Juan? >> > >> > If so, I think the best correction of this would be to let >> > reltool_target >> > insert a {start_phases,Phases} entry in the app specification only if >> > Phases=/=undefined... What do you think? >> > >> > Regards >> > /siri >> > >> > >> > >> > 2012/1/5 Ulf Wiger >> >> >> >> >> >> I would suggest that the special handling of {start_phases, undefined} >> >> be >> >> removed, and documentation updated accordingly. >> >> >> >> But this is a decision that OTP will have to make. >> >> >> >> BR, >> >> Ulf W >> >> >> >> On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote: >> >> >> >> > Would it be an option to modify the function that validates the value >> >> > assigned to 'start_phases' so that 'undefined' is considered an >> >> > acceptable value? The relevant line is: >> >> > >> >> > >> >> > >> >> > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 >> >> > >> >> > Juanjo >> >> > >> >> > >> >> > On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger wrote: >> >> >> >> >> >> Not my call. >> >> >> >> >> >> I can well understand if the reasons behind the special treatment of >> >> >> 'start_phases' have been forgotten by those maintaining the code. >> >> >> >> >> >> A closer analysis might reveal whether backward compatibility has >> >> >> already been sufficiently compromised that it is now time to Make It >> >> >> Right >> >> >> (?). >> >> >> >> >> >> Even the old AXD 301 project, for which the oddity was introduced in >> >> >> the first place, took the first opportunity to make the code fully >> >> >> compatible with the new semantics. >> >> >> >> >> >> BR, >> >> >> Ulf W >> >> >> >> >> >> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: >> >> >> >> >> >>> I can make the change and add it to the branch I created, but the >> >> >>> question is: should I? I'm not really that well informed about the >> >> >>> history of this value. All I can say is that the parts that care >> >> >>> about >> >> >>> the 'start_phases' entry in reltool and systools assume that it >> >> >>> will >> >> >>> be an empty list when it is not set and fail otherwise. >> >> >>> >> >> >>> Let me know if I have to modify my patch to make it acceptable for >> >> >>> inclusion in OTP. >> >> >>> >> >> >>> Juanjo >> >> >>> >> >> >>> >> >> >>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger >> >> >>> wrote: >> >> >>>> >> >> >>>> Hmm, there's an old catch here. Someone will have to hollar if it >> >> >>>> is >> >> >>>> no >> >> >>>> longer relevant - but if it isn't, some documentation patch is >> >> >>>> called >> >> >>>> for. >> >> >>>> >> >> >>>> In >> >> >>>> >> >> >>>> http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 >> >> >>>> >> >> >>>> StartType defines the type of start: >> >> >>>> >> >> >>>> normal if it's a normal startup. >> >> >>>> normal also if the application is distributed and started at the >> >> >>>> current >> >> >>>> node due to a failover from another node, and the application >> >> >>>> specification >> >> >>>> key start_phases == undefined. >> >> >>>> {takeover,Node} if the application is distributed and started at >> >> >>>> the >> >> >>>> current >> >> >>>> node due to a takeover from Node, either because >> >> >>>> application:takeover/2 has >> >> >>>> been called or because the current node has higher priority than >> >> >>>> Node. >> >> >>>> {failover,Node} if the application is distributed and started at >> >> >>>> the >> >> >>>> current >> >> >>>> node due to a failover from Node, and the application >> >> >>>> specification >> >> >>>> key start_phases /= undefined. >> >> >>>> >> >> >>>> Note that StartType = {failover, Node} is only used if >> >> >>>> start_phases >> >> >>>> /= >> >> >>>> undefined. I will guess that it is for this reason that >> >> >>>> start_phases >> >> >>>> is >> >> >>>> actually set to undefined as default. If it isn't, it was a happy >> >> >>>> coincidence, since it actually preserves backward compatibility. >> >> >>>> >> >> >>>> This particular oddity was introduced many years ago, in the 90s - >> >> >>>> possibly >> >> >>>> even before Erlang was released as Open Source, so the legacy >> >> >>>> argument may >> >> >>>> not be that relevant. >> >> >>>> >> >> >>>> OTOH, I don't think many people use the start_phases attribute, so >> >> >>>> even new >> >> >>>> code might break if the Mod:start/2 function is suddenly called >> >> >>>> with >> >> >>>> a >> >> >>>> StartType that was never seen before. >> >> >>>> >> >> >>>> BR, >> >> >>>> Ulf W >> >> >>>> >> >> >>>> >> >> >>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: >> >> >>>> >> >> >>>> The default value for 'start_phases' in .app files should be [], >> >> >>>> but >> >> >>>> it is incorrectly set to 'undefined' when generating a release. >> >> >>>> This >> >> >>>> happens when the original .app file does not set a value for >> >> >>>> 'start_phases' explicitly. >> >> >>>> >> >> >>>> The reltool application defines its own copy of a record to handle >> >> >>>> .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) >> >> >>>> that >> >> >>>> has different default values than the one used by systools >> >> >>>> (#application{}, defined in lib/sasl/src/systools.hrl). In >> >> >>>> particular, >> >> >>>> the 'start_phases' entry is assumed by all of OTP to be [] when it >> >> >>>> is >> >> >>>> not explicitly set but reltool sets it to 'undefined' by default. >> >> >>>> This >> >> >>>> causes badmatch errors when trying to generate release upgrades. >> >> >>>> >> >> >>>> Without this patch, all of the rebar examples that generate >> >> >>>> release >> >> >>>> upgrades that I've found on the web will fail. The bug was >> >> >>>> introduced >> >> >>>> in R14A. >> >> >>>> >> >> >>>> git fetch git://github.com/jcomellas/otp.git >> >> >>>> jc-fix-default-start-phases >> >> >>>> >> >> >>>> Juanjo >> >> >>>> _______________________________________________ >> >> >>>> erlang-patches mailing list >> >> >>>> erlang-patches@REDACTED >> >> >>>> http://erlang.org/mailman/listinfo/erlang-patches >> >> >>>> >> >> >>>> >> >> >> >> >> >> >> _______________________________________________ >> >> erlang-patches mailing list >> >> erlang-patches@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-patches >> > >> > > > From juanjo@REDACTED Thu Jan 12 20:55:58 2012 From: juanjo@REDACTED (Juan Jose Comellas) Date: Thu, 12 Jan 2012 16:55:58 -0300 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> Message-ID: Siri, I have compiled the maint branch with my change and tested generating a release using rebar. The .app file I sent as an example before now looks like this: %% app generated at {2012,1,12} {16,49,25} {application,sasl, [{description,"SASL CXC 138 11"}, {vsn,"2.2"}, {id,[]}, {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, overload,rb,rb_format_supp,release_handler, release_handler_1,sasl,sasl_report,sasl_report_file_h, sasl_report_tty_h,si,si_sasl_supp,systools, systools_lib,systools_make,systools_rc, systools_relup]}, {registered,[sasl_sup,alarm_handler,overload,release_handler]}, {applications,[kernel,stdlib]}, {included_applications,[]}, {env,[{sasl_error_logger,tty},{errlog_type,all}]}, {maxT,infinity}, {maxP,infinity}, {mod,{sasl,[]}}]}. You can see that now the .app file does not include the 'start_phases' entry. You can get this patch by running: git fetch git://github.com/jcomellas/otp.git jc-omit-undefined-start_phases Juanjo On Thu, Jan 12, 2012 at 4:30 PM, Juan Jose Comellas wrote: > Siri, I have made the change. You can review it here: > > https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases > > And you can fetch the changes with: > > git fetch git://github.com/jcomellas/otp.git jc-omit-undefined-start_phases > > I am recompiling the maint branch with this change and I intend to > test generating a release upgrade with it, but it's going to take a > while. > > Juanjo > > > On Thu, Jan 12, 2012 at 5:58 AM, Siri Hansen wrote: >> Ok, thanks! >> Then I think that we will go for the solution where reltool_target:gen_app >> does not add the start_phases entry if #app_info.start_phases==undefined. >> And the default value for #app_info.start_phases shall still be 'undefined'. >> This will keep the backwards compatibility. >> >> Will you do the change, Juan? >> >> Regards >> /siri >> >> >> 2012/1/11 Juan Jose Comellas >>> >>> Siri, what you mention is exactly what was happening. I did all my >>> tests with rebar and what I experienced was that after performing a >>> 'rebar generate' reltool creates all the .app files in the release >>> with 'start_phases' set as 'undefined'. Here's an example: >>> >>> %% app generated at {2012,1,11} {14,17,10} >>> {application,sasl, >>> ? ? ? ? ? ? [{description,"SASL ?CXC 138 11"}, >>> ? ? ? ? ? ? ?{vsn,"2.2"}, >>> ? ? ? ? ? ? ?{id,[]}, >>> ? ? ? ? ? ? ?{modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, >>> ? ? ? ? ? ? ? ? ? ? ? ?overload,rb,rb_format_supp,release_handler, >>> >>> ?release_handler_1,sasl,sasl_report,sasl_report_file_h, >>> ? ? ? ? ? ? ? ? ? ? ? ?sasl_report_tty_h,si,si_sasl_supp,systools, >>> ? ? ? ? ? ? ? ? ? ? ? ?systools_lib,systools_make,systools_rc, >>> ? ? ? ? ? ? ? ? ? ? ? ?systools_relup]}, >>> >>> ?{registered,[sasl_sup,alarm_handler,overload,release_handler]}, >>> ? ? ? ? ? ? ?{applications,[kernel,stdlib]}, >>> ? ? ? ? ? ? ?{included_applications,[]}, >>> ? ? ? ? ? ? ?{env,[{sasl_error_logger,tty},{errlog_type,all}]}, >>> ? ? ? ? ? ? ?{start_phases,undefined}, >>> ? ? ? ? ? ? ?{maxT,infinity}, >>> ? ? ? ? ? ? ?{maxP,infinity}, >>> ? ? ? ? ? ? ?{mod,{sasl,[]}}]}. >>> >>> The problem is that once you try to run 'rebar generate-upgrade' you >>> get all kinds of badmatch errors because the function that validates >>> the 'start_phases' entry in the generated .app files does not allow it >>> to be set to 'undefined'. Here's the relevant line: >>> >>> >>> https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 >>> >>> My thought was to set the 'start_phases' field to [] by default in the >>> #app_info record (in lib/reltool/src/reltool.hrl) to avoid this >>> problem. What you proposed (not adding ?the 'start_phases' entry if it >>> is set to 'undefined') is equally valid. Also, another option would be >>> to allow 'undefined' to be a valid value in the line I referenced from >>> Github above. >>> >>> This seems to have been broken for over a year, and from what I can >>> see it was impossible to automatically generate releases and release >>> upgrades without triggering this error (at least with rebar). >>> >>> Juanjo >>> >>> >>> On Wed, Jan 11, 2012 at 7:45 AM, Siri Hansen wrote: >>> > Sorry for the delay, but finally I have had a look at this.... >>> > >>> > As far as I can see the empty list used as default >>> > for?#application.start_phase?in systools.hrl will *never* come out in a >>> > real >>> > instance of the #application record. The fields of this record gets its >>> > values in systools_make:parse_application/4 ?(from get_items/2 -> >>> > check_item/2) - which will give the start_phases field the value >>> > 'undefined' >>> > if there is no start_phases entry in the .app file. The only way >>> > start_phases can get the value [] here is if there is a >>> > {start_phases,[]} >>> > entry in the .app file, but this has nothing to do with the default >>> > value. >>> > >>> > I agree of course that systools.hrl is a bit misleading by stating a >>> > default >>> > value which is never used... >>> > >>> > reltool_server on the other hand does use the default value from >>> > reltool.hrl >>> > file when parsing - but (and this might be the real bug) reltool_target >>> > does >>> > the opposite operation - i.e. it takes information from #app_info >>> > records >>> > and generates app specifications where it takes the value of the >>> > start_phases field in the record and inserts it directly as a >>> > {start_phases,Phases} entry in the app specification. It then seems like >>> > this is written to a .app file during target installation. I am not 100% >>> > sure of this (and why), so any objections would be good... But anyway, >>> > if >>> > this is the case - there might be .app files containing >>> > {start_phases,undefined} in the target installation from reltool... And >>> > this >>> > can never be parsed by systools!!! >>> > >>> > Could this be what happens in your case, Juan? >>> > >>> > If so, I think the best correction of this would be to let >>> > reltool_target >>> > insert a {start_phases,Phases} entry in the app specification only if >>> > Phases=/=undefined... What do you think? >>> > >>> > Regards >>> > /siri >>> > >>> > >>> > >>> > 2012/1/5 Ulf Wiger >>> >> >>> >> >>> >> I would suggest that the special handling of {start_phases, undefined} >>> >> be >>> >> removed, and documentation updated accordingly. >>> >> >>> >> But this is a decision that OTP will have to make. >>> >> >>> >> BR, >>> >> Ulf W >>> >> >>> >> On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote: >>> >> >>> >> > Would it be an option to modify the function that validates the value >>> >> > assigned to 'start_phases' so that 'undefined' is considered an >>> >> > acceptable value? The relevant line is: >>> >> > >>> >> > >>> >> > >>> >> > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 >>> >> > >>> >> > Juanjo >>> >> > >>> >> > >>> >> > On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger wrote: >>> >> >> >>> >> >> Not my call. >>> >> >> >>> >> >> I can well understand if the reasons behind the special treatment of >>> >> >> 'start_phases' have been forgotten by those maintaining the code. >>> >> >> >>> >> >> A closer analysis might reveal whether backward compatibility has >>> >> >> already been sufficiently compromised that it is now time to Make It >>> >> >> Right >>> >> >> (?). >>> >> >> >>> >> >> Even the old AXD 301 project, for which the oddity was introduced in >>> >> >> the first place, took the first opportunity to make the code fully >>> >> >> compatible with the new semantics. >>> >> >> >>> >> >> BR, >>> >> >> Ulf W >>> >> >> >>> >> >> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: >>> >> >> >>> >> >>> I can make the change and add it to the branch I created, but the >>> >> >>> question is: should I? I'm not really that well informed about the >>> >> >>> history of this value. All I can say is that the parts that care >>> >> >>> about >>> >> >>> the 'start_phases' entry in reltool and systools assume that it >>> >> >>> will >>> >> >>> be an empty list when it is not set and fail otherwise. >>> >> >>> >>> >> >>> Let me know if I have to modify my patch to make it acceptable for >>> >> >>> inclusion in OTP. >>> >> >>> >>> >> >>> Juanjo >>> >> >>> >>> >> >>> >>> >> >>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger >>> >> >>> wrote: >>> >> >>>> >>> >> >>>> Hmm, there's an old catch here. Someone will have to hollar if it >>> >> >>>> is >>> >> >>>> no >>> >> >>>> longer relevant - but if it isn't, some documentation patch is >>> >> >>>> called >>> >> >>>> for. >>> >> >>>> >>> >> >>>> In >>> >> >>>> >>> >> >>>> http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 >>> >> >>>> >>> >> >>>> StartType defines the type of start: >>> >> >>>> >>> >> >>>> normal if it's a normal startup. >>> >> >>>> normal also if the application is distributed and started at the >>> >> >>>> current >>> >> >>>> node due to a failover from another node, and the application >>> >> >>>> specification >>> >> >>>> key start_phases == undefined. >>> >> >>>> {takeover,Node} if the application is distributed and started at >>> >> >>>> the >>> >> >>>> current >>> >> >>>> node due to a takeover from Node, either because >>> >> >>>> application:takeover/2 has >>> >> >>>> been called or because the current node has higher priority than >>> >> >>>> Node. >>> >> >>>> {failover,Node} if the application is distributed and started at >>> >> >>>> the >>> >> >>>> current >>> >> >>>> node due to a failover from Node, and the application >>> >> >>>> specification >>> >> >>>> key start_phases /= undefined. >>> >> >>>> >>> >> >>>> Note that StartType = {failover, Node} is only used if >>> >> >>>> start_phases >>> >> >>>> /= >>> >> >>>> undefined. I will guess that it is for this reason that >>> >> >>>> start_phases >>> >> >>>> is >>> >> >>>> actually set to undefined as default. If it isn't, it was a happy >>> >> >>>> coincidence, since it actually preserves backward compatibility. >>> >> >>>> >>> >> >>>> This particular oddity was introduced many years ago, in the 90s - >>> >> >>>> possibly >>> >> >>>> even before Erlang was released as Open Source, so the legacy >>> >> >>>> argument may >>> >> >>>> not be that relevant. >>> >> >>>> >>> >> >>>> OTOH, I don't think many people use the start_phases attribute, so >>> >> >>>> even new >>> >> >>>> code might break if the Mod:start/2 function is suddenly called >>> >> >>>> with >>> >> >>>> a >>> >> >>>> StartType that was never seen before. >>> >> >>>> >>> >> >>>> BR, >>> >> >>>> Ulf W >>> >> >>>> >>> >> >>>> >>> >> >>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: >>> >> >>>> >>> >> >>>> The default value for 'start_phases' in .app files should be [], >>> >> >>>> but >>> >> >>>> it is incorrectly set to 'undefined' when generating a release. >>> >> >>>> This >>> >> >>>> happens when the original .app file does not set a value for >>> >> >>>> 'start_phases' explicitly. >>> >> >>>> >>> >> >>>> The reltool application defines its own copy of a record to handle >>> >> >>>> .app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) >>> >> >>>> that >>> >> >>>> has different default values than the one used by systools >>> >> >>>> (#application{}, defined in lib/sasl/src/systools.hrl). In >>> >> >>>> particular, >>> >> >>>> the 'start_phases' entry is assumed by all of OTP to be [] when it >>> >> >>>> is >>> >> >>>> not explicitly set but reltool sets it to 'undefined' by default. >>> >> >>>> This >>> >> >>>> causes badmatch errors when trying to generate release upgrades. >>> >> >>>> >>> >> >>>> Without this patch, all of the rebar examples that generate >>> >> >>>> release >>> >> >>>> upgrades that I've found on the web will fail. The bug was >>> >> >>>> introduced >>> >> >>>> in R14A. >>> >> >>>> >>> >> >>>> git fetch git://github.com/jcomellas/otp.git >>> >> >>>> jc-fix-default-start-phases >>> >> >>>> >>> >> >>>> Juanjo >>> >> >>>> _______________________________________________ >>> >> >>>> erlang-patches mailing list >>> >> >>>> erlang-patches@REDACTED >>> >> >>>> http://erlang.org/mailman/listinfo/erlang-patches >>> >> >>>> >>> >> >>>> >>> >> >> >>> >> >>> >> _______________________________________________ >>> >> erlang-patches mailing list >>> >> erlang-patches@REDACTED >>> >> http://erlang.org/mailman/listinfo/erlang-patches >>> > >>> > >> >> From henrik@REDACTED Fri Jan 13 11:41:56 2012 From: henrik@REDACTED (Henrik Nord) Date: Fri, 13 Jan 2012 11:41:56 +0100 Subject: [erlang-patches] Adds missing spaces in xmerl doc In-Reply-To: <20120112122515.GB2033@viper.local> References: <20120112122515.GB2033@viper.local> Message-ID: <4F100A74.7070702@erlang.org> Thank you for the contribution. I will include this On 01/12/2012 01:25 PM, Ricardo Catalinas Jim?nez wrote: > Please fetch: > git fetch git://github.com/jimenezrick/otp.git spaces-xmerl-doc > > Review here: > https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:spaces-xmerl-doc > https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:spaces-xmerl-doc.patch > > > Regards -- /Henrik Nord Erlang/OTP From juanjo@REDACTED Fri Jan 13 14:34:10 2012 From: juanjo@REDACTED (Juan Jose Comellas) Date: Fri, 13 Jan 2012 10:34:10 -0300 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> Message-ID: Siri, I agree with making it more readable. This being my first commit to Erlang/OTP I wanted to make everything as unobtrusive and predictable as possible. I've changed the patch as you requested and I made two versions of it in the following branches: 1) jc-omit-undefined-start_phases-2 Using the style present in the original file for the case expression (i.e. case StartMod =:= undefined of true -> ....) Fetch with: git fetch git://github.com/jcomellas/otp.git jc-omit-undefined-start_phases-2 Diff against 'maint': https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-2 2) jc-omit-undefined-start_phases-3 Using the more modern Erlang style for case expressions that Tuncer suggested in his email (i.e. case StartMod of undefined -> ...) Fetch with: git fetch git://github.com/jcomellas/otp.git jc-omit-undefined-start_phases-3 Diff against 'maint': https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-3 I've also tested a release with both branches and the resulting .app files are exactly the same, as expected: e.g. With 'start_phases' unset in the original .app file: %% app generated at {2012,1,13} {10,15,39} {application,sasl, [{description,"SASL CXC 138 11"}, {vsn,"2.2"}, {id,[]}, {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, overload,rb,rb_format_supp,release_handler, release_handler_1,sasl,sasl_report,sasl_report_file_h, sasl_report_tty_h,si,si_sasl_supp,systools, systools_lib,systools_make,systools_rc, systools_relup]}, {registered,[sasl_sup,alarm_handler,overload,release_handler]}, {applications,[kernel,stdlib]}, {included_applications,[]}, {env,[{sasl_error_logger,tty},{errlog_type,all}]}, {maxT,infinity}, {maxP,infinity}, {mod,{sasl,[]}}]}. e.g. With 'start_phases' set to [] in the original .app file: %% app generated at {2012,1,13} {10,15,39} {application,etest, [{description,[]}, {vsn,"2"}, {id,[]}, {modules,[etest_app,etest_sup]}, {registered,[]}, {applications,[kernel,stdlib]}, {included_applications,[]}, {env,[]}, {maxT,infinity}, {maxP,infinity}, {mod,{etest_app,[]}}, {start_phases,[]}]}. Let me know if any other change is required. Juanjo On Fri, Jan 13, 2012 at 6:55 AM, Siri Hansen wrote: > Hi Juan! > > Thanks for the patch - I had a look at your changes, and I have one comment: > > There is no requirement of any specific order of the items in the .app file > and I therefore think it would be more readable to just add the start_phases > and mod items at the end of the list instead of merging them with the maxT > and maxP items. > > I know that this change would make the result from this function differ > compared to earlier but it would still be correct, and I think that the > readability is quite important. What do you think? > > Regards > /siri > > > 2012/1/12 Juan Jose Comellas >> >> Siri, I have compiled the maint branch with my change and tested >> generating a release using rebar. The .app file I sent as an example >> before now looks like this: >> >> %% app generated at {2012,1,12} {16,49,25} >> {application,sasl, >> ? ? ? ? ? ? [{description,"SASL ?CXC 138 11"}, >> ? ? ? ? ? ? ?{vsn,"2.2"}, >> ? ? ? ? ? ? ?{id,[]}, >> ? ? ? ? ? ? ?{modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, >> ? ? ? ? ? ? ? ? ? ? ? ?overload,rb,rb_format_supp,release_handler, >> >> ?release_handler_1,sasl,sasl_report,sasl_report_file_h, >> ? ? ? ? ? ? ? ? ? ? ? ?sasl_report_tty_h,si,si_sasl_supp,systools, >> ? ? ? ? ? ? ? ? ? ? ? ?systools_lib,systools_make,systools_rc, >> ? ? ? ? ? ? ? ? ? ? ? ?systools_relup]}, >> >> ?{registered,[sasl_sup,alarm_handler,overload,release_handler]}, >> ? ? ? ? ? ? ?{applications,[kernel,stdlib]}, >> ? ? ? ? ? ? ?{included_applications,[]}, >> ? ? ? ? ? ? ?{env,[{sasl_error_logger,tty},{errlog_type,all}]}, >> ? ? ? ? ? ? ?{maxT,infinity}, >> ? ? ? ? ? ? ?{maxP,infinity}, >> ? ? ? ? ? ? ?{mod,{sasl,[]}}]}. >> >> You can see that now the .app file does not include the 'start_phases' >> entry. You can get this patch by running: >> >> git fetch git://github.com/jcomellas/otp.git >> jc-omit-undefined-start_phases >> >> Juanjo >> >> >> On Thu, Jan 12, 2012 at 4:30 PM, Juan Jose Comellas >> wrote: >> > Siri, I have made the change. You can review it here: >> > >> > >> > https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases >> > >> > And you can fetch the changes with: >> > >> > git fetch git://github.com/jcomellas/otp.git >> > jc-omit-undefined-start_phases >> > >> > I am recompiling the maint branch with this change and I intend to >> > test generating a release upgrade with it, but it's going to take a >> > while. >> > >> > Juanjo >> > >> > >> > On Thu, Jan 12, 2012 at 5:58 AM, Siri Hansen >> > wrote: >> >> Ok, thanks! >> >> Then I think that we will go for the solution where >> >> reltool_target:gen_app >> >> does not add the start_phases entry if >> >> #app_info.start_phases==undefined. >> >> And the default value for #app_info.start_phases shall still be >> >> 'undefined'. >> >> This will keep the backwards compatibility. >> >> >> >> Will you do the change, Juan? >> >> >> >> Regards >> >> /siri >> >> >> >> >> >> 2012/1/11 Juan Jose Comellas >> >>> >> >>> Siri, what you mention is exactly what was happening. I did all my >> >>> tests with rebar and what I experienced was that after performing a >> >>> 'rebar generate' reltool creates all the .app files in the release >> >>> with 'start_phases' set as 'undefined'. Here's an example: >> >>> >> >>> %% app generated at {2012,1,11} {14,17,10} >> >>> {application,sasl, >> >>> ? ? ? ? ? ? [{description,"SASL ?CXC 138 11"}, >> >>> ? ? ? ? ? ? ?{vsn,"2.2"}, >> >>> ? ? ? ? ? ? ?{id,[]}, >> >>> ? ? ? ? ? ? ?{modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, >> >>> ? ? ? ? ? ? ? ? ? ? ? ?overload,rb,rb_format_supp,release_handler, >> >>> >> >>> ?release_handler_1,sasl,sasl_report,sasl_report_file_h, >> >>> ? ? ? ? ? ? ? ? ? ? ? ?sasl_report_tty_h,si,si_sasl_supp,systools, >> >>> ? ? ? ? ? ? ? ? ? ? ? ?systools_lib,systools_make,systools_rc, >> >>> ? ? ? ? ? ? ? ? ? ? ? ?systools_relup]}, >> >>> >> >>> ?{registered,[sasl_sup,alarm_handler,overload,release_handler]}, >> >>> ? ? ? ? ? ? ?{applications,[kernel,stdlib]}, >> >>> ? ? ? ? ? ? ?{included_applications,[]}, >> >>> ? ? ? ? ? ? ?{env,[{sasl_error_logger,tty},{errlog_type,all}]}, >> >>> ? ? ? ? ? ? ?{start_phases,undefined}, >> >>> ? ? ? ? ? ? ?{maxT,infinity}, >> >>> ? ? ? ? ? ? ?{maxP,infinity}, >> >>> ? ? ? ? ? ? ?{mod,{sasl,[]}}]}. >> >>> >> >>> The problem is that once you try to run 'rebar generate-upgrade' you >> >>> get all kinds of badmatch errors because the function that validates >> >>> the 'start_phases' entry in the generated .app files does not allow it >> >>> to be set to 'undefined'. Here's the relevant line: >> >>> >> >>> >> >>> >> >>> https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 >> >>> >> >>> My thought was to set the 'start_phases' field to [] by default in the >> >>> #app_info record (in lib/reltool/src/reltool.hrl) to avoid this >> >>> problem. What you proposed (not adding ?the 'start_phases' entry if it >> >>> is set to 'undefined') is equally valid. Also, another option would be >> >>> to allow 'undefined' to be a valid value in the line I referenced from >> >>> Github above. >> >>> >> >>> This seems to have been broken for over a year, and from what I can >> >>> see it was impossible to automatically generate releases and release >> >>> upgrades without triggering this error (at least with rebar). >> >>> >> >>> Juanjo >> >>> >> >>> >> >>> On Wed, Jan 11, 2012 at 7:45 AM, Siri Hansen >> >>> wrote: >> >>> > Sorry for the delay, but finally I have had a look at this.... >> >>> > >> >>> > As far as I can see the empty list used as default >> >>> > for?#application.start_phase?in systools.hrl will *never* come out >> >>> > in a >> >>> > real >> >>> > instance of the #application record. The fields of this record gets >> >>> > its >> >>> > values in systools_make:parse_application/4 ?(from get_items/2 -> >> >>> > check_item/2) - which will give the start_phases field the value >> >>> > 'undefined' >> >>> > if there is no start_phases entry in the .app file. The only way >> >>> > start_phases can get the value [] here is if there is a >> >>> > {start_phases,[]} >> >>> > entry in the .app file, but this has nothing to do with the default >> >>> > value. >> >>> > >> >>> > I agree of course that systools.hrl is a bit misleading by stating a >> >>> > default >> >>> > value which is never used... >> >>> > >> >>> > reltool_server on the other hand does use the default value from >> >>> > reltool.hrl >> >>> > file when parsing - but (and this might be the real bug) >> >>> > reltool_target >> >>> > does >> >>> > the opposite operation - i.e. it takes information from #app_info >> >>> > records >> >>> > and generates app specifications where it takes the value of the >> >>> > start_phases field in the record and inserts it directly as a >> >>> > {start_phases,Phases} entry in the app specification. It then seems >> >>> > like >> >>> > this is written to a .app file during target installation. I am not >> >>> > 100% >> >>> > sure of this (and why), so any objections would be good... But >> >>> > anyway, >> >>> > if >> >>> > this is the case - there might be .app files containing >> >>> > {start_phases,undefined} in the target installation from reltool... >> >>> > And >> >>> > this >> >>> > can never be parsed by systools!!! >> >>> > >> >>> > Could this be what happens in your case, Juan? >> >>> > >> >>> > If so, I think the best correction of this would be to let >> >>> > reltool_target >> >>> > insert a {start_phases,Phases} entry in the app specification only >> >>> > if >> >>> > Phases=/=undefined... What do you think? >> >>> > >> >>> > Regards >> >>> > /siri >> >>> > >> >>> > >> >>> > >> >>> > 2012/1/5 Ulf Wiger >> >>> >> >> >>> >> >> >>> >> I would suggest that the special handling of {start_phases, >> >>> >> undefined} >> >>> >> be >> >>> >> removed, and documentation updated accordingly. >> >>> >> >> >>> >> But this is a decision that OTP will have to make. >> >>> >> >> >>> >> BR, >> >>> >> Ulf W >> >>> >> >> >>> >> On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote: >> >>> >> >> >>> >> > Would it be an option to modify the function that validates the >> >>> >> > value >> >>> >> > assigned to 'start_phases' so that 'undefined' is considered an >> >>> >> > acceptable value? The relevant line is: >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 >> >>> >> > >> >>> >> > Juanjo >> >>> >> > >> >>> >> > >> >>> >> > On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger >> >>> >> > wrote: >> >>> >> >> >> >>> >> >> Not my call. >> >>> >> >> >> >>> >> >> I can well understand if the reasons behind the special >> >>> >> >> treatment of >> >>> >> >> 'start_phases' have been forgotten by those maintaining the >> >>> >> >> code. >> >>> >> >> >> >>> >> >> A closer analysis might reveal whether backward compatibility >> >>> >> >> has >> >>> >> >> already been sufficiently compromised that it is now time to >> >>> >> >> Make It >> >>> >> >> Right >> >>> >> >> (?). >> >>> >> >> >> >>> >> >> Even the old AXD 301 project, for which the oddity was >> >>> >> >> introduced in >> >>> >> >> the first place, took the first opportunity to make the code >> >>> >> >> fully >> >>> >> >> compatible with the new semantics. >> >>> >> >> >> >>> >> >> BR, >> >>> >> >> Ulf W >> >>> >> >> >> >>> >> >> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: >> >>> >> >> >> >>> >> >>> I can make the change and add it to the branch I created, but >> >>> >> >>> the >> >>> >> >>> question is: should I? I'm not really that well informed about >> >>> >> >>> the >> >>> >> >>> history of this value. All I can say is that the parts that >> >>> >> >>> care >> >>> >> >>> about >> >>> >> >>> the 'start_phases' entry in reltool and systools assume that it >> >>> >> >>> will >> >>> >> >>> be an empty list when it is not set and fail otherwise. >> >>> >> >>> >> >>> >> >>> Let me know if I have to modify my patch to make it acceptable >> >>> >> >>> for >> >>> >> >>> inclusion in OTP. >> >>> >> >>> >> >>> >> >>> Juanjo >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger >> >>> >> >>> wrote: >> >>> >> >>>> >> >>> >> >>>> Hmm, there's an old catch here. Someone will have to hollar if >> >>> >> >>>> it >> >>> >> >>>> is >> >>> >> >>>> no >> >>> >> >>>> longer relevant - but if it isn't, some documentation patch is >> >>> >> >>>> called >> >>> >> >>>> for. >> >>> >> >>>> >> >>> >> >>>> In >> >>> >> >>>> >> >>> >> >>>> >> >>> >> >>>> http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 >> >>> >> >>>> >> >>> >> >>>> StartType defines the type of start: >> >>> >> >>>> >> >>> >> >>>> normal if it's a normal startup. >> >>> >> >>>> normal also if the application is distributed and started at >> >>> >> >>>> the >> >>> >> >>>> current >> >>> >> >>>> node due to a failover from another node, and the application >> >>> >> >>>> specification >> >>> >> >>>> key start_phases == undefined. >> >>> >> >>>> {takeover,Node} if the application is distributed and started >> >>> >> >>>> at >> >>> >> >>>> the >> >>> >> >>>> current >> >>> >> >>>> node due to a takeover from Node, either because >> >>> >> >>>> application:takeover/2 has >> >>> >> >>>> been called or because the current node has higher priority >> >>> >> >>>> than >> >>> >> >>>> Node. >> >>> >> >>>> {failover,Node} if the application is distributed and started >> >>> >> >>>> at >> >>> >> >>>> the >> >>> >> >>>> current >> >>> >> >>>> node due to a failover from Node, and the application >> >>> >> >>>> specification >> >>> >> >>>> key start_phases /= undefined. >> >>> >> >>>> >> >>> >> >>>> Note that StartType = {failover, Node} is only used if >> >>> >> >>>> start_phases >> >>> >> >>>> /= >> >>> >> >>>> undefined. I will guess that it is for this reason that >> >>> >> >>>> start_phases >> >>> >> >>>> is >> >>> >> >>>> actually set to undefined as default. If it isn't, it was a >> >>> >> >>>> happy >> >>> >> >>>> coincidence, since it actually preserves backward >> >>> >> >>>> compatibility. >> >>> >> >>>> >> >>> >> >>>> This particular oddity was introduced many years ago, in the >> >>> >> >>>> 90s - >> >>> >> >>>> possibly >> >>> >> >>>> even before Erlang was released as Open Source, so the legacy >> >>> >> >>>> argument may >> >>> >> >>>> not be that relevant. >> >>> >> >>>> >> >>> >> >>>> OTOH, I don't think many people use the start_phases >> >>> >> >>>> attribute, so >> >>> >> >>>> even new >> >>> >> >>>> code might break if the Mod:start/2 function is suddenly >> >>> >> >>>> called >> >>> >> >>>> with >> >>> >> >>>> a >> >>> >> >>>> StartType that was never seen before. >> >>> >> >>>> >> >>> >> >>>> BR, >> >>> >> >>>> Ulf W >> >>> >> >>>> >> >>> >> >>>> >> >>> >> >>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: >> >>> >> >>>> >> >>> >> >>>> The default value for 'start_phases' in .app files should be >> >>> >> >>>> [], >> >>> >> >>>> but >> >>> >> >>>> it is incorrectly set to 'undefined' when generating a >> >>> >> >>>> release. >> >>> >> >>>> This >> >>> >> >>>> happens when the original .app file does not set a value for >> >>> >> >>>> 'start_phases' explicitly. >> >>> >> >>>> >> >>> >> >>>> The reltool application defines its own copy of a record to >> >>> >> >>>> handle >> >>> >> >>>> .app files (#app_info{}, defined in >> >>> >> >>>> lib/reltool/src/reltool.hrl) >> >>> >> >>>> that >> >>> >> >>>> has different default values than the one used by systools >> >>> >> >>>> (#application{}, defined in lib/sasl/src/systools.hrl). In >> >>> >> >>>> particular, >> >>> >> >>>> the 'start_phases' entry is assumed by all of OTP to be [] >> >>> >> >>>> when it >> >>> >> >>>> is >> >>> >> >>>> not explicitly set but reltool sets it to 'undefined' by >> >>> >> >>>> default. >> >>> >> >>>> This >> >>> >> >>>> causes badmatch errors when trying to generate release >> >>> >> >>>> upgrades. >> >>> >> >>>> >> >>> >> >>>> Without this patch, all of the rebar examples that generate >> >>> >> >>>> release >> >>> >> >>>> upgrades that I've found on the web will fail. The bug was >> >>> >> >>>> introduced >> >>> >> >>>> in R14A. >> >>> >> >>>> >> >>> >> >>>> git fetch git://github.com/jcomellas/otp.git >> >>> >> >>>> jc-fix-default-start-phases >> >>> >> >>>> >> >>> >> >>>> Juanjo >> >>> >> >>>> _______________________________________________ >> >>> >> >>>> erlang-patches mailing list >> >>> >> >>>> erlang-patches@REDACTED >> >>> >> >>>> http://erlang.org/mailman/listinfo/erlang-patches >> >>> >> >>>> >> >>> >> >>>> >> >>> >> >> >> >>> >> >> >>> >> _______________________________________________ >> >>> >> erlang-patches mailing list >> >>> >> erlang-patches@REDACTED >> >>> >> http://erlang.org/mailman/listinfo/erlang-patches >> >>> > >> >>> > >> >> >> >> > > From jimenezrick@REDACTED Sat Jan 14 18:43:59 2012 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Sat, 14 Jan 2012 18:43:59 +0100 Subject: [erlang-patches] Replace courier font by monospace in OTP's HTML doc Message-ID: <20120114174359.GA27911@viper.local> Modifies the OTP's CSS, replacing courier font by monospace. **IMHO** it should be more pleasant to read typespecs and code examples. Also adds minor cosmetic changes to the CSS. Please fetch: git fetch git://github.com/jimenezrick/otp.git doc-monospace-css Review here: https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:doc-monospace-css https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:doc-monospace-css.patch Regards -- Ricardo (http://r.untroubled.be/) From fhunleth@REDACTED Sun Jan 15 02:13:04 2012 From: fhunleth@REDACTED (Frank Hunleth) Date: Sat, 14 Jan 2012 20:13:04 -0500 Subject: [erlang-patches] otp_build make call fix Message-ID: I was having some trouble with otp_build due to some of its calls to make. The calls in question captured the stdout from make. If otp_build was invoked from another Makefile, the calls to make in otp_build would send "Entering directory..." messages to stdout which would then be captured and saved to a variable in otp_build. This would break otp_build. My fix was simply to turn off this output from make. Hopefully the patch makes this obvious: git fetch git://github.com/fhunleth/otp.git otp_build_make_fix This patch works for me with GNU make. If otp_build is supposed to run under non-GNU makes, then I'm not sure if this patch is sufficient. Thanks, Frank From jimenezrick@REDACTED Sun Jan 15 13:07:43 2012 From: jimenezrick@REDACTED (=?UTF-8?Q?Ricardo_Catalinas_Jim=C3=A9nez?=) Date: Sun, 15 Jan 2012 13:07:43 +0100 Subject: [erlang-patches] Replace courier font by monospace in OTP's HTML doc In-Reply-To: <20120114174359.GA27911@viper.local> References: <20120114174359.GA27911@viper.local> Message-ID: On Sat, Jan 14, 2012 at 6:43 PM, Ricardo Catalinas Jim?nez wrote: > Modifies the OTP's CSS, replacing courier font by monospace. **IMHO** it > should be more pleasant to read typespecs and code examples. Also adds > minor cosmetic changes to the CSS. I added a second commit: Set `font-family: Courier, monospace', much better. This should be much better for everybody, I left Courier as the primary font and also added monospace as secondary for people like me which in Linux doesn't have it installed. Please fetch: git fetch git://github.com/jimenezrick/otp.git doc-monospace-css Review here: https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:doc-monospace-css https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:doc-monospace-css.patch Regards -- Ricardo (http://r.untroubled.be/) From tomas@REDACTED Sun Jan 15 14:16:04 2012 From: tomas@REDACTED (Tomas Pihl) Date: Sun, 15 Jan 2012 14:16:04 +0100 Subject: [erlang-patches] Better printouts from AC in case of errors Message-ID: I got fed up with those pesky little 'Kernel pid terminated' and I couldn't figure out what was going on, so I did some digging in application_master/supervisor and came up with the below patch. As IO for some reason is blocked during these early phases, the use of error_loggger is of no use so instead I send Reason up the chain and let application_controller use it. As can be seen from the below printouts, running with the patch makes it fairly easy to see the problem I'm having here (a missing dependency to SSL). No patch: Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe] [kernel-poll:false] =INFO REPORT==== 15-Jan-2012::12:50:15 === ? ? application: topi ? ? exited: {shutdown,{topi_app,start,[normal,[]]}} ? ? type: permanent {"Kernel pid terminated",application_controller,"{application_start_failure,topi,{shutdown,{topi_app,start,[normal,[]]}}}"} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,topi,{shutdown,{topi_app,start,[normal,[]]}}}) And with the patch applied: Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe] [kernel-poll:false] =INFO REPORT==== 15-Jan-2012::12:52:34 === ? ? application: topi ? ? exited: {{undef, ? ? ? ? ? ? ? ? ?[{ssl,listen, ? ? ? ? ? ? ? ? ? ? ? [8043, ? ? ? ? ? ? ? ? ? ? ? ?[inet, ? ? ? ? ? ? ? . ? ? ? ? ? ? ? . ? ? ? ? ? ? ? . ? ? type: permanent {"Kernel pid terminated",application_controller,"{application_start_failure,topi,{{undef,[{ssl,listen,[8043,[inet,{ip,{0,0,0,0}}, .... Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,topi,{{undef,[{ssl,listen,[8043,[inet,{ip,{0,0,0,0}}, ... git fetch git@REDACTED:dozepih/otp.git supervisor_pass_on_errors https://github.com/dozepih/otp/tree/supervisor_pass_on_errors /topi From tuncer.ayaz@REDACTED Sun Jan 15 17:18:30 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 15 Jan 2012 17:18:30 +0100 Subject: [erlang-patches] Better printouts from AC in case of errors In-Reply-To: References: Message-ID: On Sun, Jan 15, 2012 at 2:16 PM, Tomas Pihl wrote: > I got fed up with those pesky little 'Kernel pid terminated' and I > couldn't figure out what was going on, so I did some digging in > application_master/supervisor and came up with the below patch. > > As IO for some reason is blocked during these early phases, the use > of error_loggger is of no use so instead I send Reason up the chain > and let application_controller use it. As can be seen from the below > printouts, running with the patch makes it fairly easy to see the > problem I'm having here (a missing dependency to SSL). > > No patch: > > Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe] > [kernel-poll:false] > > =INFO REPORT==== 15-Jan-2012::12:50:15 === > application: topi > exited: {shutdown,{topi_app,start,[normal,[]]}} > type: permanent > {"Kernel pid > terminated",application_controller,"{application_start_failure,topi, > {shutdown,{topi_app,start,[normal,[]]}}}"} > > Crash dump was written to: erl_crash.dump > Kernel pid terminated (application_controller) > ({application_start_failure,topi,{shutdown,{topi_app,start,[normal,[]]}}}) > > And with the patch applied: > > Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe] > [kernel-poll:false] > > =INFO REPORT==== 15-Jan-2012::12:52:34 === > application: topi > exited: {{undef, > [{ssl,listen, > [8043, > [inet, > . > . > . > type: permanent > > {"Kernel pid terminated",application_controller, > "{application_start_failure,topi, > {{undef,[{ssl,listen,[8043,[inet,{ip,{0,0,0,0}}, > .... > > Crash dump was written to: erl_crash.dump > Kernel pid terminated (application_controller) > ({application_start_failure,topi,{{undef,[{ssl,listen, > [8043,[inet,{ip,{0,0,0,0}}, > ... Looks useful, but what about backward compatibility? From tomas@REDACTED Sun Jan 15 19:38:32 2012 From: tomas@REDACTED (Tomas Pihl) Date: Sun, 15 Jan 2012 19:38:32 +0100 Subject: [erlang-patches] Better printouts from AC in case of errors In-Reply-To: References: Message-ID: On 15 January 2012 17:18, Tuncer Ayaz wrote: > On Sun, Jan 15, 2012 at 2:16 PM, Tomas Pihl wrote: >> I got fed up with those pesky little 'Kernel pid terminated' and I >> couldn't figure out what was going on, so I did some digging in >> application_master/supervisor and came up with the below patch. >> >> As IO for some reason is blocked during these early phases, the use >> of error_loggger is of no use so instead I send Reason up the chain >> and let application_controller use it. As can be seen from the below >> printouts, running with the patch makes it fairly easy to see the >> problem I'm having here (a missing dependency to SSL). >> >> No patch: >> >> Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe] >> [kernel-poll:false] >> >> =INFO REPORT==== 15-Jan-2012::12:50:15 === >> ? ? application: topi >> ? ? exited: {shutdown,{topi_app,start,[normal,[]]}} >> ? ? type: permanent >> {"Kernel pid >> terminated",application_controller,"{application_start_failure,topi, >> {shutdown,{topi_app,start,[normal,[]]}}}"} >> >> Crash dump was written to: erl_crash.dump >> Kernel pid terminated (application_controller) >> ({application_start_failure,topi,{shutdown,{topi_app,start,[normal,[]]}}}) >> >> And with the patch applied: >> >> Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe] >> [kernel-poll:false] >> >> =INFO REPORT==== 15-Jan-2012::12:52:34 === >> ? ? application: topi >> ? ? exited: {{undef, >> ? ? ? ? ? ? ? ? ?[{ssl,listen, >> ? ? ? ? ? ? ? ? ? ? ? [8043, >> ? ? ? ? ? ? ? ? ? ? ? ?[inet, >> ? ? ? ? ? ? ? . >> ? ? ? ? ? ? ? . >> ? ? ? ? ? ? ? . >> ? ? type: permanent >> >> {"Kernel pid terminated",application_controller, >> "{application_start_failure,topi, >> {{undef,[{ssl,listen,[8043,[inet,{ip,{0,0,0,0}}, >> .... >> >> Crash dump was written to: erl_crash.dump >> Kernel pid terminated (application_controller) >> ({application_start_failure,topi,{{undef,[{ssl,listen, >> [8043,[inet,{ip,{0,0,0,0}}, >> ... > > Looks useful, but what about backward compatibility? I was a bit worried about that also, but from what I can see, sending back a {error, term()} to supervisor:start_link/3 is ok and any users of it handles it just as a Reason which is what they should IMHO. But I might have overlooked something so your concern is valid but I can't find anything which might be affected. /topi From henrik@REDACTED Mon Jan 16 11:33:05 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 16 Jan 2012 11:33:05 +0100 Subject: [erlang-patches] Better printouts from AC in case of errors In-Reply-To: References: Message-ID: <4F13FCE1.9050106@erlang.org> Hi Tomas Thank you for the contribution! I have included your patch in 'pu', (I will rebase it onto 'maint' and run it in 'pu') On 01/15/2012 02:16 PM, Tomas Pihl wrote: > I got fed up with those pesky little 'Kernel pid terminated' and I > couldn't figure out what was going on, so I did some digging in > application_master/supervisor and came up with the below patch. > > As IO for some reason is blocked during these early phases, the use of > error_loggger is of no use so instead I send Reason up the chain and > let application_controller use it. As can be seen from the below > printouts, running with the patch makes it fairly easy to see the > problem I'm having here (a missing dependency to SSL). > > No patch: > > Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe] > [kernel-poll:false] > > =INFO REPORT==== 15-Jan-2012::12:50:15 === > application: topi > exited: {shutdown,{topi_app,start,[normal,[]]}} > type: permanent > {"Kernel pid terminated",application_controller,"{application_start_failure,topi,{shutdown,{topi_app,start,[normal,[]]}}}"} > > Crash dump was written to: erl_crash.dump > Kernel pid terminated (application_controller) > ({application_start_failure,topi,{shutdown,{topi_app,start,[normal,[]]}}}) > > And with the patch applied: > > Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe] > [kernel-poll:false] > > =INFO REPORT==== 15-Jan-2012::12:52:34 === > application: topi > exited: {{undef, > [{ssl,listen, > [8043, > [inet, > . > . > . > type: permanent > > {"Kernel pid terminated",application_controller,"{application_start_failure,topi,{{undef,[{ssl,listen,[8043,[inet,{ip,{0,0,0,0}}, > .... > > Crash dump was written to: erl_crash.dump > Kernel pid terminated (application_controller) > ({application_start_failure,topi,{{undef,[{ssl,listen,[8043,[inet,{ip,{0,0,0,0}}, > ... > > > git fetch git@REDACTED:dozepih/otp.git supervisor_pass_on_errors > > https://github.com/dozepih/otp/tree/supervisor_pass_on_errors > > /topi > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From kostis@REDACTED Mon Jan 16 13:55:02 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 16 Jan 2012 13:55:02 +0100 Subject: [erlang-patches] Fix discrepancy in compile_info Message-ID: <4F141E26.5090908@cs.ntua.gr> git fetch git://github.com/kostis/otp.git compile_info-fix Kostis From pguyot@REDACTED Mon Jan 16 14:06:43 2012 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 16 Jan 2012 14:06:43 +0100 Subject: [erlang-patches] SSL distribution fixes (was: Re: [erlang-questions] SSL distribution issues) In-Reply-To: References: <291DBF2D-AB8F-40A5-A137-51736D95AC9D@kallisys.net> Message-ID: Le 16 janv. 2012 ? 10:15, Ingela Andin a ?crit : > There is one blocking problem that I know of that can happen when > a none ssl node tries to contact an ssl node. If the nodename is > fairly short the first message can be seen as the begining of a > correct "ssl/tls"-packet and then it will wait for more data that > never comes and the other end is waiting for the response for its > first message. This can be fairly easily fixed by adding a check > for the value of the first byte for handshake messages. We will > be adding this for the next release. This has however not > interfered with the legitimate nodes in our tests. This probably is what happens. The other bug I saw is that the client can timeout (using dist_utils:timer) while the proxy doesn't handle this. What is the rationale behind the use of the proxy? Isn't it related to the old implementation of SSL? Eventually, we are running a cluster with currently a dozen nodes using the new implementation and the following fixes: - the proxy is made more robust to a death of the caller (the crash I reported, typically after a timeout); - inet_tls_dist:setup/5 now links the process just like what inet_tcp_dist:setup/5 does (I also set the priority to maximum like inet_tcp_dist does); - #hs_data.f_address function was updated to handle the case where the node disappeared, just like inet_tcp_dist does as well. This was done by exporting get_tcp_address from ssl_tls_dist_proxy and changing its return type. Besides, the proxy is now running on the loopback interface only (the sockets listen on {127,0,0,1}) as it is not meant to be connected from another node, from what I understand... The patch can be found here: https://github.com/pguyot/otp/compare/ssl_dist-fixes git fetch git://github.com/pguyot/otp.git ssl_dist-fixes Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From ingela@REDACTED Mon Jan 16 14:56:19 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 16 Jan 2012 14:56:19 +0100 Subject: [erlang-patches] SSL distribution fixes In-Reply-To: References: <291DBF2D-AB8F-40A5-A137-51736D95AC9D@kallisys.net> Message-ID: <4F142C83.7020406@erix.ericsson.se> Hi Paul! Paul Guyot wrote: > Le 16 janv. 2012 ? 10:15, Ingela Andin a ?crit : > > >> There is one blocking problem that I know of that can happen when >> > > >> a none ssl node tries to contact an ssl node. If the nodename is >> fairly short the first message can be seen as the begining of a >> correct "ssl/tls"-packet and then it will wait for more data that >> never comes and the other end is waiting for the response for its >> first message. This can be fairly easily fixed by adding a check >> for the value of the first byte for handshake messages. We will >> be adding this for the next release. This has however not >> interfered with the legitimate nodes in our tests. >> > > This probably is what happens. The other bug I saw is that the client can timeout (using dist_utils:timer) while the proxy doesn't handle this. > > What is the rationale behind the use of the proxy? Isn't it related to the old implementation of SSL? > > We want to avoid having a driver. > Eventually, we are running a cluster with currently a dozen nodes using the new implementation and the following fixes: > - the proxy is made more robust to a death of the caller (the crash I reported, typically after a timeout); > - inet_tls_dist:setup/5 now links the process just like what inet_tcp_dist:setup/5 does (I also set the priority to maximum like inet_tcp_dist does); > - #hs_data.f_address function was updated to handle the case where the node disappeared, just like inet_tcp_dist does as well. This was done by exporting get_tcp_address from ssl_tls_dist_proxy and changing its return type. > > Besides, the proxy is now running on the loopback interface only (the sockets listen on {127,0,0,1}) as it is not meant to be connected from another node, from what I understand... > > I think the changes are sound. > The patch can be found here: > https://github.com/pguyot/otp/compare/ssl_dist-fixes > git fetch git://github.com/pguyot/otp.git ssl_dist-fixes > > Paul > Henrik has/will include it in pu. Regards Ingela Erlang/OTP team - Ericsson AB From pguyot@REDACTED Mon Jan 16 15:21:38 2012 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 16 Jan 2012 15:21:38 +0100 Subject: [erlang-patches] SSL distribution fixes In-Reply-To: <4F142C83.7020406@erix.ericsson.se> References: <291DBF2D-AB8F-40A5-A137-51736D95AC9D@kallisys.net> <4F142C83.7020406@erix.ericsson.se> Message-ID: Le 16 janv. 2012 ? 14:56, Ingela Anderton Andin a ?crit : >> This probably is what happens. The other bug I saw is that the client can timeout (using dist_utils:timer) while the proxy doesn't handle this. >> >> What is the rationale behind the use of the proxy? Isn't it related to the old implementation of SSL? >> >> > We want to avoid having a driver. Ingela, Thank you for your replies. I still do not fully understand the way distribution over TLS works. I've just read in the (old) documentation that proto_dist requires a driver. Is this such a driver that you try to avoid? Is inet_ssl_dist using the same driver as inet_tcp_dist and hence requires a proxy? Is this why inet_tls_dist cannot use ssl:send/2 and ssl:recv/3 as f_recv and f_send handlers (lines 244 and 248)? > Henrik has/will include it in pu. Great! Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From Tobias.Schlager@REDACTED Mon Jan 16 15:21:39 2012 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Mon, 16 Jan 2012 14:21:39 +0000 Subject: [erlang-patches] Extended specs for built-in functions In-Reply-To: <12F2115FD1CCEE4294943B2608A18FA3EAB1E4@MAIL01.win.lbaum.eu> References: <12F2115FD1CCEE4294943B2608A18FA3EAB1E4@MAIL01.win.lbaum.eu> Message-ID: <12F2115FD1CCEE4294943B2608A18FA3EAB27A@MAIL01.win.lbaum.eu> This patch extends the specs for the following built-in functions: * process_flag/2,3 * system_flag/2 * system_info/1 * spawn_opt/2,3,4 The main intention for this patch was to make dialyzer recognize the process_flag option 'sensitive'. When fixing this issue I noticed some more missing specs and added what I could find in the latest documentation. Regards Tobias >From 2d57bd2fe55573e48c035cc0e1ecc94617263630 Mon Sep 17 00:00:00 2001 From: Tobias Schlager Date: Mon, 16 Jan 2012 14:29:01 +0100 Subject: [PATCH] extended specs for built-in functions --- lib/hipe/cerl/erl_bif_types.erl | 48 ++++++++++++++++++++++++++++++++++++-- 1 files changed, 45 insertions(+), 3 deletions(-) diff --git a/lib/hipe/cerl/erl_bif_types.erl b/lib/hipe/cerl/erl_bif_types.erl index cee399e..88058ae 100644 --- a/lib/hipe/cerl/erl_bif_types.erl +++ b/lib/hipe/cerl/erl_bif_types.erl @@ -1202,11 +1202,13 @@ type(erlang, process_flag, 2, Xs) -> case t_atom_vals(Flag) of ['error_handler'] -> t_atom(); ['min_heap_size'] -> t_non_neg_integer(); + ['min_bin_vheap_size'] -> t_non_neg_integer(); ['scheduler'] -> t_non_neg_integer(); ['monitor_nodes'] -> t_boolean(); ['priority'] -> t_process_priority_level(); ['save_calls'] -> t_non_neg_integer(); ['trap_exit'] -> t_boolean(); + ['sensitive'] -> t_boolean(); List when is_list(List) -> T_process_flag_returns; unknown -> @@ -1503,6 +1505,8 @@ type(erlang, system_flag, 2, Xs) -> t_non_neg_fixnum(); ['min_heap_size'] -> t_non_neg_fixnum(); + ['min_bin_vheap_size'] -> + t_non_neg_fixnum(); ['multi_scheduling'] -> t_system_multi_scheduling(); ['schedulers_online'] -> @@ -1546,8 +1550,12 @@ type(erlang, system_info, 1, Xs) -> t_list(t_tuple([t_atom(), t_list(t_tuple([t_atom(), t_any()]))]))]); + ['build_type'] -> + t_system_build_type_return(); ['break_ignored'] -> t_boolean(); + ['c_compiler_used'] -> + t_tuple([t_atom(), t_any()]); ['cpu_topology'] -> t_system_cpu_topology(); ['compat_rel'] -> @@ -1560,6 +1568,8 @@ type(erlang, system_info, 1, Xs) -> t_binary(); ['dist_ctrl'] -> t_list(t_tuple([t_atom(), t_sup([t_pid(), t_port])])); + ['driver_version'] -> + t_string(); %% elib_malloc is intentionally not included, %% because it scheduled for removal in R15. ['endian'] -> @@ -1573,7 +1583,9 @@ type(erlang, system_info, 1, Xs) -> ['heap_sizes'] -> t_list(t_integer()); ['heap_type'] -> - t_sup([t_atom('private'), t_atom('hybrid')]); + t_sup([t_atom('private'), + t_atom('shared'), + t_atom('hybrid')]); ['hipe_architecture'] -> t_atoms(['amd64', 'arm', 'powerpc', 'ppc64', 'undefined', 'ultrasparc', 'x86']); @@ -1581,12 +1593,20 @@ type(erlang, system_info, 1, Xs) -> t_binary(); ['internal_cpu_topology'] -> %% Undocumented internal feature t_internal_cpu_topology(); + ['kernel_poll'] -> + t_boolean(); ['loaded'] -> t_binary(); ['logical_processors'] -> t_non_neg_fixnum(); ['machine'] -> t_string(); + ['min_heap_size'] -> + t_tuple([t_atom('min_heap_size'), + t_non_neg_integer()]); + ['min_bin_vheap_size'] -> + t_tuple([t_atom('min_bin_vheap_size'), + t_non_neg_integer()]); ['multi_scheduling'] -> t_system_multi_scheduling(); ['multi_scheduling_blockers'] -> @@ -1601,6 +1621,8 @@ type(erlang, system_info, 1, Xs) -> t_non_neg_fixnum(), t_non_neg_fixnum()]), t_string()); + ['otp_release'] -> + t_string(); ['process_count'] -> t_non_neg_fixnum(); ['process_limit'] -> @@ -1630,6 +1652,8 @@ type(erlang, system_info, 1, Xs) -> t_non_neg_fixnum(); ['trace_control_word'] -> t_integer(); + ['update_cpu_info'] -> + t_sup([t_atom('changed'), t_atom('unchanged')]); ['version'] -> t_string(); ['wordsize'] -> @@ -3747,8 +3771,13 @@ arg_types(erlang, pre_loaded, 0) -> arg_types(erlang, process_display, 2) -> [t_pid(), t_atom('backtrace')]; arg_types(erlang, process_flag, 2) -> - [t_sup([t_atom('trap_exit'), t_atom('error_handler'), - t_atom('min_heap_size'), t_atom('priority'), t_atom('save_calls'), + [t_sup([t_atom('trap_exit'), + t_atom('error_handler'), + t_atom('min_heap_size'), + t_atom('min_bin_vheap_size'), + t_atom('priority'), + t_atom('save_calls'), + t_atom('sensitive'), t_atom('scheduler'), % undocumented t_atom('monitor_nodes'), % undocumented t_tuple([t_atom('monitor_nodes'), t_list()])]), % undocumented @@ -3861,6 +3890,7 @@ arg_types(erlang, system_flag, 2) -> t_atom('display_items'), % undocumented t_atom('fullsweep_after'), t_atom('min_heap_size'), + t_atom('min_bin_vheap_size'), t_atom('multi_scheduling'), t_atom('schedulers_online'), t_atom('scheduler_bind_type'), @@ -4733,6 +4763,7 @@ t_spawn_options() -> t_atom('monitor'), t_tuple([t_atom('priority'), t_process_priority_level()]), t_tuple([t_atom('min_heap_size'), t_fixnum()]), + t_tuple([t_atom('min_bin_vheap_size'), t_fixnum()]), t_tuple([t_atom('fullsweep_after'), t_fixnum()])]). t_spawn_opt_return(List) -> @@ -4821,6 +4852,17 @@ t_system_profile_return() -> t_sup(t_atom('undefined'), t_tuple([t_sup(t_pid(), t_port()), t_system_profile_options()])). +t_system_build_type_return() -> + t_sup([t_atom('opt'), + t_atom('debug'), + t_atom('purify'), + t_atom('quantify'), + t_atom('purecov'), + t_atom('gcov'), + t_atom('valgrind'), + t_atom('gprof'), + t_atom('lcnt')]). + %% ===================================================================== %% These are used for the built-in functions of 'ets' %% ===================================================================== -- 1.7.7.5 -------------- next part -------------- A non-text attachment was scrubbed... Name: extended_specs_for_builtin_functions.patch Type: text/x-patch Size: 6120 bytes Desc: extended_specs_for_builtin_functions.patch URL: From henrik@REDACTED Mon Jan 16 16:24:53 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 16 Jan 2012 16:24:53 +0100 Subject: [erlang-patches] Fix discrepancy in compile_info In-Reply-To: <4F141E26.5090908@cs.ntua.gr> References: <4F141E26.5090908@cs.ntua.gr> Message-ID: <4F144145.7080808@erlang.org> Hi It looks like its a bugfix, so I will rebase it on maint and run it in 'pu'. Also it would be great if you could include the diff url:s in the mail for easy access for our reviewing pleasure. Thank you On 01/16/2012 01:55 PM, Kostis Sagonas wrote: > git fetch git://github.com/kostis/otp.git compile_info-fix > > Kostis > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Mon Jan 16 16:31:35 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 16 Jan 2012 16:31:35 +0100 Subject: [erlang-patches] SSL distribution fixes In-Reply-To: References: <291DBF2D-AB8F-40A5-A137-51736D95AC9D@kallisys.net> Message-ID: <4F1442D7.4000109@erlang.org> Hi Yes as Ingela stated I have included this in 'pu' It was however based on 'master' not maint so I had to rebase it. A friendly reminder for all of you readers: pu maint bugfixes, small changes, next patch-release. (now R15B01) master-pu master major fixes, changes and new functionality, next major release (now R16) On 01/16/2012 02:06 PM, Paul Guyot wrote: > Le 16 janv. 2012 ? 10:15, Ingela Andin a ?crit : > >> There is one blocking problem that I know of that can happen when >> a none ssl node tries to contact an ssl node. If the nodename is >> fairly short the first message can be seen as the begining of a >> correct "ssl/tls"-packet and then it will wait for more data that >> never comes and the other end is waiting for the response for its >> first message. This can be fairly easily fixed by adding a check >> for the value of the first byte for handshake messages. We will >> be adding this for the next release. This has however not >> interfered with the legitimate nodes in our tests. > This probably is what happens. The other bug I saw is that the client can timeout (using dist_utils:timer) while the proxy doesn't handle this. > > What is the rationale behind the use of the proxy? Isn't it related to the old implementation of SSL? > > Eventually, we are running a cluster with currently a dozen nodes using the new implementation and the following fixes: > - the proxy is made more robust to a death of the caller (the crash I reported, typically after a timeout); > - inet_tls_dist:setup/5 now links the process just like what inet_tcp_dist:setup/5 does (I also set the priority to maximum like inet_tcp_dist does); > - #hs_data.f_address function was updated to handle the case where the node disappeared, just like inet_tcp_dist does as well. This was done by exporting get_tcp_address from ssl_tls_dist_proxy and changing its return type. > > Besides, the proxy is now running on the loopback interface only (the sockets listen on {127,0,0,1}) as it is not meant to be connected from another node, from what I understand... > > The patch can be found here: > https://github.com/pguyot/otp/compare/ssl_dist-fixes > git fetch git://github.com/pguyot/otp.git ssl_dist-fixes > > Paul -- /Henrik Nord Erlang/OTP From henrik@REDACTED Mon Jan 16 16:52:49 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 16 Jan 2012 16:52:49 +0100 Subject: [erlang-patches] Extend erlang:port_info/1, 2 to show the OS pid of a spawned process In-Reply-To: References: <4F0ABB0A.4070003@erlang.org> <275F49D5-2BDC-4990-B40E-6DA9D3D9C2E5@kallisys.net> <4F0AEE41.9040301@erlang.org> Message-ID: <4F1447D1.6070409@erlang.org> Yes as you might have noticed already, I did include this patch in 'master-pu'. Thank you for the contribution! On 01/09/2012 03:21 PM, Paul Guyot wrote: > Le 9 janv. 2012 ? 14:40, Henrik Nord a ?crit : > >> erts/emulator/test/port_bif_SUITE.erl >> >> There is tests for port_info in here. > Thank you. > > You will find a test for this feature here: > > git fetch git://github.com/pguyot/otp.git add-os-pid-to-port-info > https://github.com/pguyot/otp/commit/336d1d1d65fa7d75ebe6341a9aa2b7966a8e8052 > > As I simply amended the commit, the patch is still limited to a single commit. > Please let me know if you need anything else to consider this patch for inclusion. > > Paul -- /Henrik Nord Erlang/OTP From kostis@REDACTED Mon Jan 16 18:04:48 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 16 Jan 2012 18:04:48 +0100 Subject: [erlang-patches] Fix discrepancy in compile_info In-Reply-To: <4F144145.7080808@erlang.org> References: <4F141E26.5090908@cs.ntua.gr> <4F144145.7080808@erlang.org> Message-ID: <4F1458B0.6050709@cs.ntua.gr> On 01/16/2012 04:24 PM, Henrik Nord wrote: > Hi > > It looks like its a bugfix, so I will rebase it on maint and run it in > 'pu'. Strictly, this is not a bug since this 'none' atom is used to pass information from the beam_disasm module to the hipe compiler. The problem is that this is not in accordance with the type declaration in the record. So it's a discrepancy which results in a dialyzer warning. In principle it could have been fixed by extending the type declaration. In any case, it would be nice to include this in a maintainance release of R15B instead of in R16. > Also it would be great if you could include the diff url:s in the mail > for easy access for our reviewing pleasure. I think the diff can be viewed here: https://github.com/kostis/otp/commit/baeab90a39ad01389e91136722206f5d3ac47486 Kostis > On 01/16/2012 01:55 PM, Kostis Sagonas wrote: >> git fetch git://github.com/kostis/otp.git compile_info-fix >> >> Kostis >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From erlangsiri@REDACTED Tue Jan 17 12:07:42 2012 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 17 Jan 2012 12:07:42 +0100 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> Message-ID: Juan - I think we will go for solution 2) (i.e. jc-omit-undefined-start_phases-3). Thanks! I've asked Henrik to include it in pu. Regards /siri 2012/1/13 Juan Jose Comellas > Siri, I agree with making it more readable. This being my first commit > to Erlang/OTP I wanted to make everything as unobtrusive and > predictable as possible. I've changed the patch as you requested and I > made two versions of it in the following branches: > > 1) jc-omit-undefined-start_phases-2 > > Using the style present in the original file for the case expression > (i.e. case StartMod =:= undefined of true -> ....) > > Fetch with: > git fetch git://github.com/jcomellas/otp.gitjc-omit-undefined-start_phases-2 > Diff against 'maint': > > https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-2 > > > 2) jc-omit-undefined-start_phases-3 > > Using the more modern Erlang style for case expressions that Tuncer > suggested in his email (i.e. case StartMod of undefined -> ...) > > Fetch with: > git fetch git://github.com/jcomellas/otp.gitjc-omit-undefined-start_phases-3 > Diff against 'maint': > > https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-3 > > I've also tested a release with both branches and the resulting .app > files are exactly the same, as expected: > > e.g. With 'start_phases' unset in the original .app file: > > %% app generated at {2012,1,13} {10,15,39} > {application,sasl, > [{description,"SASL CXC 138 11"}, > {vsn,"2.2"}, > {id,[]}, > {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, > overload,rb,rb_format_supp,release_handler, > > release_handler_1,sasl,sasl_report,sasl_report_file_h, > sasl_report_tty_h,si,si_sasl_supp,systools, > systools_lib,systools_make,systools_rc, > systools_relup]}, > > {registered,[sasl_sup,alarm_handler,overload,release_handler]}, > {applications,[kernel,stdlib]}, > {included_applications,[]}, > {env,[{sasl_error_logger,tty},{errlog_type,all}]}, > {maxT,infinity}, > {maxP,infinity}, > {mod,{sasl,[]}}]}. > > e.g. With 'start_phases' set to [] in the original .app file: > > %% app generated at {2012,1,13} {10,15,39} > {application,etest, > [{description,[]}, > {vsn,"2"}, > {id,[]}, > {modules,[etest_app,etest_sup]}, > {registered,[]}, > {applications,[kernel,stdlib]}, > {included_applications,[]}, > {env,[]}, > {maxT,infinity}, > {maxP,infinity}, > {mod,{etest_app,[]}}, > {start_phases,[]}]}. > > Let me know if any other change is required. > > Juanjo > > > On Fri, Jan 13, 2012 at 6:55 AM, Siri Hansen wrote: > > Hi Juan! > > > > Thanks for the patch - I had a look at your changes, and I have one > comment: > > > > There is no requirement of any specific order of the items in the .app > file > > and I therefore think it would be more readable to just add the > start_phases > > and mod items at the end of the list instead of merging them with the > maxT > > and maxP items. > > > > I know that this change would make the result from this function differ > > compared to earlier but it would still be correct, and I think that the > > readability is quite important. What do you think? > > > > Regards > > /siri > > > > > > 2012/1/12 Juan Jose Comellas > >> > >> Siri, I have compiled the maint branch with my change and tested > >> generating a release using rebar. The .app file I sent as an example > >> before now looks like this: > >> > >> %% app generated at {2012,1,12} {16,49,25} > >> {application,sasl, > >> [{description,"SASL CXC 138 11"}, > >> {vsn,"2.2"}, > >> {id,[]}, > >> {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, > >> overload,rb,rb_format_supp,release_handler, > >> > >> release_handler_1,sasl,sasl_report,sasl_report_file_h, > >> sasl_report_tty_h,si,si_sasl_supp,systools, > >> systools_lib,systools_make,systools_rc, > >> systools_relup]}, > >> > >> {registered,[sasl_sup,alarm_handler,overload,release_handler]}, > >> {applications,[kernel,stdlib]}, > >> {included_applications,[]}, > >> {env,[{sasl_error_logger,tty},{errlog_type,all}]}, > >> {maxT,infinity}, > >> {maxP,infinity}, > >> {mod,{sasl,[]}}]}. > >> > >> You can see that now the .app file does not include the 'start_phases' > >> entry. You can get this patch by running: > >> > >> git fetch git://github.com/jcomellas/otp.git > >> jc-omit-undefined-start_phases > >> > >> Juanjo > >> > >> > >> On Thu, Jan 12, 2012 at 4:30 PM, Juan Jose Comellas < > juanjo@REDACTED> > >> wrote: > >> > Siri, I have made the change. You can review it here: > >> > > >> > > >> > > https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases > >> > > >> > And you can fetch the changes with: > >> > > >> > git fetch git://github.com/jcomellas/otp.git > >> > jc-omit-undefined-start_phases > >> > > >> > I am recompiling the maint branch with this change and I intend to > >> > test generating a release upgrade with it, but it's going to take a > >> > while. > >> > > >> > Juanjo > >> > > >> > > >> > On Thu, Jan 12, 2012 at 5:58 AM, Siri Hansen > >> > wrote: > >> >> Ok, thanks! > >> >> Then I think that we will go for the solution where > >> >> reltool_target:gen_app > >> >> does not add the start_phases entry if > >> >> #app_info.start_phases==undefined. > >> >> And the default value for #app_info.start_phases shall still be > >> >> 'undefined'. > >> >> This will keep the backwards compatibility. > >> >> > >> >> Will you do the change, Juan? > >> >> > >> >> Regards > >> >> /siri > >> >> > >> >> > >> >> 2012/1/11 Juan Jose Comellas > >> >>> > >> >>> Siri, what you mention is exactly what was happening. I did all my > >> >>> tests with rebar and what I experienced was that after performing a > >> >>> 'rebar generate' reltool creates all the .app files in the release > >> >>> with 'start_phases' set as 'undefined'. Here's an example: > >> >>> > >> >>> %% app generated at {2012,1,11} {14,17,10} > >> >>> {application,sasl, > >> >>> [{description,"SASL CXC 138 11"}, > >> >>> {vsn,"2.2"}, > >> >>> {id,[]}, > >> >>> > {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, > >> >>> overload,rb,rb_format_supp,release_handler, > >> >>> > >> >>> release_handler_1,sasl,sasl_report,sasl_report_file_h, > >> >>> sasl_report_tty_h,si,si_sasl_supp,systools, > >> >>> systools_lib,systools_make,systools_rc, > >> >>> systools_relup]}, > >> >>> > >> >>> {registered,[sasl_sup,alarm_handler,overload,release_handler]}, > >> >>> {applications,[kernel,stdlib]}, > >> >>> {included_applications,[]}, > >> >>> {env,[{sasl_error_logger,tty},{errlog_type,all}]}, > >> >>> {start_phases,undefined}, > >> >>> {maxT,infinity}, > >> >>> {maxP,infinity}, > >> >>> {mod,{sasl,[]}}]}. > >> >>> > >> >>> The problem is that once you try to run 'rebar generate-upgrade' you > >> >>> get all kinds of badmatch errors because the function that validates > >> >>> the 'start_phases' entry in the generated .app files does not allow > it > >> >>> to be set to 'undefined'. Here's the relevant line: > >> >>> > >> >>> > >> >>> > >> >>> > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 > >> >>> > >> >>> My thought was to set the 'start_phases' field to [] by default in > the > >> >>> #app_info record (in lib/reltool/src/reltool.hrl) to avoid this > >> >>> problem. What you proposed (not adding the 'start_phases' entry if > it > >> >>> is set to 'undefined') is equally valid. Also, another option would > be > >> >>> to allow 'undefined' to be a valid value in the line I referenced > from > >> >>> Github above. > >> >>> > >> >>> This seems to have been broken for over a year, and from what I can > >> >>> see it was impossible to automatically generate releases and release > >> >>> upgrades without triggering this error (at least with rebar). > >> >>> > >> >>> Juanjo > >> >>> > >> >>> > >> >>> On Wed, Jan 11, 2012 at 7:45 AM, Siri Hansen > >> >>> wrote: > >> >>> > Sorry for the delay, but finally I have had a look at this.... > >> >>> > > >> >>> > As far as I can see the empty list used as default > >> >>> > for #application.start_phase in systools.hrl will *never* come out > >> >>> > in a > >> >>> > real > >> >>> > instance of the #application record. The fields of this record > gets > >> >>> > its > >> >>> > values in systools_make:parse_application/4 (from get_items/2 -> > >> >>> > check_item/2) - which will give the start_phases field the value > >> >>> > 'undefined' > >> >>> > if there is no start_phases entry in the .app file. The only way > >> >>> > start_phases can get the value [] here is if there is a > >> >>> > {start_phases,[]} > >> >>> > entry in the .app file, but this has nothing to do with the > default > >> >>> > value. > >> >>> > > >> >>> > I agree of course that systools.hrl is a bit misleading by > stating a > >> >>> > default > >> >>> > value which is never used... > >> >>> > > >> >>> > reltool_server on the other hand does use the default value from > >> >>> > reltool.hrl > >> >>> > file when parsing - but (and this might be the real bug) > >> >>> > reltool_target > >> >>> > does > >> >>> > the opposite operation - i.e. it takes information from #app_info > >> >>> > records > >> >>> > and generates app specifications where it takes the value of the > >> >>> > start_phases field in the record and inserts it directly as a > >> >>> > {start_phases,Phases} entry in the app specification. It then > seems > >> >>> > like > >> >>> > this is written to a .app file during target installation. I am > not > >> >>> > 100% > >> >>> > sure of this (and why), so any objections would be good... But > >> >>> > anyway, > >> >>> > if > >> >>> > this is the case - there might be .app files containing > >> >>> > {start_phases,undefined} in the target installation from > reltool... > >> >>> > And > >> >>> > this > >> >>> > can never be parsed by systools!!! > >> >>> > > >> >>> > Could this be what happens in your case, Juan? > >> >>> > > >> >>> > If so, I think the best correction of this would be to let > >> >>> > reltool_target > >> >>> > insert a {start_phases,Phases} entry in the app specification only > >> >>> > if > >> >>> > Phases=/=undefined... What do you think? > >> >>> > > >> >>> > Regards > >> >>> > /siri > >> >>> > > >> >>> > > >> >>> > > >> >>> > 2012/1/5 Ulf Wiger > >> >>> >> > >> >>> >> > >> >>> >> I would suggest that the special handling of {start_phases, > >> >>> >> undefined} > >> >>> >> be > >> >>> >> removed, and documentation updated accordingly. > >> >>> >> > >> >>> >> But this is a decision that OTP will have to make. > >> >>> >> > >> >>> >> BR, > >> >>> >> Ulf W > >> >>> >> > >> >>> >> On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote: > >> >>> >> > >> >>> >> > Would it be an option to modify the function that validates the > >> >>> >> > value > >> >>> >> > assigned to 'start_phases' so that 'undefined' is considered an > >> >>> >> > acceptable value? The relevant line is: > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 > >> >>> >> > > >> >>> >> > Juanjo > >> >>> >> > > >> >>> >> > > >> >>> >> > On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger > >> >>> >> > wrote: > >> >>> >> >> > >> >>> >> >> Not my call. > >> >>> >> >> > >> >>> >> >> I can well understand if the reasons behind the special > >> >>> >> >> treatment of > >> >>> >> >> 'start_phases' have been forgotten by those maintaining the > >> >>> >> >> code. > >> >>> >> >> > >> >>> >> >> A closer analysis might reveal whether backward compatibility > >> >>> >> >> has > >> >>> >> >> already been sufficiently compromised that it is now time to > >> >>> >> >> Make It > >> >>> >> >> Right > >> >>> >> >> (?). > >> >>> >> >> > >> >>> >> >> Even the old AXD 301 project, for which the oddity was > >> >>> >> >> introduced in > >> >>> >> >> the first place, took the first opportunity to make the code > >> >>> >> >> fully > >> >>> >> >> compatible with the new semantics. > >> >>> >> >> > >> >>> >> >> BR, > >> >>> >> >> Ulf W > >> >>> >> >> > >> >>> >> >> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: > >> >>> >> >> > >> >>> >> >>> I can make the change and add it to the branch I created, but > >> >>> >> >>> the > >> >>> >> >>> question is: should I? I'm not really that well informed > about > >> >>> >> >>> the > >> >>> >> >>> history of this value. All I can say is that the parts that > >> >>> >> >>> care > >> >>> >> >>> about > >> >>> >> >>> the 'start_phases' entry in reltool and systools assume that > it > >> >>> >> >>> will > >> >>> >> >>> be an empty list when it is not set and fail otherwise. > >> >>> >> >>> > >> >>> >> >>> Let me know if I have to modify my patch to make it > acceptable > >> >>> >> >>> for > >> >>> >> >>> inclusion in OTP. > >> >>> >> >>> > >> >>> >> >>> Juanjo > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger > > >> >>> >> >>> wrote: > >> >>> >> >>>> > >> >>> >> >>>> Hmm, there's an old catch here. Someone will have to hollar > if > >> >>> >> >>>> it > >> >>> >> >>>> is > >> >>> >> >>>> no > >> >>> >> >>>> longer relevant - but if it isn't, some documentation patch > is > >> >>> >> >>>> called > >> >>> >> >>>> for. > >> >>> >> >>>> > >> >>> >> >>>> In > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 > >> >>> >> >>>> > >> >>> >> >>>> StartType defines the type of start: > >> >>> >> >>>> > >> >>> >> >>>> normal if it's a normal startup. > >> >>> >> >>>> normal also if the application is distributed and started at > >> >>> >> >>>> the > >> >>> >> >>>> current > >> >>> >> >>>> node due to a failover from another node, and the > application > >> >>> >> >>>> specification > >> >>> >> >>>> key start_phases == undefined. > >> >>> >> >>>> {takeover,Node} if the application is distributed and > started > >> >>> >> >>>> at > >> >>> >> >>>> the > >> >>> >> >>>> current > >> >>> >> >>>> node due to a takeover from Node, either because > >> >>> >> >>>> application:takeover/2 has > >> >>> >> >>>> been called or because the current node has higher priority > >> >>> >> >>>> than > >> >>> >> >>>> Node. > >> >>> >> >>>> {failover,Node} if the application is distributed and > started > >> >>> >> >>>> at > >> >>> >> >>>> the > >> >>> >> >>>> current > >> >>> >> >>>> node due to a failover from Node, and the application > >> >>> >> >>>> specification > >> >>> >> >>>> key start_phases /= undefined. > >> >>> >> >>>> > >> >>> >> >>>> Note that StartType = {failover, Node} is only used if > >> >>> >> >>>> start_phases > >> >>> >> >>>> /= > >> >>> >> >>>> undefined. I will guess that it is for this reason that > >> >>> >> >>>> start_phases > >> >>> >> >>>> is > >> >>> >> >>>> actually set to undefined as default. If it isn't, it was a > >> >>> >> >>>> happy > >> >>> >> >>>> coincidence, since it actually preserves backward > >> >>> >> >>>> compatibility. > >> >>> >> >>>> > >> >>> >> >>>> This particular oddity was introduced many years ago, in the > >> >>> >> >>>> 90s - > >> >>> >> >>>> possibly > >> >>> >> >>>> even before Erlang was released as Open Source, so the > legacy > >> >>> >> >>>> argument may > >> >>> >> >>>> not be that relevant. > >> >>> >> >>>> > >> >>> >> >>>> OTOH, I don't think many people use the start_phases > >> >>> >> >>>> attribute, so > >> >>> >> >>>> even new > >> >>> >> >>>> code might break if the Mod:start/2 function is suddenly > >> >>> >> >>>> called > >> >>> >> >>>> with > >> >>> >> >>>> a > >> >>> >> >>>> StartType that was never seen before. > >> >>> >> >>>> > >> >>> >> >>>> BR, > >> >>> >> >>>> Ulf W > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: > >> >>> >> >>>> > >> >>> >> >>>> The default value for 'start_phases' in .app files should be > >> >>> >> >>>> [], > >> >>> >> >>>> but > >> >>> >> >>>> it is incorrectly set to 'undefined' when generating a > >> >>> >> >>>> release. > >> >>> >> >>>> This > >> >>> >> >>>> happens when the original .app file does not set a value for > >> >>> >> >>>> 'start_phases' explicitly. > >> >>> >> >>>> > >> >>> >> >>>> The reltool application defines its own copy of a record to > >> >>> >> >>>> handle > >> >>> >> >>>> .app files (#app_info{}, defined in > >> >>> >> >>>> lib/reltool/src/reltool.hrl) > >> >>> >> >>>> that > >> >>> >> >>>> has different default values than the one used by systools > >> >>> >> >>>> (#application{}, defined in lib/sasl/src/systools.hrl). In > >> >>> >> >>>> particular, > >> >>> >> >>>> the 'start_phases' entry is assumed by all of OTP to be [] > >> >>> >> >>>> when it > >> >>> >> >>>> is > >> >>> >> >>>> not explicitly set but reltool sets it to 'undefined' by > >> >>> >> >>>> default. > >> >>> >> >>>> This > >> >>> >> >>>> causes badmatch errors when trying to generate release > >> >>> >> >>>> upgrades. > >> >>> >> >>>> > >> >>> >> >>>> Without this patch, all of the rebar examples that generate > >> >>> >> >>>> release > >> >>> >> >>>> upgrades that I've found on the web will fail. The bug was > >> >>> >> >>>> introduced > >> >>> >> >>>> in R14A. > >> >>> >> >>>> > >> >>> >> >>>> git fetch git://github.com/jcomellas/otp.git > >> >>> >> >>>> jc-fix-default-start-phases > >> >>> >> >>>> > >> >>> >> >>>> Juanjo > >> >>> >> >>>> _______________________________________________ > >> >>> >> >>>> erlang-patches mailing list > >> >>> >> >>>> erlang-patches@REDACTED > >> >>> >> >>>> http://erlang.org/mailman/listinfo/erlang-patches > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >> > >> >>> >> > >> >>> >> _______________________________________________ > >> >>> >> erlang-patches mailing list > >> >>> >> erlang-patches@REDACTED > >> >>> >> http://erlang.org/mailman/listinfo/erlang-patches > >> >>> > > >> >>> > > >> >> > >> >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Tue Jan 17 12:07:55 2012 From: henrik@REDACTED (Henrik Nord) Date: Tue, 17 Jan 2012 12:07:55 +0100 Subject: [erlang-patches] The 'start_phases' entry in .app files is incorrectly set to 'undefined' when generating a release In-Reply-To: References: <60A93D91-E1C1-4CDD-BA7F-1642D19315E3@feuerlabs.com> <0CE7736B-57D2-4915-B35E-CB59CDF18115@feuerlabs.com> Message-ID: <4F15568B.6070809@erlang.org> jc-omit-undefined-start_phases-3 I have added this version to 'pu' Thank you ! On 01/13/2012 02:34 PM, Juan Jose Comellas wrote: > Siri, I agree with making it more readable. This being my first commit > to Erlang/OTP I wanted to make everything as unobtrusive and > predictable as possible. I've changed the patch as you requested and I > made two versions of it in the following branches: > > 1) jc-omit-undefined-start_phases-2 > > Using the style present in the original file for the case expression > (i.e. case StartMod =:= undefined of true -> ....) > > Fetch with: > git fetch git://github.com/jcomellas/otp.git jc-omit-undefined-start_phases-2 > Diff against 'maint': > https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-2 > > > 2) jc-omit-undefined-start_phases-3 > > Using the more modern Erlang style for case expressions that Tuncer > suggested in his email (i.e. case StartMod of undefined -> ...) > > Fetch with: > git fetch git://github.com/jcomellas/otp.git jc-omit-undefined-start_phases-3 > Diff against 'maint': > https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-3 > > I've also tested a release with both branches and the resulting .app > files are exactly the same, as expected: > > e.g. With 'start_phases' unset in the original .app file: > > %% app generated at {2012,1,13} {10,15,39} > {application,sasl, > [{description,"SASL CXC 138 11"}, > {vsn,"2.2"}, > {id,[]}, > {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, > overload,rb,rb_format_supp,release_handler, > release_handler_1,sasl,sasl_report,sasl_report_file_h, > sasl_report_tty_h,si,si_sasl_supp,systools, > systools_lib,systools_make,systools_rc, > systools_relup]}, > {registered,[sasl_sup,alarm_handler,overload,release_handler]}, > {applications,[kernel,stdlib]}, > {included_applications,[]}, > {env,[{sasl_error_logger,tty},{errlog_type,all}]}, > {maxT,infinity}, > {maxP,infinity}, > {mod,{sasl,[]}}]}. > > e.g. With 'start_phases' set to [] in the original .app file: > > %% app generated at {2012,1,13} {10,15,39} > {application,etest, > [{description,[]}, > {vsn,"2"}, > {id,[]}, > {modules,[etest_app,etest_sup]}, > {registered,[]}, > {applications,[kernel,stdlib]}, > {included_applications,[]}, > {env,[]}, > {maxT,infinity}, > {maxP,infinity}, > {mod,{etest_app,[]}}, > {start_phases,[]}]}. > > Let me know if any other change is required. > > Juanjo > > > On Fri, Jan 13, 2012 at 6:55 AM, Siri Hansen wrote: >> Hi Juan! >> >> Thanks for the patch - I had a look at your changes, and I have one comment: >> >> There is no requirement of any specific order of the items in the .app file >> and I therefore think it would be more readable to just add the start_phases >> and mod items at the end of the list instead of merging them with the maxT >> and maxP items. >> >> I know that this change would make the result from this function differ >> compared to earlier but it would still be correct, and I think that the >> readability is quite important. What do you think? >> >> Regards >> /siri >> >> >> 2012/1/12 Juan Jose Comellas >>> Siri, I have compiled the maint branch with my change and tested >>> generating a release using rebar. The .app file I sent as an example >>> before now looks like this: >>> >>> %% app generated at {2012,1,12} {16,49,25} >>> {application,sasl, >>> [{description,"SASL CXC 138 11"}, >>> {vsn,"2.2"}, >>> {id,[]}, >>> {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, >>> overload,rb,rb_format_supp,release_handler, >>> >>> release_handler_1,sasl,sasl_report,sasl_report_file_h, >>> sasl_report_tty_h,si,si_sasl_supp,systools, >>> systools_lib,systools_make,systools_rc, >>> systools_relup]}, >>> >>> {registered,[sasl_sup,alarm_handler,overload,release_handler]}, >>> {applications,[kernel,stdlib]}, >>> {included_applications,[]}, >>> {env,[{sasl_error_logger,tty},{errlog_type,all}]}, >>> {maxT,infinity}, >>> {maxP,infinity}, >>> {mod,{sasl,[]}}]}. >>> >>> You can see that now the .app file does not include the 'start_phases' >>> entry. You can get this patch by running: >>> >>> git fetch git://github.com/jcomellas/otp.git >>> jc-omit-undefined-start_phases >>> >>> Juanjo >>> >>> >>> On Thu, Jan 12, 2012 at 4:30 PM, Juan Jose Comellas >>> wrote: >>>> Siri, I have made the change. You can review it here: >>>> >>>> >>>> https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases >>>> >>>> And you can fetch the changes with: >>>> >>>> git fetch git://github.com/jcomellas/otp.git >>>> jc-omit-undefined-start_phases >>>> >>>> I am recompiling the maint branch with this change and I intend to >>>> test generating a release upgrade with it, but it's going to take a >>>> while. >>>> >>>> Juanjo >>>> >>>> >>>> On Thu, Jan 12, 2012 at 5:58 AM, Siri Hansen >>>> wrote: >>>>> Ok, thanks! >>>>> Then I think that we will go for the solution where >>>>> reltool_target:gen_app >>>>> does not add the start_phases entry if >>>>> #app_info.start_phases==undefined. >>>>> And the default value for #app_info.start_phases shall still be >>>>> 'undefined'. >>>>> This will keep the backwards compatibility. >>>>> >>>>> Will you do the change, Juan? >>>>> >>>>> Regards >>>>> /siri >>>>> >>>>> >>>>> 2012/1/11 Juan Jose Comellas >>>>>> Siri, what you mention is exactly what was happening. I did all my >>>>>> tests with rebar and what I experienced was that after performing a >>>>>> 'rebar generate' reltool creates all the .app files in the release >>>>>> with 'start_phases' set as 'undefined'. Here's an example: >>>>>> >>>>>> %% app generated at {2012,1,11} {14,17,10} >>>>>> {application,sasl, >>>>>> [{description,"SASL CXC 138 11"}, >>>>>> {vsn,"2.2"}, >>>>>> {id,[]}, >>>>>> {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp, >>>>>> overload,rb,rb_format_supp,release_handler, >>>>>> >>>>>> release_handler_1,sasl,sasl_report,sasl_report_file_h, >>>>>> sasl_report_tty_h,si,si_sasl_supp,systools, >>>>>> systools_lib,systools_make,systools_rc, >>>>>> systools_relup]}, >>>>>> >>>>>> {registered,[sasl_sup,alarm_handler,overload,release_handler]}, >>>>>> {applications,[kernel,stdlib]}, >>>>>> {included_applications,[]}, >>>>>> {env,[{sasl_error_logger,tty},{errlog_type,all}]}, >>>>>> {start_phases,undefined}, >>>>>> {maxT,infinity}, >>>>>> {maxP,infinity}, >>>>>> {mod,{sasl,[]}}]}. >>>>>> >>>>>> The problem is that once you try to run 'rebar generate-upgrade' you >>>>>> get all kinds of badmatch errors because the function that validates >>>>>> the 'start_phases' entry in the generated .app files does not allow it >>>>>> to be set to 'undefined'. Here's the relevant line: >>>>>> >>>>>> >>>>>> >>>>>> https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 >>>>>> >>>>>> My thought was to set the 'start_phases' field to [] by default in the >>>>>> #app_info record (in lib/reltool/src/reltool.hrl) to avoid this >>>>>> problem. What you proposed (not adding the 'start_phases' entry if it >>>>>> is set to 'undefined') is equally valid. Also, another option would be >>>>>> to allow 'undefined' to be a valid value in the line I referenced from >>>>>> Github above. >>>>>> >>>>>> This seems to have been broken for over a year, and from what I can >>>>>> see it was impossible to automatically generate releases and release >>>>>> upgrades without triggering this error (at least with rebar). >>>>>> >>>>>> Juanjo >>>>>> >>>>>> >>>>>> On Wed, Jan 11, 2012 at 7:45 AM, Siri Hansen >>>>>> wrote: >>>>>>> Sorry for the delay, but finally I have had a look at this.... >>>>>>> >>>>>>> As far as I can see the empty list used as default >>>>>>> for #application.start_phase in systools.hrl will *never* come out >>>>>>> in a >>>>>>> real >>>>>>> instance of the #application record. The fields of this record gets >>>>>>> its >>>>>>> values in systools_make:parse_application/4 (from get_items/2 -> >>>>>>> check_item/2) - which will give the start_phases field the value >>>>>>> 'undefined' >>>>>>> if there is no start_phases entry in the .app file. The only way >>>>>>> start_phases can get the value [] here is if there is a >>>>>>> {start_phases,[]} >>>>>>> entry in the .app file, but this has nothing to do with the default >>>>>>> value. >>>>>>> >>>>>>> I agree of course that systools.hrl is a bit misleading by stating a >>>>>>> default >>>>>>> value which is never used... >>>>>>> >>>>>>> reltool_server on the other hand does use the default value from >>>>>>> reltool.hrl >>>>>>> file when parsing - but (and this might be the real bug) >>>>>>> reltool_target >>>>>>> does >>>>>>> the opposite operation - i.e. it takes information from #app_info >>>>>>> records >>>>>>> and generates app specifications where it takes the value of the >>>>>>> start_phases field in the record and inserts it directly as a >>>>>>> {start_phases,Phases} entry in the app specification. It then seems >>>>>>> like >>>>>>> this is written to a .app file during target installation. I am not >>>>>>> 100% >>>>>>> sure of this (and why), so any objections would be good... But >>>>>>> anyway, >>>>>>> if >>>>>>> this is the case - there might be .app files containing >>>>>>> {start_phases,undefined} in the target installation from reltool... >>>>>>> And >>>>>>> this >>>>>>> can never be parsed by systools!!! >>>>>>> >>>>>>> Could this be what happens in your case, Juan? >>>>>>> >>>>>>> If so, I think the best correction of this would be to let >>>>>>> reltool_target >>>>>>> insert a {start_phases,Phases} entry in the app specification only >>>>>>> if >>>>>>> Phases=/=undefined... What do you think? >>>>>>> >>>>>>> Regards >>>>>>> /siri >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2012/1/5 Ulf Wiger >>>>>>>> >>>>>>>> I would suggest that the special handling of {start_phases, >>>>>>>> undefined} >>>>>>>> be >>>>>>>> removed, and documentation updated accordingly. >>>>>>>> >>>>>>>> But this is a decision that OTP will have to make. >>>>>>>> >>>>>>>> BR, >>>>>>>> Ulf W >>>>>>>> >>>>>>>> On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote: >>>>>>>> >>>>>>>>> Would it be an option to modify the function that validates the >>>>>>>>> value >>>>>>>>> assigned to 'start_phases' so that 'undefined' is considered an >>>>>>>>> acceptable value? The relevant line is: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681 >>>>>>>>> >>>>>>>>> Juanjo >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger >>>>>>>>> wrote: >>>>>>>>>> Not my call. >>>>>>>>>> >>>>>>>>>> I can well understand if the reasons behind the special >>>>>>>>>> treatment of >>>>>>>>>> 'start_phases' have been forgotten by those maintaining the >>>>>>>>>> code. >>>>>>>>>> >>>>>>>>>> A closer analysis might reveal whether backward compatibility >>>>>>>>>> has >>>>>>>>>> already been sufficiently compromised that it is now time to >>>>>>>>>> Make It >>>>>>>>>> Right >>>>>>>>>> (?). >>>>>>>>>> >>>>>>>>>> Even the old AXD 301 project, for which the oddity was >>>>>>>>>> introduced in >>>>>>>>>> the first place, took the first opportunity to make the code >>>>>>>>>> fully >>>>>>>>>> compatible with the new semantics. >>>>>>>>>> >>>>>>>>>> BR, >>>>>>>>>> Ulf W >>>>>>>>>> >>>>>>>>>> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote: >>>>>>>>>> >>>>>>>>>>> I can make the change and add it to the branch I created, but >>>>>>>>>>> the >>>>>>>>>>> question is: should I? I'm not really that well informed about >>>>>>>>>>> the >>>>>>>>>>> history of this value. All I can say is that the parts that >>>>>>>>>>> care >>>>>>>>>>> about >>>>>>>>>>> the 'start_phases' entry in reltool and systools assume that it >>>>>>>>>>> will >>>>>>>>>>> be an empty list when it is not set and fail otherwise. >>>>>>>>>>> >>>>>>>>>>> Let me know if I have to modify my patch to make it acceptable >>>>>>>>>>> for >>>>>>>>>>> inclusion in OTP. >>>>>>>>>>> >>>>>>>>>>> Juanjo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger >>>>>>>>>>> wrote: >>>>>>>>>>>> Hmm, there's an old catch here. Someone will have to hollar if >>>>>>>>>>>> it >>>>>>>>>>>> is >>>>>>>>>>>> no >>>>>>>>>>>> longer relevant - but if it isn't, some documentation patch is >>>>>>>>>>>> called >>>>>>>>>>>> for. >>>>>>>>>>>> >>>>>>>>>>>> In >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2 >>>>>>>>>>>> >>>>>>>>>>>> StartType defines the type of start: >>>>>>>>>>>> >>>>>>>>>>>> normal if it's a normal startup. >>>>>>>>>>>> normal also if the application is distributed and started at >>>>>>>>>>>> the >>>>>>>>>>>> current >>>>>>>>>>>> node due to a failover from another node, and the application >>>>>>>>>>>> specification >>>>>>>>>>>> key start_phases == undefined. >>>>>>>>>>>> {takeover,Node} if the application is distributed and started >>>>>>>>>>>> at >>>>>>>>>>>> the >>>>>>>>>>>> current >>>>>>>>>>>> node due to a takeover from Node, either because >>>>>>>>>>>> application:takeover/2 has >>>>>>>>>>>> been called or because the current node has higher priority >>>>>>>>>>>> than >>>>>>>>>>>> Node. >>>>>>>>>>>> {failover,Node} if the application is distributed and started >>>>>>>>>>>> at >>>>>>>>>>>> the >>>>>>>>>>>> current >>>>>>>>>>>> node due to a failover from Node, and the application >>>>>>>>>>>> specification >>>>>>>>>>>> key start_phases /= undefined. >>>>>>>>>>>> >>>>>>>>>>>> Note that StartType = {failover, Node} is only used if >>>>>>>>>>>> start_phases >>>>>>>>>>>> /= >>>>>>>>>>>> undefined. I will guess that it is for this reason that >>>>>>>>>>>> start_phases >>>>>>>>>>>> is >>>>>>>>>>>> actually set to undefined as default. If it isn't, it was a >>>>>>>>>>>> happy >>>>>>>>>>>> coincidence, since it actually preserves backward >>>>>>>>>>>> compatibility. >>>>>>>>>>>> >>>>>>>>>>>> This particular oddity was introduced many years ago, in the >>>>>>>>>>>> 90s - >>>>>>>>>>>> possibly >>>>>>>>>>>> even before Erlang was released as Open Source, so the legacy >>>>>>>>>>>> argument may >>>>>>>>>>>> not be that relevant. >>>>>>>>>>>> >>>>>>>>>>>> OTOH, I don't think many people use the start_phases >>>>>>>>>>>> attribute, so >>>>>>>>>>>> even new >>>>>>>>>>>> code might break if the Mod:start/2 function is suddenly >>>>>>>>>>>> called >>>>>>>>>>>> with >>>>>>>>>>>> a >>>>>>>>>>>> StartType that was never seen before. >>>>>>>>>>>> >>>>>>>>>>>> BR, >>>>>>>>>>>> Ulf W >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote: >>>>>>>>>>>> >>>>>>>>>>>> The default value for 'start_phases' in .app files should be >>>>>>>>>>>> [], >>>>>>>>>>>> but >>>>>>>>>>>> it is incorrectly set to 'undefined' when generating a >>>>>>>>>>>> release. >>>>>>>>>>>> This >>>>>>>>>>>> happens when the original .app file does not set a value for >>>>>>>>>>>> 'start_phases' explicitly. >>>>>>>>>>>> >>>>>>>>>>>> The reltool application defines its own copy of a record to >>>>>>>>>>>> handle >>>>>>>>>>>> .app files (#app_info{}, defined in >>>>>>>>>>>> lib/reltool/src/reltool.hrl) >>>>>>>>>>>> that >>>>>>>>>>>> has different default values than the one used by systools >>>>>>>>>>>> (#application{}, defined in lib/sasl/src/systools.hrl). In >>>>>>>>>>>> particular, >>>>>>>>>>>> the 'start_phases' entry is assumed by all of OTP to be [] >>>>>>>>>>>> when it >>>>>>>>>>>> is >>>>>>>>>>>> not explicitly set but reltool sets it to 'undefined' by >>>>>>>>>>>> default. >>>>>>>>>>>> This >>>>>>>>>>>> causes badmatch errors when trying to generate release >>>>>>>>>>>> upgrades. >>>>>>>>>>>> >>>>>>>>>>>> Without this patch, all of the rebar examples that generate >>>>>>>>>>>> release >>>>>>>>>>>> upgrades that I've found on the web will fail. The bug was >>>>>>>>>>>> introduced >>>>>>>>>>>> in R14A. >>>>>>>>>>>> >>>>>>>>>>>> git fetch git://github.com/jcomellas/otp.git >>>>>>>>>>>> jc-fix-default-start-phases >>>>>>>>>>>> >>>>>>>>>>>> Juanjo >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> erlang-patches mailing list >>>>>>>>>>>> erlang-patches@REDACTED >>>>>>>>>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> erlang-patches mailing list >>>>>>>> erlang-patches@REDACTED >>>>>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>>>> >>>>> >> > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From carlsson.richard@REDACTED Tue Jan 17 16:36:21 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 17 Jan 2012 16:36:21 +0100 Subject: [erlang-patches] update to mnesia-lock-conflict-events Message-ID: <4F159575.5020302@gmail.com> We realized that report_info was a better choice than report_warning for this patch. Please refetch: git fetch git://github.com/richcarl/otp.git mnesia-lock-conflict-events /Richard From ingela@REDACTED Wed Jan 18 17:31:15 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 18 Jan 2012 17:31:15 +0100 Subject: [erlang-patches] SSL distribution fixes In-Reply-To: References: <291DBF2D-AB8F-40A5-A137-51736D95AC9D@kallisys.net> <4F142C83.7020406@erix.ericsson.se> Message-ID: <4F16F3D3.8030404@erix.ericsson.se> Hi! Paul Guyot wrote: > Le 16 janv. 2012 ? 14:56, Ingela Anderton Andin a ?crit : > > >>> This probably is what happens. The other bug I saw is that the client can timeout (using dist_utils:timer) while the proxy doesn't handle this. >>> >>> What is the rationale behind the use of the proxy? Isn't it related to the old implementation of SSL? >>> >>> >>> >> We want to avoid having a driver. >> > > Ingela, > > Thank you for your replies. > > I still do not fully understand the way distribution over TLS works. I've just read in the (old) documentation that proto_dist requires a driver. Is this such a driver that you try to avoid? Is inet_ssl_dist using the same driver as inet_tcp_dist and hence requires a proxy? Is this why inet_tls_dist cannot use ssl:send/2 and ssl:recv/3 as f_recv and f_send handlers (lines 244 and 248)? > > ssl:send/recv operates on ssl-sockes. ssl-sockets are not the same thing as inet-sockets that will be used in the inet callback-functions in inet_tls_dist. New ssl is a pure erlang application, this is sort of a problem as when starting the erlang distribution you are not able to start erlang applications yet, this is solved by "cloning" the ssl-application hanging it under the kernel application supervisor. Then all distribution messages are sent from erts to erlang and handled by erlang ssl and sent back to erts that knows nothing about the SSL/TLS-handshaking and TLS/SSL-decryption/encryption. This is a short and simplified description, but hope it helps. Regards Ingela Erlang/OTP team -Ericsson AB From henrik@REDACTED Thu Jan 19 16:29:58 2012 From: henrik@REDACTED (Henrik Nord) Date: Thu, 19 Jan 2012 16:29:58 +0100 Subject: [erlang-patches] [PATCH] fix EST leak in snmp_note_store In-Reply-To: <201111071628.32059.sg2342@googlemail.com> References: <201111071628.32059.sg2342@googlemail.com> Message-ID: <4F1836F6.4010305@erlang.org> Hi This fails on Linux 2.6.27.54-0.2-default, SLES 11-0 (x86_64) notes memory (not empty): 560 wait 3 times the GC timeout *** [2012:01:16 05:00:59 4721] SNMP A-NOTE-STORE DEBUG *** timeout *** [2012:01:16 05:01:00 4229] SNMP A-NOTE-STORE DEBUG *** timeout *** [2012:01:16 05:01:00 4725] SNMP A-NOTE-STORE LOG *** info notes memory (after GC): 339 verify notes db memory *** [2012:01:16 05:01:00 4726] SNMP A-NOTE-STORE DEBUG *** terminate: {#Ref<0.0.0.98467>,2515150, {'EXIT', {{badmatch,300}, [{snmp_note_store_test,gc_timer,1, [{file,"snmp_note_store_test.erl"},{line,288}]}, {test_server,ts_tc,3, [{file,"test_server.erl"},{line,1635}]}, {test_server,run_test_case_eval1,6, [{file,"test_server.erl"},{line,1182}]}, {test_server,run_test_case_eval,9, [{file,"test_server.erl"},{line,1123}]}]}}, [{snmp_note_store_test,gc_timer,288}, {test_server,ts_tc,1635}, {test_server,run_test_case_eval1,1182}, {test_server,run_test_case_eval,1123}], []} On 11/07/2011 05:28 PM, Stefan Grundmann wrote: > fix GC timer in snmp_note_store > > in deactivate_timer/1 the new state of the timer is not set correctly, > instead the timeout value set to 'false', resulting in a "crash loop" > when the snmp note store process tries to restart the timer process. > > the incorrect activation state also leads to an ETS memory leak: > an expired note will not get deleted except when > snmp_note_store:get_note/2 is called with its key - the GC mechanism > does not work because a deactivated timer will never be activated again. > > Commit that corrects this issue: > > git fetch git://github.com/sg2342/otp.git fix-snmp_note_store_timer > > Inline diff: > > diff --git a/lib/snmp/src/misc/snmp_note_store.erl > b/lib/snmp/src/misc/snmp_note > index a21a620..5bb5cb4 100644 > --- a/lib/snmp/src/misc/snmp_note_store.erl > +++ b/lib/snmp/src/misc/snmp_note_store.erl > @@ -282,7 +282,7 @@ deactivate_timer(#state{timer = Pid, active = true} = > State) > receive > deactivated -> ok > end, > - State#state{timeout = false}; > + State#state{active = false}; > deactivate_timer(State) -> > State. > > > Regression test: > > git fetch git://github.com/sg2342/otp.git snmp_note_store_timer-tc > > best regards > > Stefan Grundmann > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Thu Jan 19 16:55:58 2012 From: henrik@REDACTED (Henrik Nord) Date: Thu, 19 Jan 2012 16:55:58 +0100 Subject: [erlang-patches] [PATCH] fix EST leak in snmp_note_store In-Reply-To: <201111071628.32059.sg2342@googlemail.com> References: <201111071628.32059.sg2342@googlemail.com> Message-ID: <4F183D0E.2040908@erlang.org> Hi again. We already did merge your patch. So you can ignore my previous email about said patch and its failing test-case. Sorry for your inconvenience. -- /Henrik Nord Erlang/OTP From jose.valim@REDACTED Fri Jan 20 10:14:23 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Fri, 20 Jan 2012 10:14:23 +0100 Subject: [erlang-patches] Support ** for recursion in filelib:wildcard Message-ID: Some programming languages/softwares (Bash, RACF, Ruby, ...) support "**" for automatic directory recursion when doing a glob. A very convenient use of this feature is to get all files recursively with a given extension: filelib:wildcard("src/**/*.erl"). Notice we don't need to loop recursively and it also requires fewer filesystem lookups. I am aware filelib:fold_files allows recursion, but I consider filelib:wildcard simpler to use. My proposal is to extend filelib:wildcard to support "**". I can provide a patch with docs if you agree to have this feature merged in. * Jos? Valim www.plataformatec.com.br Founder and Lead Developer * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Fri Jan 20 13:33:37 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Fri, 20 Jan 2012 13:33:37 +0100 Subject: [erlang-patches] Update module attributes page Message-ID: The page on module attributes does not mention on_load and callback attributes: http://www.erlang.org/doc/reference_manual/modules.html Should I submit a patch to update those or they are not mentioned there on purpose? * Jos? Valim www.plataformatec.com.br Founder and Lead Developer * -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Fri Jan 20 14:27:33 2012 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 20 Jan 2012 14:27:33 +0100 Subject: [erlang-patches] Update module attributes page In-Reply-To: References: Message-ID: <4F196BC5.4070309@erlang.org> On 2012-01-20 13:33, Jos? Valim wrote: > The page on module attributes does not mention on_load and callback > attributes: > > http://www.erlang.org/doc/reference_manual/modules.html > > Should I submit a patch to update those or they are not mentioned > there on purpose? Ah something that was overlooked I guess. =) -on_load is described here http://www.erlang.org/doc/reference_manual/code_loading.html but i feel it should definitely be described with modules as well and link to code loading. Feel free to submit a patch! =) (I actually had trouble finding on_load docs just the other day, so I would welcome it). Actually anyone that feels the docs should have something that isn't there should submit a patch for it. I some cases internal exported functions are not documented to deter others from using it but normally we welcome any clarification and beautification patches to the docs. Regards, Bj?rn-Egil Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From gomoripeti@REDACTED Sun Jan 22 12:36:03 2012 From: gomoripeti@REDACTED (=?ISO-8859-1?Q?Peti_G=F6m=F6ri?=) Date: Sun, 22 Jan 2012 12:36:03 +0100 Subject: [erlang-patches] observer tv fixes Message-ID: Hi, finally a table visualizer in wx. unfortunately it crashed pretty easily when I tried to click here and there. Here are some tiny improvement proposals to fix some of the issues: - when canceling in Edit Object window 'cancel' atom is expected to be returned - when parsing edited object according to erl_parse docs "token list must end with the dot token"; ensure this is always true - handle parse errors in edited objects - handle invalid regexp in search - MEssageDialog error terms even if they are not strings - show printable strings in objects instead of integer lists (like old tv did) (ugly: 9999 terminal width) thanks Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: observer_lib.erl.patch Type: application/octet-stream Size: 935 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: observer_tv_table.erl.patch Type: application/octet-stream Size: 1556 bytes Desc: not available URL: From henrik@REDACTED Mon Jan 23 11:22:26 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 23 Jan 2012 11:22:26 +0100 Subject: [erlang-patches] DTrace patch, review draft #3 In-Reply-To: <7822.1322004858@snookles.snookles.com> References: <7822.1322004858@snookles.snookles.com> Message-ID: <4F1D34E2.5070709@erlang.org> Hi Scott! Been a while sens we got any news for this. The last branch you submitted, this draft #3 I think it was, did not compile, and you where in contact with Bj?rn and or Bj?rn-Egil. Then there was a release here and we did not really think about this for a while. So now im looking at my branches and there are no Dtrace here. Do you need assistance from us with something? there was talk about loader support? Let me know what version of the branch you want us to test and how/if we may be of assistance so that we can add that to our plans. -- /Henrik Nord Erlang/OTP From dangud@REDACTED Tue Jan 24 09:52:57 2012 From: dangud@REDACTED (Dan Gudmundsson) Date: Tue, 24 Jan 2012 09:52:57 +0100 Subject: [erlang-patches] observer tv fixes In-Reply-To: References: Message-ID: Thanks I have already fixed most of the issues on an internal branch. I will grab the regexp fixes which I missed. I guess I will have to copy tv's formatting as well, since this is the second request on that issue. /Dan On Sun, Jan 22, 2012 at 12:36 PM, Peti G?m?ri wrote: > Hi, > > finally a table visualizer in wx. > unfortunately it crashed pretty easily when I tried to click here and there. > Here are some tiny improvement proposals to fix some of the issues: > - when canceling in Edit Object window 'cancel' atom is expected to be returned > - when parsing edited object according to erl_parse docs "token list > must end with the dot token"; ensure this is always true > - handle parse errors in edited objects > - handle invalid regexp in search > - MEssageDialog error terms even if they are not strings > - show printable strings in objects instead of integer lists (like old > tv did) (ugly: 9999 terminal width) > > > thanks > Peter > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From mattevans123@REDACTED Wed Jan 25 21:38:20 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Wed, 25 Jan 2012 15:38:20 -0500 Subject: [erlang-patches] [erlang-bugs] Observer table viewer crash - Patch??? In-Reply-To: References: , Message-ID: Ok, as well as the problem below it appears that observer_tv_table was missing the handle_info/2 for the atom refresh_interval. The patch attached to this email appears to fix this. Feel free to try it... Again, I'm using R15B on Ubuntu. Thanks Matt From: mattevans123@REDACTED To: erlang-bugs@REDACTED Date: Wed, 25 Jan 2012 13:06:27 -0500 Subject: Re: [erlang-bugs] Observer table viewer crash One additional point. I added the following tuple {true,20} to the "timer" parameter in the state record of observer_tv_table.erl It didn't crash. What is interesting though is that it refreshed the "parent" window, not the child window. Matt From: mattevans123@REDACTED To: erlang-bugs@REDACTED Date: Wed, 25 Jan 2012 11:20:18 -0500 Subject: [erlang-bugs] Observer table viewer crash Hi When I use the table viewer, select a table (any table) and "Edit->Refresh Interval" I get the following error. I am running R15B on Ubuntu 11.10. Interestingly I can select "View->Refresh Interval" from the table list window. The crash happens immediately, the dialog doesn't even open. Thanks Matt Child crashed exiting: <0.17131.1> {function_clause, [{observer_lib,interval_dialog, [{wx_ref,294,wxListCtrl,[]}, undefined,10,300], [{file,"observer_lib.erl"},{line,40}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"}, {line,374}]}, {wx_object,handle_msg,5, [{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]}(plexxi@REDACTED)13> =ERROR REPORT==== 25-Jan-2012::08:14:38 ===** wx object server <0.17134.1> terminating ** Last message in was {wx,402, {wx_ref,268,wxFrame,[]}, [], {wxCommand,command_menu_selected,[],0,0}}** When Server state == {state, {wx_ref,220,wxListCtrl,[]}, {wx_ref,268,wxFrame,[]}, {wx_ref,294,wxListCtrl,[]}, {wx_ref,285,wxStatusBar,[]}, {wx_ref,293,wxBoxSizer,[]}, {search,true, {wx_ref,295,wxBoxSizer,[]}, 'Search Area', {wx_ref,298,wxTextCtrl,[]}, {wx_ref,309,wxTextCtrl,[]}, {{wx_ref,300,wxRadioButton,[]}, {wx_ref,302,wxRadioButton,[]}, {wx_ref,304,wxCheckBox,[]}}, undefined}, undefined,plexxi@REDACTED,2,<0.17135.1>,ets, {tab,bob,81944,0,1228,<0.38.0>,ignore,protected, set,1,none,false,false,undefined,undefined}, {attrs, {wx_ref,287,wxListItemAttr,[]}, {wx_ref,288,wxListItemAttr,[]}, {wx_ref,289,wxListItemAttr,[]}, {wx_ref,290,wxListItemAttr,[]}, {wx_ref,291,wxListItemAttr,[]}}, undefined}** Reason for termination == ** {function_clause, [{observer_lib,interval_dialog, [{wx_ref,294,wxListCtrl,[]},undefined,10,300], [{file,"observer_lib.erl"},{line,40}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"},{line,374}]}, {wx_object,handle_msg,5,[{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: observer_tv_table.erl.patch Type: text/x-patch Size: 552 bytes Desc: not available URL: From dangud@REDACTED Thu Jan 26 08:35:07 2012 From: dangud@REDACTED (Dan Gudmundsson) Date: Thu, 26 Jan 2012 08:35:07 +0100 Subject: [erlang-patches] [erlang-bugs] Observer table viewer crash - Patch??? In-Reply-To: References: Message-ID: Thanks for the bug reports (and patches). I did some late refactoring there, seems I broke a lot of things. I need to come up with away to automatically test at least the basic functionality. The timer was off by default for tables, I didn't want it to automatically refresh since the tables can so large. You think the tables should refresh automatically by default? /Dan On Wed, Jan 25, 2012 at 9:38 PM, Matthew Evans wrote: > Ok, as well as the problem below it appears that observer_tv_table was > missing the handle_info/2 for the atom refresh_interval. > > The patch attached to this email appears to fix this. > > Feel free to try it... > > Again, I'm using R15B on Ubuntu. > > Thanks > > Matt > > > ________________________________ > From: mattevans123@REDACTED > To: erlang-bugs@REDACTED > Date: Wed, 25 Jan 2012 13:06:27 -0500 > Subject: Re: [erlang-bugs] Observer table viewer crash > > One additional point. > > I added the following tuple {true,20} to the "timer" parameter in the state > record of observer_tv_table.erl > > It didn't crash. > > What is interesting though is that it refreshed the "parent" window, not the > child window. > > Matt > > ________________________________ > From: mattevans123@REDACTED > To: erlang-bugs@REDACTED > Date: Wed, 25 Jan 2012 11:20:18 -0500 > Subject: [erlang-bugs] Observer table viewer crash > > Hi > > When I use the table viewer, select a table (any table) and "Edit->Refresh > Interval" I get the following error. > > I am running R15B on Ubuntu 11.10. Interestingly I can select "View->Refresh > Interval" from the table list window. > > The crash happens immediately, the dialog doesn't even open. > > Thanks > > Matt > > > Child crashed exiting: ?<0.17131.1> {function_clause, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{observer_lib,interval_dialog, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{wx_ref,294,wxListCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? undefined,10,300], > > ?[{file,"observer_lib.erl"},{line,40}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {observer_tv_table,handle_event,2, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{file,"observer_tv_table.erl"}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {line,374}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_object,handle_msg,5, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{file,"wx_object.erl"},{line,394}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {proc_lib,init_p_do_apply,3, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{file,"proc_lib.erl"},{line,227}]}]} > (plexxi@REDACTED)13> > =ERROR REPORT==== 25-Jan-2012::08:14:38 === > ** wx object server <0.17134.1> terminating > ** Last message in was {wx,402, > ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wx_ref,268,wxFrame,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ?[], > ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wxCommand,command_menu_selected,[],0,0}} > ** When Server state == {state, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,220,wxListCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,268,wxFrame,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,294,wxListCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,285,wxStatusBar,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,293,wxBoxSizer,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {search,true, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,295,wxBoxSizer,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 'Search Area', > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,298,wxTextCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,309,wxTextCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {{wx_ref,300,wxRadioButton,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wx_ref,302,wxRadioButton,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wx_ref,304,wxCheckBox,[]}}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? undefined}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? undefined,plexxi@REDACTED,2,<0.17135.1>,ets, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {tab,bob,81944,0,1228,<0.38.0>,ignore,protected, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? set,1,none,false,false,undefined,undefined}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {attrs, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,287,wxListItemAttr,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,288,wxListItemAttr,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,289,wxListItemAttr,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,290,wxListItemAttr,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,291,wxListItemAttr,[]}}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? undefined} > ** Reason for termination == > ** {function_clause, > ? ? ? ?[{observer_lib,interval_dialog, > ? ? ? ? ? ? [{wx_ref,294,wxListCtrl,[]},undefined,10,300], > ? ? ? ? ? ? [{file,"observer_lib.erl"},{line,40}]}, > ? ? ? ? {observer_tv_table,handle_event,2, > ? ? ? ? ? ? [{file,"observer_tv_table.erl"},{line,374}]}, > ? ? ? ? {wx_object,handle_msg,5,[{file,"wx_object.erl"},{line,394}]}, > ? ? ? ? {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} > > > _______________________________________________ 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 > From pguyot@REDACTED Sun Jan 29 16:25:50 2012 From: pguyot@REDACTED (Paul Guyot) Date: Sun, 29 Jan 2012 16:25:50 +0100 Subject: [erlang-patches] SSL distribution proxy processes must exit when sockets close Message-ID: Hello, There is a bug in SSL distribution : the proxy processes do not exit if the sockets close during the setup. Since SSL distribution connections can be very slow to setup, this situation happens to be quite common on a production cluster and can yield to thousands of processes with close messages in their queue. The following patch, based on maint branch, fixes this bug by simply exiting when a close message is received during setup. https://github.com/pguyot/otp/compare/fix-ssl_tls_dist_proxy-setup-loop git fetch git://github.com/pguyot/otp.git fix-ssl_tls_dist_proxy-setup-loop Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From henrik@REDACTED Mon Jan 30 14:02:11 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 30 Jan 2012 14:02:11 +0100 Subject: [erlang-patches] SSL distribution proxy processes must exit when sockets close In-Reply-To: References: Message-ID: <4F2694D3.3080409@erlang.org> Hi We would like this patch, but with tests. Could that be arranged? Thank you! On 01/29/2012 04:25 PM, Paul Guyot wrote: > Hello, > > There is a bug in SSL distribution : the proxy processes do not exit if the sockets close during the setup. Since SSL distribution connections can be very slow to setup, this situation happens to be quite common on a production cluster and can yield to thousands of processes with close messages in their queue. > > The following patch, based on maint branch, fixes this bug by simply exiting when a close message is received during setup. > > https://github.com/pguyot/otp/compare/fix-ssl_tls_dist_proxy-setup-loop > git fetch git://github.com/pguyot/otp.git fix-ssl_tls_dist_proxy-setup-loop > > Paul -- /Henrik Nord Erlang/OTP From pguyot@REDACTED Mon Jan 30 14:17:28 2012 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 30 Jan 2012 14:17:28 +0100 Subject: [erlang-patches] SSL distribution proxy processes must exit when sockets close In-Reply-To: <4F2694D3.3080409@erlang.org> References: <4F2694D3.3080409@erlang.org> Message-ID: <8CDF04A9-F5F3-4C8E-A9AC-81EBD49BABCD@kallisys.net> Hi, In this very case, the bug is obvious, the fix is trivial, but a test would either be : - too simplistic to actually add value to the test suite (it would use a fake node that would initiate a connection and then close the socket, but such a node would be implementation or at least protocol-dependent) ; or - undeterministic (the leak typically happens under high loads, especially between nodes on two different servers). In particular, a test with real nodes would very likely fail when some important performance issues of SSL distribution are solved (you need to close the socket during the handshake). Paul Le 30 janv. 2012 ? 14:02, Henrik Nord a ?crit : > Hi > We would like this patch, but with tests. > > Could that be arranged? > > Thank you! > > On 01/29/2012 04:25 PM, Paul Guyot wrote: >> Hello, >> >> There is a bug in SSL distribution : the proxy processes do not exit if the sockets close during the setup. Since SSL distribution connections can be very slow to setup, this situation happens to be quite common on a production cluster and can yield to thousands of processes with close messages in their queue. >> >> The following patch, based on maint branch, fixes this bug by simply exiting when a close message is received during setup. >> >> https://github.com/pguyot/otp/compare/fix-ssl_tls_dist_proxy-setup-loop >> git fetch git://github.com/pguyot/otp.git fix-ssl_tls_dist_proxy-setup-loop >> >> Paul > > -- > /Henrik Nord Erlang/OTP > -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From henrik@REDACTED Tue Jan 31 10:02:43 2012 From: henrik@REDACTED (Henrik Nord) Date: Tue, 31 Jan 2012 10:02:43 +0100 Subject: [erlang-patches] SSL distribution proxy processes must exit when sockets close In-Reply-To: <8CDF04A9-F5F3-4C8E-A9AC-81EBD49BABCD@kallisys.net> References: <4F2694D3.3080409@erlang.org> <8CDF04A9-F5F3-4C8E-A9AC-81EBD49BABCD@kallisys.net> Message-ID: <4F27AE33.5060604@erlang.org> Hi again Paul we did some talking here, and decided that you are right, and that the patch should be correct. So I have included it in 'pu' now. On 01/30/2012 02:17 PM, Paul Guyot wrote: > Hi, > > In this very case, the bug is obvious, the fix is trivial, but a test would either be : > - too simplistic to actually add value to the test suite (it would use a fake node that would initiate a connection and then close the socket, but such a node would be implementation or at least protocol-dependent) ; or > - undeterministic (the leak typically happens under high loads, especially between nodes on two different servers). In particular, a test with real nodes would very likely fail when some important performance issues of SSL distribution are solved (you need to close the socket during the handshake). > > Paul > > Le 30 janv. 2012 ? 14:02, Henrik Nord a ?crit : > >> Hi >> We would like this patch, but with tests. >> >> Could that be arranged? >> >> Thank you! >> >> On 01/29/2012 04:25 PM, Paul Guyot wrote: >>> Hello, >>> >>> There is a bug in SSL distribution : the proxy processes do not exit if the sockets close during the setup. Since SSL distribution connections can be very slow to setup, this situation happens to be quite common on a production cluster and can yield to thousands of processes with close messages in their queue. >>> >>> The following patch, based on maint branch, fixes this bug by simply exiting when a close message is received during setup. >>> >>> https://github.com/pguyot/otp/compare/fix-ssl_tls_dist_proxy-setup-loop >>> git fetch git://github.com/pguyot/otp.git fix-ssl_tls_dist_proxy-setup-loop >>> >>> Paul >> -- >> /Henrik Nord Erlang/OTP >> -- /Henrik Nord Erlang/OTP