From knutin@REDACTED Wed Jul 1 10:25:35 2015 From: knutin@REDACTED (Knut Nesheim) Date: Wed, 1 Jul 2015 10:25:35 +0200 Subject: [erlang-bugs] Dirty schedulers and '-smp disable' In-Reply-To: References: Message-ID: Yes, your answer makes sense. Just to clarify, the VM has been built with smp support, but when it boots up on a single-core machine it doesn't enable smp because it only detects one logical processor. I was able to reproduce the "dirty nif stuck" problem with "erl -smp disable". Knut On Tue, Jun 30, 2015 at 5:06 PM, Steve Vinoski wrote: > > > On Tue, Jun 30, 2015 at 10:39 AM, Knut Nesheim wrote: >> >> Dear list, >> >> I ran into unexpected behaviour in the following situation: >> >> * OTP 18.0, compiled from the git tag with dirty schedulers enabled >> * NIF with the ERL_NIF_DIRTY_JOB_CPU_BOUND flag >> * Small machine with only one core (AWS t1.micro) >> * The first log line from startup with no explicit flags looks like >> this: Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10] >> [hipe] [kernel-poll:false] >> >> When I call the NIF, the calling process hangs forever. When I call it >> from the shell, I'm unable to interrupt the process (C-g, i 1 does >> nothing useful). >> >> If I explicitly use '-smp enable' as arguments to erl, the NIF runs >> fine. In that case the first log line looks like this: Erlang/OTP 18 >> [erts-7.0] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:10] >> [hipe] [kernel-poll:false] >> >> This behaviour got me a bit confused, as there is no indication what >> is happening except "something somewhere got stuck". It's not a common >> case for me, as most machines have multiple cores except tiny cloud >> instances or virtual machines. > > > The short answer is that currently, dirty schedulers always require SMP. > > The longer answer is that configure should raise an error if this > configuration is attempted. I can't recall for sure but I think it behaved > like this at one point, but a lot changed for Erlang 18 and so perhaps this > config check got lost along the way. > > --steve From krupicka.adam@REDACTED Fri Jul 3 20:07:16 2015 From: krupicka.adam@REDACTED (Adam Krupicka) Date: Fri, 03 Jul 2015 18:07:16 +0000 Subject: [erlang-bugs] SSH library does not conform to the RFC standard Message-ID: Hi, I recently tried to play with distributed CT (Common Tests); these require the ability to open a SSH connection to the target host to start the remote nodes. It was there that I found that Erlang is unable to open a SSH connection to an up-to-date, defautly-configured OpenSSH server. The SSH Erlang library only supports a single Kex (key-exchange algorithm): diffie-hellman-group1-sha1. The RFC[1], however, specifically requests that every SSH implementation must also support the diffie-hellman-group14-sha1 algorithm. The current version of OpenSSH (OpenSSH_6.8p1, OpenSSL 1.0.2c 12 Jun 2015) in its default configuration only accepts: curve25519-sha256@REDACTED, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha1. I've been told in #erlang on irc.freenode.net that the SSH library was probably only meant to access Erlang systems running SSH shells, however, the CT implementation depends on being able to connect to a real OpenSSH server; that is, on a correct implementation of the SSH standard. I thought fixing this would be just a matter of implementing the correct Kex algorithm, but upon looking at the source I saw that the current implementation of the Kex algorithms seems to be a bit of a hack[2]. Can you please confirm that this is indeed a bug? I did also come across other people having what I consider to be the same issue[3]. Thanks, A. K. [1] https://tools.ietf.org/html/rfc4253#section-8.2 [2] https://github.com/erlang/otp/blob/74a95b3d511177a9b35c2b0272b9ca5511b6f750/lib/ssh/src/ssh_transport.erl#L367 [3] https://stackoverflow.com/questions/31193906/cannot-connect-to-openssh-using-otp-ssh-module -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Fri Jul 3 22:02:40 2015 From: tony@REDACTED (Tony Rogvall) Date: Fri, 3 Jul 2015 22:02:40 +0200 Subject: [erlang-bugs] SSH library does not conform to the RFC standard In-Reply-To: References: Message-ID: <4DE8D4CF-A6A3-49F7-9840-95B888CF59B1@rogvall.se> Sent from my iPad > On 3 jul 2015, at 20:07, Adam Krupicka wrote: > > Hi, > > I recently tried to play with distributed CT (Common Tests); these require the ability to open a SSH connection to the target host to start the remote nodes. It was there that I found that Erlang is unable to open a SSH connection to an up-to-date, defautly-configured OpenSSH server. The SSH Erlang library only supports a single Kex (key-exchange algorithm): diffie-hellman-group1-sha1. The RFC[1], however, specifically requests that every SSH implementation must also support the diffie-hellman-group14-sha1 algorithm. The current version of OpenSSH (OpenSSH_6.8p1, OpenSSL 1.0.2c 12 Jun 2015) in its default configuration only accepts: > curve25519-sha256@REDACTED, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha1. Strange, because the RFC also states that diffie-hellman-group1-sha1 MUST also be supported, in the paragraph above the one you are referring to (8.1) I guess the SSH servers are not running in an interoperability mode? I guess that adding kext algorithm and making the code more flexible should be an easy task. > I've been told in #erlang on irc.freenode.net that the SSH library was probably only meant to access Erlang systems running SSH shells, however, the CT implementation depends on being able to connect to a real OpenSSH server; that is, on a correct implementation of the SSH standard. > I thought fixing this would be just a matter of implementing the correct Kex algorithm, but upon looking at the source I saw that the current implementation of the Kex algorithms seems to be a bit of a hack[2]. > A long time ago ... > Can you please confirm that this is indeed a bug? I did also come across other people having what I consider to be the same issue[3]. > It is probably not a bug, it just does not comply to the RFC 4253. /Tony > > Thanks, > A. K. > > > > [1] https://tools.ietf.org/html/rfc4253#section-8.2 > [2] https://github.com/erlang/otp/blob/74a95b3d511177a9b35c2b0272b9ca5511b6f750/lib/ssh/src/ssh_transport.erl#L367 > [3] https://stackoverflow.com/questions/31193906/cannot-connect-to-openssh-using-otp-ssh-module > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From krupicka.adam@REDACTED Fri Jul 3 22:46:32 2015 From: krupicka.adam@REDACTED (Adam Krupicka) Date: Fri, 03 Jul 2015 20:46:32 +0000 Subject: [erlang-bugs] SSH library does not conform to the RFC standard In-Reply-To: <4DE8D4CF-A6A3-49F7-9840-95B888CF59B1@rogvall.se> References: <4DE8D4CF-A6A3-49F7-9840-95B888CF59B1@rogvall.se> Message-ID: > > Strange, because the RFC also states that diffie-hellman-group1-sha1 MUST > also be supported, in the paragraph above the one you are referring to (8.1) > I guess the SSH servers are not running in an interoperability mode? > Sorry, I wasn't clear enough. The algorithm is supported, but is disabled by default in the OpenSSH version (that I've mentioned above) I'm using. I don't know what the reason behind that choice was, though. A. K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex@REDACTED Tue Jul 7 01:17:02 2015 From: alex@REDACTED (Alex Wilson) Date: Tue, 07 Jul 2015 09:17:02 +1000 Subject: [erlang-bugs] SSH library does not conform to the RFC standard In-Reply-To: References: <4DE8D4CF-A6A3-49F7-9840-95B888CF59B1@rogvall.se> Message-ID: <1436224622.30264.7.camel@cooperi.net> On Fri, 2015-07-03 at 20:46 +0000, Adam Krupicka wrote: > Strange, because the RFC also states > that diffie-hellman-group1-sha1 MUST also be supported, in the > paragraph above the one you are referring to (8.1) > > I guess the SSH servers are not running in an interoperability > mode? > > > Sorry, I wasn't clear enough. The algorithm is supported, but is > disabled by default in the OpenSSH version (that I've mentioned above) > I'm using. I don't know what the reason behind that choice was, > though. OpenSSH have been aggressively deprecating and removing older ciphers and kex algorithms when they are found to be weak in practice. This has always been their policy (they consider security far more important than compatibility), but I guess we picked the right algos to implement originally because we've stayed compatible for quite a long time. With reference particularly to dh-group1-sha1, this is a fixed 1024 bit DH group, which is known to be vulnerable to an analogue of the LOGJAM attack (see https://weakdh.org/) -- this is the reason why support for it has been dropped by default. They normally turn these weak ciphers and kex algos off in the server first, and then a few versions later in the client, to avoid suddenly annoying too many people. The dh-group1-sha1 change has also affected some PuTTY users and those of other clients, as well. So yes, we will need to implement the group14 variant. The difference is fairly small, hopefully it won't be too much trouble. From garret.smith@REDACTED Tue Jul 7 02:25:17 2015 From: garret.smith@REDACTED (Garret Smith) Date: Mon, 6 Jul 2015 17:25:17 -0700 Subject: [erlang-bugs] Change in abstract format of user-specified -types in 18.0 (breaks PropEr) Message-ID: This code: -module(tt). -type a() :: atom(). -type b() :: a(). has a different abstract syntax in 18.0 vs 17.5 as returned by epp:parse_file("tt.erl", []) in 18.0: {ok,[{attribute,1,file,{"tt.erl",1}}, {attribute,1,module,tt}, {attribute,3,type,{a,{type,3,atom,[]},[]}}, {attribute,4,type,{b,{user_type,4,a,[]},[]}}, <-- user_type {eof,6}]} and in 17.0: {ok,[{attribute,1,file,{"tt.erl",1}}, {attribute,1,module,tt}, {attribute,3,type,{a,{type,3,atom,[]},[]}}, {attribute,4,type,{b,{type,4,a,[]},[]}}, <-- type {eof,6}]} When I use PropEr on a module containing module-defined types like 'b' above, it fails with: Error: The typeserver encountered an error: {unsupported_type,{user_type,45,point,[]}}. The module I'm checking defines -type point() and uses it in other types. Question: is this a bug, since 17.x included user_type in the abstract format, but apparently never actually used it? If this was an intended fix, I didn't read about it in the release notes (only about improving the documentation of the abstract format). Any other code, including parse transforms, that work with the abstract format could be affected as well. Thanks, Garret From garret.smith@REDACTED Tue Jul 7 02:32:18 2015 From: garret.smith@REDACTED (Garret Smith) Date: Mon, 6 Jul 2015 17:32:18 -0700 Subject: [erlang-bugs] Change in abstract format of user-specified -types in 18.0 (breaks PropEr) Message-ID: This code: -module(tt). -type a() :: atom(). -type b() :: a(). has a different abstract syntax in 18.0 vs 17.5 as returned by epp:parse_file("tt.erl", []) in 18.0: {ok,[{attribute,1,file,{"tt.erl",1}}, {attribute,1,module,tt}, {attribute,3,type,{a,{type,3,atom,[]},[]}}, {attribute,4,type,{b,{user_type,4,a,[]},[]}}, <-- user_type {eof,6}]} and in 17.0: {ok,[{attribute,1,file,{"tt.erl",1}}, {attribute,1,module,tt}, {attribute,3,type,{a,{type,3,atom,[]},[]}}, {attribute,4,type,{b,{type,4,a,[]},[]}}, <-- type {eof,6}]} When I use PropEr on a module containing module-defined types like 'b' above, it fails with: Error: The typeserver encountered an error: {unsupported_type,{user_type,45,point,[]}}. The module I'm checking defines -type point() and uses it in other types. Question: is this a bug, since 17.x included user_type in the abstract format, but apparently never actually used it? If this was an intended fix, I didn't read about it in the release notes (only about improving the documentation of the abstract format). Any other code, including parse transforms, that work with the abstract format could be affected as well. Thanks, Garret From raimo+erlang-bugs@REDACTED Thu Jul 9 11:44:29 2015 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 9 Jul 2015 11:44:29 +0200 Subject: [erlang-bugs] ipv6 bug in inet:ntoa In-Reply-To: References: Message-ID: <20150709094429.GA18276@erix.ericsson.se> On Fri, Jun 26, 2015 at 08:43:42PM +0000, Rik Ribbers wrote: > Hello, > > I've been playing around with ipv6 in erlang and came across at first > strange behaviour in converting string to ipv6 and back > > ~ --> erl > Erlang/OTP 18 [erts-7.0] [source-4d83b58] [64-bit] [smp:4:4] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V7.0 (abort with ^G) > 1>inet:parse_address("2a00:d78::147:94:198:152:68"). > {ok,{10752,3448,0,327,148,408,338,104}} > 2> inet:ntoa({10752,3448,0,327,148,408,338,104}). > "2A00:D78:0:147:94:198:152:68" > > If you look closely you will see that there is an extra 0 introduced. This > is actually correct. In IETF RFC5952 section 4.2.2 states that a single 0 > must not be shortened. This however introduces however the question is the > inet:parse_address is actually correct, however it is being friendly to its > caller... There is no ambiguity here so why not. > > The real issue is however that the addresses are displayed in uppercase > which is simply wrong. As RFC5952 clearly states in section 4.3. There is > even Errata on this issue that states it must be in lower case. > > The RFC can be found here https://tools.ietf.org/html/rfc5952 Oh dear. We'll probably have to fix that. To my defence I will say that the code is from November 2009 which predates that RFC and that it tries to follow RFC 4291 or maybe RFC 3513. It also uses erlang:integer_to_list/2 that produces uppercase, just for the same reasons that the rejected Errata voices... Thank you for pointing this out. > > Kind regards, > Rik Ribbers > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From rik.ribbers@REDACTED Thu Jul 9 12:10:53 2015 From: rik.ribbers@REDACTED (Rik Ribbers) Date: Thu, 09 Jul 2015 10:10:53 +0000 Subject: [erlang-bugs] ipv6 bug in inet:ntoa In-Reply-To: <20150709094429.GA18276@erix.ericsson.se> References: <20150709094429.GA18276@erix.ericsson.se> Message-ID: Hello Raimo, You're welcome. As I'm relatively new to Erlang, is there an external source where I can monitor this issue? Or provide a fix: string:to_lower(erlang:integer_to_list(X,16)) Kind regards, Rik Op do 9 jul. 2015 om 11:44 schreef Raimo Niskanen < raimo+erlang-bugs@REDACTED>: > On Fri, Jun 26, 2015 at 08:43:42PM +0000, Rik Ribbers wrote: > > Hello, > > > > I've been playing around with ipv6 in erlang and came across at first > > strange behaviour in converting string to ipv6 and back > > > > ~ --> erl > > Erlang/OTP 18 [erts-7.0] [source-4d83b58] [64-bit] [smp:4:4] > > [async-threads:10] [hipe] [kernel-poll:false] > > > > Eshell V7.0 (abort with ^G) > > 1>inet:parse_address("2a00:d78::147:94:198:152:68"). > > {ok,{10752,3448,0,327,148,408,338,104}} > > 2> inet:ntoa({10752,3448,0,327,148,408,338,104}). > > "2A00:D78:0:147:94:198:152:68" > > > > If you look closely you will see that there is an extra 0 introduced. > This > > is actually correct. In IETF RFC5952 section 4.2.2 states that a single 0 > > must not be shortened. This however introduces however the question is > the > > inet:parse_address is actually correct, however it is being friendly to > its > > caller... > > There is no ambiguity here so why not. > > > > > The real issue is however that the addresses are displayed in uppercase > > which is simply wrong. As RFC5952 clearly states in section 4.3. There is > > even Errata on this issue that states it must be in lower case. > > > > The RFC can be found here https://tools.ietf.org/html/rfc5952 > > Oh dear. We'll probably have to fix that. > > To my defence I will say that the code is from November 2009 which predates > that RFC and that it tries to follow RFC 4291 or maybe RFC 3513. It also > uses > erlang:integer_to_list/2 that produces uppercase, just for the same reasons > that the rejected Errata voices... > > Thank you for pointing this out. > > > > > > Kind regards, > > Rik Ribbers > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-bugs@REDACTED Thu Jul 9 14:08:24 2015 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 9 Jul 2015 14:08:24 +0200 Subject: [erlang-bugs] ipv6 bug in inet:ntoa In-Reply-To: References: <20150709094429.GA18276@erix.ericsson.se> Message-ID: <20150709120824.GA19817@erix.ericsson.se> On Thu, Jul 09, 2015 at 10:10:53AM +0000, Rik Ribbers wrote: > Hello Raimo, > > You're welcome. As I'm relatively new to Erlang, is there an external > source where I can monitor this issue? Nope. Not yet. There is work in progress on an external bug tracker. > > Or provide a fix: > > string:to_lower(erlang:integer_to_list(X,16)) I am afraid we can not simply apply such a fix. I started looking at the impact of such a change, and directly stumbled upon an OTP application that uses inet_parse:ntoa/1 to get a string and then uses a regexp to match it against user supplied data to decide if a connection is allowed. In other words there are applications depending on an uppercase return value, so this would be a backwards incompatible change. So we will have to consider making a new ntoa function... Best regards. / Raimo > > Kind regards, > Rik > > Op do 9 jul. 2015 om 11:44 schreef Raimo Niskanen < > raimo+erlang-bugs@REDACTED>: > > > On Fri, Jun 26, 2015 at 08:43:42PM +0000, Rik Ribbers wrote: > > > Hello, > > > > > > I've been playing around with ipv6 in erlang and came across at first > > > strange behaviour in converting string to ipv6 and back > > > > > > ~ --> erl > > > Erlang/OTP 18 [erts-7.0] [source-4d83b58] [64-bit] [smp:4:4] > > > [async-threads:10] [hipe] [kernel-poll:false] > > > > > > Eshell V7.0 (abort with ^G) > > > 1>inet:parse_address("2a00:d78::147:94:198:152:68"). > > > {ok,{10752,3448,0,327,148,408,338,104}} > > > 2> inet:ntoa({10752,3448,0,327,148,408,338,104}). > > > "2A00:D78:0:147:94:198:152:68" > > > > > > If you look closely you will see that there is an extra 0 introduced. > > This > > > is actually correct. In IETF RFC5952 section 4.2.2 states that a single 0 > > > must not be shortened. This however introduces however the question is > > the > > > inet:parse_address is actually correct, however it is being friendly to > > its > > > caller... > > > > There is no ambiguity here so why not. > > > > > > > > The real issue is however that the addresses are displayed in uppercase > > > which is simply wrong. As RFC5952 clearly states in section 4.3. There is > > > even Errata on this issue that states it must be in lower case. > > > > > > The RFC can be found here https://tools.ietf.org/html/rfc5952 > > > > Oh dear. We'll probably have to fix that. > > > > To my defence I will say that the code is from November 2009 which predates > > that RFC and that it tries to follow RFC 4291 or maybe RFC 3513. It also > > uses > > erlang:integer_to_list/2 that produces uppercase, just for the same reasons > > that the rejected Errata voices... > > > > Thank you for pointing this out. > > > > > > > > > > Kind regards, > > > Rik Ribbers > > > > > _______________________________________________ > > > erlang-bugs mailing list > > > erlang-bugs@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From mjtruog@REDACTED Fri Jul 10 03:53:27 2015 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 09 Jul 2015 18:53:27 -0700 Subject: [erlang-bugs] supervisor transient child error? Message-ID: <559F2597.7030909@gmail.com> Hi, I have noticed that when the supervisor has a child process with the childspec restart set to transient, and the process terminates in a way that is not abnormal, the childspec remains within the supervisor. This appears to be an error based on old documentation: "When a |temporary|child dies for any reason or a |transient|child dies normally, the child is removed from the supervisor." (http://www.erlang.org/documentation/doc-4.8.2/lib/stdlib-1.6.1/doc/html/supervisor.html). The new documentation states: "a transientchild process will be restarted only if it terminates abnormally, i.e. with another exit reason than normal, shutdownor {shutdown,Term}" (http://www.erlang.org/doc/man/supervisor.html), and this statement is true with the current supervisor code. Is it an error that transient processes that terminate in a way that is not abnormal do not get removed from the supervisor? I think it is, but I am not sure if this was accepted legacy behavior that the documentation didn't want to contradict. I have an example below with output: -module(test). -behaviour(supervisor). -export([start_link/0, test_child/0, test/0, init/1]). start_link() -> supervisor:start_link({local, ?MODULE}, ?MODULE, []). test_child() -> {ok, erlang:spawn_link(fun() -> erlang:exit(normal) end)}. test() -> ChildSpec = {test, {test, test_child, []}, transient, 2000, worker, []}, supervisor:start_child(?MODULE, ChildSpec). init([]) -> {ok, {{one_for_one, 5, 300}, []}}. Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:10] [kernel-poll:false] Eshell V7.0 (abort with ^G) 1> {ok, Sup} = test:start_link(). {ok,<0.35.0>} 2> erlang:unlink(Sup). true 3> {ok, P} = test:test(). {ok,<0.38.0>} 4> erlang:is_process_alive(P). false 5> supervisor:which_children(test). [{test,undefined,worker,[]}] 6> test:test(). {error,already_present} Isn't keeping the entry in the supervisor, after a termination that is not abnormal, an error? Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aleksander.Nycz@REDACTED Fri Jul 10 16:10:06 2015 From: Aleksander.Nycz@REDACTED (Aleksander Nycz) Date: Fri, 10 Jul 2015 16:10:06 +0200 Subject: [erlang-bugs] mnesia:dirty_update_counter doesn't work as expected in mnesia_frag context Message-ID: <559FD23E.4080708@comarch.pl> Hello, Please create frag table: rd(testCounter, {key, value}). testCounter mnesia:create_table(tTest , [{ram_copies, [node()]} ,{type,set} ,{attributes,record_info(fields, testCounter)} ,{record_name, testCounter} ,{frag_properties, [{n_fragments, 10}, {n_ram_copies, 1}, {node_pool, [node()]}]}]) and insert record using mnesia:write/3 func, that is called in mnesia_frag access context: mnesia:activity(sync_dirty, fun()-> mnesia:table_info(tTest, size) end, [], mnesia_frag). 0 mnesia:activity(sync_dirty, fun() -> mnesia:write(tTest, {testCounter, 100, 200}, write) end, [], mnesia_frag). ok mnesia:activity(sync_dirty, fun()-> mnesia:table_info(tTest, size) end, [], mnesia_frag). 1 [T || T <- ([tTest] ++ [list_to_atom("tTest_frag" ++ integer_to_list(N)) || N <- lists:seq(2, 10)]), mnesia:table_info(T, size) > 0]. [tTest_frag2] ets:tab2list(tTest_frag2). [#testCounter{key = 100,value = 200}] *We have 1 record in table in frag: tTest_frag2* Now please "insert" record using mnesia:dirty_update_counter/3: [mnesia:clear_table(T) || T <- ([tTest] ++ [list_to_atom("tTest_frag" ++ integer_to_list(N)) || N <- lists:seq(2, 10)])]. [{atomic,ok}, {atomic,ok}, {atomic,ok}, {atomic,ok}, {atomic,ok}, {atomic,ok}, {atomic,ok}, {atomic,ok}, {atomic,ok}, {atomic,ok}] mnesia:activity(sync_dirty, fun()-> mnesia:table_info(tTest, size) end, [], mnesia_frag). 0 mnesia:activity(sync_dirty, fun() -> mnesia:dirty_update_counter(tTest, 100, 200) end, [], mnesia_frag). 200 mnesia:activity(sync_dirty, fun()-> mnesia:table_info(tTest, size) end, [], mnesia_frag). 1 [T || T <- ([tTest] ++ [list_to_atom("tTest_frag" ++ integer_to_list(N)) || N <- lists:seq(2, 10)]), mnesia:table_info(T, size) > 0]. [tTest] ets:tab2list(tTest). [#testCounter{key = 100,value = 200}] *Now record goes to 1st frag: tTest* So it looks, that dirty_update_counter doesn't handle frag table properly. Best regards Aleksander Nycz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4936 bytes Desc: Kryptograficzna sygnatura S/MIME URL: From dszoboszlay@REDACTED Mon Jul 13 11:30:46 2015 From: dszoboszlay@REDACTED (=?UTF-8?Q?D=C3=A1niel_Szoboszlay?=) Date: Mon, 13 Jul 2015 11:30:46 +0200 Subject: [erlang-bugs] Emacs indentation problems Message-ID: Hi, I found a few issues with erlang.el's indentation. I'm not good enough with Emacs Lisp to write a fix, but it would be great if someone could do so. :) The following code was auto-indented with Emacs: %%% -*- mode: erlang; erlang-indent-level: 2 -*- -module(foo). -compile([export_all]). -record(comma_first, { x , y :: integer() % good indentation , z % bad indentation (caused by type spec) }). try_blocks() -> try ok, ok % bad indentation after ok end, try ok of X -> X % bad indentation: erlang-indent-level is 2! after ok end, try ok of Y -> % bad indentation Y % looks terrible after ok end. list_comprehensions() -> [ok || X <- [ 1 , 2 , 3] % comma-first indentation works here , X > 2 % but not here ]. In case email would screw the indentation, here's the same in a gist: https://gist.github.com/dszoboszlay/bf60b674dadc49c7d999 Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Wed Jul 15 05:59:36 2015 From: sdl.web@REDACTED (Leo Liu) Date: Wed, 15 Jul 2015 11:59:36 +0800 Subject: [erlang-bugs] Typo on leex:file/2 options Message-ID: The documentation in parsetools-2.1/doc/html/leex.html#file-2 says returning: {error, Warnings, Errors}, but the code seems to suggest {error, Errors, Warnings}. Leo From tuncer.ayaz@REDACTED Wed Jul 15 10:49:07 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 15 Jul 2015 10:49:07 +0200 Subject: [erlang-bugs] Typo on leex:file/2 options In-Reply-To: References: Message-ID: On Wed, Jul 15, 2015 at 5:59 AM, Leo Liu wrote: > The documentation in parsetools-2.1/doc/html/leex.html#file-2 says > returning: {error, Warnings, Errors}, but the code seems to suggest > {error, Errors, Warnings}. Good catch :). Actually, it's mentioned twice in the docs, and only one has the incorrect order. Also, the same error exist in yecc docs. https://github.com/erlang/otp/pull/792 From sdl.web@REDACTED Thu Jul 16 06:16:04 2015 From: sdl.web@REDACTED (Leo Liu) Date: Thu, 16 Jul 2015 12:16:04 +0800 Subject: [erlang-bugs] Typo on leex:file/2 options In-Reply-To: (Tuncer Ayaz's message of "Wed, 15 Jul 2015 10:49:07 +0200") References: Message-ID: On 2015-07-15 16:49 +0800, Tuncer Ayaz wrote: > Actually, it's mentioned twice in the docs, and only one has the > incorrect order. Also, the same error exist in yecc docs. > > https://github.com/erlang/otp/pull/792 Thanks for the fix. Leo From alttagil@REDACTED Fri Jul 17 14:00:48 2015 From: alttagil@REDACTED (Alex Hudich) Date: Fri, 17 Jul 2015 15:00:48 +0300 Subject: [erlang-bugs] bad certificate if trying to verify StartSsl certificate Message-ID: <8A2EE54F-8F44-4FD8-9B0C-C2683D078756@gmail.com> I don?t know if it is an Erlang bug but still I don?t have any clue how to resolve this situation: ubuntu 14.04 and OTP 18.0 # wget http://curl.haxx.se/ca/cacert.pem --2015-07-16 19:11:50-- http://curl.haxx.se/ca/cacert.pem Resolving curl.haxx.se (curl.haxx.se)... 2a00:1a28:1200:9::2, 80.67.6.50 Connecting to curl.haxx.se (curl.haxx.se)|2a00:1a28:1200:9::2|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 258424 (252K) Saving to: 'cacert.pem' 100%[=============================================================================================================================================================================================>] 258,424 1.62MB/s in 0.2s 2015-07-16 19:11:50 (1.62 MB/s) - 'cacert.pem' saved [258424/258424] # erl Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.0 (abort with ^G) 1> application:ensure_all_started(ssl). {ok,[crypto,asn1,public_key,ssl]} 2> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem"}] ). =ERROR REPORT==== 16-Jul-2015::19:12:18 === SSL: certify: ssl_handshake.erl:1476:Fatal error: bad certificate {error,{tls_alert,"bad certificate"}} 3> and Mac OS X and OTP 17.4 $ wget http://curl.haxx.se/ca/cacert.pem --2015-07-16 22:09:02-- http://curl.haxx.se/ca/cacert.pem Resolving curl.haxx.se... 80.67.6.50, 2a00:1a28:1200:9::2 Connecting to curl.haxx.se|80.67.6.50|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 258424 (252K) Saving to: 'cacert.pem' 100%[=============================================================================================================================================================================================>] 258,424 --.-K/s in 0.1s 2015-07-16 22:09:02 (1.92 MB/s) - 'cacert.pem' saved [258424/258424] $ erl Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] [dtrace] Eshell V6.3 (abort with ^G) 1> application:ensure_all_started(ssl). {ok,[crypto,asn1,public_key,ssl]} 2> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem"}] ). =ERROR REPORT==== 16-Jul-2015::22:09:23 === SSL: certify: ssl_handshake.erl:1389:Fatal error: bad certificate {error,{tls_alert,"bad certificate"}} 3> Then Santiago Fern?ndez reported that problem couldn?t be reproduced with OTP 17.5 and I tried it. Indeed connection was successful but I decided to dig it more and I found interesting things: I prepared two files. cacert.pem.1 was just an empty file (with zero legth) and cacert.pem which I?d downloaded earlier. And there is an output of 17.5 which seems to me wrong. Line 2 and 3 is ok. Line 4 is ok. But why line 5 gave me no error?? Erlang/OTP 17 [erts-6.4] [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.4 (abort with ^G) 1> application:ensure_all_started(ssl). {ok,[crypto,asn1,public_key,ssl]} 2> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem.1"}] ). =ERROR REPORT==== 17-Jul-2015::13:26:45 === SSL: certify: ssl_handshake.erl:1401:Fatal error: unknown ca {error,{tls_alert,"unknown ca"}} 3> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem.1"}] ). =ERROR REPORT==== 17-Jul-2015::13:26:48 === SSL: certify: ssl_handshake.erl:1401:Fatal error: unknown ca {error,{tls_alert,"unknown ca"}} 4> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem"}] ). {ok,{sslsocket,{gen_tcp,#Port<0.1236>,tls_connection, undefined}, <0.53.0>}} 5> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem.1"}] ). {ok,{sslsocket,{gen_tcp,#Port<0.1243>,tls_connection, undefined}, <0.55.0>}} -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Wed Jul 29 18:24:03 2015 From: james@REDACTED (James Fish) Date: Wed, 29 Jul 2015 17:24:03 +0100 Subject: [erlang-bugs] Type assertion failure when tracing with process_dump message Message-ID: When using {message, {process_dump}} in a trace the VM can abort on OTP R16B03 to 18.0.2 (not R16B02 and earlier) on a linux 3.19.0-21-generic x86_64: TYPE ASSERTION FAILED, file beam/erl_term.c, line 115: tag_val_def: 0x7f9c183ee6d2 Aborted (core dumped) #0 0x00007f9c1c56f267 in __GI_raise (sig=sig@REDACTED=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007f9c1c570eca in __GI_abort () at abort.c:89 #2 0x000000000056dfd1 in et_abort (expr=0x9081e0 "tag_val_def: 0x7f9c183ee6d2", file=0x64fe45 "beam/erl_term.c", line=115) at beam/erl_term.c:48 #3 tag_val_def (x=x@REDACTED=140308398401234) at beam/erl_term.c:115 #4 0x00000000004cf12e in print_term (obj_base=, dcount=, obj=140308398401234, arg=0x7f9c1d780078, fn=0x630a10 ) at beam/erl_printf_term.c:352 #5 erts_printf_term (fn=0x630a10 , arg=0x7f9c1d780078, term=, precision=99999, term_base=) at beam/erl_printf_term.c:657 #6 0x000000000062ed17 in erts_printf_format (fn=fn@REDACTED=0x630a10 , arg=arg@REDACTED=0x7f9c1d780078, fmt=fmt@REDACTED=0x64830b "%T\n", ap=ap@REDACTED=0x7f9c198fc640) at common/erl_printf_format.c:847 #7 0x0000000000631750 in erts_vdsprintf (dsbufp=dsbufp@REDACTED=0x7f9c1d780078, format=format@REDACTED=0x64830b "%T\n", arglist=arglist@REDACTED=0x7f9c198fc640) at common/erl_printf.c:459 #8 0x00000000004a9696 in erts_print (to=to@REDACTED=-4, arg=arg@REDACTED=0x7f9c1d780078, format=format@REDACTED=0x64830b "%T\n") at beam/utils.c:400 #9 0x00000000004ea8cf in stack_element_dump (yreg=2, sp=0x7f9c183ef258, to_arg=0x7f9c1d780078, to=-4) at beam/erl_process.c:12546 #10 erts_stack_dump (to=to@REDACTED=-4, to_arg=to_arg@REDACTED=0x7f9c1d780078, p=p@REDACTED=0x7f9c1bb003d8) at beam/erl_process.c:12466 #11 0x000000000055b56d in print_process_info (to=to@REDACTED=-4, to_arg=to_arg@REDACTED=0x7f9c1d780078, p=p@REDACTED=0x7f9c1bb003d8) at beam/break.c:339 #12 0x000000000052cc20 in db_prog_match (c_p=c_p@REDACTED=0x7f9c1bb003d8, bprog=0x7f9c1bdc0b78, term=term@REDACTED=18446744073709551611, base=base@REDACTED=0x0, termp=termp@REDACTED=0x7f9c198fca70, arity=arity@REDACTED=1, in_flags=ERTS_PAM_TMP_RESULT, return_flags=0x7f9c198fca14) at beam/erl_db_util.c:2404 #13 0x000000000052e5ec in erts_match_set_run (p=p@REDACTED=0x7f9c1bb003d8, mpsp=, args=args@REDACTED=0x7f9c198fca70, num_args=num_args@REDACTED=1, in_flags=in_flags@REDACTED=ERTS_PAM_TMP_RESULT, return_flags=return_flags@REDACTED=0x7f9c198fca14) at beam/erl_db_util.c:1243 #14 0x00000000004a0c55 in erts_call_trace (p=p@REDACTED=0x7f9c1bb003d8, mfa=mfa@REDACTED=0x7f9c1822f058, match_spec=, args=0x7f9c198fca70, args@REDACTED=0x7f9c1bfc4180, local=local@REDACTED=1, tracer_pid=0x7f9c1bb003e8, tracer_pid@REDACTED=0x7f9c198fdcc8) at beam/erl_trace.c:1873 #15 0x0000000000455654 in do_call_trace (c_p=0x7f9c1bb003d8, I=0x7f9c1822f070, reg=0x7f9c1bfc4180, local=local@REDACTED=1, ms=, tracer_pid=tracer_pid@REDACTED=75) at beam/beam_bp.c:900 #16 0x0000000000459524 in erts_generic_breakpoint (c_p=0x7f9c1bb003d8, I=0x7f9c1822f070, reg=0x7f9c1bfc4180) at beam/beam_bp.c:626 #17 0x0000000000443f23 in process_main () at beam/beam_emu.c:4921 #18 0x00000000004d6415 in sched_thread_func (vesdp=0x7f9c1ae4bc40) at beam/erl_process.c:8021 #19 0x000000000062d0e3 in thr_wrapper (vtwd=0x7fff8a43d010) at pthread/ethread.c:114 #20 0x00007f9c1cb136aa in start_thread (arg=0x7f9c198fe700) at pthread_create.c:333 #21 0x00007f9c1c640eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 A minimal example: c("test.erl"), dbg:tracer(), dbg:p(self(), [call]), dbg:tpl(test, identity, [{'_',[],[{message,{process_dump}}]}]), test:sum(<<0>>, 0). test.erl: -module(test). -export([sum/2]). sum(<>, Acc) -> sum(Rest, Acc + identity(Int)); sum(<<>>, Acc) -> Acc. identity(Int) -> Int. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Wed Jul 29 20:55:37 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 29 Jul 2015 20:55:37 +0200 Subject: [erlang-bugs] Type assertion failure when tracing with process_dump message In-Reply-To: References: Message-ID: <21945.8617.922895.528392@gargle.gargle.HOWL> James Fish writes: > When using {message, {process_dump}} in a trace the VM can abort on OTP > R16B03 to 18.0.2 (not R16B02 and earlier) on a linux 3.19.0-21-generic > x86_64: > > TYPE ASSERTION FAILED, file beam/erl_term.c, line 115: tag_val_def: > 0x7f9c183ee6d2 > Aborted (core dumped) > > #0 0x00007f9c1c56f267 in __GI_raise (sig=sig@REDACTED=6) at > ../sysdeps/unix/sysv/linux/raise.c:55 > #1 0x00007f9c1c570eca in __GI_abort () at abort.c:89 > #2 0x000000000056dfd1 in et_abort (expr=0x9081e0 "tag_val_def: > 0x7f9c183ee6d2", file=0x64fe45 "beam/erl_term.c", line=115) at > beam/erl_term.c:48 > #3 tag_val_def (x=x@REDACTED=140308398401234) at beam/erl_term.c:115 > #4 0x00000000004cf12e in print_term (obj_base=, > dcount=, obj=140308398401234, arg=0x7f9c1d780078, > fn=0x630a10 ) at beam/erl_printf_term.c:352 > #5 erts_printf_term (fn=0x630a10 , arg=0x7f9c1d780078, > term=, precision=99999, term_base=) at > beam/erl_printf_term.c:657 > #6 0x000000000062ed17 in erts_printf_format (fn=fn@REDACTED=0x630a10 > , arg=arg@REDACTED=0x7f9c1d780078, fmt=fmt@REDACTED=0x64830b "%T\n", > ap=ap@REDACTED=0x7f9c198fc640) at common/erl_printf_format.c:847 > #7 0x0000000000631750 in erts_vdsprintf (dsbufp=dsbufp@REDACTED=0x7f9c1d780078, > format=format@REDACTED=0x64830b "%T\n", arglist=arglist@REDACTED=0x7f9c198fc640) > at common/erl_printf.c:459 > #8 0x00000000004a9696 in erts_print (to=to@REDACTED=-4, > arg=arg@REDACTED=0x7f9c1d780078, > format=format@REDACTED=0x64830b "%T\n") at beam/utils.c:400 > #9 0x00000000004ea8cf in stack_element_dump (yreg=2, sp=0x7f9c183ef258, > to_arg=0x7f9c1d780078, to=-4) at beam/erl_process.c:12546 > #10 erts_stack_dump (to=to@REDACTED=-4, to_arg=to_arg@REDACTED=0x7f9c1d780078, > p=p@REDACTED=0x7f9c1bb003d8) at beam/erl_process.c:12466 > #11 0x000000000055b56d in print_process_info (to=to@REDACTED=-4, > to_arg=to_arg@REDACTED=0x7f9c1d780078, p=p@REDACTED=0x7f9c1bb003d8) at > beam/break.c:339 > #12 0x000000000052cc20 in db_prog_match (c_p=c_p@REDACTED=0x7f9c1bb003d8, > bprog=0x7f9c1bdc0b78, term=term@REDACTED=18446744073709551611, > base=base@REDACTED=0x0, > termp=termp@REDACTED=0x7f9c198fca70, arity=arity@REDACTED=1, > in_flags=ERTS_PAM_TMP_RESULT, return_flags=0x7f9c198fca14) at > beam/erl_db_util.c:2404 > #13 0x000000000052e5ec in erts_match_set_run (p=p@REDACTED=0x7f9c1bb003d8, > mpsp=, args=args@REDACTED=0x7f9c198fca70, > num_args=num_args@REDACTED=1, in_flags=in_flags@REDACTED=ERTS_PAM_TMP_RESULT, > return_flags=return_flags@REDACTED=0x7f9c198fca14) at > beam/erl_db_util.c:1243 > #14 0x00000000004a0c55 in erts_call_trace (p=p@REDACTED=0x7f9c1bb003d8, > mfa=mfa@REDACTED=0x7f9c1822f058, match_spec=, > args=0x7f9c198fca70, args@REDACTED=0x7f9c1bfc4180, local=local@REDACTED=1, > tracer_pid=0x7f9c1bb003e8, tracer_pid@REDACTED=0x7f9c198fdcc8) at > beam/erl_trace.c:1873 > #15 0x0000000000455654 in do_call_trace (c_p=0x7f9c1bb003d8, > I=0x7f9c1822f070, reg=0x7f9c1bfc4180, local=local@REDACTED=1, ms= out>, tracer_pid=tracer_pid@REDACTED=75) at beam/beam_bp.c:900 > #16 0x0000000000459524 in erts_generic_breakpoint (c_p=0x7f9c1bb003d8, > I=0x7f9c1822f070, reg=0x7f9c1bfc4180) at beam/beam_bp.c:626 > #17 0x0000000000443f23 in process_main () at beam/beam_emu.c:4921 > #18 0x00000000004d6415 in sched_thread_func (vesdp=0x7f9c1ae4bc40) at > beam/erl_process.c:8021 > #19 0x000000000062d0e3 in thr_wrapper (vtwd=0x7fff8a43d010) at > pthread/ethread.c:114 > #20 0x00007f9c1cb136aa in start_thread (arg=0x7f9c198fe700) at > pthread_create.c:333 > #21 0x00007f9c1c640eed in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > A minimal example: > > c("test.erl"), > dbg:tracer(), > dbg:p(self(), [call]), > dbg:tpl(test, identity, [{'_',[],[{message,{process_dump}}]}]), > test:sum(<<0>>, 0). > > test.erl: > > -module(test). > > -export([sum/2]). > > sum(<>, Acc) -> > sum(Rest, Acc + identity(Int)); > sum(<<>>, Acc) -> Acc. > > identity(Int) -> > Int. I can reproduce, with otp 18.0.2 on Linux x86_64 w/ gcc-4.9.3. Inspecting the term at the final et_abort() in tag_val_def() gave me nonsense data (it looked like a perfectly fine 2-tuple), but adding an et_abort() at the end of the TAG_PRIMARY_BOXED case showed me a boxed term with header 0x144, a BIN_MATCHSTATE_SUBTAG, which isn't allowed here (it's not a user-visible term type). Running with erl -smp disable didn't prevent the error, so it's hopefully not a concurrency problem. From niku@REDACTED Thu Jul 30 19:40:42 2015 From: niku@REDACTED (-E:), niku) Date: Fri, 31 Jul 2015 02:40:42 +0900 Subject: [erlang-bugs] erlang:binary_to_integer(<<"+">>) returns 0 Message-ID: Hi folks. erlang:binary_to_integer(<<"+">>) and erlang:binary_to_integer(<<"-">>) return 0 I think it should cause exception same as erlang:list_to_integer("+"). Here is an example $ erl Erlang/OTP 17 [erts-6.4] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [dtrace] Eshell V6.4 (abort with ^G) 1> binary_to_integer(<<"+">>). 0 2> binary_to_integer(<<"-">>). 0 regards. From mikpelinux@REDACTED Fri Jul 31 21:26:40 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Fri, 31 Jul 2015 21:26:40 +0200 Subject: [erlang-bugs] erlang:binary_to_integer(<<"+">>) returns 0 In-Reply-To: References: Message-ID: <21947.52208.375066.547172@gargle.gargle.HOWL> -E:), niku writes: > Hi folks. > > erlang:binary_to_integer(<<"+">>) and > erlang:binary_to_integer(<<"-">>) return 0 > > I think it should cause exception same as erlang:list_to_integer("+"). > > Here is an example > > $ erl > Erlang/OTP 17 [erts-6.4] [source] [64-bit] [smp:4:4] > [async-threads:10] [hipe] [kernel-poll:false] [dtrace] > > Eshell V6.4 (abort with ^G) > 1> binary_to_integer(<<"+">>). > 0 > 2> binary_to_integer(<<"-">>). > 0 > > regards. Confirmed with otp 18.0.2. Fix: https://github.com/erlang/otp/pull/803