From erlang@REDACTED Fri Feb 8 21:55:54 2008 From: erlang@REDACTED (Peter Lund) Date: Fri, 08 Feb 2008 21:55:54 +0100 Subject: [erlang-patches] ssh rekeying missing (was: Erlang/OTP R12B-1 has been released) In-Reply-To: References: Message-ID: <47ACC1DA.1020704@lundata.se> Hello, I noticed you did not include the fix I reported in for the "rekeying bug". SSH rekeying is often initiated by either party client or server after 1GB of transferred data (or because the max time for ssh keys has been reached). In the current OTP version, neither the ssh client nor ssh server is able to handle the rekeying procedure. Here attached you find the unified diff (for the latest R12B-1 ssh_transport.erl) and attached you the full new version of the file. /Peter Bjorn Gustavsson skrev: > Bug fix release : otp_src_R12B-1 > Build date : 2008-02-06 > > This is bug fix release 1 for the R12B release. > You can download the full source distribution from > > http://www.erlang.org/download/otp_src_R12B-1.tar.gz > http://www.erlang.org/download/otp_src_R12B-1.readme > > Note: To unpack the TAR archive you need a GNU TAR compatible program. > > For installation instructions please read the README that is part of > the distribution. > > The Windows binary distribution can be downloaded from > > http://www.erlang.org/download/otp_win32_R12B-1.exe > > > On-line documentation can be found at http://www.erlang.org/doc/. > You can also download the complete HTML documentation or the Unix manual files > > http://www.erlang.org/download/otp_doc_html_R12B-1.tar.gz > http://www.erlang.org/download/otp_doc_man_R12B-1.tar.gz > > We also want to thank those that sent us patches, suggestions and bug > reports, > > The OTP Team > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh_transport.erl.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh_transport.erl.gz Type: application/x-gzip Size: 12445 bytes Desc: not available URL: From ola@REDACTED Wed Feb 13 15:35:29 2008 From: ola@REDACTED (Ola Samuelsson) Date: Wed, 13 Feb 2008 15:35:29 +0100 Subject: [erlang-patches] SNMP Agent bugs Message-ID: Hi, I've found a few bugs in the SNMP Agent application in OTP. We are running an older OTP release (R10B-10) but I suspect that the SNMP application haven't been updated for a while. Anyway, I've listed the problems I've found below if you're interested. Ola Samuelsson ola@REDACTED ---------------------------------------- The MIB-compiler does not suppport a name assignment which is sequence of numbers, only a father object name followed by a sequence of numbers. ---------------------------------------- Grammar looked like this: (line 392 in snmpc_mib_gram.yrl) % Returns: {FatherName, SubIndex} (the parent) nameassign -> implies '{' fatherobjectname parentintegers '}' : {'$3', '$4' }. Added another rule to handle case with only numbers: % Returns: {FatherName, SubIndex} (the parent) nameassign -> implies '{' fatherobjectname parentintegers '}' : {'$3', '$4' }. nameassign -> implies '{' parentintegers '}' : { root, '$3'}. ---------------------------------------- The MIB-compiler does not recognize well-known-names as top parents. The names 'ccitt' (0) , 'iso' (1) and 'joint-iso-ccitt' (2), should be familiar to the SNMP compiler. ---------------------------------------- Quick solution was to fix the import in snmpc_lib.erl and register these names before the imports take place. (line 176 in snmpc_lib.erl) import(ImportList) -> + %% FIX: Added well-known-nodes + WellKnownNodes= [ makeInternalNode(ccitt,[0]), + makeInternalNode(iso, [1]), + makeInternalNode('joint-iso-ccitt',[2])], + lists:foreach(fun(ME) -> + register_oid(undef, ME#me.aliasname, root, ME#me.oid) + end, + WellKnownNodes), lists:foreach(fun import_mib/1, ImportList). ---------------------------------------- TRAP sending in SNMP does not give correct order on the varbinds. ---------------------------------------- The agent tries to lookup the varbinds for values that are not given by the user, but it reverses the order of the looked up objects. The problem can be solved in many ways, and this is a lazy fix for it. (line 404? snmpa_trap.erl) get_all(VariablesWithType) -> {Order, Varbinds} = extract_order(VariablesWithType, 1), case snmpa_agent:do_get(snmpa_acm:get_root_mib_view(), Varbinds, true) of + {noError, _, NewVarbinds} -> + %% Bug... + %% Can't do contract order on the returned list of + %% Varbinds since it's reversed. + %% It has an org_index on it which tells the varbind order, + %% and if we sort on that first, + %% the contract_order/2 will be correct. + %% + NewVarbinds1 = lists:keysort(#varbind.org_index,NewVarbinds), + contract_order(Order, NewVarbinds1); {ErrorStatus, ErrorIndex, _} -> user_err("snmpa_trap: get operation failed {~w, ~w}" "~n in ~w", [ErrorStatus, ErrorIndex, Varbinds]), throw(error) end. From alceste@REDACTED Thu Feb 14 14:43:46 2008 From: alceste@REDACTED (Alceste Scalas) Date: Thu, 14 Feb 2008 14:43:46 +0100 Subject: [erlang-patches] New yecc:file/2 option: parserpackage Message-ID: <1202996626.6390.104.camel@gnatziu.crs4.it> Hello, the following patch adds a new option to yecc:file/2: {parserpackage, ParserPackage}. Use ParserPackage as the package of the Erlang parser code that is generated. The default ("") is not to put package names in front of the parser module. This option allows to generate parsers within Erlang packages: for example, given the file src/foo/bar/parser.yrl, a call like yecc:file(parser, [{parserpackage, 'foo.bar'}]) will generate parser.erl with module 'foo.bar.parser' (instead of 'parser' alone). Regards, alceste -- Alceste Scalas CRS4 - http://www.crs4.it/ -------------- next part -------------- A non-text attachment was scrubbed... Name: yecc-parserpackage.diff Type: text/x-patch Size: 2570 bytes Desc: not available URL: From alceste@REDACTED Thu Feb 14 14:39:37 2008 From: alceste@REDACTED (Alceste Scalas) Date: Thu, 14 Feb 2008 14:39:37 +0100 Subject: [erlang-patches] Oops! (was: New yecc:file/2 option: parsermodule) In-Reply-To: <1202996176.6390.93.camel@gnatziu.crs4.it> References: <1202996176.6390.93.camel@gnatziu.crs4.it> Message-ID: <1202996377.6390.99.camel@gnatziu.crs4.it> On 14/02/2008 at 14.36 +0100, Alceste Scalas wrote: > the following patch adds a new option to yecc:file/2: > [...] Oops! Sorry, I clicked on the "send" button by mistake. The correct email will arrive in a few seconds. -- Alceste Scalas CRS4 - http://www.crs4.it/ From alceste@REDACTED Thu Feb 14 14:36:16 2008 From: alceste@REDACTED (Alceste Scalas) Date: Thu, 14 Feb 2008 14:36:16 +0100 Subject: [erlang-patches] New yecc:file/2 option: parsermodule Message-ID: <1202996176.6390.93.camel@gnatziu.crs4.it> Hello, the following patch adds a new option to yecc:file/2: {parserpackage, ParserPackage}. Use ParserPackage as the package of the Erlang parser code that is generated. The default ("") is not to put package names in front of the parser module. This option allows to generate parsers within Erlang packages: for example, given the file src/foo/bar/parser.yrl, a call like yecc:file(parser, [{parserpackage, 'foo.bar'}]) will generate parser.erl with module 'foo.bar.parser' (instead of 'parser' alone). Regards, alceste -- Alceste Scalas CRS4 - http://www.crs4.it/ From ola@REDACTED Thu Feb 14 16:19:17 2008 From: ola@REDACTED (Ola Samuelsson) Date: Thu, 14 Feb 2008 16:19:17 +0100 Subject: [erlang-patches] SNMP Agent bugs In-Reply-To: <47B443CF.4000902@erix.ericsson.se> References: <47B443CF.4000902@erix.ericsson.se> Message-ID: <52D9C8D5-2841-42D6-ACA7-0190446C1F6C@tail-f.com> Your welcome. Martin suggested me to send these patches. I did not verify with the OTP R12B release before sending to this forum, so I'm sorry about that. I've checked with the OTP R12B release now and the first two problems is still there at least. (don't have time to check the third fault right now, could be my own fault of course, running a hacked SNMP agent...:-) /ola ola@REDACTED On Feb 14, 2008, at 2:36 PM, Micael Karlberg wrote: > Hi, > > Thanks for the patch. > > The current version of the SNMP application is 4.10.1 and > the application is actively maintained, which your resident > snmp contact (Martin) should know :). > > Regards, > /BMK > > Ola Samuelsson wrote: >> Hi, >> I've found a few bugs in the SNMP Agent application in OTP. >> We are running an older OTP release (R10B-10) but >> I suspect that the SNMP application haven't been updated for a >> while. >> Anyway, I've listed the problems I've found below if you're >> interested. >> Ola Samuelsson >> ola@REDACTED >> ---------------------------------------- >> The MIB-compiler does not suppport a name assignment >> which is sequence of numbers, >> only a father object name followed by a sequence of numbers. >> ---------------------------------------- >> Grammar looked like this: >> (line 392 in snmpc_mib_gram.yrl) >> % Returns: {FatherName, SubIndex} (the parent) >> nameassign -> implies '{' fatherobjectname parentintegers '}' >> : {'$3', '$4' }. >> Added another rule to handle case with only numbers: >> % Returns: {FatherName, SubIndex} (the parent) >> nameassign -> implies '{' fatherobjectname parentintegers '}' >> : {'$3', '$4' }. >> nameassign -> implies '{' parentintegers '}' : { root, '$3'}. >> ---------------------------------------- >> The MIB-compiler does not recognize well-known-names >> as top parents. >> The names 'ccitt' (0) , 'iso' (1) and 'joint-iso-ccitt' (2), >> should be familiar to the SNMP compiler. >> ---------------------------------------- >> Quick solution was to fix the import in snmpc_lib.erl and >> register these names before the imports take place. >> (line 176 in snmpc_lib.erl) >> import(ImportList) -> >> + %% FIX: Added well-known-nodes >> + WellKnownNodes= [ makeInternalNode(ccitt,[0]), >> + makeInternalNode(iso, [1]), >> + makeInternalNode('joint-iso-ccitt',[2])], >> + lists:foreach(fun(ME) -> >> + register_oid(undef, ME#me.aliasname, root, ME#me.oid) >> + end, >> + WellKnownNodes), >> lists:foreach(fun import_mib/1, ImportList). >> ---------------------------------------- >> TRAP sending in SNMP does not give correct order on >> the varbinds. >> ---------------------------------------- >> The agent tries to lookup the varbinds for values that >> are not given by the user, but it reverses the order of >> the looked up objects. >> The problem can be solved in many ways, and this is a lazy fix >> for it. >> (line 404? snmpa_trap.erl) >> get_all(VariablesWithType) -> >> {Order, Varbinds} = extract_order(VariablesWithType, 1), >> case snmpa_agent:do_get(snmpa_acm:get_root_mib_view(), >> Varbinds, true) of >> + {noError, _, NewVarbinds} -> >> + %% Bug... >> + %% Can't do contract order on the returned list of >> + %% Varbinds since it's reversed. >> + %% It has an org_index on it which tells the varbind order, >> + %% and if we sort on that first, >> + %% the contract_order/2 will be correct. >> + %% >> + NewVarbinds1 = lists:keysort(#varbind.org_index,NewVarbinds), >> + contract_order(Order, NewVarbinds1); >> {ErrorStatus, ErrorIndex, _} -> >> user_err("snmpa_trap: get operation failed {~w, ~w}" >> "~n in ~w", >> [ErrorStatus, ErrorIndex, Varbinds]), >> throw(error) >> end. >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-patches > > > > From alceste@REDACTED Thu Feb 14 17:19:04 2008 From: alceste@REDACTED (Alceste Scalas) Date: Thu, 14 Feb 2008 17:19:04 +0100 Subject: [erlang-patches] Absolute module references in Yecc parsers (was: New yecc:file/2 option: parserpackage) In-Reply-To: <1202996626.6390.104.camel@gnatziu.crs4.it> References: <1202996626.6390.104.camel@gnatziu.crs4.it> Message-ID: <1203005944.6390.127.camel@gnatziu.crs4.it> Il giorno gio, 14/02/2008 alle 14.43 +0100, Alceste Scalas ha scritto: > This option allows to generate parsers within Erlang packages: for > example, given the file src/foo/bar/parser.yrl, a call like > > yecc:file(parser, [{parserpackage, 'foo.bar'}]) > > will generate parser.erl with module 'foo.bar.parser' (instead of > 'parser' alone). The following patch may help, too: it makes the generated parsers always use absolute module references, by adding a leading dot to some function calls (both in yecc.erl and yeccpre.hrl). I chose this solution over two other approaches: 1. adding -import(lists) and -import(io_lib) to yeccpre.hrl; 2. asking the Yecc users to explicitly add -import(lists) and -import(io_lib) to the "Erlang code" section of their grammars, when they want to generate parsers inside a package hierarchy. IMHO the patch is clearer (no packaging issues at all) and cleaner (it does not interfere with "Erlang code" sections by adding unexpected imports). Regards, alceste -- Alceste Scalas CRS4 - http://www.crs4.it/ -------------- next part -------------- A non-text attachment was scrubbed... Name: yecc-absmodules.diff Type: text/x-patch Size: 2568 bytes Desc: not available URL: From alceste@REDACTED Fri Feb 15 12:07:23 2008 From: alceste@REDACTED (Alceste Scalas) Date: Fri, 15 Feb 2008 12:07:23 +0100 Subject: [erlang-patches] New yecc:file/2 option: parserpackage (R12B updates) In-Reply-To: <1203005944.6390.127.camel@gnatziu.crs4.it> References: <1202996626.6390.104.camel@gnatziu.crs4.it> <1203005944.6390.127.camel@gnatziu.crs4.it> Message-ID: <1203073643.6390.172.camel@gnatziu.crs4.it> Il giorno gio, 14/02/2008 alle 17.19 +0100, Alceste Scalas ha scritto: > Il giorno gio, 14/02/2008 alle 14.43 +0100, Alceste Scalas ha scritto: > > This option allows to generate parsers within Erlang packages: for > > example, given the file src/foo/bar/parser.yrl, a call like > > > > yecc:file(parser, [{parserpackage, 'foo.bar'}]) > > > > will generate parser.erl with module 'foo.bar.parser' (instead of > > 'parser' alone). > > The following patch may help, too: it makes the generated parsers always > use absolute module references, by adding a leading dot to some function > calls (both in yecc.erl and yeccpre.hrl). D'oh, the previous patches were only tested with OTP-R11B-5 and don't apply cleanly on newer OTP releases. I'm sorry! Here's an updated patch, tested with OTP-R12B-1, that implements both the new 'parserpackage' option and absolute module references in generated parsers. Regards, alceste -- Alceste Scalas CRS4 - http://www.crs4.it/ -------------- next part -------------- A non-text attachment was scrubbed... Name: yecc-r12b-parserpackage.diff Type: text/x-patch Size: 7125 bytes Desc: not available URL: From matthew@REDACTED Wed Feb 20 09:11:31 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Wed, 20 Feb 2008 00:11:31 -0800 Subject: [erlang-patches] Bad format string in erts/emulator/sys/common/erl_check_io.c Message-ID: In large_fd_error_common, erts_dsprintf is called with two %d directives but only one integer argument. --- erl_check_io.c.orig 2008-02-19 23:50:30.000000000 -0800 +++ erl_check_io.c 2008-02-19 23:51:24.000000000 -0800 @@ -741,11 +741,11 @@ #ifdef ERTS_SYS_CONTINOUS_FD_NUMBERS static void -large_fd_error_common(erts_dsprintf_buf_t *dsbufp) +large_fd_error_common(erts_dsprintf_buf_t *dsbufp, ErtsSysFdType fd) { erts_dsprintf(dsbufp, "fd=%d is larger than the largest allowed fd=%d\n", - max_fds - 1); + (int) fd, max_fds - 1); } static void @@ -754,7 +754,7 @@ erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); print_select_op(dsbufp, ix, fd, mode, on); erts_dsprintf(dsbufp, "failed: "); - large_fd_error_common(dsbufp); + large_fd_error_common(dsbufp, fd); erts_send_error_to_logger_nogl(dsbufp); } #endif @@ -796,7 +796,7 @@ erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); print_event_op(dsbufp, ix, fd, event_data); erts_dsprintf(dsbufp, "failed: "); - large_fd_error_common(dsbufp); + large_fd_error_common(dsbufp, fd); erts_send_error_to_logger_nogl(dsbufp); } #endif From rickard.s.green@REDACTED Wed Feb 20 12:20:06 2008 From: rickard.s.green@REDACTED (Rickard Green) Date: Wed, 20 Feb 2008 12:20:06 +0100 Subject: [erlang-patches] Bad format string in erts/emulator/sys/common/erl_check_io.c In-Reply-To: References: Message-ID: <47BC0CE6.3000004@ericsson.com> Thanks for the patch! It will be included in R12B-2. BR, Rickard Green, Erlang/OTP, Ericsson AB. Matthew Dempsky wrote: > In large_fd_error_common, erts_dsprintf is called with two %d > directives but only one integer argument. > > --- erl_check_io.c.orig 2008-02-19 23:50:30.000000000 -0800 > +++ erl_check_io.c 2008-02-19 23:51:24.000000000 -0800 > @@ -741,11 +741,11 @@ > > #ifdef ERTS_SYS_CONTINOUS_FD_NUMBERS > static void > -large_fd_error_common(erts_dsprintf_buf_t *dsbufp) > +large_fd_error_common(erts_dsprintf_buf_t *dsbufp, ErtsSysFdType fd) > { > erts_dsprintf(dsbufp, > "fd=%d is larger than the largest allowed fd=%d\n", > - max_fds - 1); > + (int) fd, max_fds - 1); > } > > static void > @@ -754,7 +754,7 @@ > erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); > print_select_op(dsbufp, ix, fd, mode, on); > erts_dsprintf(dsbufp, "failed: "); > - large_fd_error_common(dsbufp); > + large_fd_error_common(dsbufp, fd); > erts_send_error_to_logger_nogl(dsbufp); > } > #endif > @@ -796,7 +796,7 @@ > erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); > print_event_op(dsbufp, ix, fd, event_data); > erts_dsprintf(dsbufp, "failed: "); > - large_fd_error_common(dsbufp); > + large_fd_error_common(dsbufp, fd); > erts_send_error_to_logger_nogl(dsbufp); > } > #endif > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-patches > From klacke@REDACTED Thu Feb 21 15:04:04 2008 From: klacke@REDACTED (Claes Wikstrom) Date: Thu, 21 Feb 2008 15:04:04 +0100 Subject: [erlang-patches] gen_server broken !! Message-ID: <47BD84D4.4070101@hyber.org> This is something that has bothered me for quite some time. There is no way to write a function which calls gen_server:start_link() that then returns a nice controlled error. If we return ignore from out init() callback, there is no way to propagate a Reason. If we return stop or {stop, Reason} we get all sorts of bad behavior including ugly printouts in the error log. Furthermore if we are a) trapping exits - we get an EXIT signal in our inbox from a Pid we've never heard of b) Not trapping EXITs, we die All I want is to silently return say we have in myserver.erl start_link() -> gen_server:start_link(?MODULE, [], []). .... init([]) -> case file:open("FOO") of {ok, Fd} -> {ok, mkstate(Fd)}; {error, Reason} -> {stop, Reason} end. It means that myserver:start_link() really sucks. It has different behavior whether the caller traps exit or not. The solution is to have init([]) -> case file:open("FOO") of {ok, Fd} -> {ok, mkstate(Fd)}; {error, Reason} -> {ignore, Reason} end. Index: gen_server.erl =================================================================== --- gen_server.erl (revision 15284) +++ gen_server.erl (working copy) @@ -31,6 +31,7 @@ %%% ==> {ok, State} %%% {ok, State, Timeout} %%% ignore +%%% {ignore, Reason} %%% {stop, Reason} %%% %%% handle_call(Msg, {From, Tag}, State) @@ -285,7 +286,12 @@ exit(Reason); ignore -> proc_lib:init_ack(Starter, ignore), + unlink(Parent), exit(normal); + {ignore, Reason} -> + proc_lib:init_ack(Starter, {ignore, Reason}), + unlink(Parent), + exit(normal); {'EXIT', Reason} -> proc_lib:init_ack(Starter, {error, Reason}), exit(Reason); /klacke From matthew@REDACTED Thu Feb 21 18:21:04 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Thu, 21 Feb 2008 09:21:04 -0800 Subject: [erlang-patches] gen_server broken !! In-Reply-To: <47BD84D4.4070101@hyber.org> References: <47BD84D4.4070101@hyber.org> Message-ID: On 2/21/08, Claes Wikstrom wrote: > This is something that has bothered me for quite some time. > There is no way to write a function which calls > gen_server:start_link() that then returns a nice controlled error. I can imagine uses for that, but I think crying "gen_server broken !!" over this is a bit sensational. From klacke@REDACTED Thu Feb 21 22:07:50 2008 From: klacke@REDACTED (Claes Wikstrom) Date: Thu, 21 Feb 2008 22:07:50 +0100 Subject: [erlang-patches] gen_server broken !! In-Reply-To: References: <47BD84D4.4070101@hyber.org> Message-ID: <47BDE826.70907@hyber.org> Matthew Dempsky wrote: > On 2/21/08, Claes Wikstrom wrote: >> This is something that has bothered me for quite some time. >> There is no way to write a function which calls >> gen_server:start_link() that then returns a nice controlled error. > > I can imagine uses for that, but I think crying "gen_server broken !!" > over this is a bit sensational. I know - I chose the mail title mostly for fun. Nevertheless gen_server as it is now is not suitable for transient gen_servers where the init() cb may return an error. If this is your usecase it is better to roll your own server - which is boring. This patch can be made completely backwards compat and should be added in some form. /klacke