From ulf@REDACTED Tue May 1 14:49:04 2012 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 1 May 2012 14:49:04 +0200 Subject: [erlang-patches] release_handler:find_script/4 to use 're' matching in .appup scripts Message-ID: git fetch git://github.com/uwiger/otp.git uw-release_handler-find_script commit b8259b6a0304b83007983793b9da40207f261209 Author: Ulf Wiger Date: Tue May 1 14:35:35 2012 +0200 release_handler:find_script/4 to use 're' matching in .appup scripts The function release_handler:find_script/4 locates an .appup script for a given application, and searches it for the matching up- or downgrade script (given OldVsn). The original implementation of this function used lists:keysearch/3 to find the matching script, but since the .appup files nowadays may contain regexps instead of distinct versions, that approach no longer works. This patch uses re:run/2 to find a matching script instead. Example: Stock R15B: Erlang R15B (erts-5.9) [source] [...] Eshell V5.9 (abort with ^G) 1> release_handler:upgrade_script(stdlib,code:lib_dir(stdlib)). ** exception throw: {version_not_in_appup,"1.18"} in function release_handler:find_script/4 (release_handler.erl, line 5 in call from release_handler:upgrade_script/2 (release_handler.erl, lin Current patch: Erlang R16B (erts-5.10) [source] [...] Eshell V5.10 (abort with ^G) 1> release_handler:upgrade_script(stdlib,code:lib_dir(stdlib)). {ok,"1.19",[restart_new_emulator,point_of_no_return]} Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From tuncer.ayaz@REDACTED Wed May 2 22:51:09 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 2 May 2012 22:51:09 +0200 Subject: [erlang-patches] Fix escript zip archive bugs Message-ID: Prompted by https://github.com/basho/rebar/issues/213 we've debugged and isolated two corner cases in erl_prim_loader. 1. erl_prim_loader:read_file_info/1 returning 'error' 2. erl_prim_loader:list_dir/1 returning {ok, ["dir1", [], "file1"]} leading to an infinite loop in reltool_target:spec_dir/1 git fetch git://github.com/tuncer/otp.git archive-script https://github.com/tuncer/otp/compare/maint...archive-script https://github.com/tuncer/otp/compare/maint...archive-script.patch Thanks to Siri Hansen and Shunichi Shinohara for debugging and co-authoring the patches. From henrik@REDACTED Thu May 3 10:36:53 2012 From: henrik@REDACTED (Henrik Nord) Date: Thu, 3 May 2012 10:36:53 +0200 Subject: [erlang-patches] Fix escript zip archive bugs In-Reply-To: References: Message-ID: <4FA243A5.5040105@erlang.org> Thank you for the contribution! Your patch is included in 'pu' On 05/02/2012 10:51 PM, Tuncer Ayaz wrote: > Prompted by https://github.com/basho/rebar/issues/213 we've debugged > and isolated two corner cases in erl_prim_loader. > > 1. erl_prim_loader:read_file_info/1 returning 'error' > 2. erl_prim_loader:list_dir/1 returning {ok, ["dir1", [], "file1"]} > leading to an infinite loop in reltool_target:spec_dir/1 > > git fetch git://github.com/tuncer/otp.git archive-script > > https://github.com/tuncer/otp/compare/maint...archive-script > https://github.com/tuncer/otp/compare/maint...archive-script.patch > > Thanks to Siri Hansen and Shunichi Shinohara for debugging and > co-authoring the patches. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From tomer.chachamu@REDACTED Fri May 4 13:16:20 2012 From: tomer.chachamu@REDACTED (Tomer Chachamu) Date: Fri, 4 May 2012 12:16:20 +0100 Subject: [erlang-patches] Fix rpc:call/5 for local calls with a finite Timeout In-Reply-To: References: Message-ID: The rpc testcases don't include any local calls, unfortunately. The patch: git fetch git://github.com/r3m0t/otp.git rpc-call-fix https://github.com/r3m0t/otp/compare/rpc-call-fix https://github.com/r3m0t/otp/compare/rpc-call-fix.patch [assuming my previous copy of this message was silently dropped as I wasn't subscribed to the list at the time] From bob@REDACTED Sat May 5 04:02:16 2012 From: bob@REDACTED (Bob Ippolito) Date: Fri, 4 May 2012 19:02:16 -0700 Subject: [erlang-patches] Fix 2 second delay after eval in shell running under ssh_cli Message-ID: Fix 2 second delay after eval in shell running under ssh_cli ssh_cli needs to reply to the tty_geometry message or else group will wait 2000 msec every time an expression is successfully evaluated in the shell. A "more correct" fix might refactor io_request and io_requests to take Group as an argument so that it isn't special-cased in handle_msg. git fetch git://github.com/etrepum/otp.git ssh_cli-tty_geometry *https://github.com/etrepum/otp/compare/maint...ssh_cli-tty_geometry* *https://github.com/etrepum/otp/compare/maint...ssh_cli-tty_geometry.patch* -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.abrahamsson@REDACTED Sat May 5 20:02:52 2012 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Sat, 5 May 2012 20:02:52 +0200 Subject: [erlang-patches] [PATCH] Fix SCTP multihoming for IPv6 In-Reply-To: <20120424141107.GA23589@erix.ericsson.se> References: <1325275858-13477-1-git-send-email-tomas.abrahamsson@gmail.com> <20120423141635.GA6988@erix.ericsson.se> <20120424141107.GA23589@erix.ericsson.se> Message-ID: On Tue, Apr 24, 2012 at 16:11, Raimo Niskanen wrote: > On Mon, Apr 23, 2012 at 11:21:08PM +0200, Tomas Abrahamsson wrote: >> On Mon, Apr 23, 2012 at 16:16 +02:00, Raimo Niskanen wrote: >> > Is it so that the sctp_bindx argument 2 declared as (struct sockaddr *) >> > is in fact misused to be able to contain IPv6 addresses by packing >> > them unaligned? >> > >> > If so, I would like this fact more visible in the code by defining 'addrs' as: >> > ? ? ? ?char addrs[256 * sizeof(struct inet_address)] > > But before that the Linux man page says: > ? ? ? ?If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. > ? ? ? ?If sd is an IPv6 socket, the addresses passed can be either IPv4 or > ? ? ? ?IPv6 addresses. > > So it might be possible to mix them... And if that is allowed the only way > I can see is packing them in a char array. > > If it is not allowed to pack them in a char array, the sctp_bindx call > should be able to detect mixed addresses immediately on the first > differing address. I've done some experimenting. It seems I was a bit too early in claiming that multihoming works with the patch. Should have tested other OSes. There are several issues. I have tested Linux, Solaris 11 (OpenIndiana 151a3) and to some extent also FreeBSD 8.2. On Solaris and FreeBSD, one must call bind before calling sctp_bindx. On Linux it is required according to the man page, but in practice, it seems to work also with no call to bind at all. This means ipv4 multihoming currently does not work on Solaris and FreeBSD, with or without any patch. I've verified that on OpenIndiana and FreeBSD 8.2. Additionally, FreeBSD accepts only one address at a time in the sctp_bindx call. Quoting the man page: "The argument addrs is a list of addresses (where the list may be only 1 in length)". On Solaris, mixing ipv4 addresses and ipv6 adresses in the call to sctp_bindx is not allowed according to the man page. Specifying ipv4-mapped ipv6 addresses is allowed, though. But it seems to half-work in practice: sctp_bindx does not return an error when adding an ipv4 address to an ipv6 sctp socket, but on the other hand, it does not seem to work to connect to it over ipv4 and send sctp messages. The client thinks it successfully connects, but the server does not see anything. Same symptoms both when specifying an ipv4 address and an ipv4-mapped ipv6 address to sctp_bindx: can't get ipv4 sctp communication to work. On Linux, mixing ipv4 and ipv6 addresses seems to work in the call to sctp_bindx seems to work well. It is possible to connect and send messages also over ipv4 to an ipv6 socket with ipv4 addresses added to it, and even to connect over ipv4 to an ipv6 socket with ipv4-mapped ipv6 addresses added to it. (Tested internally within one host, though, not between hosts.) So to make multihoming work also on Solaris and FreeBSD, we would need to make it call bind before calling sctp_bindx, and call sctp_bindx repeatedly with only one address at a time. About calling bind before sctp_bindx, I guess the proper place to change would be to make gen_sctp:open call bind on the first ip address, and sctp_bindx any following ip addresses. Currenty, it calls sctp_bindx (only), if more than one ip address is specified, otherwise it calls bind. The decision to call bind or sctp_bindx happens in inet:open/8. ~ ~ ~ If we would like to go the route of allowing mixing ipv4 and ipv6 addresses in the sctp_bindx call, then we would also need to change the inet_drv.c and prim_inet.erl, so that the SCTP_REQ_BINDX and INET_REQ_BIND messages also carry some kind of indication saying if the address(es) is/are ipv4 or ipv6 address(es). Currently, the prim_inet.erl sends 2 bytes port number followed by 4 or 16 bytes of address, and inet_drv.c expects 4 or 16 byte addresses, depending on the socket's/port's family (ipv4 or ipv6). With the patch previously submitted, specifying for instance two ipv6 addresses and one ipv4 address to gen_sctp:open, will cause a badarg, because inet_set_address in inet_drv.c will not find enough bytes to unpack, thus returning einval. Specifying 3 ipv4 addresses (3 * (2+4) = 18 bytes) for an ipv6 sctp socket (expected number of bytes = 2+16) might not cause an error, but unexpected surprises instead. Ouch :( ~ ~ ~ Regarding patching, I suppose it ought to be split into something like 3 commits: one fixing the bind + sctp_bindx issue, another adding support for mixing ipv4 and ipv6 addresses and the last commit updating the preloaded prim_inet (never done that before, so please forgive any error in reasoning here). The first commit would have a value in its own, since it would add multihoming support for non-Linux OSes, while also adding ipv6 multihoming support for Linux. Does this sound ok? BRs Tomas From zl9d97p02@REDACTED Sun May 6 07:14:06 2012 From: zl9d97p02@REDACTED (Simon Cornish) Date: Sat, 5 May 2012 22:14:06 -0700 Subject: [erlang-patches] [PATCH] Fix SCTP multihoming for IPv6 In-Reply-To: References: <1325275858-13477-1-git-send-email-tomas.abrahamsson@gmail.com> <20120423141635.GA6988@erix.ericsson.se> <20120424141107.GA23589@erix.ericsson.se> Message-ID: <15744-1336281247-356525@sneakemail.com> Hi Tomas, I had the attached patch against R12 for the Solaris bindx issue. At the time, IIRC, I didn't have the time to package it up sufficiently and no one on the OTP team seemed to either. For what it's worth, I think that is the correct behaviour for any OS - even if the current linux kernel implementation doesn't mind all addresses use bindx. Regards, Simon On 5 May 2012 11:02, Tomas Abrahamsson tomas.abrahamsson-at-gmail.com |erlang-mail/gmail| wrote: > On Tue, Apr 24, 2012 at 16:11, Raimo Niskanen > wrote: >> On Mon, Apr 23, 2012 at 11:21:08PM +0200, Tomas Abrahamsson wrote: >>> On Mon, Apr 23, 2012 at 16:16 +02:00, Raimo Niskanen wrote: >>> > Is it so that the sctp_bindx argument 2 declared as (struct sockaddr *) >>> > is in fact misused to be able to contain IPv6 addresses by packing >>> > them unaligned? >>> > >>> > If so, I would like this fact more visible in the code by defining 'addrs' as: >>> > ? ? ? ?char addrs[256 * sizeof(struct inet_address)] >> >> But before that the Linux man page says: >> ? ? ? ?If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. >> ? ? ? ?If sd is an IPv6 socket, the addresses passed can be either IPv4 or >> ? ? ? ?IPv6 addresses. >> >> So it might be possible to mix them... And if that is allowed the only way >> I can see is packing them in a char array. >> >> If it is not allowed to pack them in a char array, the sctp_bindx call >> should be able to detect mixed addresses immediately on the first >> differing address. > > I've done some experimenting. ?It seems I was a bit too > early in claiming that multihoming works with the patch. > Should have tested other OSes. ?There are several issues. > > I have tested Linux, Solaris 11 (OpenIndiana 151a3) > and to some extent also FreeBSD 8.2. > > On Solaris and FreeBSD, one must call bind before calling > sctp_bindx. ?On Linux it is required according to the man > page, but in practice, it seems to work also with no call to > bind at all. ?This means ipv4 multihoming currently does not > work on Solaris and FreeBSD, with or without any patch. > I've verified that on OpenIndiana and FreeBSD 8.2. > > Additionally, FreeBSD accepts only one address at a time in > the sctp_bindx call. ?Quoting the man page: "The argument > addrs is a list of addresses (where the list may be only 1 > in length)". > > On Solaris, mixing ipv4 addresses and ipv6 adresses in the > call to sctp_bindx is not allowed according to the man page. > Specifying ipv4-mapped ipv6 addresses is allowed, though. > But it seems to half-work in practice: sctp_bindx does not > return an error when adding an ipv4 address to an ipv6 sctp > socket, but on the other hand, it does not seem to work to > connect to it over ipv4 and send sctp messages. ?The client > thinks it successfully connects, but the server does not see > anything. ?Same symptoms both when specifying an ipv4 > address and an ipv4-mapped ipv6 address to sctp_bindx: > can't get ipv4 sctp communication to work. > > On Linux, mixing ipv4 and ipv6 addresses seems to work in > the call to sctp_bindx seems to work well. ?It is possible > to connect and send messages also over ipv4 to an ipv6 > socket with ipv4 addresses added to it, and even to connect > over ipv4 to an ipv6 socket with ipv4-mapped ipv6 addresses > added to it. ?(Tested internally within one host, though, not > between hosts.) > > So to make multihoming work also on Solaris and FreeBSD, we > would need to make it call bind before calling > sctp_bindx, and call sctp_bindx repeatedly with only one > address at a time. > > About calling bind before sctp_bindx, I guess the proper > place to change would be to make gen_sctp:open call bind on > the first ip address, and sctp_bindx any following ip > addresses. ?Currenty, it calls sctp_bindx (only), if more > than one ip address is specified, otherwise it calls bind. > The decision to call bind or sctp_bindx happens in > inet:open/8. > > ? ~ ~ ~ > > If we would like to go the route of allowing mixing ipv4 and > ipv6 addresses in the sctp_bindx call, then we would also > need to change the inet_drv.c and prim_inet.erl, so that the > SCTP_REQ_BINDX and INET_REQ_BIND messages also carry some > kind of indication saying if the address(es) is/are ipv4 or > ipv6 address(es). ?Currently, the prim_inet.erl sends 2 > bytes port number followed by 4 or 16 bytes of address, and > inet_drv.c expects 4 or 16 byte addresses, depending on the > socket's/port's family (ipv4 or ipv6). > > With the patch previously submitted, specifying for instance > two ipv6 addresses and one ipv4 address to gen_sctp:open, > will cause a badarg, because inet_set_address in inet_drv.c > will not find enough bytes to unpack, thus returning einval. > Specifying 3 ipv4 addresses (3 * (2+4) = 18 bytes) for an > ipv6 sctp socket (expected number of bytes = 2+16) might not > cause an error, but unexpected surprises instead. ?Ouch :( > > ? ~ ~ ~ > > Regarding patching, I suppose it ought to be split into > something like 3 commits: one fixing the bind + sctp_bindx > issue, another adding support for mixing ipv4 and ipv6 > addresses and the last commit updating the preloaded > prim_inet (never done that before, so please forgive any > error in reasoning here). ?The first commit would have a > value in its own, since it would add multihoming support for > non-Linux OSes, while also adding ipv6 multihoming support > for Linux. ?Does this sound ok? > > > BRs > Tomas > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- A non-text attachment was scrubbed... Name: R12B-3.patch-0D Type: application/octet-stream Size: 863 bytes Desc: not available URL: From henrik@REDACTED Mon May 7 10:13:03 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 7 May 2012 10:13:03 +0200 Subject: [erlang-patches] [PATCH] Fix SCTP multihoming for IPv6 In-Reply-To: References: <1325275858-13477-1-git-send-email-tomas.abrahamsson@gmail.com> <20120423141635.GA6988@erix.ericsson.se> <20120424141107.GA23589@erix.ericsson.se> Message-ID: <4FA7840F.6080309@erlang.org> On 05/05/2012 08:02 PM, Tomas Abrahamsson wrote: > On Tue, Apr 24, 2012 at 16:11, Raimo Niskanen > wrote: >> On Mon, Apr 23, 2012 at 11:21:08PM +0200, Tomas Abrahamsson wrote: >>> On Mon, Apr 23, 2012 at 16:16 +02:00, Raimo Niskanen wrote: >>>> Is it so that the sctp_bindx argument 2 declared as (struct sockaddr *) >>>> is in fact misused to be able to contain IPv6 addresses by packing >>>> them unaligned? >>>> >>>> If so, I would like this fact more visible in the code by defining 'addrs' as: >>>> char addrs[256 * sizeof(struct inet_address)] >> But before that the Linux man page says: >> If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. >> If sd is an IPv6 socket, the addresses passed can be either IPv4 or >> IPv6 addresses. >> >> So it might be possible to mix them... And if that is allowed the only way >> I can see is packing them in a char array. >> >> If it is not allowed to pack them in a char array, the sctp_bindx call >> should be able to detect mixed addresses immediately on the first >> differing address. > I've done some experimenting. It seems I was a bit too > early in claiming that multihoming works with the patch. > Should have tested other OSes. There are several issues. > > I have tested Linux, Solaris 11 (OpenIndiana 151a3) > and to some extent also FreeBSD 8.2. > > On Solaris and FreeBSD, one must call bind before calling > sctp_bindx. On Linux it is required according to the man > page, but in practice, it seems to work also with no call to > bind at all. This means ipv4 multihoming currently does not > work on Solaris and FreeBSD, with or without any patch. > I've verified that on OpenIndiana and FreeBSD 8.2. > > Additionally, FreeBSD accepts only one address at a time in > the sctp_bindx call. Quoting the man page: "The argument > addrs is a list of addresses (where the list may be only 1 > in length)". > > On Solaris, mixing ipv4 addresses and ipv6 adresses in the > call to sctp_bindx is not allowed according to the man page. > Specifying ipv4-mapped ipv6 addresses is allowed, though. > But it seems to half-work in practice: sctp_bindx does not > return an error when adding an ipv4 address to an ipv6 sctp > socket, but on the other hand, it does not seem to work to > connect to it over ipv4 and send sctp messages. The client > thinks it successfully connects, but the server does not see > anything. Same symptoms both when specifying an ipv4 > address and an ipv4-mapped ipv6 address to sctp_bindx: > can't get ipv4 sctp communication to work. > > On Linux, mixing ipv4 and ipv6 addresses seems to work in > the call to sctp_bindx seems to work well. It is possible > to connect and send messages also over ipv4 to an ipv6 > socket with ipv4 addresses added to it, and even to connect > over ipv4 to an ipv6 socket with ipv4-mapped ipv6 addresses > added to it. (Tested internally within one host, though, not > between hosts.) > > So to make multihoming work also on Solaris and FreeBSD, we > would need to make it call bind before calling > sctp_bindx, and call sctp_bindx repeatedly with only one > address at a time. > > About calling bind before sctp_bindx, I guess the proper > place to change would be to make gen_sctp:open call bind on > the first ip address, and sctp_bindx any following ip > addresses. Currenty, it calls sctp_bindx (only), if more > than one ip address is specified, otherwise it calls bind. > The decision to call bind or sctp_bindx happens in > inet:open/8. > > ~ ~ ~ > > If we would like to go the route of allowing mixing ipv4 and > ipv6 addresses in the sctp_bindx call, then we would also > need to change the inet_drv.c and prim_inet.erl, so that the > SCTP_REQ_BINDX and INET_REQ_BIND messages also carry some > kind of indication saying if the address(es) is/are ipv4 or > ipv6 address(es). Currently, the prim_inet.erl sends 2 > bytes port number followed by 4 or 16 bytes of address, and > inet_drv.c expects 4 or 16 byte addresses, depending on the > socket's/port's family (ipv4 or ipv6). > > With the patch previously submitted, specifying for instance > two ipv6 addresses and one ipv4 address to gen_sctp:open, > will cause a badarg, because inet_set_address in inet_drv.c > will not find enough bytes to unpack, thus returning einval. > Specifying 3 ipv4 addresses (3 * (2+4) = 18 bytes) for an > ipv6 sctp socket (expected number of bytes = 2+16) might not > cause an error, but unexpected surprises instead. Ouch :( > > ~ ~ ~ > > Regarding patching, I suppose it ought to be split into > something like 3 commits: one fixing the bind + sctp_bindx > issue, another adding support for mixing ipv4 and ipv6 > addresses and the last commit updating the preloaded > prim_inet (never done that before, so please forgive any > error in reasoning here). The first commit would have a > value in its own, since it would add multihoming support for > non-Linux OSes, while also adding ipv6 multihoming support > for Linux. Does this sound ok? This sounds splendid, as long as there are tests included in said commits. Thank you for the contribution! > > > BRs > Tomas > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Mon May 7 10:39:45 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 7 May 2012 10:39:45 +0200 Subject: [erlang-patches] Fix 2 second delay after eval in shell running under ssh_cli In-Reply-To: References: Message-ID: <4FA78A51.4020401@erlang.org> Thank for for your contribution, I have included your patch in 'pu' On 05/05/2012 04:02 AM, Bob Ippolito wrote: > git fetch git://github.com/etrepum/otp.git > ssh_cli-tty_geometry -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-patches@REDACTED Mon May 7 15:17:49 2012 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Mon, 7 May 2012 15:17:49 +0200 Subject: [erlang-patches] [PATCH] Fix SCTP multihoming for IPv6 In-Reply-To: References: <1325275858-13477-1-git-send-email-tomas.abrahamsson@gmail.com> <20120423141635.GA6988@erix.ericsson.se> <20120424141107.GA23589@erix.ericsson.se> Message-ID: <20120507131749.GA8402@erix.ericsson.se> On Sat, May 05, 2012 at 08:02:52PM +0200, Tomas Abrahamsson wrote: > On Tue, Apr 24, 2012 at 16:11, Raimo Niskanen > wrote: > > On Mon, Apr 23, 2012 at 11:21:08PM +0200, Tomas Abrahamsson wrote: > >> On Mon, Apr 23, 2012 at 16:16 +02:00, Raimo Niskanen wrote: > >> > Is it so that the sctp_bindx argument 2 declared as (struct sockaddr *) > >> > is in fact misused to be able to contain IPv6 addresses by packing > >> > them unaligned? > >> > > >> > If so, I would like this fact more visible in the code by defining 'addrs' as: > >> > ? ? ? ?char addrs[256 * sizeof(struct inet_address)] > > > > But before that the Linux man page says: > > ? ? ? ?If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. > > ? ? ? ?If sd is an IPv6 socket, the addresses passed can be either IPv4 or > > ? ? ? ?IPv6 addresses. > > > > So it might be possible to mix them... And if that is allowed the only way > > I can see is packing them in a char array. > > > > If it is not allowed to pack them in a char array, the sctp_bindx call > > should be able to detect mixed addresses immediately on the first > > differing address. > > I've done some experimenting. It seems I was a bit too > early in claiming that multihoming works with the patch. > Should have tested other OSes. There are several issues. You got me worried, I thought I scared you off. Very good findings from you below... > > I have tested Linux, Solaris 11 (OpenIndiana 151a3) > and to some extent also FreeBSD 8.2. That should cover what is important. > > On Solaris and FreeBSD, one must call bind before calling > sctp_bindx. On Linux it is required according to the man > page, but in practice, it seems to work also with no call to > bind at all. This means ipv4 multihoming currently does not > work on Solaris and FreeBSD, with or without any patch. > I've verified that on OpenIndiana and FreeBSD 8.2. > > Additionally, FreeBSD accepts only one address at a time in > the sctp_bindx call. Quoting the man page: "The argument > addrs is a list of addresses (where the list may be only 1 > in length)". > > On Solaris, mixing ipv4 addresses and ipv6 adresses in the > call to sctp_bindx is not allowed according to the man page. > Specifying ipv4-mapped ipv6 addresses is allowed, though. > But it seems to half-work in practice: sctp_bindx does not > return an error when adding an ipv4 address to an ipv6 sctp > socket, but on the other hand, it does not seem to work to > connect to it over ipv4 and send sctp messages. The client > thinks it successfully connects, but the server does not see > anything. Same symptoms both when specifying an ipv4 > address and an ipv4-mapped ipv6 address to sctp_bindx: > can't get ipv4 sctp communication to work. I would expect such problems on FreeBSD since you have to use a rc.conf setting: ipv6_ipv4mapping="YES" that sets a sysctl flag net.inet6.ip6.v6only: 0 or the OS will not allow IPv6 sockets to handle IPv4 traffic. They claim there are too many security problems in that. So it would not surprise me if Solaris does something similar. > > On Linux, mixing ipv4 and ipv6 addresses seems to work in > the call to sctp_bindx seems to work well. It is possible > to connect and send messages also over ipv4 to an ipv6 > socket with ipv4 addresses added to it, and even to connect > over ipv4 to an ipv6 socket with ipv4-mapped ipv6 addresses > added to it. (Tested internally within one host, though, not > between hosts.) > > So to make multihoming work also on Solaris and FreeBSD, we > would need to make it call bind before calling > sctp_bindx, and call sctp_bindx repeatedly with only one > address at a time. Very good. Then it will work as good as the OS can do. > > About calling bind before sctp_bindx, I guess the proper > place to change would be to make gen_sctp:open call bind on > the first ip address, and sctp_bindx any following ip > addresses. Currenty, it calls sctp_bindx (only), if more > than one ip address is specified, otherwise it calls bind. > The decision to call bind or sctp_bindx happens in > inet:open/8. > > ~ ~ ~ > > If we would like to go the route of allowing mixing ipv4 and > ipv6 addresses in the sctp_bindx call, then we would also > need to change the inet_drv.c and prim_inet.erl, so that the > SCTP_REQ_BINDX and INET_REQ_BIND messages also carry some > kind of indication saying if the address(es) is/are ipv4 or > ipv6 address(es). Currently, the prim_inet.erl sends 2 > bytes port number followed by 4 or 16 bytes of address, and > inet_drv.c expects 4 or 16 byte addresses, depending on the > socket's/port's family (ipv4 or ipv6). There is a function inet_set_faddress in inet_drv.c for this. In prim_inet you might reuse the functions type_value(set, [addr], Addr) that returns true or false depending on if Addr will be encodable by enc_value(set, [addr], Addr). > > With the patch previously submitted, specifying for instance > two ipv6 addresses and one ipv4 address to gen_sctp:open, > will cause a badarg, because inet_set_address in inet_drv.c > will not find enough bytes to unpack, thus returning einval. > Specifying 3 ipv4 addresses (3 * (2+4) = 18 bytes) for an > ipv6 sctp socket (expected number of bytes = 2+16) might not > cause an error, but unexpected surprises instead. Ouch :( > > ~ ~ ~ > > Regarding patching, I suppose it ought to be split into > something like 3 commits: one fixing the bind + sctp_bindx > issue, another adding support for mixing ipv4 and ipv6 > addresses and the last commit updating the preloaded > prim_inet (never done that before, so please forgive any > error in reasoning here). The first commit would have a > value in its own, since it would add multihoming support for > non-Linux OSes, while also adding ipv6 multihoming support > for Linux. Does this sound ok? Yes. I would say is clearer to have the updated prim_inet.beam file in the second commit too and no third commit so a git bisect will not find any intermediate non-working commit. > > > BRs > Tomas > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From jimenezrick@REDACTED Mon May 7 23:40:00 2012 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Mon, 7 May 2012 23:40:00 +0200 Subject: [erlang-patches] Super silly fix in string:strip/{1,2,3} doc Message-ID: <20120507214000.GG869@viper.local> Please fetch: git fetch git://github.com/jimenezrick/otp.git fix-string-strip-doc Review here: https://github.com/jimenezrick/otp/compare/erlang:maint...fix-string-strip-doc https://github.com/jimenezrick/otp/compare/erlang:maint...fix-string-strip-doc.patch Best regards -- Ricardo (http://r.untroubled.be/) From tomas.abrahamsson@REDACTED Tue May 8 08:31:34 2012 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Tue, 8 May 2012 08:31:34 +0200 Subject: [erlang-patches] [PATCH] Fix SCTP multihoming for IPv6 In-Reply-To: <20120507131749.GA8402@erix.ericsson.se> References: <1325275858-13477-1-git-send-email-tomas.abrahamsson@gmail.com> <20120423141635.GA6988@erix.ericsson.se> <20120424141107.GA23589@erix.ericsson.se> <20120507131749.GA8402@erix.ericsson.se> Message-ID: On Mon, May 7, 2012 at 3:17 PM, Raimo Niskanen wrote: > On Sat, May 05, 2012 at 08:02:52PM +0200, Tomas Abrahamsson wrote: >> On Tue, Apr 24, 2012 at 16:11, Raimo Niskanen >> wrote: >> > On Mon, Apr 23, 2012 at 11:21:08PM +0200, Tomas Abrahamsson wrote: >> >> On Mon, Apr 23, 2012 at 16:16 +02:00, Raimo Niskanen wrote: >> >> > Is it so that the sctp_bindx argument 2 declared as (struct sockaddr *) >> >> > is in fact misused to be able to contain IPv6 addresses by packing >> >> > them unaligned? >> >> > >> >> > If so, I would like this fact more visible in the code by defining 'addrs' as: >> >> > ? ? ? ?char addrs[256 * sizeof(struct inet_address)] >> > >> > But before that the Linux man page says: >> > ? ? ? ?If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. >> > ? ? ? ?If sd is an IPv6 socket, the addresses passed can be either IPv4 or >> > ? ? ? ?IPv6 addresses. >> > >> > So it might be possible to mix them... And if that is allowed the only way >> > I can see is packing them in a char array. >> > >> > If it is not allowed to pack them in a char array, the sctp_bindx call >> > should be able to detect mixed addresses immediately on the first >> > differing address. >> >> I've done some experimenting. ?It seems I was a bit too >> early in claiming that multihoming works with the patch. >> Should have tested other OSes. ?There are several issues. > > You got me worried, I thought I scared you off. No problems, I found out I had to do some experimenting first, but then I got interrupted and delayed. I'll put together another patch, trying to address all the issues discussed so far. >> On Solaris, mixing ipv4 addresses and ipv6 adresses in the >> call to sctp_bindx is not allowed according to the man page. >> Specifying ipv4-mapped ipv6 addresses is allowed, though. >> But it seems to half-work in practice: sctp_bindx does not >> return an error when adding an ipv4 address to an ipv6 sctp >> socket, but on the other hand, it does not seem to work to >> connect to it over ipv4 and send sctp messages. ?The client >> thinks it successfully connects, but the server does not see >> anything. ?Same symptoms both when specifying an ipv4 >> address and an ipv4-mapped ipv6 address to sctp_bindx: >> can't get ipv4 sctp communication to work. > > I would expect such problems on FreeBSD since you have to > use a rc.conf setting: ipv6_ipv4mapping="YES" that sets > a sysctl flag net.inet6.ip6.v6only: 0 > or the OS will not allow IPv6 sockets to handle IPv4 traffic. > They claim there are too many security problems in that. > > So it would not surprise me if Solaris does something similar. That's a good suggestion. Didn't know about it. Will dig into it a bit to see if this could be a reason. The server side symptoms were that poll didn't return, while the client saw a comm_up. It might well fit with what you describe. BRs Tomas From raimo+erlang-patches@REDACTED Tue May 8 16:02:28 2012 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Tue, 8 May 2012 16:02:28 +0200 Subject: [erlang-patches] [PATCH] Fix SCTP multihoming for IPv6 In-Reply-To: References: <1325275858-13477-1-git-send-email-tomas.abrahamsson@gmail.com> <20120423141635.GA6988@erix.ericsson.se> <20120424141107.GA23589@erix.ericsson.se> <20120507131749.GA8402@erix.ericsson.se> Message-ID: <20120508140228.GA4062@erix.ericsson.se> On Tue, May 08, 2012 at 08:31:34AM +0200, Tomas Abrahamsson wrote: > On Mon, May 7, 2012 at 3:17 PM, Raimo Niskanen > wrote: > > On Sat, May 05, 2012 at 08:02:52PM +0200, Tomas Abrahamsson wrote: : :: > >> On Solaris, mixing ipv4 addresses and ipv6 adresses in the > >> call to sctp_bindx is not allowed according to the man page. > >> Specifying ipv4-mapped ipv6 addresses is allowed, though. > >> But it seems to half-work in practice: sctp_bindx does not > >> return an error when adding an ipv4 address to an ipv6 sctp > >> socket, but on the other hand, it does not seem to work to > >> connect to it over ipv4 and send sctp messages. ?The client > >> thinks it successfully connects, but the server does not see > >> anything. ?Same symptoms both when specifying an ipv4 > >> address and an ipv4-mapped ipv6 address to sctp_bindx: > >> can't get ipv4 sctp communication to work. > > > > I would expect such problems on FreeBSD since you have to > > use a rc.conf setting: ipv6_ipv4mapping="YES" that sets > > a sysctl flag net.inet6.ip6.v6only: 0 > > or the OS will not allow IPv6 sockets to handle IPv4 traffic. > > They claim there are too many security problems in that. > > > > So it would not surprise me if Solaris does something similar. > > That's a good suggestion. Didn't know about it. Will dig into it > a bit to see if this could be a reason. The server side symptoms > were that poll didn't return, while the client saw a comm_up. > It might well fit with what you describe. I would have guessed no connection on the client side since there is no matching listening socket, but who knows... > > > BRs > Tomas > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From michael.santos@REDACTED Tue May 8 18:55:05 2012 From: michael.santos@REDACTED (Michael Santos) Date: Tue, 8 May 2012 12:55:05 -0400 Subject: [erlang-patches] [PATCH] Correct formating in exit error messages Message-ID: <20120508165505.GA23123@ioctl> Ensure displayed sizes are not negative. --- erts/emulator/drivers/common/efile_drv.c | 2 +- erts/emulator/drivers/unix/unix_efile.c | 8 ++++---- lib/kernel/examples/uds_dist/c_src/uds_drv.c | 4 ++-- lib/runtime_tools/c_src/trace_ip_drv.c | 8 ++++---- 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/erts/emulator/drivers/common/efile_drv.c b/erts/emulator/drivers/common/efile_drv.c index 603d1d4..347247e 100644 --- a/erts/emulator/drivers/common/efile_drv.c +++ b/erts/emulator/drivers/common/efile_drv.c @@ -522,7 +522,7 @@ static void *ef_safe_alloc(Uint s) static void *ef_safe_realloc(void *op, Uint s) { void *p = EF_REALLOC(op, s); - if (!p) erl_exit(1, "efile drv: Can't reallocate %d bytes of memory\n", s); + if (!p) erl_exit(1, "efile drv: Can't reallocate %lu bytes of memory\n", (unsigned long)s); return p; } diff --git a/erts/emulator/drivers/unix/unix_efile.c b/erts/emulator/drivers/unix/unix_efile.c index ad112f7..b250bac 100644 --- a/erts/emulator/drivers/unix/unix_efile.c +++ b/erts/emulator/drivers/unix/unix_efile.c @@ -107,8 +107,8 @@ static void *ef_safe_alloc(Uint s) { void *p = EF_ALLOC(s); if (!p) erl_exit(1, - "unix efile drv: Can't allocate %d bytes of memory\n", - s); + "unix efile drv: Can't allocate %lu bytes of memory\n", + (unsigned long)s); return p; } @@ -118,8 +118,8 @@ static void *ef_safe_realloc(void *op, Uint s) { void *p = EF_REALLOC(op, s); if (!p) erl_exit(1, - "unix efile drv: Can't reallocate %d bytes of memory\n", - s); + "unix efile drv: Can't reallocate %lu bytes of memory\n", + (unsigned long)s); return p; } diff --git a/lib/kernel/examples/uds_dist/c_src/uds_drv.c b/lib/kernel/examples/uds_dist/c_src/uds_drv.c index 9327ab1..9ad6b85 100644 --- a/lib/kernel/examples/uds_dist/c_src/uds_drv.c +++ b/lib/kernel/examples/uds_dist/c_src/uds_drv.c @@ -967,7 +967,7 @@ static void *my_malloc(size_t size) void *ptr; if ((ptr = driver_alloc(size)) == NULL) { - erl_exit(1,"Could not allocate %d bytes of memory",(int) size); + erl_exit(1,"Could not allocate %lu bytes of memory",(unsigned long) size); } return ptr; } @@ -977,7 +977,7 @@ static void *my_realloc(void *ptr, size_t size) void erl_exit(int, char *, ...); void *nptr; if ((nptr = driver_realloc(ptr, size)) == NULL) { - erl_exit(1,"Could not reallocate %d bytes of memory",(int) size); + erl_exit(1,"Could not reallocate %lu bytes of memory",(unsigned long) size); } return nptr; } diff --git a/lib/runtime_tools/c_src/trace_ip_drv.c b/lib/runtime_tools/c_src/trace_ip_drv.c index 7f7ab8d..6b77128 100644 --- a/lib/runtime_tools/c_src/trace_ip_drv.c +++ b/lib/runtime_tools/c_src/trace_ip_drv.c @@ -590,8 +590,8 @@ static void *my_alloc(size_t size) void *ret; if ((ret = driver_alloc(size)) == NULL) { /* May or may not work... */ - fprintf(stderr, "Could not allocate %d bytes of memory in %s.", - (int) size, __FILE__); + fprintf(stderr, "Could not allocate %lu bytes of memory in %s.", + (unsigned long) size, __FILE__); exit(1); } return ret; @@ -605,8 +605,8 @@ static ErlDrvBinary *my_alloc_binary(int size) ErlDrvBinary *ret; if ((ret = driver_alloc_binary(size)) == NULL) { /* May or may not work... */ - fprintf(stderr, "Could not allocate a binary of %d bytes in %s.", - (int) size, __FILE__); + fprintf(stderr, "Could not allocate a binary of %lu bytes in %s.", + (unsigned long) size, __FILE__); exit(1); } return ret; -- 1.7.9.5 From mikpe@REDACTED Tue May 8 21:12:30 2012 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 8 May 2012 21:12:30 +0200 Subject: [erlang-patches] [PATCH 2/2] hipe_arm.c: remove dead code Message-ID: <20393.28702.427170.528950@pilspetsen.it.uu.se> erts/emulator/hipe/hipe_arm.c started out as a clone of hipe_ppc.c, with #ifdefs to select ARM-specific code. Somehow those #ifdefs never got cleaned out, resulting in fairly ugly-looking code. This eliminates the #ifdefs, deletes dead PowerPC-specific code, and keeps only the ARM-specific code. I've verified that the exact same assembly code is generated for hipe_arm.c before and after this patch (if you compile without -g, with -g there are unavoidable changes to the debug data). Signed-off-by: Mikael Pettersson --- --- otp_src_R15B01/erts/emulator/hipe/hipe_arm.c.~1~ 2012-05-08 19:15:12.000000000 +0200 +++ otp_src_R15B01/erts/emulator/hipe/hipe_arm.c 2012-05-08 19:39:54.000000000 +0200 @@ -181,11 +181,9 @@ void *hipe_alloc_code(Uint nrbytes, Eter curseg.base = base; curseg.code_pos = base; curseg.tramp_pos = (unsigned int*)((char*)base + SEGMENT_NRBYTES); -#if defined(__arm__) curseg.tramp_pos -= 2; curseg.tramp_pos[0] = 0xE51FF004; /* ldr pc, [pc,#-4] */ curseg.tramp_pos[1] = (unsigned int)&nbif_callemu; -#endif address = try_alloc(nrwords, nrcallees, callees, trampvec); if (!address) { @@ -214,11 +212,9 @@ static unsigned int *alloc_stub(Uint nrw curseg.base = base; curseg.code_pos = base; curseg.tramp_pos = (unsigned int*)((char*)base + SEGMENT_NRBYTES); -#if defined(__arm__) curseg.tramp_pos -= 2; curseg.tramp_pos[0] = 0xE51FF004; /* ldr pc, [pc,#-4] */ curseg.tramp_pos[1] = (unsigned int)&nbif_callemu; -#endif address = try_alloc(nrwords, 0, NIL, NULL); if (!address) { @@ -269,10 +265,8 @@ int hipe_patch_insn(void *address, Uint3 void *hipe_make_native_stub(void *beamAddress, unsigned int beamArity) { unsigned int *code; -#if defined(__arm__) unsigned int *tramp_callemu; int callemu_offset; -#endif /* * Native code calls BEAM via a stub looking as follows: @@ -288,13 +282,6 @@ void *hipe_make_native_stub(void *beamAd * (Trampolines are allowed to modify r12, but they don't.) */ -#if !defined(__arm__) - /* verify that 'ba' can reach nbif_callemu */ - if ((unsigned long)&nbif_callemu & ~0x01FFFFFCUL) - abort(); -#endif - -#if defined(__arm__) code = alloc_stub(4, &tramp_callemu); if (!code) abort(); @@ -304,11 +291,7 @@ void *hipe_make_native_stub(void *beamAd if (!(callemu_offset >= -0x00800000 && callemu_offset <= 0x007FFFFF)) abort(); } -#else - code = alloc_stub(4, &trampoline); -#endif -#if defined(__arm__) /* mov r0, #beamArity */ code[0] = 0xE3A00000 | (beamArity & 0xFF); /* ldr r8, [pc,#0] // beamAddress */ @@ -317,16 +300,6 @@ void *hipe_make_native_stub(void *beamAd code[2] = 0xEA000000 | (callemu_offset & 0x00FFFFFF); /* .long beamAddress */ code[3] = (unsigned int)beamAddress; -#else - /* addi r12,0,beamAddress@REDACTED */ - code[0] = 0x39800000 | ((unsigned long)beamAddress & 0xFFFF); - /* addi r0,0,beamArity */ - code[1] = 0x38000000 | (beamArity & 0x7FFF); - /* addis r12,r12,beamAddress@REDACTED */ - code[2] = 0x3D8C0000 | at_ha((unsigned long)beamAddress); - /* ba nbif_callemu */ - code[3] = 0x48000002 | (unsigned long)&nbif_callemu; -#endif hipe_flush_icache_range(code, 4*sizeof(int)); @@ -336,60 +309,32 @@ void *hipe_make_native_stub(void *beamAd static void patch_b(Uint32 *address, Sint32 offset, Uint32 AA) { Uint32 oldI = *address; -#if defined(__arm__) Uint32 newI = (oldI & 0xFF000000) | (offset & 0x00FFFFFF); -#else - Uint32 newI = (oldI & 0xFC000001) | ((offset & 0x00FFFFFF) << 2) | (AA & 2); -#endif *address = newI; hipe_flush_icache_word(address); } int hipe_patch_call(void *callAddress, void *destAddress, void *trampoline) { -#if !defined(__arm__) - if ((Uint32)destAddress == ((Uint32)destAddress & 0x01FFFFFC)) { - /* The destination is in the [0,32MB[ range. - We can reach it with a ba/bla instruction. - This is the typical case for BIFs and primops. - It's also common for trap-to-BEAM stubs (on ppc32). */ - patch_b((Uint32*)callAddress, (Uint32)destAddress >> 2, 2); + Sint32 destOffset = ((Sint32)destAddress - ((Sint32)callAddress+8)) >> 2; + if (destOffset >= -0x800000 && destOffset <= 0x7FFFFF) { + /* The destination is within a [-32MB,+32MB[ range from us. + We can reach it with a b/bl instruction. + This is typical for nearby Erlang code. */ + patch_b((Uint32*)callAddress, destOffset, 0); } else { -#endif -#if defined(__arm__) - Sint32 destOffset = ((Sint32)destAddress - ((Sint32)callAddress+8)) >> 2; -#else - Sint32 destOffset = ((Sint32)destAddress - (Sint32)callAddress) >> 2; -#endif - if (destOffset >= -0x800000 && destOffset <= 0x7FFFFF) { - /* The destination is within a [-32MB,+32MB[ range from us. - We can reach it with a b/bl instruction. - This is typical for nearby Erlang code. */ - patch_b((Uint32*)callAddress, destOffset, 0); - } else { - /* The destination is too distant for b/bl/ba/bla. - Must do a b/bl to the trampoline. */ -#if defined(__arm__) - Sint32 trampOffset = ((Sint32)trampoline - ((Sint32)callAddress+8)) >> 2; -#else - Sint32 trampOffset = ((Sint32)trampoline - (Sint32)callAddress) >> 2; -#endif - if (trampOffset >= -0x800000 && trampOffset <= 0x7FFFFF) { - /* Update the trampoline's address computation. - (May be redundant, but we can't tell.) */ -#if defined(__arm__) - patch_imm32((Uint32*)trampoline+1, (Uint32)destAddress); -#else - patch_li((Uint32*)trampoline, (Uint32)destAddress); -#endif - /* Update this call site. */ - patch_b((Uint32*)callAddress, trampOffset, 0); - } else - return -1; - } -#if !defined(__arm__) + /* The destination is too distant for b/bl. + Must do a b/bl to the trampoline. */ + Sint32 trampOffset = ((Sint32)trampoline - ((Sint32)callAddress+8)) >> 2; + if (trampOffset >= -0x800000 && trampOffset <= 0x7FFFFF) { + /* Update the trampoline's address computation. + (May be redundant, but we can't tell.) */ + patch_imm32((Uint32*)trampoline+1, (Uint32)destAddress); + /* Update this call site. */ + patch_b((Uint32*)callAddress, trampOffset, 0); + } else + return -1; } -#endif return 0; } From mikpe@REDACTED Tue May 8 21:11:47 2012 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 8 May 2012 21:11:47 +0200 Subject: [erlang-patches] [PATCH 1/2] hipe_arm.c: fix compile warning Message-ID: <20393.28659.178298.745102@pilspetsen.it.uu.se> When compiling otp_src_R15B01 on arm-linux-gnueabi with --enable-hipe one gets: hipe/hipe_arm.c: In function 'hipe_make_native_stub': hipe/hipe_arm.c:273:19: warning: 'tramp_callemu' may be used uninitialized in this function The local helper function alloc_stub() has both a normal return value and output parameter (via a pointer). Due to a missing error check on the return value, gcc sees a control flow path where the output parameter may be used uninitialized. In this case gcc's analysis is correct. Fixed by adding the missing error check (an abort(), which looks primitive but that's the de facto error handling in this area across HiPE's targets; at some point we should fix that globally). Tested with gcc-4.5.3 on armv5tel-linux-gnueabi. Thanks to Kostis for notifiying me about this warning. Signed-off-by: Mikael Pettersson --- --- otp_src_R15B01/erts/emulator/hipe/hipe_arm.c.~1~ 2012-04-01 20:15:00.000000000 +0200 +++ otp_src_R15B01/erts/emulator/hipe/hipe_arm.c 2012-05-08 19:15:12.000000000 +0200 @@ -296,6 +296,8 @@ void *hipe_make_native_stub(void *beamAd #if defined(__arm__) code = alloc_stub(4, &tramp_callemu); + if (!code) + abort(); callemu_offset = ((int)&nbif_callemu - ((int)&code[2] + 8)) >> 2; if (!(callemu_offset >= -0x00800000 && callemu_offset <= 0x007FFFFF)) { callemu_offset = ((int)tramp_callemu - ((int)&code[2] + 8)) >> 2; From fritchie@REDACTED Wed May 9 01:06:58 2012 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Tue, 08 May 2012 18:06:58 -0500 Subject: [erlang-patches] Proposed expansion of Erlang-triggerable DTrace probes Message-ID: <80121.1336518418@snookles.snookles.com> Hi, all. I've got a proposal for expanding the number of triggerable-by-Erlang-code DTrace probes. There's a hassle with the current implementation: it isn't possible to create truly dynamic DTrace probes(*). So the method in the R15B01 release creates a single generic probe that Erlang code can fire: you have 4 integers and 4 strings/binaries/iodata to give to that single probe. But there's a problem with the spamminess of the things. From a DTrace point of view, there's only a single probe. So when you enable that one probe, you automatically get overhead for *all* Erlang-level probe statements that share that one probe. You can reduce the overhead by using pattern-matching-style guards to limit what gets executed, e.g. arg2 == 703 in order to really fire a probe when arg2 (the first of four probe-specified integers) is 703 (where 703 == some category of probe event used by your app). (See below for an example.) (*) Except that it _is_ possible, using the technique found in https://github.com/chrisa/libusdt. The problem is that we'd like to have SystemTap users be able to use the same probes as DTrace users, if at all possible. So, to solve this problem, we need to: 1. create more probes that Erlang code can trigger 2. use libusdt to create truly-dynamic probes These patches follow method #1, fetch via: git fetch git://github.com/slfritchie/otp.git slf-dtrace-nif-N-probes Review via: https://github.com/slfritchie/otp/compare/erlang:master...slf-dtrace-nif-N-probes https://github.com/slfritchie/otp/compare/erlang:master...slf-dtrace-nif-N-probes.patch The patches add 1024 new probes, each with 4 integers and 4 strings. 1024 isn't strictly necessary: the number could be smaller, though I believe that 256 is probably the smallest useful number. I could also entertain the notion of adding: * 256 probes with 4 integers & 4 strings * 256 probes with 8 integers * 256 probes with 8 strings * N probes with some other combination of integers & strings Thoughts/opinions? This isn't a fully-baked submission, quite yet. -Scott P.S. Here's the example that I promised. Say that I've got an application that has probes that look like this: -define(CATEGORY_FOO, 701). -define(CATEGORY_BAR, 702). -define(CATEGORY_BAZ, 703). %% code path #1 dyntrace:p(?CATEGORY_FOO, length(SomeList)). [...] %% code path #2 dyntrace:p(?CATEGORY_BAZ, size(SomeBinary), "doin' some stuff"). Say that you're interested in the probe in code path #2. You can do this via D to print something whenever that probe fires: dtrace -qn 'erlang*:::user_trace* /arg2 == 703/ {printf("pid %s: size %d string %s\n", copyinstr(arg0), arg2, copyinstr(arg6));}' However, if code path #2 is only running 10 times/sec, and code path #1 is running 20K times/sec, the "/arg2 == 703/" guard will help lower the runtime cost of the 20,010 times/sec by a small amount. But it would be much better if we could have a single probe firing only 10 times/sec. From lists.nico.k@REDACTED Wed May 9 11:52:18 2012 From: lists.nico.k@REDACTED (Nico Kruber) Date: Wed, 09 May 2012 11:52:18 +0200 Subject: [erlang-patches] Fwd: Re: fixed reading compressed binary terms from Java Message-ID: <4428437.ziQ7czlS06@csr-pc40.zib.de> forwarded to mailing list as the reply was only send to Henrik Nord... ---------- Forwarded Message ---------- Subject: Re: [erlang-patches] fixed reading compressed binary terms from Java Date: Friday 04 May 2012, 16:37:55 From: Nico Kruber To: Henrik Nord Can you give me a hint on how to write and run tests your way? I could easily write a JUnit test for that and won't even need Erlang since the only thing that needs testing here is that write_compressed and read_any work with each other with differently sized values. You could even use bytes/OtpErlangBinary for simplicity. The only roundtrip test so far is the echo server, i.e. nc_SUITE.erl, which currently only has small terms. I could add larger terms but I need some help in how to actually run the test. It is not as simple as "make tests" (with the proper ERL_TOP set). Nico On Friday 27 April 2012 10:23:37 you wrote: > Hi > > I would like you to add a test for this. As there already are compress > and decompress roundtrip tests, > the effort should be minimal for adding tests for this specific bug. > > Also the commit message should conform to > (fix, not fixed etc..) > > https://github.com/erlang/otp/wiki/Writing-good-commit-messages > > Thank you for the contribution! > > On 04/25/2012 10:48 AM, Nico Kruber wrote: > > Problem was that when reading from an InputStream, you can only specify a > > maximum number of bytes to read. Java doesn't guarantee that it actually > > reads this many bytes - it could be less! > > > > This patch now reads up until the expected size number of bytes. If there > > are more than expected, the actual number of available bytes is not > > printed (we probably shouldn't read the additional bytes, security-wise - > > the erlang external byte representation is broken in this case though). > > > > I applied a patch posted on erlang-questins in September 2009, see > > http://erlang.org/pipermail/erlang-patches/2009-September/000478.html > > It was not enough to fix the bug though so I extended this patch a little. > > > > https://github.com/NicoK/otp/compare/jinterface.fix_compressed_binary > > https://github.com/NicoK/otp/compare/jinterface.fix_compressed_binary.patc > > h > > > > > > Regards > > Nico Kruber > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches ----------------------------------------- From zhengsyao@REDACTED Wed May 9 14:10:38 2012 From: zhengsyao@REDACTED (=?utf-8?Q?=22Siyao_Zheng=28=E9=83=91=E6=80=9D=E9=81=A5=29=22?=) Date: Wed, 9 May 2012 20:10:38 +0800 Subject: [erlang-patches] DTrace bug in message-send Message-ID: <7D411C9C-B71E-41E5-9AB8-FD006E73FFAA@gmail.com> Hi, When dtracing message related probes, sender pid and receiver pid are always truncated to 7 characters on my 64bit mac. The bug is at the string composing code in message send probe. When composing pid string, the code used the length of a pointer instead of the length of a buffer. The bug fix can be fetched at git fetch git://github.com/zhengsyao/otp.git dtrace_message_send_fix view at https://github.com/zhengsyao/otp/compare/dtrace_message_send_fix https://github.com/zhengsyao/otp/compare/dtrace_message_send_fix.patch Cheers From henrik@REDACTED Wed May 9 14:58:37 2012 From: henrik@REDACTED (Henrik Nord) Date: Wed, 9 May 2012 14:58:37 +0200 Subject: [erlang-patches] [PATCH 2/2] hipe_arm.c: remove dead code In-Reply-To: <20393.28702.427170.528950@pilspetsen.it.uu.se> References: <20393.28702.427170.528950@pilspetsen.it.uu.se> Message-ID: <4FAA69FD.5050201@erlang.org> Thank you for the contribution! I have included your patches in 'pu' On 05/08/2012 09:12 PM, Mikael Pettersson wrote: > erts/emulator/hipe/hipe_arm.c started out as a clone of hipe_ppc.c, > with #ifdefs to select ARM-specific code. Somehow those #ifdefs > never got cleaned out, resulting in fairly ugly-looking code. > > This eliminates the #ifdefs, deletes dead PowerPC-specific code, and > keeps only the ARM-specific code. I've verified that the exact same > assembly code is generated for hipe_arm.c before and after this patch > (if you compile without -g, with -g there are unavoidable changes to > the debug data). > > Signed-off-by: Mikael Pettersson > --- > > --- otp_src_R15B01/erts/emulator/hipe/hipe_arm.c.~1~ 2012-05-08 19:15:12.000000000 +0200 > +++ otp_src_R15B01/erts/emulator/hipe/hipe_arm.c 2012-05-08 19:39:54.000000000 +0200 > @@ -181,11 +181,9 @@ void *hipe_alloc_code(Uint nrbytes, Eter > curseg.base = base; > curseg.code_pos = base; > curseg.tramp_pos = (unsigned int*)((char*)base + SEGMENT_NRBYTES); > -#if defined(__arm__) > curseg.tramp_pos -= 2; > curseg.tramp_pos[0] = 0xE51FF004; /* ldr pc, [pc,#-4] */ > curseg.tramp_pos[1] = (unsigned int)&nbif_callemu; > -#endif > > address = try_alloc(nrwords, nrcallees, callees, trampvec); > if (!address) { > @@ -214,11 +212,9 @@ static unsigned int *alloc_stub(Uint nrw > curseg.base = base; > curseg.code_pos = base; > curseg.tramp_pos = (unsigned int*)((char*)base + SEGMENT_NRBYTES); > -#if defined(__arm__) > curseg.tramp_pos -= 2; > curseg.tramp_pos[0] = 0xE51FF004; /* ldr pc, [pc,#-4] */ > curseg.tramp_pos[1] = (unsigned int)&nbif_callemu; > -#endif > > address = try_alloc(nrwords, 0, NIL, NULL); > if (!address) { > @@ -269,10 +265,8 @@ int hipe_patch_insn(void *address, Uint3 > void *hipe_make_native_stub(void *beamAddress, unsigned int beamArity) > { > unsigned int *code; > -#if defined(__arm__) > unsigned int *tramp_callemu; > int callemu_offset; > -#endif > > /* > * Native code calls BEAM via a stub looking as follows: > @@ -288,13 +282,6 @@ void *hipe_make_native_stub(void *beamAd > * (Trampolines are allowed to modify r12, but they don't.) > */ > > -#if !defined(__arm__) > - /* verify that 'ba' can reach nbif_callemu */ > - if ((unsigned long)&nbif_callemu& ~0x01FFFFFCUL) > - abort(); > -#endif > - > -#if defined(__arm__) > code = alloc_stub(4,&tramp_callemu); > if (!code) > abort(); > @@ -304,11 +291,7 @@ void *hipe_make_native_stub(void *beamAd > if (!(callemu_offset>= -0x00800000&& callemu_offset<= 0x007FFFFF)) > abort(); > } > -#else > - code = alloc_stub(4,&trampoline); > -#endif > > -#if defined(__arm__) > /* mov r0, #beamArity */ > code[0] = 0xE3A00000 | (beamArity& 0xFF); > /* ldr r8, [pc,#0] // beamAddress */ > @@ -317,16 +300,6 @@ void *hipe_make_native_stub(void *beamAd > code[2] = 0xEA000000 | (callemu_offset& 0x00FFFFFF); > /* .long beamAddress */ > code[3] = (unsigned int)beamAddress; > -#else > - /* addi r12,0,beamAddress@REDACTED */ > - code[0] = 0x39800000 | ((unsigned long)beamAddress& 0xFFFF); > - /* addi r0,0,beamArity */ > - code[1] = 0x38000000 | (beamArity& 0x7FFF); > - /* addis r12,r12,beamAddress@REDACTED */ > - code[2] = 0x3D8C0000 | at_ha((unsigned long)beamAddress); > - /* ba nbif_callemu */ > - code[3] = 0x48000002 | (unsigned long)&nbif_callemu; > -#endif > > hipe_flush_icache_range(code, 4*sizeof(int)); > > @@ -336,60 +309,32 @@ void *hipe_make_native_stub(void *beamAd > static void patch_b(Uint32 *address, Sint32 offset, Uint32 AA) > { > Uint32 oldI = *address; > -#if defined(__arm__) > Uint32 newI = (oldI& 0xFF000000) | (offset& 0x00FFFFFF); > -#else > - Uint32 newI = (oldI& 0xFC000001) | ((offset& 0x00FFFFFF)<< 2) | (AA& 2); > -#endif > *address = newI; > hipe_flush_icache_word(address); > } > > int hipe_patch_call(void *callAddress, void *destAddress, void *trampoline) > { > -#if !defined(__arm__) > - if ((Uint32)destAddress == ((Uint32)destAddress& 0x01FFFFFC)) { > - /* The destination is in the [0,32MB[ range. > - We can reach it with a ba/bla instruction. > - This is the typical case for BIFs and primops. > - It's also common for trap-to-BEAM stubs (on ppc32). */ > - patch_b((Uint32*)callAddress, (Uint32)destAddress>> 2, 2); > + Sint32 destOffset = ((Sint32)destAddress - ((Sint32)callAddress+8))>> 2; > + if (destOffset>= -0x800000&& destOffset<= 0x7FFFFF) { > + /* The destination is within a [-32MB,+32MB[ range from us. > + We can reach it with a b/bl instruction. > + This is typical for nearby Erlang code. */ > + patch_b((Uint32*)callAddress, destOffset, 0); > } else { > -#endif > -#if defined(__arm__) > - Sint32 destOffset = ((Sint32)destAddress - ((Sint32)callAddress+8))>> 2; > -#else > - Sint32 destOffset = ((Sint32)destAddress - (Sint32)callAddress)>> 2; > -#endif > - if (destOffset>= -0x800000&& destOffset<= 0x7FFFFF) { > - /* The destination is within a [-32MB,+32MB[ range from us. > - We can reach it with a b/bl instruction. > - This is typical for nearby Erlang code. */ > - patch_b((Uint32*)callAddress, destOffset, 0); > - } else { > - /* The destination is too distant for b/bl/ba/bla. > - Must do a b/bl to the trampoline. */ > -#if defined(__arm__) > - Sint32 trampOffset = ((Sint32)trampoline - ((Sint32)callAddress+8))>> 2; > -#else > - Sint32 trampOffset = ((Sint32)trampoline - (Sint32)callAddress)>> 2; > -#endif > - if (trampOffset>= -0x800000&& trampOffset<= 0x7FFFFF) { > - /* Update the trampoline's address computation. > - (May be redundant, but we can't tell.) */ > -#if defined(__arm__) > - patch_imm32((Uint32*)trampoline+1, (Uint32)destAddress); > -#else > - patch_li((Uint32*)trampoline, (Uint32)destAddress); > -#endif > - /* Update this call site. */ > - patch_b((Uint32*)callAddress, trampOffset, 0); > - } else > - return -1; > - } > -#if !defined(__arm__) > + /* The destination is too distant for b/bl. > + Must do a b/bl to the trampoline. */ > + Sint32 trampOffset = ((Sint32)trampoline - ((Sint32)callAddress+8))>> 2; > + if (trampOffset>= -0x800000&& trampOffset<= 0x7FFFFF) { > + /* Update the trampoline's address computation. > + (May be redundant, but we can't tell.) */ > + patch_imm32((Uint32*)trampoline+1, (Uint32)destAddress); > + /* Update this call site. */ > + patch_b((Uint32*)callAddress, trampOffset, 0); > + } else > + return -1; > } > -#endif > return 0; > } > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Fri May 11 11:17:17 2012 From: henrik@REDACTED (Henrik Nord) Date: Fri, 11 May 2012 11:17:17 +0200 Subject: [erlang-patches] Proposed expansion of Erlang-triggerable DTrace probes In-Reply-To: <80121.1336518418@snookles.snookles.com> References: <80121.1336518418@snookles.snookles.com> Message-ID: <4FACD91D.5020707@erlang.org> I have included this patch in 'pu' On 05/09/2012 01:06 AM, Scott Lystig Fritchie wrote: > Hi, all. I've got a proposal for expanding the number of > triggerable-by-Erlang-code DTrace probes. > > There's a hassle with the current implementation: it isn't possible to > create truly dynamic DTrace probes(*). So the method in the R15B01 > release creates a single generic probe that Erlang code can fire: you > have 4 integers and 4 strings/binaries/iodata to give to that single > probe. > > But there's a problem with the spamminess of the things. From a DTrace > point of view, there's only a single probe. So when you enable that one > probe, you automatically get overhead for *all* Erlang-level probe > statements that share that one probe. You can reduce the overhead by > using pattern-matching-style guards to limit what gets executed, > e.g. arg2 == 703 in order to really fire a probe when arg2 (the first of > four probe-specified integers) is 703 (where 703 == some category of > probe event used by your app). (See below for an example.) > > (*) Except that it _is_ possible, using the technique found in > https://github.com/chrisa/libusdt. The problem is that we'd like to > have SystemTap users be able to use the same probes as DTrace users, if > at all possible. > > So, to solve this problem, we need to: > > 1. create more probes that Erlang code can trigger > 2. use libusdt to create truly-dynamic probes > > These patches follow method #1, fetch via: > > git fetch git://github.com/slfritchie/otp.git slf-dtrace-nif-N-probes > > Review via: > > https://github.com/slfritchie/otp/compare/erlang:master...slf-dtrace-nif-N-probes > https://github.com/slfritchie/otp/compare/erlang:master...slf-dtrace-nif-N-probes.patch > > The patches add 1024 new probes, each with 4 integers and 4 strings. > 1024 isn't strictly necessary: the number could be smaller, though I > believe that 256 is probably the smallest useful number. > > I could also entertain the notion of adding: > > * 256 probes with 4 integers& 4 strings > * 256 probes with 8 integers > * 256 probes with 8 strings > * N probes with some other combination of integers& strings > > Thoughts/opinions? This isn't a fully-baked submission, quite yet. > > -Scott > > P.S. Here's the example that I promised. Say that I've got an > application that has probes that look like this: > > -define(CATEGORY_FOO, 701). > -define(CATEGORY_BAR, 702). > -define(CATEGORY_BAZ, 703). > > %% code path #1 > dyntrace:p(?CATEGORY_FOO, length(SomeList)). > [...] > > %% code path #2 > dyntrace:p(?CATEGORY_BAZ, size(SomeBinary), "doin' some stuff"). > > Say that you're interested in the probe in code path #2. You can do > this via D to print something whenever that probe fires: > > dtrace -qn 'erlang*:::user_trace* /arg2 == 703/ {printf("pid %s: size %d string %s\n", copyinstr(arg0), arg2, copyinstr(arg6));}' > > However, if code path #2 is only running 10 times/sec, and code path #1 > is running 20K times/sec, the "/arg2 == 703/" guard will help lower the > runtime cost of the 20,010 times/sec by a small amount. But it would be > much better if we could have a single probe firing only 10 times/sec. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From raimo+erlang-patches@REDACTED Fri May 11 15:00:24 2012 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Fri, 11 May 2012 15:00:24 +0200 Subject: [erlang-patches] Fwd: Re: fixed reading compressed binary terms from Java In-Reply-To: <4428437.ziQ7czlS06@csr-pc40.zib.de> References: <4428437.ziQ7czlS06@csr-pc40.zib.de> Message-ID: <20120511130024.GA9378@erix.ericsson.se> On Wed, May 09, 2012 at 11:52:18AM +0200, Nico Kruber wrote: > forwarded to mailing list as the reply was only send to Henrik Nord... > ---------- Forwarded Message ---------- > > Subject: Re: [erlang-patches] fixed reading compressed binary terms from Java > Date: Friday 04 May 2012, 16:37:55 > From: Nico Kruber > To: Henrik Nord > > Can you give me a hint on how to write and run tests your way? > I could easily write a JUnit test for that and won't even need Erlang since > the only thing that needs testing here is that write_compressed and read_any > work with each other with differently sized values. You could even use > bytes/OtpErlangBinary for simplicity. > > The only roundtrip test so far is the echo server, i.e. nc_SUITE.erl, which > currently only has small terms. I could add larger terms but I need some help > in how to actually run the test. It is not as simple as "make tests" (with the > proper ERL_TOP set). Is this sufficient to get you started?: https://github.com/erlang/otp/wiki/Running-tests > > > Nico > > On Friday 27 April 2012 10:23:37 you wrote: > > Hi > > > > I would like you to add a test for this. As there already are compress > > and decompress roundtrip tests, > > the effort should be minimal for adding tests for this specific bug. > > > > Also the commit message should conform to > > (fix, not fixed etc..) > > > > https://github.com/erlang/otp/wiki/Writing-good-commit-messages > > > > Thank you for the contribution! > > > > On 04/25/2012 10:48 AM, Nico Kruber wrote: > > > Problem was that when reading from an InputStream, you can only specify a > > > maximum number of bytes to read. Java doesn't guarantee that it actually > > > reads this many bytes - it could be less! > > > > > > This patch now reads up until the expected size number of bytes. If there > > > are more than expected, the actual number of available bytes is not > > > printed (we probably shouldn't read the additional bytes, security-wise - > > > the erlang external byte representation is broken in this case though). > > > > > > I applied a patch posted on erlang-questins in September 2009, see > > > http://erlang.org/pipermail/erlang-patches/2009-September/000478.html > > > It was not enough to fix the bug though so I extended this patch a little. > > > > > > https://github.com/NicoK/otp/compare/jinterface.fix_compressed_binary > > > https://github.com/NicoK/otp/compare/jinterface.fix_compressed_binary.patc > > > h > > > > > > > > > Regards > > > Nico Kruber > > > _______________________________________________ > > > 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 -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From klyr@REDACTED Sat May 12 02:16:10 2012 From: klyr@REDACTED (Julien Barbot) Date: Sat, 12 May 2012 02:16:10 +0200 Subject: [erlang-patches] Server Name Indication SSL extension Message-ID: Hi, Here is an implementation of SSL SNI extension: RFC6066 Section 3. - http://tools.ietf.org/html/rfc6066#section-3 - https://en.wikipedia.org/wiki/Server_Name_Indication It's kind of VirtualHosts for SSL: One SSL server with one IP/PORT couple can present differents SSL parameters. To fetch: git fetch git://github.com/klyr/otp.git ssl _sni Review at: https://github.com/klyr/otp/compare/erlang:master...ssl_sni https://github.com/klyr/otp/compare/erlang:master...ssl_sni.patch Feel free to comment/criticize the code and the API modification choices: - ssl:sni_hostname(Socket): to get the hostname selected by the server or undefined if not found or not specified by the client, - a new sni_hosts server parameter to specify per-host configuration. Basic usage example: Opts = [ {certfile, "default.pem"}, {keyfile, "default.key"}, {verify, verify_none} % Default parameters {sni_hosts, [ {"vhost1.example.com", [{certfile, "vhost1.pem"}, {keyfile, "vhost1.key"}]}, {"vhost2.example.org", [{verify, verify_peer}]} ]} ], {ok, ListenSocket} = ssl:listen(9999, Opts), {ok, S} = ssl:transport_accept(ListenSocket), ok = ssl:ssl_accept(S), SelectedHost = ssl:sni_hostname(S), io:format("Selected Vhost: ~s~n", [SelectedHost]). Best regards, -- Julien Barbot -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.abrahamsson@REDACTED Sun May 13 23:52:56 2012 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Sun, 13 May 2012 23:52:56 +0200 Subject: [erlang-patches] [PATCH] Fix SCTP multihoming for IPv6 In-Reply-To: <20120508140228.GA4062@erix.ericsson.se> References: <1325275858-13477-1-git-send-email-tomas.abrahamsson@gmail.com> <20120423141635.GA6988@erix.ericsson.se> <20120424141107.GA23589@erix.ericsson.se> <20120507131749.GA8402@erix.ericsson.se> <20120508140228.GA4062@erix.ericsson.se> Message-ID: Hi, regarding the SCTP multihoming, here are three commits on a branch, I think I've addressed all issues I know of, and hope I haven't introduced any new issues :) https://github.com/tomas-abrahamsson/otp/compare/sctp-multihoming https://github.com/tomas-abrahamsson/otp/compare/sctp-multihoming.patch The first commit sets the 'len' field in the inet/inet6 address in the inet_drv.c, if that field exists on the host (FreeBSD) The second commit changes the way the inet_drv.c binds: the first address is bound using bind, the subsequent addresses are added one at a time using sctp_bindx. The third commit adds possibility to mix ipv4 and ipv6 addresses. For the record, I have had troubles running the tests (both the added and the existing). They all succeed on my Linux box, but ipv6 tests fail for sctp on non non-::1 addresses on my virtual Solaris and FreeBSD machines. I think (hope) that this boils down to bad machine configurations. On one hand, tcp worked well over ipv6 (to the same non-::1 addresses), on the other hand, the sctp_darn program (taken from the lksctp package and ported to FreeBSD) failed for me the same way my tests did (also tried sysctl that was previously metioned). Are there other sctp test programs? I had trouble locating them. If the tests or code would require some changes or further troubleshooting, please let me know. BRs Tomas From klyr@REDACTED Wed May 16 19:20:03 2012 From: klyr@REDACTED (Julien Barbot) Date: Wed, 16 May 2012 19:20:03 +0200 Subject: [erlang-patches] Server Name Indication SSL extension In-Reply-To: <4FB27B84.4090204@erix.ericsson.se> References: <4FB27B84.4090204@erix.ericsson.se> Message-ID: Hi Ingela, thanks for the reply, Notice that I made a mistake in my (HTML) links. See correction below. 2012/5/15 Ingela Anderton Andin : > Thank you for the contribution, I will review it and come back to you. I am > currently in the middle of some restructuring to avoid bottlenecks so I do > not have time to do it right away, and when I am done your contribution > will need to be rebased. I can say up front that it might not be a trivial > rebase. Ok, if the rebase is too hard, maybe you could only apply the client-side implementation patch which is simpler (first of both commits). >> To fetch: >> git fetch git://github.com/klyr/otp.git >> ssl_sni git fetch git://github.com/klyr/otp.git >> Review at: >> https://github.com/klyr/otp/compare/erlang:master...ssl_sni >> https://github.com/klyr/otp/compare/erlang:master...ssl_sni >> https://github.com/klyr/otp/compare/erlang:master...ssl_sni.patch >> https://github.com/klyr/otp/compare/erlang:master...ssl_sni.patch -- Julien Barbot From ates@REDACTED Thu May 17 14:33:37 2012 From: ates@REDACTED (Artem Teslenko) Date: Thu, 17 May 2012 15:33:37 +0300 Subject: [erlang-patches] Typo fix in asn1ct_gen_ber_bin_v2:gen_decode_selected function Message-ID: <20120517123337.GA16499@mail.ipv6.dp.ua> Hello, It fixes a small typo in lib/asn1/src/asn1ct_gen_ber_bin_v2.erl Please fetch: git fetch git://github.com/ates/otp.git fix_asn1_typo Here is a commit for review: https://github.com/ates/otp/commit/24367b7d5169f9382550de38101a6bc247b70060 From henrik@REDACTED Mon May 21 15:28:50 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 21 May 2012 15:28:50 +0200 Subject: [erlang-patches] Typo fix in asn1ct_gen_ber_bin_v2:gen_decode_selected function In-Reply-To: <20120517123337.GA16499@mail.ipv6.dp.ua> References: <20120517123337.GA16499@mail.ipv6.dp.ua> Message-ID: <4FBA4312.204@erlang.org> Thank you, I will include this in maint On 05/17/2012 02:33 PM, Artem Teslenko wrote: > Hello, > > It fixes a small typo in lib/asn1/src/asn1ct_gen_ber_bin_v2.erl > > Please fetch: > git fetch git://github.com/ates/otp.git fix_asn1_typo > > Here is a commit for review: > https://github.com/ates/otp/commit/24367b7d5169f9382550de38101a6bc247b70060 > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Thu May 24 11:35:25 2012 From: henrik@REDACTED (Henrik Nord) Date: Thu, 24 May 2012 11:35:25 +0200 Subject: [erlang-patches] Fix 2 second delay after eval in shell running under ssh_cli In-Reply-To: References: Message-ID: <4FBE00DD.1070705@erlang.org> This patch does not pass the test. We would like you to do the "more correct" fix as that is the better approach. Please run the tests and make sure they all pass and before submitting the patch. Thank you for the contribution! On 05/05/2012 04:02 AM, Bob Ippolito wrote: > Fix 2 second delay after eval in shell running under ssh_cli > > ssh_cli needs to reply to the tty_geometry message or else group > will wait 2000 msec every time an expression is successfully > evaluated in the shell. > > A "more correct" fix might refactor io_request and io_requests to > take Group as an argument so that it isn't special-cased in > handle_msg. > > git fetch git://github.com/etrepum/otp.git > ssh_cli-tty_geometry > > _https://github.com/etrepum/otp/compare/maint...ssh_cli-tty_geometry_ > _https://github.com/etrepum/otp/compare/maint...ssh_cli-tty_geometry.patch_ > > > _______________________________________________ > 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 serge@REDACTED Thu May 24 16:02:32 2012 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 24 May 2012 10:02:32 -0400 Subject: [erlang-patches] [patch] new float_to_list/2 In-Reply-To: <4FBDFCB2.2050402@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> Message-ID: <4FBE3F78.8050405@aleynikov.org> Henrik, Fetch: git fetch https://github.com/saleyn/otp/tree/float_to_list_2 Diff: https://github.com/saleyn/otp/compare/float_to_list_2 I added the definition for the new BIF to make the type checker happy: https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 Once you do the "otp_build tests", how do you execute all tests suites in $ERL_TOP or if possible only tests in a given SUITE? I tried the following but all tests fail: [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s test_server_ctrl run_test DIR "." -s erlang halt I did however run individual tests in bif_SUIT:types to make sure my patch didn't break anything. Serge On 5/24/2012 5:17 AM, Henrik Nord wrote: > > Hi again. > > > This test is not passing: emulator/bif_SUIT:types > > No type information: > > [{erlang,float_to_list,2}] > > > > On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 > From bob@REDACTED Thu May 24 20:25:57 2012 From: bob@REDACTED (Bob Ippolito) Date: Thu, 24 May 2012 11:25:57 -0700 Subject: [erlang-patches] Fix 2 second delay after eval in shell running under ssh_cli In-Reply-To: <4FBE00DD.1070705@erlang.org> References: <4FBE00DD.1070705@erlang.org> Message-ID: Could you be more specific about which test(s) are failing? Also, what's the procedure for building just the ssh application? https://github.com/erlang/otp/wiki/Running-tests covers how to run tests for a single application after building all of OTP, but not how to build it again after making some changes. On Thu, May 24, 2012 at 2:35 AM, Henrik Nord wrote: > This patch does not pass the test. > We would like you to do the "more correct" fix as that is the better > approach. > > Please run the tests and make sure they all pass and before submitting the > patch. > > > Thank you for the contribution! > > > > On 05/05/2012 04:02 AM, Bob Ippolito wrote: > > Fix 2 second delay after eval in shell running under ssh_cli > > ssh_cli needs to reply to the tty_geometry message or else group > will wait 2000 msec every time an expression is successfully > evaluated in the shell. > > A "more correct" fix might refactor io_request and io_requests to > take Group as an argument so that it isn't special-cased in > handle_msg. > > git fetch git://github.com/etrepum/otp.git ssh_cli-tty_geometry > > *https://github.com/etrepum/otp/compare/maint...ssh_cli-tty_geometry* > *https://github.com/etrepum/otp/compare/maint...ssh_cli-tty_geometry.patch > * > > > _______________________________________________ > erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches > > > -- > /Henrik Nord Erlang/OTP > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Thu May 24 20:53:45 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 24 May 2012 20:53:45 +0200 Subject: [erlang-patches] Fix 2 second delay after eval in shell running under ssh_cli In-Reply-To: References: <4FBE00DD.1070705@erlang.org> Message-ID: On Thu, May 24, 2012 at 8:25 PM, Bob Ippolito wrote: > Also, what's the procedure for building just the ssh application? > https://github.com/erlang/otp/wiki/Running-tests covers how to run > tests for a single application after building all of OTP, but not > how to build it again after making some changes. $ cd lib/ssh $ make From bob@REDACTED Thu May 24 21:46:56 2012 From: bob@REDACTED (Bob Ippolito) Date: Thu, 24 May 2012 12:46:56 -0700 Subject: [erlang-patches] Fix 2 second delay after eval in shell running under ssh_cli In-Reply-To: References: <4FBE00DD.1070705@erlang.org> Message-ID: On Thu, May 24, 2012 at 11:53 AM, Tuncer Ayaz wrote: > On Thu, May 24, 2012 at 8:25 PM, Bob Ippolito wrote: > > Also, what's the procedure for building just the ssh application? > > https://github.com/erlang/otp/wiki/Running-tests covers how to run > > tests for a single application after building all of OTP, but not > > how to build it again after making some changes. > > $ cd lib/ssh > $ make > Seems to build, but does that get it into the release that the tests are run against, or is there a different way to run the tests for just the ssh app in-place like this? -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Thu May 24 22:36:08 2012 From: bob@REDACTED (Bob Ippolito) Date: Thu, 24 May 2012 13:36:08 -0700 Subject: [erlang-patches] Fix 2 second delay after eval in shell running under ssh_cli In-Reply-To: References: <4FBE00DD.1070705@erlang.org> Message-ID: On Thu, May 24, 2012 at 12:46 PM, Bob Ippolito wrote: > On Thu, May 24, 2012 at 11:53 AM, Tuncer Ayaz wrote: > >> On Thu, May 24, 2012 at 8:25 PM, Bob Ippolito wrote: >> > Also, what's the procedure for building just the ssh application? >> > https://github.com/erlang/otp/wiki/Running-tests covers how to run >> > tests for a single application after building all of OTP, but not >> > how to build it again after making some changes. >> >> $ cd lib/ssh >> $ make >> > > Seems to build, but does that get it into the release that the tests are > run against, or is there a different way to run the tests for just the ssh > app in-place like this? > It seems that the ssh tests do not pass even without my changes, at least on my Mac OS X machine. In fact, they seem to hang (possibly indefinitely, but I haven't waited that long). Here's the output from attempting to run them on the maint branch at revision 9bbda97: https://gist.github.com/2784056 -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Fri May 25 00:42:00 2012 From: bob@REDACTED (Bob Ippolito) Date: Thu, 24 May 2012 15:42:00 -0700 Subject: [erlang-patches] Fix 2 second delay after eval in shell running under ssh_cli In-Reply-To: References: <4FBE00DD.1070705@erlang.org> Message-ID: On Thu, May 24, 2012 at 1:36 PM, Bob Ippolito wrote: > On Thu, May 24, 2012 at 12:46 PM, Bob Ippolito wrote: > >> On Thu, May 24, 2012 at 11:53 AM, Tuncer Ayaz wrote: >> >>> On Thu, May 24, 2012 at 8:25 PM, Bob Ippolito wrote: >>> > Also, what's the procedure for building just the ssh application? >>> > https://github.com/erlang/otp/wiki/Running-tests covers how to run >>> > tests for a single application after building all of OTP, but not >>> > how to build it again after making some changes. >>> >>> $ cd lib/ssh >>> $ make >>> >> >> Seems to build, but does that get it into the release that the tests are >> run against, or is there a different way to run the tests for just the ssh >> app in-place like this? >> > > It seems that the ssh tests do not pass even without my changes, at least > on my Mac OS X machine. In fact, they seem to hang (possibly indefinitely, > but I haven't waited that long). > > Here's the output from attempting to run them on the maint branch at > revision 9bbda97: > https://gist.github.com/2784056 > I'm seeing similar failures on Linux. Maybe I'm missing a step somewhere? https://gist.github.com/2784652 -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Fri May 25 12:23:29 2012 From: henrik@REDACTED (Henrik Nord) Date: Fri, 25 May 2012 12:23:29 +0200 Subject: [erlang-patches] [patch] new float_to_list/2 In-Reply-To: <4FBE3F78.8050405@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> Message-ID: <4FBF5DA1.70609@erlang.org> Hi Have you consulted the wiki @github? https://github.com/erlang/otp/wiki/Running-tests To run all test suites do ts:run(). application: ts:run(Application, [batch]). Suite: ts:run(emulator, bif_SUITE, [batch]). I refetched your branch Thank you for the contribution! On 05/24/2012 04:02 PM, Serge Aleynikov wrote: > Henrik, > > Fetch: git fetch https://github.com/saleyn/otp/tree/float_to_list_2 > Diff: https://github.com/saleyn/otp/compare/float_to_list_2 > > I added the definition for the new BIF to make the type checker happy: > https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 > > Once you do the "otp_build tests", how do you execute all tests suites > in $ERL_TOP or if possible only tests in a given SUITE? I tried the > following but all tests fail: > > [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s test_server_ctrl > run_test DIR "." -s erlang halt > > I did however run individual tests in bif_SUIT:types to make sure my > patch didn't break anything. > > > > Serge > > On 5/24/2012 5:17 AM, Henrik Nord wrote: >> Hi again. >> >> >> This test is not passing: emulator/bif_SUIT:types >> >> No type information: >> >> [{erlang,float_to_list,2}] >> >> >> >> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 -- /Henrik Nord Erlang/OTP From tuncer.ayaz@REDACTED Fri May 25 17:26:47 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 25 May 2012 17:26:47 +0200 Subject: [erlang-patches] Fix 2 second delay after eval in shell running under ssh_cli In-Reply-To: References: <4FBE00DD.1070705@erlang.org> Message-ID: On Fri, May 25, 2012 at 12:42 AM, Bob Ippolito wrote: > On Thu, May 24, 2012 at 1:36 PM, Bob Ippolito wrote: > > > > On Thu, May 24, 2012 at 12:46 PM, Bob Ippolito wrote: > > > > Here's the output from attempting to run them on the maint branch at > > revision 9bbda97: > > https://gist.github.com/2784056 > > > I'm seeing similar failures on Linux. Maybe I'm missing a step somewhere? > > https://gist.github.com/2784652 While I don't want to encourage ignoring the tests which rely on a running OpenSSH sshd, if you stop sshd you should have 26 tests skipped with "No openssh server" and the rest passing successfully. The failing tests seem to be all from the 26 skipped. From henrik@REDACTED Thu May 31 14:07:27 2012 From: henrik@REDACTED (Henrik Nord) Date: Thu, 31 May 2012 14:07:27 +0200 Subject: [erlang-patches] better delete_any in gb_{sets, trees}, better difference in gb_sets In-Reply-To: <4F8FFC18.1060805@rabbitmq.com> References: <4F8C949F.3010601@rabbitmq.com> <4F8D948B.4030102@gmail.com> <4F8D98AB.8020808@rabbitmq.com> <4F8FFC18.1060805@rabbitmq.com> Message-ID: <4FC75EFF.7050605@erlang.org> Hi Your branch "gb-delete_any" has been reviewed with the following comments: fma/gb-delete_any The commits should have been squashed. Rejected. Breaks the documentation which says that it does nothing if the key is not present. And for you branch "gb_difference" the comments are as follows fma/gb_difference The commits should have been squashed. Clarify: Explain what is not sane with the current gb_sets:difference/2 and gb_sets:is_subset/2. Thank you for your contribution! -- /Henrik Nord Erlang/OTP From carlsson.richard@REDACTED Thu May 31 14:30:35 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 31 May 2012 14:30:35 +0200 Subject: [erlang-patches] better delete_any in gb_{sets, trees}, better difference in gb_sets In-Reply-To: <4FC75EFF.7050605@erlang.org> References: <4F8C949F.3010601@rabbitmq.com> <4F8D948B.4030102@gmail.com> <4F8D98AB.8020808@rabbitmq.com> <4F8FFC18.1060805@rabbitmq.com> <4FC75EFF.7050605@erlang.org> Message-ID: <4FC7646B.2020103@gmail.com> Henrik's comments were a bit terse. I made some more detailed comments from an implementation perspective, under https://github.com/erlang/otp/commit/5bb65b7c8db3a9cdc233d2f323581c95614cb3fb and https://github.com/erlang/otp/commit/5529e94bd91bc410d01a433084d586e98cf408ef I don't have time to do the changes myself right now, so I'd appreciate if you rework your patches along the lines of what I suggested. /Richard On 05/31/2012 02:07 PM, Henrik Nord wrote: > Hi > Your branch "gb-delete_any" has been reviewed with the following comments: > > > fma/gb-delete_any > The commits should have been squashed. > > Rejected. Breaks the documentation which says that it does nothing > if the key is not present. > > > And for you branch "gb_difference" the comments are as follows > > fma/gb_difference > The commits should have been squashed. > > Clarify: Explain what is not sane with the current > gb_sets:difference/2 and gb_sets:is_subset/2. > > > Thank you for your contribution! >