From roberto.aloi@REDACTED Thu Mar 1 17:43:37 2012 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Thu, 01 Mar 2012 16:43:37 -0000 (GMT) Subject: [erlang-bugs] Any special reason why filename:join/1 doesn't accept empty lists? Message-ID: Hi all, I've just noticed that filename:join/1 doesn't accept empty lists as input. This seems not clear in the documentation: http://www.erlang.org/doc/man/filename.html#join-1 join(Components) -> file:filename() Components = [file:filename()] >From the file documentation: http://www.erlang.org/doc/man/file.html#type-filename filename() = string() | binary() As oppose example, take lists:concat/1: http://www.erlang.org/doc/man/lists.html#concat-1 concat(Things) -> string() Things = [Thing] Thing = atom() | integer() | float() | string() 1> lists:concat([]). [] 2> filename:join([]). ** exception error: no function clause matching filename:join([]) (filename.erl, line 392) Cheers, Roberto Aloi --- Erlang Solutions Ltd. www.erlang-solutions.com From robert.virding@REDACTED Sat Mar 3 00:45:55 2012 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 02 Mar 2012 23:45:55 -0000 (GMT) Subject: [erlang-bugs] Re bug In-Reply-To: Message-ID: I have a pattern a?(n)a(n) where the (n) denotes repetition so a?(3)a(3) is shorthand for a?a?a?aaa. I will call this A(3). Then the pattern A(3) should match the string a(3). Which is does in re where I get (using my shorthand forms): > re:run(a(3), A(3)). %re:run("aaa", "a?a?a?aaa"). {match,[{0,3}]} It also works as expected for bigger n: > re:run(a(15), A(15)). {match,[{0,15}]} all the way up to 22: > re:run(a(22), A(22)). {match,[{0,22}]} but for 23 it fails: > re:run(a(23), A(23)). nomatch I don't see why it fails here as the pattern should match the string. Yes, I know this is a pathological case but I still don't think it should return nomatch. If it is giving up it should say so. Otherwise this is a bug. Robert From eric.pailleau@REDACTED Sat Mar 3 13:39:11 2012 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 03 Mar 2012 13:39:11 +0100 Subject: [erlang-bugs] Re bug In-Reply-To: References: Message-ID: <4F5210EF.3070004@wanadoo.fr> Hi Robert, your pattern can be shorten to a{0,n}a{n} and this way 23 is working. 4> re:run("aaa", "a?a?a?aaa"). {match,[{0,3}]} 5> re:run("aaa", "a{0,3}a{3}"). {match,[{0,3}]} 6> re:run(string:copies("a",23), "a{0,23}a{23}"). {match,[{0,23}]} 7> re:run(string:copies("a",24), "a{0,24}a{24}"). {match,[{0,24}]} looks like this is a pattern string length limitation to more than 22*2 + 22 = 66 and less than 23*2 + 23 = ... 69 ... hum looks like it is not only pathological but sexual too :>) !!!!! hope it can help... From robert.virding@REDACTED Sat Mar 3 16:42:22 2012 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 03 Mar 2012 15:42:22 -0000 (GMT) Subject: [erlang-bugs] Re bug In-Reply-To: <4F5210EF.3070004@wanadoo.fr> Message-ID: <93a7e0cb-2a6a-47f8-bc9d-3a6c0d9fdf8c@knuth> Hi Eric, Yes, I know I can shorten it. The bug, as I see it, is that it suddenly gives up and returns 'nomatch' on a pattern/string which should match. Now I will admit that this is a very pathological pattern and that the time taken to match grows exponentially (I think) and if you give n=30 you will have to wait a long time. But if it gives up it should tell me that, perhaps return an error or crash, not lie. Hadn't noticed the 69, but of course 23+46=69 :-) Robert ----- Original Message ----- > Hi Robert, > > your pattern can be shorten to a{0,n}a{n} and this way 23 is working. > > 4> re:run("aaa", "a?a?a?aaa"). > {match,[{0,3}]} > 5> re:run("aaa", "a{0,3}a{3}"). > {match,[{0,3}]} > 6> re:run(string:copies("a",23), "a{0,23}a{23}"). > {match,[{0,23}]} > 7> re:run(string:copies("a",24), "a{0,24}a{24}"). > {match,[{0,24}]} > > looks like this is a pattern string length limitation to more than > 22*2 > + 22 = 66 and less than 23*2 + 23 = ... 69 ... > > hum looks like it is not only pathological but sexual too :>) !!!!! > > hope it can help... > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From eric.pailleau@REDACTED Sat Mar 3 17:27:03 2012 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 03 Mar 2012 17:27:03 +0100 Subject: [erlang-bugs] Re bug In-Reply-To: <93a7e0cb-2a6a-47f8-bc9d-3a6c0d9fdf8c@knuth> References: <93a7e0cb-2a6a-47f8-bc9d-3a6c0d9fdf8c@knuth> Message-ID: <4F524657.50006@wanadoo.fr> Le 03/03/2012 16:42, Robert Virding a ?crit : > Hi Eric, > > Yes, I know I can shorten it. The bug, as I see it, is that it suddenly gives up and returns 'nomatch' on a pattern/string which should match. Now I will admit that this is a very pathological pattern and that the time taken to match grows exponentially (I think) and if you give n=30 you will have to wait a long time. But if it gives up it should tell me that, perhaps return an error or crash, not lie. > > Hadn't noticed the 69, but of course 23+46=69 :-) Hi Robert, the strange thing : 6>re:run(string:copies("a",23),string:copies("a?",23)++string:copies("a",23)). nomatch while : 7>re:run(string:copies("a",24),string:copies("a?",23)++string:copies("a",23)). {match,[{0,24}]} the pattern that do not mach with 23, does on a 24 length string and not on the 23 length string. So the length of the pattern is may be not the reason but the fact that the string is modulo the pattern... but why after 23 ... mystery . It looks like it is a real bug in such case... Note that the shorten notation is not only shorter but much more quick than yours (*I know your way is just for fun*) re:run(string:copies("a",30), "a{0,30}a{30}"). returns immediately, as well re:run(string:copies("a",1000), "a{0,1000}a{1000}") !!! while re:run(string:copies("a",1000),string:copies("a?",1000)++string:copies("a",1000)) take almost 5 seconds to return on my laptop. Best regards. From mayamatakeshi@REDACTED Sun Mar 4 04:19:44 2012 From: mayamatakeshi@REDACTED (mayamatakeshi) Date: Sun, 4 Mar 2012 12:19:44 +0900 Subject: [erlang-bugs] {error,ekeyfile} when using new ssl implementation Message-ID: Hello, I have this keyfile that I use with the old SSL implementation and it works fine with this code: -module(ssl_test). -export([connect/0]). connect() -> ssl:start(), Address = "gateway.sandbox.push.apple.com", Port = 2195, CaCert = "entrust_root_certification_authority.pem", Cert = "server_cerificates_bundle_sandbox.pem", Key = "server_cerificates_bundle_sandbox.pem", Options = [{cacertfile, CaCert}, {certfile, Cert}, {keyfile, Key}, {mode, binary}, {ssl_imp, old}], Timeout = 1000, ssl:connect(Address, Port, Options, Timeout). However, when I try to use the new ssl implementation, I get this: [root@REDACTED erlang]# erl Erlang R15B (erts-5.9) [source] [64-bit] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1> ssl_test:connect(). {error,ekeyfile} 2> =ERROR REPORT==== 4-Mar-2012::12:08:29 === SSL: 1093: error:[{'RSAPrivateKey',<< .... >>, not_encrypted}, {'RSAPrivateKey',<< .... >>, not_encrypted}] server_cerificates_bundle_sandbox.pem [{ssl_connection,init_private_key,5, [{file,"ssl_connection.erl"},{line,1085}]}, {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1027}]}, {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,305}]}, {gen_fsm,init_it,6,[{file,"gen_fsm.erl"},{line,343}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] The server_cerificates_bundle_sandbox.pem file has this format: Bag Attributes friendlyName: XXXXXXXX localKeyID: XXXXXX subject=XXXXXXX issuer=XXXXXXX -----BEGIN CERTIFICATE----- XXXXXXXXXX -----END CERTIFICATE----- Bag Attributes friendlyName: XXXXXX localKeyID: XXXXXX subject=XXXXXXXXXX issuer=XXXXXXXXX -----BEGIN CERTIFICATE----- XXXXXXXXXXXX -----END CERTIFICATE----- Bag Attributes friendlyName: XXXXXXXXX localKeyID: XXXXXXXX Key Attributes: -----BEGIN RSA PRIVATE KEY----- XXXXXXXXXXXXX -----END RSA PRIVATE KEY----- Bag Attributes friendlyName: XXXXXXXXXXX localKeyID: XXXXXXXXXXX Key Attributes: -----BEGIN RSA PRIVATE KEY----- XXXXXXXXXXXXX -----END RSA PRIVATE KEY----- So is this format supported by the new ssl implementation? Is this a bug? Or should I somehow convert this to a different format? regards, Takeshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Mon Mar 5 09:41:50 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 5 Mar 2012 09:41:50 +0100 Subject: [erlang-bugs] {error, ekeyfile} when using new ssl implementation In-Reply-To: References: Message-ID: <4F547C4E.9030001@erix.ericsson.se> Hi! The problem is that your file includes two keys and new ssl only expects there to be one. old ssl was only a glue on top of openssl so the keyfile was then passed to openssl. So it looks like openssl will pick a key if there is more than one. In a future extension of the ssl application there might be a reason to handle more keys, but at the moment I am not sure what would be the correct thing to do, we could of course always pick the first key or something like that if it will preserve some kind of backwards compatibility. Do you know why your file contains two keys? That could help determining what to do. Regards Ingela Erlang/OTP team - Ericsson AB mayamatakeshi wrote: > Hello, > I have this keyfile that I use with the old SSL implementation and it > works fine with this code: > > -module(ssl_test). > -export([connect/0]). > > connect() -> > ssl:start(), > > Address = "gateway.sandbox.push.apple.com > ", > Port = 2195, > CaCert = "entrust_root_certification_authority.pem", > Cert = "server_cerificates_bundle_sandbox.pem", > Key = "server_cerificates_bundle_sandbox.pem", > > Options = [{cacertfile, CaCert}, {certfile, Cert}, {keyfile, > Key}, {mode, binary}, {ssl_imp, old}], > Timeout = 1000, > ssl:connect(Address, Port, Options, Timeout). > > > However, when I try to use the new ssl implementation, I get this: > > [root@REDACTED erlang]# erl > Erlang R15B (erts-5.9) [source] [64-bit] [smp:2:2] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.9 (abort with ^G) > 1> ssl_test:connect(). > {error,ekeyfile} > 2> > =ERROR REPORT==== 4-Mar-2012::12:08:29 === > SSL: 1093: error:[{'RSAPrivateKey',<< .... >>, > not_encrypted}, > {'RSAPrivateKey',<< .... >>, > not_encrypted}] > server_cerificates_bundle_sandbox.pem > [{ssl_connection,init_private_key,5, > [{file,"ssl_connection.erl"},{line,1085}]}, > {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1027}]}, > {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,305}]}, > {gen_fsm,init_it,6,[{file,"gen_fsm.erl"},{line,343}]}, > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] > > > The server_cerificates_bundle_sandbox.pem file has this format: > > Bag Attributes > friendlyName: XXXXXXXX > localKeyID: XXXXXX > subject=XXXXXXX > issuer=XXXXXXX > -----BEGIN CERTIFICATE----- > XXXXXXXXXX > -----END CERTIFICATE----- > Bag Attributes > friendlyName: XXXXXX > localKeyID: > XXXXXX > subject=XXXXXXXXXX > issuer=XXXXXXXXX > -----BEGIN CERTIFICATE----- > XXXXXXXXXXXX > -----END CERTIFICATE----- > Bag Attributes > friendlyName: XXXXXXXXX > localKeyID: XXXXXXXX > Key Attributes: > -----BEGIN RSA PRIVATE KEY----- > XXXXXXXXXXXXX > -----END RSA PRIVATE KEY----- > Bag Attributes > friendlyName: XXXXXXXXXXX > localKeyID: XXXXXXXXXXX > Key Attributes: > -----BEGIN RSA PRIVATE KEY----- > XXXXXXXXXXXXX > -----END RSA PRIVATE KEY----- > > So is this format supported by the new ssl implementation? Is this a bug? > Or should I somehow convert this to a different format? > > regards, > Takeshi > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From mayamatakeshi@REDACTED Tue Mar 6 02:14:58 2012 From: mayamatakeshi@REDACTED (mayamatakeshi) Date: Tue, 6 Mar 2012 10:14:58 +0900 Subject: [erlang-bugs] {error, ekeyfile} when using new ssl implementation In-Reply-To: <4F547C4E.9030001@erix.ericsson.se> References: <4F547C4E.9030001@erix.ericsson.se> Message-ID: Hi Ingela, I don't know the reason about the two keys: I got the pem file from an iphone app developer. I believe this is how Apple generates the files to be used to connect to its servers (APNs). But so I tried removing one of the keys and it worked with ssl new implementation. Thanks for the tip. Regards, Takeshi On Mon, Mar 5, 2012 at 5:41 PM, Ingela Anderton Andin < ingela@REDACTED> wrote: > Hi! > > The problem is that your file includes two keys and new ssl only expects > there to be one. old ssl was only a glue on top of openssl so > the keyfile was then passed to openssl. So it looks like openssl will > pick a key if there is more than one. In a future extension of the ssl > application > there might be a reason to handle more keys, but at the moment I am not > sure what would be the correct thing to do, we could of course always pick > the > first key or something like that if it will preserve some kind of > backwards compatibility. Do you know why your file contains two keys? That > could > help determining what to do. > > Regards Ingela Erlang/OTP team - Ericsson AB > > mayamatakeshi wrote: > >> Hello, >> I have this keyfile that I use with the old SSL implementation and it >> works fine with this code: >> >> -module(ssl_test). >> -export([connect/0]). >> >> connect() -> >> ssl:start(), >> >> Address = "gateway.sandbox.push.apple.**com< >> http://gateway.sandbox.push.**apple.com >> >", >> >> Port = 2195, >> CaCert = "entrust_root_certification_**authority.pem", >> Cert = "server_cerificates_bundle_**sandbox.pem", >> Key = "server_cerificates_bundle_**sandbox.pem", >> >> Options = [{cacertfile, CaCert}, {certfile, Cert}, {keyfile, Key}, >> {mode, binary}, {ssl_imp, old}], >> Timeout = 1000, >> ssl:connect(Address, Port, Options, Timeout). >> >> >> However, when I try to use the new ssl implementation, I get this: >> >> [root@REDACTED erlang]# erl >> Erlang R15B (erts-5.9) [source] [64-bit] [smp:2:2] [async-threads:0] >> [hipe] [kernel-poll:false] >> >> Eshell V5.9 (abort with ^G) >> 1> ssl_test:connect(). >> {error,ekeyfile} >> 2> >> =ERROR REPORT==== 4-Mar-2012::12:08:29 === >> SSL: 1093: error:[{'RSAPrivateKey',<< .... >>, >> not_encrypted}, >> {'RSAPrivateKey',<< .... >>, >> not_encrypted}] >> server_cerificates_bundle_**sandbox.pem >> [{ssl_connection,init_private_**key,5, >> [{file,"ssl_connection.erl"},{**line,1085}]}, >> {ssl_connection,ssl_init,2,[{**file,"ssl_connection.erl"},{** >> line,1027}]}, >> {ssl_connection,init,1,[{file,**"ssl_connection.erl"},{line,**305}]}, >> {gen_fsm,init_it,6,[{file,"**gen_fsm.erl"},{line,343}]}, >> {proc_lib,init_p_do_apply,3,[{**file,"proc_lib.erl"},{line,**227}]}] >> >> >> The server_cerificates_bundle_**sandbox.pem file has this format: >> >> Bag Attributes >> friendlyName: XXXXXXXX >> localKeyID: XXXXXX >> subject=XXXXXXX >> issuer=XXXXXXX >> -----BEGIN CERTIFICATE----- >> XXXXXXXXXX >> -----END CERTIFICATE----- >> Bag Attributes >> friendlyName: XXXXXX >> localKeyID: XXXXXX >> subject=XXXXXXXXXX >> issuer=XXXXXXXXX >> -----BEGIN CERTIFICATE----- >> XXXXXXXXXXXX >> -----END CERTIFICATE----- >> Bag Attributes >> friendlyName: XXXXXXXXX >> localKeyID: XXXXXXXX >> Key Attributes: >> -----BEGIN RSA PRIVATE KEY----- >> XXXXXXXXXXXXX >> -----END RSA PRIVATE KEY----- >> Bag Attributes >> friendlyName: XXXXXXXXXXX >> localKeyID: XXXXXXXXXXX >> Key Attributes: >> -----BEGIN RSA PRIVATE KEY----- >> XXXXXXXXXXXXX >> -----END RSA PRIVATE KEY----- >> >> So is this format supported by the new ssl implementation? Is this a bug? >> Or should I somehow convert this to a different format? >> >> regards, >> Takeshi >> >> >> >> ------------------------------**------------------------------** >> ------------ >> >> ______________________________**_________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-bugs >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay@REDACTED Tue Mar 6 06:29:18 2012 From: jay@REDACTED (Jay Nelson) Date: Mon, 5 Mar 2012 21:29:18 -0800 Subject: [erlang-bugs] Dialyzer error on supervisor:init spec in R15 Message-ID: <70044058-E6FA-4ACC-8B45-06498A8D23F6@duomark.com> My example is available as a rebar project at http://github.com/duomark/dk_yaws: make dialyze ==> meck (compile) ==> rel (compile) ==> yaws (compile) ==> dk_yaws (compile) dialyzer -Wrace_conditions ebin Checking whether the PLT /Users/jay/.dialyzer_plt is up-to-date... yes Proceeding with analysis... dk_yaws_sup.erl:47: The return type {'ok',{tuple(),[any()]}} in the specification of init/1 is not a subtype of 'ignore' | {'ok',{{'one_for_all',non_neg_integer(),non_neg_integer()} | {'one_for_one',non_neg_integer(),non_neg_integer()} | {'rest_for_one',non_neg_integer(),non_neg_integer()} | {'simple_one_for_one',non_neg_integer(),non_neg_integer()},[{_,{atom() | tuple(),atom(),'undefined' | [any()]},'permanent' | 'temporary' | 'transient','brutal_kill' | 'infinity' | non_neg_integer(),'supervisor' | 'worker','dynamic' | [atom() | tuple()]}]}}, which is the expected return type for the callback of supervisor behaviour Unknown functions: yaws_api:embedded_start_conf/4 yaws_api:setconf/2 done in 0m0.96s done (warnings were emitted) This problem can be recreated with a simple supervisor:init spec, pasted into any handy supervisor:init you have laying around: -spec init(Args::{}) -> {ok, {tuple(), list()}}. When I try it with R14B03, there are no errors. On R15B I get the above error. jay From ingela@REDACTED Tue Mar 6 09:11:22 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 6 Mar 2012 09:11:22 +0100 Subject: [erlang-bugs] {error, ekeyfile} when using new ssl implementation In-Reply-To: References: <4F547C4E.9030001@erix.ericsson.se> Message-ID: <4F55C6AA.1010707@erix.ericsson.se> Hi! Out of curiosity are the two key entries the same key or different keys? A certificate is signed by one key only. But Pem files may contain any number of entries. Regards Ingela Erlang/OTP team Ericsson AB mayamatakeshi wrote: > Hi Ingela, > I don't know the reason about the two keys: I got the pem file from an > iphone app developer. I believe this is how Apple generates the files > to be used to connect to its servers (APNs). > But so I tried removing one of the keys and it worked with ssl new > implementation. > Thanks for the tip. > > Regards, > Takeshi > > On Mon, Mar 5, 2012 at 5:41 PM, Ingela Anderton Andin > > wrote: > > Hi! > > The problem is that your file includes two keys and new ssl only > expects there to be one. old ssl was only a glue on top of openssl so > the keyfile was then passed to openssl. So it looks like openssl > will pick a key if there is more than one. In a future extension > of the ssl application > there might be a reason to handle more keys, but at the moment I > am not sure what would be the correct thing to do, we could of > course always pick the > first key or something like that if it will preserve some kind of > backwards compatibility. Do you know why your file contains two > keys? That could > help determining what to do. > > Regards Ingela Erlang/OTP team - Ericsson AB > > mayamatakeshi wrote: > > Hello, > I have this keyfile that I use with the old SSL implementation > and it works fine with this code: > > -module(ssl_test). > -export([connect/0]). > > connect() -> > ssl:start(), > > Address = "gateway.sandbox.push.apple.com > > ", > > Port = 2195, > CaCert = "entrust_root_certification_authority.pem", > Cert = "server_cerificates_bundle_sandbox.pem", > Key = "server_cerificates_bundle_sandbox.pem", > > Options = [{cacertfile, CaCert}, {certfile, Cert}, > {keyfile, Key}, {mode, binary}, {ssl_imp, old}], > Timeout = 1000, > ssl:connect(Address, Port, Options, Timeout). > > > However, when I try to use the new ssl implementation, I get this: > > [root@REDACTED erlang]# erl > Erlang R15B (erts-5.9) [source] [64-bit] [smp:2:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9 (abort with ^G) > 1> ssl_test:connect(). > {error,ekeyfile} > 2> > =ERROR REPORT==== 4-Mar-2012::12:08:29 === > SSL: 1093: error:[{'RSAPrivateKey',<< .... >>, > not_encrypted}, > {'RSAPrivateKey',<< .... >>, > not_encrypted}] > server_cerificates_bundle_sandbox.pem > [{ssl_connection,init_private_key,5, > [{file,"ssl_connection.erl"},{line,1085}]}, > > {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1027}]}, > > {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,305}]}, > {gen_fsm,init_it,6,[{file,"gen_fsm.erl"},{line,343}]}, > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] > > > The server_cerificates_bundle_sandbox.pem file has this format: > > Bag Attributes > friendlyName: XXXXXXXX > localKeyID: XXXXXX > subject=XXXXXXX > issuer=XXXXXXX > -----BEGIN CERTIFICATE----- > XXXXXXXXXX > -----END CERTIFICATE----- > Bag Attributes > friendlyName: XXXXXX > localKeyID: XXXXXX > subject=XXXXXXXXXX > issuer=XXXXXXXXX > -----BEGIN CERTIFICATE----- > XXXXXXXXXXXX > -----END CERTIFICATE----- > Bag Attributes > friendlyName: XXXXXXXXX > localKeyID: XXXXXXXX > Key Attributes: > -----BEGIN RSA PRIVATE KEY----- > XXXXXXXXXXXXX > -----END RSA PRIVATE KEY----- > Bag Attributes > friendlyName: XXXXXXXXXXX > localKeyID: XXXXXXXXXXX > Key Attributes: > -----BEGIN RSA PRIVATE KEY----- > XXXXXXXXXXXXX > -----END RSA PRIVATE KEY----- > > So is this format supported by the new ssl implementation? Is > this a bug? > Or should I somehow convert this to a different format? > > regards, > Takeshi > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > > > From aronisstav@REDACTED Tue Mar 6 10:01:45 2012 From: aronisstav@REDACTED (Stavros Aronis) Date: Tue, 6 Mar 2012 10:01:45 +0100 Subject: [erlang-bugs] Dialyzer error on supervisor:init spec in R15 In-Reply-To: <70044058-E6FA-4ACC-8B45-06498A8D23F6@duomark.com> References: <70044058-E6FA-4ACC-8B45-06498A8D23F6@duomark.com> Message-ID: Hi Jay, the warning does look hairy but is, nevertheless, valid. {tuple(), [any()]} is not a subtype of the expected specification (interpret this as "at least as strict as"). If you would like to use a generic specification that would still keep Dialyzer happy you should instead write: -spec init(Args::{}) -> {ok,{{supervisor:restart_strategy(),MaxR::non_neg_integer(),MaxT::non_neg_integer()},[supervisor:child_spec()]}}. Unfortunately this will still give an error in R15B, because of a real bug in Dialyzer. A patch for this has been already submitted and will soon be available in the maint branch of erlang/otp. Regards, Stavros On Tue, Mar 6, 2012 at 6:29 AM, Jay Nelson wrote: > [...] > > This problem can be recreated with a simple supervisor:init spec, pasted > into any handy supervisor:init you have laying around: > > -spec init(Args::{}) -> {ok, {tuple(), list()}}. > > When I try it with R14B03, there are no errors. > On R15B I get the above error. > > jay > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mayamatakeshi@REDACTED Wed Mar 7 03:54:14 2012 From: mayamatakeshi@REDACTED (mayamatakeshi) Date: Wed, 7 Mar 2012 11:54:14 +0900 Subject: [erlang-bugs] {error, ekeyfile} when using new ssl implementation In-Reply-To: <4F55C6AA.1010707@erix.ericsson.se> References: <4F547C4E.9030001@erix.ericsson.se> <4F55C6AA.1010707@erix.ericsson.se> Message-ID: Hello, I have 2 key files: one for sandbox APNs environment and another for the production environment. The structure of the files is like this: Certificate1 RsaPrivateKey1 Certificate2 RsaPrivateKey2 So I separated them in Certificate1 RsaPrivateKey1 Certificate2 RsaPrivateKey2 In the sandbox pem file, the pairs are identical. But in the production pem file, they are not: Certificate1 != Certificate2 but RsaPrivateKey1 == RsaPrivateKey2 Also, I verified that only Certificate1 RsaPrivateKey1 works (production). I don't know if there will be any implications ahead, but so far having the pem with just Certificate1+RsaPrivateKey1 is working fine. Regards, Takeshi On Tue, Mar 6, 2012 at 5:11 PM, Ingela Anderton Andin < ingela@REDACTED> wrote: > Hi! > > Out of curiosity are the two key entries the same key or different keys? A > certificate is signed by one key only. But Pem files may contain any > number of entries. > > Regards Ingela Erlang/OTP team Ericsson AB > > mayamatakeshi wrote: > >> Hi Ingela, >> I don't know the reason about the two keys: I got the pem file from an >> iphone app developer. I believe this is how Apple generates the files to be >> used to connect to its servers (APNs). >> But so I tried removing one of the keys and it worked with ssl new >> implementation. >> Thanks for the tip. >> >> Regards, >> Takeshi >> >> On Mon, Mar 5, 2012 at 5:41 PM, Ingela Anderton Andin < >> ingela@REDACTED >> >> wrote: >> >> Hi! >> >> The problem is that your file includes two keys and new ssl only >> expects there to be one. old ssl was only a glue on top of openssl so >> the keyfile was then passed to openssl. So it looks like openssl >> will pick a key if there is more than one. In a future extension >> of the ssl application >> there might be a reason to handle more keys, but at the moment I >> am not sure what would be the correct thing to do, we could of >> course always pick the >> first key or something like that if it will preserve some kind of >> backwards compatibility. Do you know why your file contains two >> keys? That could >> help determining what to do. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> mayamatakeshi wrote: >> >> Hello, >> I have this keyfile that I use with the old SSL implementation >> and it works fine with this code: >> >> -module(ssl_test). >> -export([connect/0]). >> >> connect() -> >> ssl:start(), >> >> Address = "gateway.sandbox.push.apple.**com >> >> > >> >> >", >> >> Port = 2195, >> CaCert = "entrust_root_certification_**authority.pem", >> Cert = "server_cerificates_bundle_**sandbox.pem", >> Key = "server_cerificates_bundle_**sandbox.pem", >> >> Options = [{cacertfile, CaCert}, {certfile, Cert}, >> {keyfile, Key}, {mode, binary}, {ssl_imp, old}], >> Timeout = 1000, >> ssl:connect(Address, Port, Options, Timeout). >> >> >> However, when I try to use the new ssl implementation, I get this: >> >> [root@REDACTED erlang]# erl >> Erlang R15B (erts-5.9) [source] [64-bit] [smp:2:2] >> [async-threads:0] [hipe] [kernel-poll:false] >> >> Eshell V5.9 (abort with ^G) >> 1> ssl_test:connect(). >> {error,ekeyfile} >> 2> >> =ERROR REPORT==== 4-Mar-2012::12:08:29 === >> SSL: 1093: error:[{'RSAPrivateKey',<< .... >>, >> not_encrypted}, >> {'RSAPrivateKey',<< .... >>, >> not_encrypted}] >> server_cerificates_bundle_**sandbox.pem >> [{ssl_connection,init_private_**key,5, >> [{file,"ssl_connection.erl"},{**line,1085}]}, >> {ssl_connection,ssl_init,2,[{** >> file,"ssl_connection.erl"},{**line,1027}]}, >> {ssl_connection,init,1,[{file,** >> "ssl_connection.erl"},{line,**305}]}, >> {gen_fsm,init_it,6,[{file,"**gen_fsm.erl"},{line,343}]}, >> {proc_lib,init_p_do_apply,3,[{**file,"proc_lib.erl"},{line,** >> 227}]}] >> >> >> The server_cerificates_bundle_**sandbox.pem file has this format: >> >> Bag Attributes >> friendlyName: XXXXXXXX >> localKeyID: XXXXXX >> subject=XXXXXXX >> issuer=XXXXXXX >> -----BEGIN CERTIFICATE----- >> XXXXXXXXXX >> -----END CERTIFICATE----- >> Bag Attributes >> friendlyName: XXXXXX >> localKeyID: XXXXXX >> subject=XXXXXXXXXX >> issuer=XXXXXXXXX >> -----BEGIN CERTIFICATE----- >> XXXXXXXXXXXX >> -----END CERTIFICATE----- >> Bag Attributes >> friendlyName: XXXXXXXXX >> localKeyID: XXXXXXXX >> Key Attributes: >> -----BEGIN RSA PRIVATE KEY----- >> XXXXXXXXXXXXX >> -----END RSA PRIVATE KEY----- >> Bag Attributes >> friendlyName: XXXXXXXXXXX >> localKeyID: XXXXXXXXXXX >> Key Attributes: >> -----BEGIN RSA PRIVATE KEY----- >> XXXXXXXXXXXXX >> -----END RSA PRIVATE KEY----- >> >> So is this format supported by the new ssl implementation? Is >> this a bug? >> Or should I somehow convert this to a different format? >> >> regards, >> Takeshi >> >> >> ------------------------------**------------------------------** >> ------------ >> >> ______________________________**_________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-bugs >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Thu Mar 8 07:59:12 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 08 Mar 2012 07:59:12 +0100 Subject: [erlang-bugs] fix the -MP flag in erlc Message-ID: <4F5858C0.2050305@gmail.com> Because of a copy-and-paste error in erlc.c, the -MP flag had the same effect as -MG. As a workaround, you had to pass +makedep_phony to enable the MP option. This patch makes -MP work as intended. git fetch git://github.com/richcarl/otp.git fix-MP-compiler-flag /Richard From jimenezrick@REDACTED Thu Mar 8 12:34:12 2012 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Thu, 8 Mar 2012 12:34:12 +0100 Subject: [erlang-bugs] EDoc limitations with type specs Message-ID: <20120308113412.GA26689@viper.local> EDoc fails extracting the module documentation data when: 1. Specs are not exactly above the function they describe. For example, this will make EDoc fail when the specs are grouped together: -spec foo() -> ok. -spec bar() -> bad. foo() -> ok bar() -> bad. 2. Type has a range with a macro, example `calendar' module from the OTP, line 354 (R15): -type secs_per_day() :: 0..?SECONDS_PER_DAY. Best regards -- Ricardo (http://r.untroubled.be/) From sverker@REDACTED Fri Mar 9 12:03:05 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 9 Mar 2012 12:03:05 +0100 Subject: [erlang-bugs] Erlang R14B4 segfaults if /sys/devices/system/node is not readable In-Reply-To: <266071295.fc9Uf4N8M7@samson> References: <266071295.fc9Uf4N8M7@samson> Message-ID: <4F59E369.7010408@erix.ericsson.se> Thanks for excellent bug-report. Here is what I've put in the pipe for R15B01: diff --git a/erts/lib_src/common/erl_misc_utils.c b/erts/lib_src/common/erl_misc_utils.c index 5e94ff1..4806311 100644 --- a/erts/lib_src/common/erl_misc_utils.c +++ b/erts/lib_src/common/erl_misc_utils.c @@ -834,8 +834,8 @@ read_topology(erts_cpu_info_t *cpuinfo) ix = -1; if (realpath(ERTS_SYS_NODE_PATH, npath)) { - got_nodes = 1; ndir = opendir(npath); + got_nodes = (ndir != NULL); } /Sverker, Erlang/OTP Ericsson Dennis Schridde wrote: > Hello! > > I am using Erlang on a Gentoo/Hardened system, which restricts several things > for security reasons. For example /sys/devices/system/node is only read and > traversable (0700) by root, which makes erlexec segfault. I will describe how > I reproduce the segfault and attach a backtrace. > > In the following the directory "otp" refers to "otp_src_R14B04", which was the > one I started building Erlang in (the build process also never finishes due to > this issue). > > otp/bootstrap/bin/erl was modified to set: > --- > ROOTDIR=$ERL_TOP/bootstrap > BINDIR=$ERL_TOP/bin/ia64-unknown-linux-gnu > --- > > The script I use to reproduce is: > --- > export ERL_TOP=`pwd`/otp > export PATH=$ERL_TOP/bootstrap/bin:${PATH} > > echo "run -W +debug_info +warn_exported_vars +warn_missing_spec > +warn_untyped_record -oebin misc/hipe_consttab.erl" > gdb.cmd > > gdb erlc -x gdb.cmd > --- > > The segfault will happen in read_topology at common/erl_misc_utils.c:850. > That line reads: > nde = readdir(ndir); > The issue comes from ndir which is set a few lines before: > ndir = opendir(npath); > The return value should be checked against NULL, because that is what opendir > returns on error - errno will tell the details. > > It would be nice if you could provide a fallback method in case > /sys/devices/system/node cannot be read. > > If you need any additional information, please ask. > > Kind regards, > Dennis > > P.S: /sys/devices/system/cpu is readable by every user, so you could directly > fallback to that. > > The fix would then be to replace following code, starting from line 836: > if (realpath(ERTS_SYS_NODE_PATH, npath)) { > got_nodes = 1; > ndir = opendir(npath); > } > with: > if (realpath(ERTS_SYS_NODE_PATH, npath)) { > ndir = opendir(npath); > if (ndir) { > got_nodes = 1; > } > } > > P.P.S: Does this list silently discard emails from non-subscribers? I did not > receive a is-in-moderation-queue confirmation when first sending this email > while not being subscribed... > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From daniel@REDACTED Fri Mar 9 21:55:46 2012 From: daniel@REDACTED (Daniel Luna) Date: Fri, 9 Mar 2012 15:55:46 -0500 Subject: [erlang-bugs] Unexpected crash using inet_res:lookup/3 Message-ID: Hi, inet_res:lookup/3 normally doesn't crash for almost any input (see examples 7-10 where I feed atoms and binaries to it). But in the case of a string starting with period or a containing a double period it will crash in inet_dns:encode_labels/4. No mention of this being expected in the documentation so assume that it's a bug. See examples below. Linux, R15B. Cheers, Daniel Erlang R15B (erts-5.9) [source] [64-bit] [smp:5:5] [async-threads:0] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1> inet_res:lookup("erlang.com", in, mx). [{20,"mail.numbering.info"}] 2> inet_res:lookup("erlang..com", in, mx). ** exception error: no function clause matching inet_dns:encode_labels(<<0,2,1,0,0,1,0,0,0,0,0,0,6,101,114,108,97,110,103>>, {1,{[<<"erlang">>,<<>>,<<"com">>],12,nil,nil}}, 19, [<<>>,<<"com">>]) (inet_dns.erl, line 693) in function inet_dns:encode_name/4 (inet_dns.erl, line 674) in call from inet_dns:encode_query_section/3 (inet_dns.erl, line 268) in call from inet_dns:encode/1 (inet_dns.erl, line 239) in call from inet_res:make_query/5 (inet_res.erl, line 669) in call from inet_res:make_query/4 (inet_res.erl, line 637) in call from inet_res:res_query/5 (inet_res.erl, line 608) in call from inet_res:resolve/5 (inet_res.erl, line 141) 3> inet_res:lookup("..", in, mx). ** exception error: no function clause matching inet_dns:encode_labels(<<0,3,1,0,0,1,0,0,0,0,0,0>>,{0,nil},12,[<<>>,<<>>]) (inet_dns.erl, line 693) in function inet_dns:encode_name/4 (inet_dns.erl, line 674) in call from inet_dns:encode_query_section/3 (inet_dns.erl, line 268) in call from inet_dns:encode/1 (inet_dns.erl, line 239) in call from inet_res:make_query/5 (inet_res.erl, line 669) in call from inet_res:make_query/4 (inet_res.erl, line 637) in call from inet_res:res_query/5 (inet_res.erl, line 608) in call from inet_res:resolve/5 (inet_res.erl, line 141) 4> inet_res:lookup(".", in, mx). [] 5> inet_res:lookup(".com", in, mx). ** exception error: no function clause matching inet_dns:encode_labels(<<0,5,1,0,0,1,0,0,0,0,0,0>>,{0,nil},12,[<<>>,<<"com">>]) (inet_dns.erl, line 693) in function inet_dns:encode_name/4 (inet_dns.erl, line 674) in call from inet_dns:encode_query_section/3 (inet_dns.erl, line 268) in call from inet_dns:encode/1 (inet_dns.erl, line 239) in call from inet_res:make_query/5 (inet_res.erl, line 669) in call from inet_res:make_query/4 (inet_res.erl, line 637) in call from inet_res:res_query/5 (inet_res.erl, line 608) in call from inet_res:resolve/5 (inet_res.erl, line 141) 6> inet_res:lookup("erlang.", in, mx). [] 7> inet_res:lookup([1234567], in, mx). [] 8> inet_res:lookup([atom], in, mx). [] 9> inet_res:lookup(atom, in, mx). [] 10> inet_res:lookup(<<"binary">>, in, mx). [] From jared@REDACTED Sat Mar 10 00:10:51 2012 From: jared@REDACTED (Jared Morrow) Date: Fri, 9 Mar 2012 16:10:51 -0700 Subject: [erlang-bugs] Compiling 15B on SmartOS (solaris 11) Message-ID: When compiling 15B after configuring with --enable-m64-build I get the following: gcc -m64 -g -O2 -I/home/jared/files/otp_src_R15B/erts/i386-pc-solaris2.11 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-tree-copyrename -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.11/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.11 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-pc-solaris2.11 -I../include/internal -I../include/internal/i386-pc-solaris2.11 -c i386-pc-solaris2.11/opt/smp/hipe_amd64_bifs.S -o obj/i386-pc-solaris2.11/opt/smp/hipe_amd64_bifs.o i386-pc-solaris2.11/opt/smp/hipe_amd64_bifs.S:2005:2: error: #endif without #if make[3]: *** [obj/i386-pc-solaris2.11/opt/smp/hipe_amd64_bifs.o] Error 1 It seems easy enough to fix on my end, but just wanted to let you know that there is a unmatched if/endif pair somewhere in hipe_amd64_bifs.S Thanks, Jared Morrow From superbobry@REDACTED Mon Mar 12 06:59:16 2012 From: superbobry@REDACTED (Sergei Lebedev) Date: Mon, 12 Mar 2012 09:59:16 +0400 Subject: [erlang-bugs] 'dialyzer' fails with function_clause on mongodb-erlang Message-ID: Hello, I've been trying to make 'dialyzer' work for mongodb-erlang [*] and found out that the following line seems to crash 'dialyzer': src/mongo_replset.erl:-opaque rs_connection() :: {rs_connection, rs_name(), mvar:mvar(connections()), timeout()}. Traceback: $ dialyzer ebin/{mongo_replset,mvar}.beam Checking whether the PLT /Users/bobry/.dialyzer_plt is up-to-date... yes Proceeding with analysis... =ERROR REPORT==== 12-Mar-2012::09:51:34 === Error in process <0.29.0> with exit value: {function_clause,[{erl_types,t_contains_opaque,[{c,remote,[{remote,mvar,mvar,[{c,remote,[{remote,dict,dictionary,[{c,remote,[{remote,mongo_connect,host,[]}],unknown},{c,tuple_set,[{0,[{c,tuple,[],{0,any}}]},{1,[{c... dialyzer: Analysis failed with error: {function_clause,[{erl_types,t_contains_opaque, [{c,remote,[{...}],unknown}], [{file,"erl_types.erl"},{line,473}]}, {lists,all,2,[{file,[...]},{line,...}]}, {dialyzer_dataflow,get_apply_fail_msg,9,[{file,...},{...}]}, {dialyzer_dataflow,handle_apply_or_call,8,[{...}|...]}, {dialyzer_dataflow,handle_let,3,[...]}, {dialyzer_dataflow,do_clause,6,...}, {dialyzer_dataflow,handle_clauses,...}, {dialyzer_dataflow,...}]} Last messages in the log cache: Typesig analysis for SCC: [{mongo_replset,close,1}] Typesig analysis for SCC: [{mongo_replset,connect,1}] Typesig analysis for SCC: [{mongo_replset,connect_member,2}] Typesig analysis for SCC: [{mongo_replset,fetch_member_info,1}] Typesig analysis for SCC: [{mongo_replset,primary_conn,3}] Typesig analysis for SCC: [{mongo_replset,primary,1}] Typesig analysis for SCC: [{mongo_replset,secondary_ok_conn,2}] Typesig analysis for SCC: [{mongo_replset,secondary_ok,1}] Dataflow of one SCC: [mvar] Dataflow of one SCC: [mongo_replset] Simply replacing '-opaque' with '-type' helps, but I'm not sure if it's invalid typing in mongodb-erlang which causes the issue, or is it a bug in 'dialyzer'? Sergei [*] https://github.com/mongodb/mongodb-erlang -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Mon Mar 12 11:57:45 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 12 Mar 2012 11:57:45 +0100 Subject: [erlang-bugs] Compiling 15B on SmartOS (solaris 11) In-Reply-To: References: Message-ID: <4F5DD6A9.7040002@erix.ericsson.se> Jared Morrow wrote: > When compiling 15B after configuring with --enable-m64-build I get the following: > > gcc -m64 -g -O2 -I/home/jared/files/otp_src_R15B/erts/i386-pc-solaris2.11 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-tree-copyrename -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.11/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.11 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-pc-solaris2.11 -I../include/internal -I../include/internal/i386-pc-solaris2.11 -c i386-pc-solaris2.11/opt/smp/hipe_amd64_bifs.S -o obj/i386-pc-solaris2.11/opt/smp/hipe_amd64_bifs.o > i386-pc-solaris2.11/opt/smp/hipe_amd64_bifs.S:2005:2: error: #endif without #if > make[3]: *** [obj/i386-pc-solaris2.11/opt/smp/hipe_amd64_bifs.o] Error 1 > > It seems easy enough to fix on my end, but just wanted to let you know that there is a unmatched if/endif pair somewhere in hipe_amd64_bifs.S > > hipe_amd64_bifs.S is generated from erts/emulator/hipe/hipe_amd64_bifs.m4 and erts/emulator/hipe/hipe_bif_list.m4 hipe_amd64_bifs.S on my Linux works fine. Could you supply some more information about the failing #endif /Sverker, Erlang/OTP Ericsson From gustav.simonsson@REDACTED Mon Mar 12 12:31:20 2012 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Mon, 12 Mar 2012 11:31:20 -0000 (GMT) Subject: [erlang-bugs] Unexpected crash using inet_res:lookup/3 In-Reply-To: Message-ID: Actually if you look at the typespec: Name = dns_name() | inet:ip_address() dns_name() = string() A string with no adjacent dots. // Gustav Simonsson Sent from my PC ----- Original Message ----- > From: "Daniel Luna" > To: erlang-bugs@REDACTED > Sent: Friday, 9 March, 2012 9:55:46 PM > Subject: [erlang-bugs] Unexpected crash using inet_res:lookup/3 > > Hi, > > inet_res:lookup/3 normally doesn't crash for almost any input (see > examples 7-10 where I feed atoms and binaries to it). > > But in the case of a string starting with period or a containing a > double period it will crash in inet_dns:encode_labels/4. > > No mention of this being expected in the documentation so assume that > it's a bug. See examples below. > > Linux, R15B. > > Cheers, > > Daniel > > > Erlang R15B (erts-5.9) [source] [64-bit] [smp:5:5] [async-threads:0] > [kernel-poll:false] > > Eshell V5.9 (abort with ^G) > 1> inet_res:lookup("erlang.com", in, mx). > [{20,"mail.numbering.info"}] > 2> inet_res:lookup("erlang..com", in, mx). > ** exception error: no function clause matching > inet_dns:encode_labels(<<0,2,1,0,0,1,0,0,0,0,0,0,6,101,114,108,97,110,103>>, > > {1,{[<<"erlang">>,<<>>,<<"com">>],12,nil,nil}}, > 19, > > [<<>>,<<"com">>]) (inet_dns.erl, line 693) > in function inet_dns:encode_name/4 (inet_dns.erl, line 674) > in call from inet_dns:encode_query_section/3 (inet_dns.erl, line > 268) > in call from inet_dns:encode/1 (inet_dns.erl, line 239) > in call from inet_res:make_query/5 (inet_res.erl, line 669) > in call from inet_res:make_query/4 (inet_res.erl, line 637) > in call from inet_res:res_query/5 (inet_res.erl, line 608) > in call from inet_res:resolve/5 (inet_res.erl, line 141) > 3> inet_res:lookup("..", in, mx). > ** exception error: no function clause matching > inet_dns:encode_labels(<<0,3,1,0,0,1,0,0,0,0,0,0>>,{0,nil},12,[<<>>,<<>>]) > (inet_dns.erl, line 693) > in function inet_dns:encode_name/4 (inet_dns.erl, line 674) > in call from inet_dns:encode_query_section/3 (inet_dns.erl, line > 268) > in call from inet_dns:encode/1 (inet_dns.erl, line 239) > in call from inet_res:make_query/5 (inet_res.erl, line 669) > in call from inet_res:make_query/4 (inet_res.erl, line 637) > in call from inet_res:res_query/5 (inet_res.erl, line 608) > in call from inet_res:resolve/5 (inet_res.erl, line 141) > 4> inet_res:lookup(".", in, mx). > [] > 5> inet_res:lookup(".com", in, mx). > ** exception error: no function clause matching > inet_dns:encode_labels(<<0,5,1,0,0,1,0,0,0,0,0,0>>,{0,nil},12,[<<>>,<<"com">>]) > (inet_dns.erl, line 693) > in function inet_dns:encode_name/4 (inet_dns.erl, line 674) > in call from inet_dns:encode_query_section/3 (inet_dns.erl, line > 268) > in call from inet_dns:encode/1 (inet_dns.erl, line 239) > in call from inet_res:make_query/5 (inet_res.erl, line 669) > in call from inet_res:make_query/4 (inet_res.erl, line 637) > in call from inet_res:res_query/5 (inet_res.erl, line 608) > in call from inet_res:resolve/5 (inet_res.erl, line 141) > 6> inet_res:lookup("erlang.", in, mx). > [] > 7> inet_res:lookup([1234567], in, mx). > [] > 8> inet_res:lookup([atom], in, mx). > [] > 9> inet_res:lookup(atom, in, mx). > [] > 10> inet_res:lookup(<<"binary">>, in, mx). > [] > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From daniel@REDACTED Mon Mar 12 13:49:55 2012 From: daniel@REDACTED (Daniel Luna) Date: Mon, 12 Mar 2012 08:49:55 -0400 Subject: [erlang-bugs] Unexpected crash using inet_res:lookup/3 In-Reply-To: References: Message-ID: I still call bug on this. 1. I would expect an erlang function to fail with 'badarg' if given bad arguments, not some random "I could not be bothered to code for this case" crash further down the line 2. It only fails with a string with adjacent dots (or which starts with a dot, something which is not in the documentation), but it *does not* fail when given a binary, an atom, and a whole lot of other bad arguments. This to me does not follow the type specification. /Daniel On 12 March 2012 07:31, Gustav Simonsson wrote: > > Actually if you look at the typespec: > > Name = dns_name() | inet:ip_address() > > dns_name() = string() > > A string with no adjacent dots. > > // Gustav Simonsson > > Sent from my PC > > ----- Original Message ----- >> From: "Daniel Luna" >> To: erlang-bugs@REDACTED >> Sent: Friday, 9 March, 2012 9:55:46 PM >> Subject: [erlang-bugs] Unexpected crash using inet_res:lookup/3 >> >> Hi, >> >> inet_res:lookup/3 normally doesn't crash for almost any input (see >> examples 7-10 where I feed atoms and binaries to it). >> >> But in the case of a string starting with period or a containing a >> double period it will crash in inet_dns:encode_labels/4. >> >> No mention of this being expected in the documentation so assume that >> it's a bug. ?See examples below. >> >> Linux, R15B. >> >> Cheers, >> >> Daniel >> >> >> Erlang R15B (erts-5.9) [source] [64-bit] [smp:5:5] [async-threads:0] >> [kernel-poll:false] >> >> Eshell V5.9 ?(abort with ^G) >> 1> inet_res:lookup("erlang.com", in, mx). >> [{20,"mail.numbering.info"}] >> 2> inet_res:lookup("erlang..com", in, mx). >> ** exception error: no function clause matching >> inet_dns:encode_labels(<<0,2,1,0,0,1,0,0,0,0,0,0,6,101,114,108,97,110,103>>, >> >> {1,{[<<"erlang">>,<<>>,<<"com">>],12,nil,nil}}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?19, >> >> [<<>>,<<"com">>]) (inet_dns.erl, line 693) >> ? ? ?in function ?inet_dns:encode_name/4 (inet_dns.erl, line 674) >> ? ? ?in call from inet_dns:encode_query_section/3 (inet_dns.erl, line >> ? ? ?268) >> ? ? ?in call from inet_dns:encode/1 (inet_dns.erl, line 239) >> ? ? ?in call from inet_res:make_query/5 (inet_res.erl, line 669) >> ? ? ?in call from inet_res:make_query/4 (inet_res.erl, line 637) >> ? ? ?in call from inet_res:res_query/5 (inet_res.erl, line 608) >> ? ? ?in call from inet_res:resolve/5 (inet_res.erl, line 141) >> 3> inet_res:lookup("..", in, mx). >> ** exception error: no function clause matching >> inet_dns:encode_labels(<<0,3,1,0,0,1,0,0,0,0,0,0>>,{0,nil},12,[<<>>,<<>>]) >> (inet_dns.erl, line 693) >> ? ? ?in function ?inet_dns:encode_name/4 (inet_dns.erl, line 674) >> ? ? ?in call from inet_dns:encode_query_section/3 (inet_dns.erl, line >> ? ? ?268) >> ? ? ?in call from inet_dns:encode/1 (inet_dns.erl, line 239) >> ? ? ?in call from inet_res:make_query/5 (inet_res.erl, line 669) >> ? ? ?in call from inet_res:make_query/4 (inet_res.erl, line 637) >> ? ? ?in call from inet_res:res_query/5 (inet_res.erl, line 608) >> ? ? ?in call from inet_res:resolve/5 (inet_res.erl, line 141) >> 4> inet_res:lookup(".", in, mx). >> [] >> 5> inet_res:lookup(".com", in, mx). >> ** exception error: no function clause matching >> inet_dns:encode_labels(<<0,5,1,0,0,1,0,0,0,0,0,0>>,{0,nil},12,[<<>>,<<"com">>]) >> (inet_dns.erl, line 693) >> ? ? ?in function ?inet_dns:encode_name/4 (inet_dns.erl, line 674) >> ? ? ?in call from inet_dns:encode_query_section/3 (inet_dns.erl, line >> ? ? ?268) >> ? ? ?in call from inet_dns:encode/1 (inet_dns.erl, line 239) >> ? ? ?in call from inet_res:make_query/5 (inet_res.erl, line 669) >> ? ? ?in call from inet_res:make_query/4 (inet_res.erl, line 637) >> ? ? ?in call from inet_res:res_query/5 (inet_res.erl, line 608) >> ? ? ?in call from inet_res:resolve/5 (inet_res.erl, line 141) >> 6> inet_res:lookup("erlang.", in, mx). >> [] >> 7> inet_res:lookup([1234567], in, mx). >> [] >> 8> inet_res:lookup([atom], in, mx). >> [] >> 9> inet_res:lookup(atom, in, mx). >> [] >> 10> inet_res:lookup(<<"binary">>, in, mx). >> [] >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From helllamer@REDACTED Tue Mar 13 09:43:50 2012 From: helllamer@REDACTED (Konstantin Nikiforov) Date: Tue, 13 Mar 2012 12:43:50 +0400 Subject: [erlang-bugs] R14B04 erlc OOM on buggy .hrl include Message-ID: <20120313124350.6727625b@avers> Steps to reproduce: 0. mkdir abcd 1. Copy attached files to abcd/ 2. $ erl 1> c(error1). Expected result: - syntax error in line 7 in wrappers.hrl Real result: - compiler hungs and crashes with out-of-memory. -------------- next part -------------- A non-text attachment was scrubbed... Name: error1.erl Type: text/x-erlang Size: 86 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrappers.hrl Type: text/x-erlang Size: 346 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From bengt.kleberg@REDACTED Tue Mar 13 15:32:39 2012 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 13 Mar 2012 15:32:39 +0100 Subject: [erlang-bugs] Documentation typo in http://www.erlang.org/doc/man/gen_sctp.html Message-ID: <1331649159.4963.13.camel@seasc1137> Greetings, I think there is a typo in the SCTP EXAMPLES. sctp_server:server/1 has a final call to server/1. It would make more sense it it was to server/2 instead. bengt From mattevans123@REDACTED Tue Mar 13 15:56:01 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Tue, 13 Mar 2012 10:56:01 -0400 Subject: [erlang-bugs] Erlang Pre-Processor (epp) issue Message-ID: Hi, Not sure if this should be a "bugs" or "questions" issue, since technically it isn't a bug. Perhaps it's a change request? We are using Apache Thrift to get Java, Erlang and a small Python test app to communicate. We all have access to the Thrift files, even non-Erlang developers. Unfortunately one particular set of these files has a nasty include hierarchy causing an "include too deep" error from epp. Personally I'd rather ensure that the include depth wasn't so bad, but I can't guarantee what Thrift does and I certainly can't guarantee what the Java developers do (since Java doesn't have include files it isn't a problem for them). I have changed epp.erl in our system to change the depth check from 8 to 10, and it gets around the problem for now. What I was wondering is if this should be a configurable option? I'm sure I am one of the first people to run into this issue..... Cheers Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Tue Mar 13 16:06:55 2012 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 13 Mar 2012 16:06:55 +0100 Subject: [erlang-bugs] Documentation typo in http://www.erlang.org/doc/man/gen_sctp.html In-Reply-To: <1331649159.4963.13.camel@seasc1137> References: <1331649159.4963.13.camel@seasc1137> Message-ID: <4F5F628F.9000900@erlang.org> Hello! If you feel like something is wrong in the documentation, please take the time to fix it and submit a patch. Doing so will make it more probable that the change is made in a timely fashion. The source for the documentation in question can be found here: https://github.com/erlang/otp/blob/master/lib/kernel/doc/src/gen_sctp.xml Lukas On 13/03/12 15:32, Bengt Kleberg wrote: > Greetings, > > I think there is a typo in the SCTP EXAMPLES. sctp_server:server/1 has a > final call to server/1. It would make more sense it it was to server/2 > instead. > > > bengt > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From spawn.think@REDACTED Wed Mar 14 17:38:10 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 14 Mar 2012 17:38:10 +0100 Subject: [erlang-bugs] Debugger crashes handling the breakpoints In-Reply-To: <20120206205412.GA845@viper.local> References: <20120206205412.GA845@viper.local> Message-ID: This commit should fix your issue https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes I already submitted it to erlang-patches On Mon, Feb 6, 2012 at 9:54 PM, Ricardo Catalinas Jim?nez < jimenezrick@REDACTED> wrote: > When I add some breakpoints in a module in the source code window, if I > close that window and I open it again, all the breakpoints are lost, not > shown in the sidebar nor in the `Break' menu. > > Also, when I open the source code window again (with all the breakpoints > lost), if I hit on the menu `Break->Enable All' or `Break->Disable All' > the debugger crashes with: > > dbg_wx_view:error {badmatch,false} > > I'm using R15B. > > > Regards > -- > Ricardo (http://r.untroubled.be/) > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Thu Mar 15 09:29:41 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 15 Mar 2012 09:29:41 +0100 Subject: [erlang-bugs] Debugger crashes handling the breakpoints In-Reply-To: References: <20120206205412.GA845@viper.local> Message-ID: Sorry this is the correct link (based on master not maint) https://github.com/spawnthink/otp/compare/erlang:master...spawnthink:fix_debugger_breaks_crashes Note : I found out that the OTP guys has it already fixed in their internal tests On Wed, Mar 14, 2012 at 5:38 PM, Ahmed Omar wrote: > This commit should fix your issue > > https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes > > I already submitted it to erlang-patches > > > On Mon, Feb 6, 2012 at 9:54 PM, Ricardo Catalinas Jim?nez < > jimenezrick@REDACTED> wrote: > >> When I add some breakpoints in a module in the source code window, if I >> close that window and I open it again, all the breakpoints are lost, not >> shown in the sidebar nor in the `Break' menu. >> >> Also, when I open the source code window again (with all the breakpoints >> lost), if I hit on the menu `Break->Enable All' or `Break->Disable All' >> the debugger crashes with: >> >> dbg_wx_view:error {badmatch,false} >> >> I'm using R15B. >> >> >> Regards >> -- >> Ricardo (http://r.untroubled.be/) >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ufm@REDACTED Thu Mar 15 20:22:10 2012 From: ufm@REDACTED (Fyodor Ustinov) Date: Thu, 15 Mar 2012 21:22:10 +0200 Subject: [erlang-bugs] Parameterized modules and extends Message-ID: <4F624162.4030909@ufm.su> Hi! I understand this may be feature, not a bug. I understand I'm say about absolutely undocumented things. 1. -- file tt.erl -- -module(tt). -export([tt/0, ee/0]). tt() -> io:format("tt:tt/0~n"), ee() . ee() -> io:format("tt:ee/0~n") . --file ttt.erl -- -module(ttt). -extends(tt). -export([tt/0, ttt/0]). ttt() -> io:format("ttt:ttt/0~n") . tt() -> io:format("ttt:tt/0~n"), ee() . -------------------- 1> c(tt). {ok,tt} 2> c(ttt). ttt.erl:12: function ee/0 undefined error replace ee() to ttt:ee() fix this. But IMHO -extends should include -import. 2. -- file tt.erl -- -module(tt,[M]). -export([tt/0, ee/0]). tt() -> io:format("tt:tt/0 ~p ~p~n",[M, THIS]), ee() . ee() -> io:format("tt:ee/0 ~p ~p~n", [M, THIS]) . -- file ttt.erl -- -module(ttt,[M]). -extends(tt). -export([tt/0, ttt/0]). ttt() -> io:format("ttt:ttt/0 ~p ~p~n",[M, THIS]) . tt() -> io:format("ttt:tt/0 ~p ~p~n", [M, THIS]), ttt:ee() . ---------- Erlang R15B (erts-5.9) [source] [64-bit] [async-threads:0] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1> c(tt). {ok,tt} 2> c(ttt). {ok,ttt} 3> {ttt, test}:ttt(). ttt:ttt/0 test {ttt,test} ok 4> {tt, test}:tt(). tt:tt/0 test {tt,test} tt:ee/0 test {tt,test} ok 5> {ttt, test}:tt(). ttt:tt/0 test {ttt,test} ** exception error: undefined function tt:ee/0 6> Oops. Hm. Ok. First attempt. Replace tt:ee() in ttt.erl to {ttt, M}:ee(). Eshell V5.9 (abort with ^G) 1> c(ttt). ttt.erl:12: Warning: invalid module and/or function name; this call will always fail {ok,ttt} 2> {ttt, test}:tt(). ttt:tt/0 test {ttt,test} tt:ee/0 test {ttt,test} ok 3> More better. But strange warning... Ok. Second attempt. Replace {ttt, M}:ee() to THIS:ee(). Eshell V5.9 (abort with ^G) 1> c(ttt). {ok,ttt} 2> {ttt, test}:tt(). ttt:tt/0 test {ttt,test} tt:ee/0 test {ttt,test} ok 3> Nice. No strange warnings. But why do not work simple ttt:ee() ? BTW, -import(tt, [ee/0]). and call simple ee() say the same: Eshell V5.9 (abort with ^G) 1> c(ttt). {ok,ttt} 2> {ttt, test}:tt(). ttt:tt/0 test {ttt,test} ** exception error: undefined function tt:ee/0 3> WBR, Fyodor. P.S. IMHO 'extends' and 'Parameterized modules' it's a great feature. Why this not documented yet? From daniel.goertzen@REDACTED Mon Mar 19 02:07:37 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Sun, 18 Mar 2012 20:07:37 -0500 Subject: [erlang-bugs] ERL_NIF_TERM type collision Message-ID: I am working on a c++ nif and have an overloaded function that takes a number of different types including integers and ERL_NIF_TERMs. The problem is that ERL_NIF_TERM really just an integer and collides with my integer functions, for example: int get(std::string var) {...} int get(unsigned long var) {...} int get(ERL_NIF_TERM var) {...} //compile error because ERL_NIF_TERM is really an unsigned long. It would be great it ERL_NIF_TERM was a unique type so it could be used in this situation. My first attempt to solve this involved creating wrappers for each NIF API function. The wrapper used a new unique type instead of ERL_NIF_TERM, and did type casting as needed. It was a type punning bloodbath. This was complex and unsatisfactory. My second attempt was to hack erl_nif.h to change the definition of ERL_NIF_TERM to a struct containing an int, and this worked great. But this is not very portable due to the custom erl_nif.h. Also, I don't know enough about linkers to know for sure if this is permitted. Has this problem come up before? Is there some easy alternative that I am missing? Should I submit a patch for the erl_nif.h hack? (It is conditionally compiled, by default nothing changes) Thanks, Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baggett.patrick@REDACTED Mon Mar 19 02:41:13 2012 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Sun, 18 Mar 2012 20:41:13 -0500 Subject: [erlang-bugs] ERL_NIF_TERM type collision In-Reply-To: References: Message-ID: At this point, you're effectively fighting the compiler. You could try an enum since enum values aren't directly convertible to integers without an explicit typecast -- maybe the compiler will get the hint. Do you really need to have the exact same name? Is it completely infeasible to have a function like int get_nif(...) instead of just "get" as an overload? (aka: the easy solution) Patrick On Sun, Mar 18, 2012 at 8:07 PM, Daniel Goertzen wrote: > I am working on a c++ nif and have an overloaded function that takes a > number of different types including integers and ERL_NIF_TERMs. The > problem is that ERL_NIF_TERM really just an integer and collides with my > integer functions, for example: > > int get(std::string var) {...} > int get(unsigned long var) {...} > int get(ERL_NIF_TERM var) {...} //compile error because ERL_NIF_TERM is > really an unsigned long. > > It would be great it ERL_NIF_TERM was a unique type so it could be used in > this situation. > > My first attempt to solve this involved creating wrappers for each NIF API > function. The wrapper used a new unique type instead of ERL_NIF_TERM, and > did type casting as needed. It was a type punning bloodbath. This was > complex and unsatisfactory. > > My second attempt was to hack erl_nif.h to change the definition of > ERL_NIF_TERM to a struct containing an int, and this worked great. But > this is not very portable due to the custom erl_nif.h. Also, I don't know > enough about linkers to know for sure if this is permitted. > > > Has this problem come up before? > > Is there some easy alternative that I am missing? > > Should I submit a patch for the erl_nif.h hack? (It is conditionally > compiled, by default nothing changes) > > > Thanks, > Dan. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Mon Mar 19 12:27:10 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 19 Mar 2012 12:27:10 +0100 Subject: [erlang-bugs] ERL_NIF_TERM type collision In-Reply-To: References: Message-ID: <4F67180E.4050101@erix.ericsson.se> Daniel Goertzen wrote: > My second attempt was to hack erl_nif.h to change the definition of > ERL_NIF_TERM to a struct containing an int, and this worked great. But > this is not very portable due to the custom erl_nif.h. Also, I don't know > enough about linkers to know for sure if this is permitted. > > I tried ERL_NIF_TERM as a struct some time ago. If I remember correctly I abandoned that because gcc used a different (slower) calling convention for functions returning struct-containing-int compared to functions returning plain-int. /Sverker, Erlang/OTP Ericsson From daniel.goertzen@REDACTED Mon Mar 19 15:07:34 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 19 Mar 2012 09:07:34 -0500 Subject: [erlang-bugs] ERL_NIF_TERM type collision In-Reply-To: References: Message-ID: ERL_NIF_TERM is 32 bits for the 32 bit and halfword emulators, and 64 bits for the 64 bit emulator. Maybe I could use an enum (32 bits) for the halfword emulator, and pointer-to-dummy-struct for the others (since Sverker says structs are slow). I really do need to use overloading. I am working on overloaded c++ wrappers for enif_get_XXX() and enif_make_XXX(), and I support tuple cracking like... // term is ERL_NIF_TERM containing {"hello", 123, decode_me_later} std::tuple tup; get(env, term, &tup); ... where the std::tuple overload of get() recursively calls get() for all its constituent types. You can crack nested tuples in this manner too. Dan. On Sun, Mar 18, 2012 at 8:41 PM, Patrick Baggett wrote: > At this point, you're effectively fighting the compiler. You could try an > enum since enum values aren't directly convertible to integers without an > explicit typecast -- maybe the compiler will get the hint. > Do you really need to have the exact same name? Is it completely > infeasible to have a function like int get_nif(...) instead of just "get" > as an overload? (aka: the easy solution) > > Patrick > > > On Sun, Mar 18, 2012 at 8:07 PM, Daniel Goertzen < > daniel.goertzen@REDACTED> wrote: > >> I am working on a c++ nif and have an overloaded function that takes a >> number of different types including integers and ERL_NIF_TERMs. The >> problem is that ERL_NIF_TERM really just an integer and collides with my >> integer functions, for example: >> >> int get(std::string var) {...} >> int get(unsigned long var) {...} >> int get(ERL_NIF_TERM var) {...} //compile error because ERL_NIF_TERM is >> really an unsigned long. >> >> It would be great it ERL_NIF_TERM was a unique type so it could be used >> in this situation. >> >> My first attempt to solve this involved creating wrappers for each NIF >> API function. The wrapper used a new unique type instead of ERL_NIF_TERM, >> and did type casting as needed. It was a type punning bloodbath. This was >> complex and unsatisfactory. >> >> My second attempt was to hack erl_nif.h to change the definition of >> ERL_NIF_TERM to a struct containing an int, and this worked great. But >> this is not very portable due to the custom erl_nif.h. Also, I don't know >> enough about linkers to know for sure if this is permitted. >> >> >> Has this problem come up before? >> >> Is there some easy alternative that I am missing? >> >> Should I submit a patch for the erl_nif.h hack? (It is conditionally >> compiled, by default nothing changes) >> >> >> Thanks, >> Dan. >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Mon Mar 19 15:25:20 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 19 Mar 2012 09:25:20 -0500 Subject: [erlang-bugs] ERL_NIF_TERM type collision In-Reply-To: References: Message-ID: I note that c++11 now lets you specify the underlying integer type of the enum; I now see that enums are the way to go. Dan. On Mon, Mar 19, 2012 at 9:07 AM, Daniel Goertzen wrote: > ERL_NIF_TERM is 32 bits for the 32 bit and halfword emulators, and 64 bits > for the 64 bit emulator. Maybe I could use an enum (32 bits) for the > halfword emulator, and pointer-to-dummy-struct for the others (since > Sverker says structs are slow). > > I really do need to use overloading. I am working on overloaded c++ > wrappers for enif_get_XXX() and enif_make_XXX(), and I support tuple > cracking like... > > // term is ERL_NIF_TERM containing {"hello", 123, decode_me_later} > std::tuple tup; > get(env, term, &tup); > > ... where the std::tuple overload of get() recursively calls get() for all > its constituent types. You can crack nested tuples in this manner too. > > > Dan. > > > > > On Sun, Mar 18, 2012 at 8:41 PM, Patrick Baggett < > baggett.patrick@REDACTED> wrote: > >> At this point, you're effectively fighting the compiler. You could try an >> enum since enum values aren't directly convertible to integers without an >> explicit typecast -- maybe the compiler will get the hint. >> Do you really need to have the exact same name? Is it completely >> infeasible to have a function like int get_nif(...) instead of just "get" >> as an overload? (aka: the easy solution) >> >> Patrick >> >> >> On Sun, Mar 18, 2012 at 8:07 PM, Daniel Goertzen < >> daniel.goertzen@REDACTED> wrote: >> >>> I am working on a c++ nif and have an overloaded function that takes a >>> number of different types including integers and ERL_NIF_TERMs. The >>> problem is that ERL_NIF_TERM really just an integer and collides with my >>> integer functions, for example: >>> >>> int get(std::string var) {...} >>> int get(unsigned long var) {...} >>> int get(ERL_NIF_TERM var) {...} //compile error because ERL_NIF_TERM is >>> really an unsigned long. >>> >>> It would be great it ERL_NIF_TERM was a unique type so it could be used >>> in this situation. >>> >>> My first attempt to solve this involved creating wrappers for each NIF >>> API function. The wrapper used a new unique type instead of ERL_NIF_TERM, >>> and did type casting as needed. It was a type punning bloodbath. This was >>> complex and unsatisfactory. >>> >>> My second attempt was to hack erl_nif.h to change the definition of >>> ERL_NIF_TERM to a struct containing an int, and this worked great. But >>> this is not very portable due to the custom erl_nif.h. Also, I don't know >>> enough about linkers to know for sure if this is permitted. >>> >>> >>> Has this problem come up before? >>> >>> Is there some easy alternative that I am missing? >>> >>> Should I submit a patch for the erl_nif.h hack? (It is conditionally >>> compiled, by default nothing changes) >>> >>> >>> Thanks, >>> Dan. >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.joseph.davis@REDACTED Mon Mar 19 15:49:15 2012 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Mon, 19 Mar 2012 09:49:15 -0500 Subject: [erlang-bugs] ERL_NIF_TERM type collision In-Reply-To: References: Message-ID: Its been awhile since I C++'ed heavily and had the more nuanced details of types in my brain cache but here's something turned up after a quick Google: http://stackoverflow.com/questions/9378338/c-overloading-operators-for-similar-integer-types On Mon, Mar 19, 2012 at 9:25 AM, Daniel Goertzen wrote: > I note that c++11 now lets you specify the underlying integer type of the > enum; I now see that enums are the way to go. > > Dan. > > > On Mon, Mar 19, 2012 at 9:07 AM, Daniel Goertzen > wrote: >> >> ERL_NIF_TERM?is 32 bits for the 32 bit and halfword emulators, and 64 bits >> for the 64 bit emulator. ?Maybe I could use an enum (32 bits) for the >> halfword emulator, and pointer-to-dummy-struct for the others (since Sverker >> says structs are slow). >> >> I really do need to use overloading. ?I am working on overloaded c++ >> wrappers for enif_get_XXX() and enif_make_XXX(), and I support tuple >> cracking like... >> >> // term is?ERL_NIF_TERM?containing {"hello", 123, decode_me_later} >> std::tuple tup; >> get(env, term, &tup); >> >> ... where the std::tuple overload of get() recursively calls get() for all >> its constituent types. ?You can crack nested tuples in this manner too. >> >> >> Dan. >> >> >> >> >> On Sun, Mar 18, 2012 at 8:41 PM, Patrick Baggett >> wrote: >>> >>> At this point, you're effectively fighting the compiler. You could try an >>> enum since enum values aren't directly convertible to integers without an >>> explicit typecast -- maybe the compiler will get the hint. >>> Do you really need to have the exact same name? Is it completely >>> infeasible to have a function like int get_nif(...) instead of just "get" as >>> an overload? (aka: the easy solution) >>> >>> Patrick >>> >>> >>> On Sun, Mar 18, 2012 at 8:07 PM, Daniel Goertzen >>> wrote: >>>> >>>> I am working on a c++ nif and have an overloaded function that takes a >>>> number of different types including integers and ERL_NIF_TERMs. ?The problem >>>> is that ERL_NIF_TERM really just an integer and collides with my integer >>>> functions, for example: >>>> >>>> int get(std::string var) {...} >>>> int get(unsigned long var) {...} >>>> int get(ERL_NIF_TERM var) {...} ?//compile error because ERL_NIF_TERM is >>>> really an unsigned long. >>>> >>>> It would be great it ERL_NIF_TERM was a unique type so it could be used >>>> in this situation. >>>> >>>> My first attempt to solve this involved creating wrappers for each NIF >>>> API function. ?The wrapper used a new unique type instead of ERL_NIF_TERM, >>>> and did type casting as needed. ?It was a type punning bloodbath. ?This was >>>> complex and unsatisfactory. >>>> >>>> My second attempt was to hack erl_nif.h to change the definition of >>>> ERL_NIF_TERM to a struct containing an int, and this worked great. ?But this >>>> is not very portable due to the custom erl_nif.h. ?Also, I don't know enough >>>> about linkers to know for sure if this is permitted. >>>> >>>> >>>> Has this problem come up before? >>>> >>>> Is there some easy alternative that I am missing? >>>> >>>> Should I submit a patch for the erl_nif.h hack? (It is conditionally >>>> compiled, by default nothing changes) >>>> >>>> >>>> Thanks, >>>> Dan. >>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >>> >> > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From arun.babu@REDACTED Fri Mar 23 09:19:44 2012 From: arun.babu@REDACTED (P Arun Babu) Date: Fri, 23 Mar 2012 16:19:44 +0800 (SGT) Subject: [erlang-bugs] Typer Bug ? Message-ID: <1332490784.64764.YahooMailNeo@web193302.mail.sg3.yahoo.com> Hi, typer seems to be producing wrong spec for the below code.? Also, dialyzer with "-Wunmatched_returns -Werror_handling -Wbehaviours -Wunderspecs -Woverspecs"? shows no warnings. I am wondering ... is this a bug ? Thanks, -ARUN ------------------------------------------------------------------------------- %% File: "test.erl" %% ---------------- -spec is_valid(_) -> boolean(). -spec start(_,_) -> {['abs_n1_minus_n2_gt_5' | 'both_are_invalid' | 'n1_is_invalid' | 'n2_is_invalid' | 'this_could_be_a_bug'],_,'not_ok' | 'ok'}. ?-module(test). -export([start/2]). is_valid (N) -> ??? N > 10. start ( N1 , N2) -> ?? ?Is_valid_N1 = is_valid (N1), ?? ?Is_valid_N2 = is_valid (N2), ?? ?case {Is_valid_N1, Is_valid_N2} of ?? ??? ?{ false, true? } ?? ?-> ?? ??? ??? ??? ??? ?{ [n1_is_invalid], N2 , ok}; ?? ??? ?{? true, false }?? ?-> ?? ??? ??? ??? ??? ?{ [n2_is_invalid], N1, ok}; ?? ??? ?{ false, false } ?? ?-> ?? ??? ??? ??? ??? ?{ [ ?? ??? ??? ??? ??? ??? ?n1_is_invalid, ?? ??? ??? ??? ??? ??? ?n2_is_invalid, ?? ??? ??? ??? ??? ??? ?both_are_invalid, ?? ??? ??? ??? ??? ??? ?this_could_be_a_bug ?? ??? ??? ??? ??? ?? ], ?? ??? ??? ??? ??? ?? invalid, not_ok }; ?? ??? ?{? true, true? } ?? ?-> ?? ??? ??? ??? ??? ?case N1 < N2 of ?? ??? ??? ??? ??? ??? ?true ->? Minimum = N1; ?? ??? ??? ??? ??? ??? ?false -> Minimum = N2 ?? ??? ??? ??? ??? ?end, ?? ??? ??? ??? ??? ?case abs(N1- N2) > 5.0 of ?? ??? ??? ??? ??? ??? ?false -> {?? ??? ???????????? [], Minimum, ok }; ?? ??? ??? ??? ??? ??? ?true ->? {?? ?[abs_n1_minus_n2_gt_5], Minimum, ok } ?? ??? ??? ??? ??? ?end ?? ?end. ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Fri Mar 23 09:32:29 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 23 Mar 2012 09:32:29 +0100 Subject: [erlang-bugs] Typer Bug ? In-Reply-To: <1332490784.64764.YahooMailNeo@web193302.mail.sg3.yahoo.com> References: <1332490784.64764.YahooMailNeo@web193302.mail.sg3.yahoo.com> Message-ID: <4F6C351D.5070105@cs.ntua.gr> On 03/23/2012 09:19 AM, P Arun Babu wrote: > > Hi, > > typer seems to be producing wrong spec for the below code. Can you be more specific in what you think is wrong in the specs that typer shows? For example, the -spec is_valid(_) -> boolean(). which is produced for is_valid (N) -> N > 10. is the correct one. Trust me on that. > Also, dialyzer with "-Wunmatched_returns -Werror_handling -Wbehaviours > -Wunderspecs -Woverspecs" shows no warnings. > > I am wondering ... is this a bug ? I do not see something wrong in the code you wrote. (Other than it is very ugly and complicated but dialyzer is not a style checker.) Since presumably you are the author of the code, what do you think is wrong with it? Kostis From ericbmerritt@REDACTED Fri Mar 23 15:11:53 2012 From: ericbmerritt@REDACTED (Eric Merritt) Date: Fri, 23 Mar 2012 09:11:53 -0500 Subject: [erlang-bugs] Bug in reltool App Discovery Message-ID: If you have two versions of an application say foo-2.0 and foo-3.0, and foo 2.0 is in the root_dir, while foo 3.0 is in a lib_dir. In the spec you have specified an app entry with a vsn of 3.0, then reltool will fail to find 3.0 basically saying that 'foo' or 3.0 could not be found. If you then delete 2.0 from the root directory it happly resolves 3.0 with no further changes. both applications are in the normal OTP App format of - with a valid app file in ebin specifying the metadata. There have been *many* other things that I would consider bugs, but may not be depending on your interpretation, but this one seems to be pretty obvious. From erlangsiri@REDACTED Tue Mar 27 11:08:39 2012 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 27 Mar 2012 11:08:39 +0200 Subject: [erlang-bugs] Bug in reltool App Discovery In-Reply-To: References: Message-ID: Den 15:11 23. mars 2012 skrev Eric Merritt f?lgende: > If you have two versions of an application say foo-2.0 and > foo-3.0, and foo 2.0 is in the root_dir, while foo 3.0 is in a > lib_dir. In the spec you have specified an app entry with a vsn > of 3.0, then reltool will fail to find 3.0 basically saying that > 'foo' or 3.0 could not be found. > > If you then delete 2.0 from the root directory it happly resolves > 3.0 with no further changes. > > both applications are in the normal OTP App format of - > with a valid app file in ebin specifying the metadata. > > There have been *many* other things that I would consider bugs, but > may not be depending on your interpretation, but this one seems to be > pretty obvious. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > Hi Eric! Thanks for reporting this! When you say you have foo-2.0 in the root_dir, do you mean directly under the $ROOT or in $ROOT/lib?? Please feel free to list the other issues that you regard as bugs, and I will have a look at it. Also, there has been a rather big update of reltool including many bug fixes in the upcoming R15B01, so maybe some of your issues are already taken care of... :) /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericbmerritt@REDACTED Tue Mar 27 18:20:13 2012 From: ericbmerritt@REDACTED (Eric Merritt) Date: Tue, 27 Mar 2012 11:20:13 -0500 Subject: [erlang-bugs] Bug in reltool App Discovery In-Reply-To: References: Message-ID: On Tue, Mar 27, 2012 at 4:08 AM, Siri Hansen wrote: > > Den 15:11 23. mars 2012 skrev Eric Merritt > f?lgende: >> >> If you have two versions of an application say foo-2.0 and >> foo-3.0, and foo 2.0 is in the root_dir, while foo 3.0 is in a >> lib_dir. In the spec you have specified an app entry with a vsn >> of 3.0, then reltool will fail to find 3.0 basically saying that >> 'foo' or 3.0 could not be found. >> >> If you then delete 2.0 from the root directory it happly resolves >> 3.0 with no further changes. >> >> both applications are in the normal OTP App format of - >> with a valid app file in ebin specifying the metadata. >> >> There have been *many* other things that I would consider bugs, but >> may not be depending on your interpretation, but this one seems to be >> pretty obvious. >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > > Hi Eric! Thanks for reporting this! > > When you say you have foo-2.0 in the root_dir, do you mean directly under > the $ROOT or in $ROOT/lib?? Directly under root I am pretty sure (I need to redo it to make sure I have forgotten a bit). However, it was root_dir as specified in the config. I basically specified a root_dir and a lib_dir directly > Please feel free to list the other issues that you regard as bugs, and I > will have a look at it. I will pull a list together. I have the details spread around a bit. > > Also, there has been a rather big update of reltool including many bug fixes > in the upcoming R15B01, so maybe some of your issues are already taken care > of... :) Sir > > /siri From ericbmerritt@REDACTED Thu Mar 29 16:05:22 2012 From: ericbmerritt@REDACTED (Eric Merritt) Date: Thu, 29 Mar 2012 09:05:22 -0500 Subject: [erlang-bugs] Bug in reltool App Discovery In-Reply-To: References: Message-ID: Siri, I think the thing that disturbed me the most was that reltool, by default creates a 'Start' release with a version of 0.1 or 1.0 (I forget). There are two big problems with this. The first and worst is that it removes all meaning from release names and versions. That is we have some unknown number of 'start' releases out there at the same version all with different functionality. When I see a start relesase I expect it to be the erlang start release and would consider it safe to run. That is very much not true now that reltool creates the start release by default. Let me rephrase this, release names are important as are versions, they give you a critical reference to what is in the release. Reltool violates that precept and clouds the issues. I think this is a pretty bad thing. The second, less important though perhaps more painful thing in day to day life is that by using the same name by default it makes it impossible to have multiple releases in the target directory. (This is actually a variation of the naming/versioning problem but bare with me). In many situations this can cause problems. I realize that reltool probably does this because it makes it very easy to start a release. Erl uses the start release by default. However, I think there are much much better ways to accomplish this task then by defaulting all releases to 'start'. Eric On Tue, Mar 27, 2012 at 11:20 AM, Eric Merritt wrote: > On Tue, Mar 27, 2012 at 4:08 AM, Siri Hansen wrote: >> >> Den 15:11 23. mars 2012 skrev Eric Merritt >> f?lgende: >>> >>> If you have two versions of an application say foo-2.0 and >>> foo-3.0, and foo 2.0 is in the root_dir, while foo 3.0 is in a >>> lib_dir. In the spec you have specified an app entry with a vsn >>> of 3.0, then reltool will fail to find 3.0 basically saying that >>> 'foo' or 3.0 could not be found. >>> >>> If you then delete 2.0 from the root directory it happly resolves >>> 3.0 with no further changes. >>> >>> both applications are in the normal OTP App format of - >>> with a valid app file in ebin specifying the metadata. >>> >>> There have been *many* other things that I would consider bugs, but >>> may not be depending on your interpretation, but this one seems to be >>> pretty obvious. >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> >> >> Hi Eric! Thanks for reporting this! >> >> When you say you have foo-2.0 in the root_dir, do you mean directly under >> the $ROOT or in $ROOT/lib?? > > Directly under root I am pretty sure (I need to redo it to make sure I > have forgotten a bit). However, it was root_dir as specified in the > config. I basically specified a root_dir and a lib_dir directly > > >> Please feel free to list the other issues that you regard as bugs, and I >> will have a look at it. > > I will pull a list together. I have the details spread around a bit. > >> >> Also, there has been a rather big update of reltool including many bug fixes >> in the upcoming R15B01, so maybe some of your issues are already taken care >> of... :) > > Sir > >> >> /siri From sebastian.egner@REDACTED Sat Mar 31 17:51:28 2012 From: sebastian.egner@REDACTED (Sebastian Egner) Date: Sat, 31 Mar 2012 17:51:28 +0200 Subject: [erlang-bugs] Dialyzer bug related to contract checking Message-ID: <0F738B23-F9C4-4546-AC2D-4A4602B1F0E8@entelios.com> Hello, The two modules a and b below seem to crash the Dialyzer in OTP R15B: ./dialyzer --src a.erl b.erl --> Error in process <0.29.0> with exit value: {{badmatch,{c,list,[any,any],nonempty}},[{erl_types,t_abstract_records,2,[{file,"erl_types.erl"},{line,3194}]},{erl_types,'-t_abstract_records/2-lc$^1/1-5-',2,[{file,"erl_types.erl"},{line,3204}]},{erl_types,'-t_abstract_records/2-lc$^1/1-5-'... (Checking a.erl and b.erl individually is inconspicious.) For a possible workaround, see below. Sebastian *Details* Here is the reduced example: % --------------- -module(a). -export([g/1]). -export_type([a/0, t/0]). -type a() :: integer(). -type t() :: a() | maybe_improper_list(t(), t()). -spec g(t()) -> t(). g(X) -> X. % --- -module(b). -export([f/1]). -spec f(a:t()) -> a:t(). f(X) -> a:g(X). % --------------- *Workaround* My understanding of the inner workings of Dialyzer is too limited to fix it at the quality needed to submit a patch directly through Github. However, the following patch of t_abstract_records/2 in "otp_src_R15B/lib/hipe/cerl/erl_types.erl" corrects what is probably an "accidental match" against NewContents: 3194,3195c3194,3195 < ?list(NewContents, NewTermination, _) = t_cons(NewContents, Other), < ?list(NewContents, NewTermination, Size) --- > ?list(NewContents2, NewTermination, _) = t_cons(NewContents, Other), > ?list(NewContents2, NewTermination, Size)