From rvirding@REDACTED Mon Mar 1 04:19:46 2010 From: rvirding@REDACTED (Robert Virding) Date: Mon, 1 Mar 2010 04:19:46 +0100 Subject: [erlang-bugs] module name with . In-Reply-To: <4B8AA800.2090406@gmail.com> References: <373657.24739.qm@web113418.mail.gq1.yahoo.com> <3dbc6d1c1002280815r5e253336j60ab467d8b18a146@mail.gmail.com> <4B8AA800.2090406@gmail.com> Message-ID: <3dbc6d1c1002281919x15881666t216c13add4903813@mail.gmail.com> Ah, so there is documentation. But I must say it has been put in a place where I would definitely not look for it, among the kernel documentation, as it is not something you call. And I think that as it is something experimental you should have to turn it on to use it, it should not *always* be there. The two other experimental features, parametrised modules and extends, are better in this respect in that you actually have to explicitly do something to get them. There was another thread which discussed the existence of parametrised modules and packages briefly appeared there as well (introduced by me). And, as I stated there, I don't see the need for either of them. Robert On 28 February 2010 18:29, Richard Carlsson wrote: > Not that poorly documented (under kernel): > > ?http://www.erlang.org/doc/man/packages.html > > And no, you can't have a source file named "fm2.2.erl". > > ? ?/Richard > > Robert Virding wrote: >> >> My guess is that you are interacting with the experimental, and poorly >> documented, package system which assumes things when it sees module >> names with '.'. As far as I know there is no way to turn this off. >> Someone else may know more about this. My only suggestion is to avoid >> module names with a '.'. >> >> Robert >> >> On 28 February 2010 10:09, J K wrote: >>> >>> Hi, >>> is this a bug? >>> >>> Erlang R13B01 (erts-5.7.2) [smp:2:2] [rq:2] [async-threads:0] >>> >>> Eshell V5.7.2 ?(abort with ^G) >>> >>> 4> c('fm2.2'). >>> fm2.2.beam: Module name 'fm2.2' does not match file name 'fm2.2' >>> error >>> 5> >>> >>> i have: >>> -module('fm2.2'). >>> >>> BR >>> Johan > From dafgar@REDACTED Mon Mar 1 15:05:23 2010 From: dafgar@REDACTED (Sergei Fomin) Date: Mon, 01 Mar 2010 17:05:23 +0300 Subject: Wrong gregorian date Message-ID: <4B8BC9A3.5060901@yandex-team.ru> Hello. It seems a part of calendar library thinks there is February 29, 2010. # date +%s 1267451701 Eshell V5.7.4 (abort with ^G) 1> calendar:gregorian_seconds_to_datetime(1267451701). {{40,2,29},{13,55,1}} Best regards, Sergei Fomin From dafgar@REDACTED Mon Mar 1 15:37:43 2010 From: dafgar@REDACTED (Sergei Fomin) Date: Mon, 01 Mar 2010 17:37:43 +0300 Subject: [erlang-bugs] Wrong Gregorian date In-Reply-To: <06D2646124E8254FB9E03CAC8F9C555493D66C@SMXMB02-FLD.mtn.co.za> References: <4B8BC9A3.5060901@yandex-team.ru> <06D2646124E8254FB9E03CAC8F9C555493D66C@SMXMB02-FLD.mtn.co.za> Message-ID: <4B8BD137.7000004@yandex-team.ru> Oh, my fault. Thank you. Best regards, Sergei Fomin Trevor Woollacott [ MTN - Innovation Centre ] wrote: > Hi Sergei > > Date +%s does not return the date and time in Gregorian seconds, rather the number of seconds since 1970-01-01 00:00:00 UTC. If you try to convert the number of seconds since 1970 back to into the date & time tuple it correctly calculates the year at 40AD, which is a leap year. > > Regards, > Trevor > > > -----Original Message----- > From: erlang-bugs@REDACTED [mailto:erlang-bugs@REDACTED] On Behalf Of Sergei Fomin > Sent: Monday, 01 March 2010 04:05 PM > To: erlang-bugs@REDACTED > Subject: [erlang-bugs] Wrong gregorian date > > Hello. > > It seems a part of calendar library thinks there is February 29, 2010. > > # date +%s > 1267451701 > > Eshell V5.7.4 (abort with ^G) > 1> calendar:gregorian_seconds_to_datetime(1267451701). > {{40,2,29},{13,55,1}} > > > Best regards, > Sergei Fomin > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > > NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx > From Woolla_T@REDACTED Mon Mar 1 15:30:55 2010 From: Woolla_T@REDACTED (Trevor Woollacott [ MTN - Innovation Centre ]) Date: Mon, 1 Mar 2010 16:30:55 +0200 Subject: [erlang-bugs] Wrong Gregorian date In-Reply-To: <4B8BC9A3.5060901@yandex-team.ru> References: <4B8BC9A3.5060901@yandex-team.ru> Message-ID: <06D2646124E8254FB9E03CAC8F9C555493D66C@SMXMB02-FLD.mtn.co.za> Hi Sergei Date +%s does not return the date and time in Gregorian seconds, rather the number of seconds since 1970-01-01 00:00:00 UTC. If you try to convert the number of seconds since 1970 back to into the date & time tuple it correctly calculates the year at 40AD, which is a leap year. Regards, Trevor -----Original Message----- From: erlang-bugs@REDACTED [mailto:erlang-bugs@REDACTED] On Behalf Of Sergei Fomin Sent: Monday, 01 March 2010 04:05 PM To: erlang-bugs@REDACTED Subject: [erlang-bugs] Wrong gregorian date Hello. It seems a part of calendar library thinks there is February 29, 2010. # date +%s 1267451701 Eshell V5.7.4 (abort with ^G) 1> calendar:gregorian_seconds_to_datetime(1267451701). {{40,2,29},{13,55,1}} Best regards, Sergei Fomin ________________________________________________________________ erlang-bugs (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx From alex.kutsko@REDACTED Mon Mar 1 16:29:11 2010 From: alex.kutsko@REDACTED (Alex Kutsko) Date: Mon, 1 Mar 2010 17:29:11 +0200 Subject: [erlang-bugs] Wrong gregorian date In-Reply-To: <4B8BC9A3.5060901@yandex-team.ru> References: <4B8BC9A3.5060901@yandex-team.ru> Message-ID: But the date you provided is not gregorian seconds. try calendar:datetime_to_gregorian_seconds({date(),time()}). 63434683473 . The result you actually got is February 29, 2040 - you can ensure that this year is leap year :). On Mon, Mar 1, 2010 at 4:05 PM, Sergei Fomin wrote: > Hello. > > It seems a part of calendar library thinks there is February 29, 2010. > > # date +%s > 1267451701 > > Eshell V5.7.4 (abort with ^G) > 1> calendar:gregorian_seconds_to_datetime(1267451701). > {{40,2,29},{13,55,1}} > > > Best regards, > Sergei Fomin > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Best regards, Alex Kutsko From alex.kutsko@REDACTED Mon Mar 1 16:33:30 2010 From: alex.kutsko@REDACTED (Alex Kutsko) Date: Mon, 1 Mar 2010 17:33:30 +0200 Subject: [erlang-bugs] Wrong gregorian date In-Reply-To: References: <4B8BC9A3.5060901@yandex-team.ru> Message-ID: Sorry to be precise you've got February, 29 of 0040 year On Mon, Mar 1, 2010 at 5:29 PM, Alex Kutsko wrote: > But the date you provided is not gregorian seconds. > try > calendar:datetime_to_gregorian_seconds({date(),time()}). > 63434683473 > . > The result you actually got is February 29, 2040 - you can ensure that this > year is leap year :). > > > > On Mon, Mar 1, 2010 at 4:05 PM, Sergei Fomin wrote: > >> Hello. >> >> It seems a part of calendar library thinks there is February 29, 2010. >> >> # date +%s >> 1267451701 >> >> Eshell V5.7.4 (abort with ^G) >> 1> calendar:gregorian_seconds_to_datetime(1267451701). >> {{40,2,29},{13,55,1}} >> >> >> Best regards, >> Sergei Fomin >> >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> > > > -- > Best regards, > Alex Kutsko > -- Best regards, Alex Kutsko From manopapad@REDACTED Mon Mar 1 17:16:25 2010 From: manopapad@REDACTED (Manolis Papadakis) Date: Mon, 1 Mar 2010 18:16:25 +0200 Subject: Yecc bug (possibly related to mutually recursive rules) Message-ID: <8f45c97e1003010816m3129305fqae8d8060c746de24@mail.gmail.com> This grammar file: Nonterminals elem seq. Terminals 'foo' 'bar' ':'. Rootsymbol elem. elem -> 'foo'. elem -> 'bar'. elem -> seq. seq -> elem. seq -> seq ':' elem. % or seq -> elem ':' seq. when fed to yecc (git version) produces this error: 2> yecc:file("bug.yrl"). =ERROR REPORT==== 1-Mar-2010::18:16:06 === Error in process <0.36.0> with exit value: {function_clause,[{yecc,find_reduce_reduce,[[accept,{reduce,10,seq,1,{0,none},undefined}],{cxt,'$end',2,{yecc,"bug.yrl","bug.erl",[],{1,2},bug,[file_attributes,{includefile,[]},{parserfile,[]},report_errors,report_warnings],false... ** exception exit: function_clause in function yecc:find_reduce_reduce/2 called as yecc:find_reduce_reduce([accept,{reduce,10,seq,1,{0,none},undefined}], {cxt,'$end',2, {yecc,"bug.yrl","bug.erl",[], {1,2}, bug, [file_attributes, {includefile,[]}, {parserfile,[]}, report_errors,report_warnings], false,true,[],[],false, [{1,':'}], [],6,<0.37.0>,<0.38.0>,1, [{0,[{...}|...]},{1,[...]},{2,...},{...}|...], 16400,20497,[],32786,...}, []}) in call from yecc:'-find_action_conflicts/1-fun-0-'/3 in call from lists:foldl/3 in call from yecc:'-find_action_conflicts/1-fun-1-'/2 in call from lists:foldl/3 in call from yecc:find_action_conflicts/1 in call from yecc:action_conflicts/1 in call from yecc:'-generate/1-fun-8-'/3 When I stumbled on this, I figured It's easy to achieve the intended behavior without using a separate non-terminal, simply by declaring the separator as a left- (or right-) associative operator - and the resulting grammar file compiles normally. From jmakarlsson@REDACTED Tue Mar 2 00:06:56 2010 From: jmakarlsson@REDACTED (J K) Date: Mon, 1 Mar 2010 15:06:56 -0800 (PST) Subject: [erlang-bugs] module name with . In-Reply-To: <4B8AE60B.1050900@m5net.com> References: <373657.24739.qm@web113418.mail.gq1.yahoo.com> <3dbc6d1c1002280815r5e253336j60ab467d8b18a146@mail.gmail.com> <141807.74724.qm@web113407.mail.gq1.yahoo.com> <4B8AE60B.1050900@m5net.com> Message-ID: <674804.22768.qm@web113419.mail.gq1.yahoo.com> Well... hehe, I know... i must have had a blackout or something... ----- Original Message ---- From: Bernard Duggan To: J K Cc: Erlang Bugs Sent: Sun, February 28, 2010 10:54:19 PM Subject: Re: [erlang-bugs] module name with . Actually, all these look pretty much as I'd expect: J K wrote: > I tried comma just for "fun": > > 254> c(fm2,2). > ./fm2.erl:none: no such file or directory > error > By putting a comma there you've passed two parameters to the 'c' function. While the shell docs don't seem to mention it, a quick glance at the source shows that there is indeed a c/2 where the second parameter is the compilation options. So you're trying to compile a module called 'fm2' with an option of 2 (which probably doesn't mean anything, but the missing file is the first problem that is picked up). > 255> compile:file(fm2,2.erl). > * 1: illegal expression > Here, you've put a full stop/period in the middle of an expression (prior to closing the parentheses). That's the character the ends expressions, so of course it makes it illegal. > 256> compile:file('fm2,2.erl'). > {ok,'fm2,2'} > And here, by correctly wrapping the whole term in single quotes to make it an atom, the syntax becomes correct. The compile module seems to be a little more permissive here than the docs suggest, allowing you to add '.erl' to the module name and have it still work. > Maybe something with the shell? > If by 'something with the shell' you mean 'the shell doing exactly what it should', then yeah, I'd say there is indeed 'something with the shell' ;) B ________________________________________________________________ erlang-bugs (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED From thijsterlouw@REDACTED Tue Mar 2 05:33:47 2010 From: thijsterlouw@REDACTED (Thijs Terlouw) Date: Tue, 2 Mar 2010 12:33:47 +0800 Subject: [erlang-bugs] Wrong gregorian date In-Reply-To: References: <4B8BC9A3.5060901@yandex-team.ru> Message-ID: <4183f4b91003012033t6029ad47kf7dd7304797f6f3@mail.gmail.com> So Sergei should use : calendar:gregorian_seconds_to_datetime(1267451701+62167219200). Where does that magic number "62167219200" come from? Here: calendar:datetime_to_gregorian_seconds({{1970, 1, 1}, {0,0,0}}). Thijs Terlouw Shenzhen, China, http://www.startinchina.com/ On Mon, Mar 1, 2010 at 11:33 PM, Alex Kutsko wrote: > Sorry to be precise you've got February, 29 of 0040 year > > On Mon, Mar 1, 2010 at 5:29 PM, Alex Kutsko wrote: > >> But the date you provided is not gregorian seconds. >> try >> calendar:datetime_to_gregorian_seconds({date(),time()}). >> 63434683473 >> . >> The result you actually got is February 29, 2040 - you can ensure that this >> year is leap year :). >> >> >> >> On Mon, Mar 1, 2010 at 4:05 PM, Sergei Fomin wrote: >> >>> Hello. >>> >>> It seems a part of calendar library thinks there is February 29, 2010. >>> >>> # date +%s >>> 1267451701 >>> >>> Eshell V5.7.4 ?(abort with ^G) >>> 1> calendar:gregorian_seconds_to_datetime(1267451701). >>> {{40,2,29},{13,55,1}} >>> >>> >>> Best regards, >>> Sergei Fomin >>> >>> >>> >>> ________________________________________________________________ >>> erlang-bugs (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >>> >>> >> >> >> -- >> Best regards, >> Alex Kutsko >> > > > > -- > Best regards, > Alex Kutsko > From hans.bolinder@REDACTED Tue Mar 2 12:19:54 2010 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 2 Mar 2010 12:19:54 +0100 Subject: [erlang-bugs] Yecc bug (possibly related to mutually recursive rules) In-Reply-To: <8f45c97e1003010816m3129305fqae8d8060c746de24@mail.gmail.com> References: <8f45c97e1003010816m3129305fqae8d8060c746de24@mail.gmail.com> Message-ID: <19340.62554.671038.576572@ornendil.du.uab.ericsson.se> [Manolis Papadakis:] > This grammar file: > > Nonterminals elem seq. > Terminals 'foo' 'bar' ':'. > Rootsymbol elem. > elem -> 'foo'. > elem -> 'bar'. > elem -> seq. > seq -> elem. > seq -> seq ':' elem. > % or seq -> elem ':' seq. > > when fed to yecc (git version) produces this error: > > 2> yecc:file("bug.yrl"). ... > ** exception exit: function_clause > in function yecc:find_reduce_reduce/2 > called as > yecc:find_reduce_reduce([accept,{reduce,10,seq,1,{0,none},undefined}], ... Thanks. The bug will be fixed in R14A. In the meantime, to get the error report, you can add a dummy rule: Rootsymbol RS. RS -> elem. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From vladdu55@REDACTED Tue Mar 2 22:46:16 2010 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 2 Mar 2010 22:46:16 +0100 Subject: Doc update regarding source files not being UTF-8 Message-ID: <95be1d3b1003021346j240f8532ib11d7606dda6bf6b@mail.gmail.com> Hi! I think it would be a good idea if the introduction chapter in the reference manual, in the "Character set" section, would note specifically that even the comments in the source code can't contain UTF-8 characters because the lexical scanner doesn't understand them. Well, they might contain them but will be garbled if processed by any source tool (like for example syntax_tools) because Latin-1 and UTF-8 aren't compatible. The Eclipse editor will even refuse to save files with UTF-8 (so that they don't get garbled). If you think that it's a good idea to mention that too, please do so. I couldn't come up with a nice way to express this clearly, so there is no patch. best regards, Vlad From kostis@REDACTED Wed Mar 3 07:41:49 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 03 Mar 2010 08:41:49 +0200 Subject: [erlang-questions] Dialyzer bug with 'not (boolexpr)' guard In-Reply-To: <201002111005.o1BA51Cf049896@pluto.hedeland.org> References: <201002111005.o1BA51Cf049896@pluto.hedeland.org> Message-ID: <4B8E04AD.4020606@cs.ntua.gr> Per Hedeland wrote: > Hi, > > I believe the code below demonstrates a bug in dialyzer (2.1.0) - it > produces the warning: > > diabug.erl:19: Clause guard cannot succeed. The variable Cs was matched against the type any() > > for the first test/1 clause, ... For the record, let me mention that this particular bug (also present in dialyzer 2.2.0) has been fixed. The fix will appear in R14 and in its dev branch in the git repository. Thanks for the report, Kostis From manopapad@REDACTED Thu Mar 4 12:38:04 2010 From: manopapad@REDACTED (Manolis Papadakis) Date: Thu, 4 Mar 2010 13:38:04 +0200 Subject: Yecc Bug Message-ID: <8f45c97e1003040338s36333b11na88caf99e7a4a7f@mail.gmail.com> The parser produced by this grammar: Nonterminals boolean command. Terminals '(' ')' if then else true and or skip while do. Rootsymbol command. Left 100 or. Left 200 and. boolean -> '(' boolean ')'. boolean -> 'true'. boolean -> boolean 'and' boolean. boolean -> boolean 'or' boolean. command -> 'skip'. command -> 'if' boolean 'then' command 'else' command. command -> 'while' boolean 'do' command. crashes when encountering an 'or', but works fine with 'and'. Here is an example: 3> bug2:parse([{'if',1}, {'true',1}, {'or',1}, {'true',1}, {'then',1}, {'skip',1}, {'else',1}, {'skip',1}]). ** exception error: {yecc_bug,"1.3",{missing_state_in_action_table,11}} in function bug2:yeccpars2/7 in call from bug2:yeccpars0/5 This is as simple as I've managed to get the failing grammar. Removing the parentheses, 'and' or 'while' constructs from the grammar fixes the crash. From hans.bolinder@REDACTED Thu Mar 4 15:32:43 2010 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 4 Mar 2010 15:32:43 +0100 Subject: [erlang-bugs] Yecc Bug In-Reply-To: <8f45c97e1003040338s36333b11na88caf99e7a4a7f@mail.gmail.com> References: <8f45c97e1003040338s36333b11na88caf99e7a4a7f@mail.gmail.com> Message-ID: <19343.50315.192936.203959@ornendil.du.uab.ericsson.se> [Manolis Papadakis:] > The parser produced by this grammar: > > Nonterminals boolean command. > Terminals '(' ')' if then else true and or skip while do. > Rootsymbol command. > Left 100 or. > Left 200 and. > boolean -> '(' boolean ')'. > boolean -> 'true'. > boolean -> boolean 'and' boolean. > boolean -> boolean 'or' boolean. > command -> 'skip'. > command -> 'if' boolean 'then' command 'else' command. > command -> 'while' boolean 'do' command. > > crashes when encountering an 'or', but works fine with 'and'. Here is > an example: Thanks! The bug will be fixed in R14A. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From a.zhuravlev@REDACTED Thu Mar 4 15:44:22 2010 From: a.zhuravlev@REDACTED (Alexander Zhuravlev) Date: Thu, 4 Mar 2010 17:44:22 +0300 Subject: run reports incorrect match position Message-ID: <20100304144422.GA69196@zaa.local> Hello, I am not sure if this is a bug in R13B04 or not, but I am experiencing the following issue: 1> re:run([1058,1077,1089,1090] ++ "http://example.com/index.php?a=b", "http", [unicode]). {match,[{8,4}]} I am trying to find position of a match in a string (list, not a binary) with unicode characters. Since the string has 4 unicode symbols and then the matching part I suppose that re:run should return {match, [{4,4}]} when I pass a list, and {match, [{8, 4}]} when I pass a binary. Right now it returns {match, [{8, 4}]} in both cases. Is this a bug? If not, how can I get position of a match in unicode string? Thank you. -- Alexander Zhuravlev From micahw@REDACTED Thu Mar 4 17:09:39 2010 From: micahw@REDACTED (Micah Warren) Date: Thu, 4 Mar 2010 11:09:39 -0500 Subject: lint_module crash on +check_untyped_records Message-ID: <0E8A5396-9A58-46FA-86BD-15BDA99E7BAF@fusedsolutions.com> Attempting to compile a module that defines a type dependant on an undefined record with the +warn_untyped_record flag causes erl_lint to crash with reason badarg. Perhaps a better behavior is to report the undefined record instead. This has been tested on R13B03 on OS 10.6.2. To reproduce the behavior: Create the file badmod.erl: Code: -module(badmod). -type(test() :: #arec{}). Compile: erlc +warn_untyped_record badmod.erl This should cause: badmod.erl:none: internal error in lint_module; crash reason: {badarg,[{dict,fetch, [arec, {dict,0,16,16,8,80,48, {[],[],[],[],[],[],[],[],[],[],[],[],[], [],[],[]}, {{[],[],[],[],[],[],[],[],[],[],[],[],[], [],[],[]}}}]}, {erl_lint,'-check_untyped_records/2-fun-1-',3}, {lists,foldl,3}, {erl_lint,post_traversal_check,2}, {erl_lint,module,3}, {compile,lint_module,1}, {compile,'-internal_comp/4-anonymous-1-',2}, {compile,fold_comp,3}]} To resolve the error define #arec{}: -module(badmod). -record(arc, {id :: string()}). -type(test() :: #arec{}). From kostis@REDACTED Thu Mar 4 18:52:15 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 04 Mar 2010 19:52:15 +0200 Subject: [erlang-bugs] lint_module crash on +check_untyped_records In-Reply-To: <0E8A5396-9A58-46FA-86BD-15BDA99E7BAF@fusedsolutions.com> References: <0E8A5396-9A58-46FA-86BD-15BDA99E7BAF@fusedsolutions.com> Message-ID: <4B8FF34F.5080500@cs.ntua.gr> Micah Warren wrote: > Attempting to compile a module that defines a type dependant on an undefined record with the +warn_untyped_record flag causes erl_lint to crash with reason badarg. Perhaps a better behavior is to report the undefined record instead. Thanks for the bug report! This will be fixed in R14 (and will appear soon in git) but in case you need a fix earlier it is included below although the line numbers differ. Kostis Index: lib/stdlib/src/erl_lint.erl =================================================================== RCS file: /hipe/otp/lib/stdlib/src/erl_lint.erl,v retrieving revision 1.137 diff -u -r1.137 erl_lint.erl --- lib/stdlib/src/erl_lint.erl 4 Mar 2010 15:27:46 -0000 1.137 +++ lib/stdlib/src/erl_lint.erl 4 Mar 2010 17:48:30 -0000 @@ -1030,11 +1030,8 @@ check_untyped_records(Forms, St0) -> case is_warn_enabled(untyped_record, St0) of true -> - %% One possibility is to use the names of all records - %% RecNames = dict:fetch_keys(St0#lint.records), - %% but I think it's better to keep those that are used by the file - Usage = St0#lint.usage, - UsedRecNames = sets:to_list(Usage#usage.used_records), + %% Use the names of all records *defined* in the module (not used) + RecNames = dict:fetch_keys(St0#lint.records), %% these are the records with field(s) containing type info TRecNames = [Name || {attribute,_,type,{{record,Name},Fields,_}} <- Forms, @@ -1047,7 +1044,7 @@ [] -> St; % exclude records with no fields [_|_] -> add_warning(L, {untyped_record, N}, St) end - end, St0, UsedRecNames -- TRecNames); + end, St0, RecNames -- TRecNames); false -> St0 end. From kostis@REDACTED Sat Mar 6 10:25:37 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 06 Mar 2010 11:25:37 +0200 Subject: Syntax of fun expressions Message-ID: <4B921F91.6030007@cs.ntua.gr> In most languages, one is typically allowed to use parentheses in most places. Indeed, in Erlang one can write all these below: 1> lists:last([1,2,3]). 3 2> lists:last(([1,2,3])). 3 3> lists:(last)([1,2,3]). 3 4> (lists):last([1,2,3]). 3 5> (lists):(last)(([1,2,3])). 3 The same is not allowed in the constituents of fun expressions. One is not allowed to put parentheses in any component of: fun M:F/A For example, fun (lists):last/1 results in a syntax error. I think this is inconsistent. Why do I want to add parentheses around fun constituents you may ask? A tidier user complained that tidier's suggestion to transform spawn_link(?MODULE, rec, []) to spawn_link(fun (?MODULE):rec/0) resulted in a syntax error. Arguably, (?MODULE) expresses the grouping of ? with MODULE in ?MODULE:rec/0 better than without parentheses. Moreover, apparently the parser insists that M and F are *statically* atoms (and A integer) so one cannot write: M = lists, F = fun M:last/1 I can possibly understand why A has to be statically known, but why should M and F also be? I thought, perhaps wrongly, that the sequence above is anyway transformed to its equivalent one: M = lists, F = fun (_L) -> M:last(_L) end. Kostis From bgustavsson@REDACTED Sun Mar 7 12:31:54 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sun, 7 Mar 2010 12:31:54 +0100 Subject: [erlang-bugs] Syntax of fun expressions In-Reply-To: <4B921F91.6030007@cs.ntua.gr> References: <4B921F91.6030007@cs.ntua.gr> Message-ID: <6672d0161003070331s62e91d21sbedf5a30adfd6fe2@mail.gmail.com> 2010/3/6 Kostis Sagonas : > A tidier user complained that tidier's suggestion to transform > > ? ? ? ?spawn_link(?MODULE, rec, []) > to > ? ? ? ?spawn_link(fun (?MODULE):rec/0) > > resulted in a syntax error. ?Arguably, (?MODULE) expresses the grouping of ? > with MODULE in ?MODULE:rec/0 better than without parentheses. > > > Moreover, apparently the parser insists that M and F are *statically* atoms > (and A integer) so one cannot write: > > ? ? ? ?M = lists, > ? ? ? ?F = fun M:last/1 > There is an EEP that propose that variables should be allowed in external funs: http://www.erlang.org/eeps/eep-0023.html As far as I can remember, we have approved that EEP. We have not implemented it because of lack of time (not that it is very difficult, just that other things had higher priority). To also allow arbitrary expressions would be fine for me, unless they would cause some ambiguity or other problem in erl_parse. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From roberto.aloi@REDACTED Fri Mar 12 14:01:07 2010 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Fri, 12 Mar 2010 13:01:07 +0000 Subject: SSH subsystems Message-ID: <4B9A3B13.1000708@erlang-solutions.com> Hi all, in the SSH 1.1.8 documentation (ssh module), when talking about subsystems: === BEGIN CITE === {subsystems, [subsystem_spec()] Provides specifications for handling of subsystems. The "sftp" subsystem-spec can be retrieved by calling ssh_sftd:subsystem_spec/1. If the subsystems option in not present the value of [ssh_sftd:subsystem_spec([])] will be used. It is of course possible to set the option to the empty list if you do not want the daemon to run any subsystems at all. === END CITE === ssh_sftd should be ssh_sftpd (twice). Regards, Roberto Aloi -- University of Kent - Erlang Solutions Ltd. Twitter: @prof3ta Blog: http://aloiroberto.wordpress.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From nick@REDACTED Mon Mar 15 14:24:36 2010 From: nick@REDACTED (Niclas Eklund) Date: Mon, 15 Mar 2010 14:24:36 +0100 (CET) Subject: [erlang-bugs] SSH subsystems In-Reply-To: <4B9A3B13.1000708@erlang-solutions.com> References: <4B9A3B13.1000708@erlang-solutions.com> Message-ID: Hello! Thank you for pointing this out. It has now been corrected. Best regards, Niclas @ Erlang/OTP On Fri, 12 Mar 2010, Roberto Aloi wrote: > Hi all, > > in the SSH 1.1.8 documentation (ssh module), when talking about subsystems: > > === BEGIN CITE === > {subsystems, [subsystem_spec()] > Provides specifications for handling of subsystems. The "sftp" > subsystem-spec can be retrieved by calling ssh_sftd:subsystem_spec/1. If > the subsystems option in not present the value of > [ssh_sftd:subsystem_spec([])] will be used. It is of course possible to > set the option to the empty list if you do not want the daemon to run > any subsystems at all. > === END CITE === > > ssh_sftd should be ssh_sftpd (twice). > > Regards, > > Roberto Aloi > > -- > University of Kent - Erlang Solutions Ltd. > Twitter: @prof3ta > Blog: http://aloiroberto.wordpress.com > --------------------------------------------------- > > --------------------------------------------------- > > WE'VE CHANGED NAMES! > > Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. > > www.erlang-solutions.com > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > From pguyot@REDACTED Thu Mar 18 15:30:48 2010 From: pguyot@REDACTED (Paul Guyot) Date: Thu, 18 Mar 2010 15:30:48 +0100 Subject: release_handler: cannot find top supervisor for application * Message-ID: <1AA7825A-8045-4C81-9ACD-521779D5E550@kallisys.net> Hello, There seems to be an incompatibility between stdlib 1.16.5 and sasl 2.1.9 and earlier. This incompatibility was introduced with OTP-8324 (github commit 88b530ea24977081020feb2123124063e58dfc12). As a consequence, one might not be able to upgrade a root supervisor in release procedures, and releases produce warnings like : =ERROR REPORT==== 2010-03-18 08:04:50 === release_handler: cannot find top supervisor for application mnesia (and it goes on for every application). Since commit 88b530ea24977081020feb2123124063e58dfc12, sys:get_status returns the formatted state from the module's format_status/2 function. For a supervisor, it means calling gen_server:format_status/2. As a result, release_handler:get_supervisor_module1/1 fails with a bad match. get_supervisor_module1(SupPid) -> {status, _Pid, {module, _Mod}, [_PDict, _SysState, _Parent, _Dbg, Misc]} = sys:get_status(SupPid), [_Name, State, _Type, _Time] = Misc, <--- bad match happens here %% Cannot use #supervisor_state{module = Module} = State. {ok, element(#supervisor_state.module, State)}. Misc used to be a list with 4 elements before 88b530ea24977081020feb2123124063e58dfc12, it now is a list with three elements and the actual state of the supervisor is deep inside the third element. For example, this is the result I have with mnesia (and R13B04) : P = application_controller:get_master(mnesia), {Root, _} = application_master:get_child(P), sys:get_status(Root). {status,<0.36.0>, {module,gen_server}, [[{'$ancestors',[<0.35.0>]}, {'$initial_call',{supervisor,mnesia_sup,1}}], running,<0.35.0>,[], [{header,"Status for generic server mnesia_sup"}, {data,[{"Status",running}, {"Parent",<0.35.0>}, {"Logged events",[]}]}, {data,[{"State", {state,{local,mnesia_sup}, one_for_all, [{child,<0.38.0>,mnesia_kernel_sup, {mnesia_kernel_sup,start,[]}, permanent,infinity,supervisor,...}, {child,<0.37.0>,mnesia_event, {mnesia_sup,start_event,...}, permanent,30000,...}], {dict,0,16,16,8,80,48,...}, 0,3600,[],mnesia_sup, [[]]}}]}]]} Moreover, sys:get_status calls gen_server:format_status which in turn calls Module:format_status if it exists and uses that as the last element of Misc list, and as a consequence, we cannot be sure how to get the state (in order to find out the supervisor callback module). In other words, a quick fix that would match against the new result of sys:get_status might fail for application root supervisors that implement a custom format_status/2. However, format_status/2 callback itself is not documented in supervisor(3) (it is documented in gen_server(3)).... Since all this code is preceded with a note : %% Note: The following is a terrible hack done in order to resolve the %% problem stated in ticket OTP-3452. I believe this deserves a rewrite (or a revert of 88b530ea24977081020feb2123124063e58dfc12). Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From kruber@REDACTED Thu Mar 18 18:23:23 2010 From: kruber@REDACTED (Nico Kruber) Date: Thu, 18 Mar 2010 18:23:23 +0100 Subject: emacs support Message-ID: <201003181823.31373.kruber@zib.de> Since R13B04 some files have been not been installed for the emacs support to work. I created a fork at github and committed changes that fix this issue http://github.com/NicoK/otp/commit/081dd393f27a93f94756d9e43822354674e674b8 I also created a git pull request that time but I didn't get any answer so I figured it might have slipped through or not have been created at all (since I don't see the github interface mentioning it anywhere). Could you have a look at it? -- Nico Kruber phone: +49 30 84185-253 ----- Zuse-Institut Berlin Takustr. 7 D-14195 Berlin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bgustavsson@REDACTED Thu Mar 18 18:56:40 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 18 Mar 2010 18:56:40 +0100 Subject: [erlang-bugs] emacs support In-Reply-To: <201003181823.31373.kruber@zib.de> References: <201003181823.31373.kruber@zib.de> Message-ID: <6672d0161003181056q40e4387duef0851399f529a13@mail.gmail.com> On Thu, Mar 18, 2010 at 6:23 PM, Nico Kruber wrote: > Since R13B04 some files have been not been installed for the emacs support to > work. > I created a fork at github and committed changes that fix this issue > http://github.com/NicoK/otp/commit/081dd393f27a93f94756d9e43822354674e674b8 > I also created a git pull request that time but I didn't get any answer so I > figured it might have slipped through or not have been created at all (since I > don't see the github interface mentioning it anywhere). The recommended way to submit patches is described here: http://wiki.github.com/erlang/otp/submitting-patches There already is a branch included in our 'pu' branch that includes the missing elisp files. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From vinoski@REDACTED Fri Mar 19 01:10:17 2010 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 18 Mar 2010 19:10:17 -0500 Subject: [erlang-bugs] release_handler: cannot find top supervisor for application * In-Reply-To: <1AA7825A-8045-4C81-9ACD-521779D5E550@kallisys.net> References: <1AA7825A-8045-4C81-9ACD-521779D5E550@kallisys.net> Message-ID: <65b2728e1003181710l52d71536wcd797e1d97741361@mail.gmail.com> On Thu, Mar 18, 2010 at 9:30 AM, Paul Guyot wrote: > Hello, > > There seems to be an incompatibility between stdlib 1.16.5 and sasl 2.1.9 and earlier. > This incompatibility was introduced with OTP-8324 (github commit 88b530ea24977081020feb2123124063e58dfc12). As a consequence, one might not be able to upgrade a root supervisor in release procedures, and releases produce warnings like : > > =ERROR REPORT==== 2010-03-18 08:04:50 === > release_handler: cannot find top supervisor for application mnesia > > (and it goes on for every application). > > Since commit 88b530ea24977081020feb2123124063e58dfc12, sys:get_status returns the formatted state from the module's format_status/2 function. For a supervisor, it means calling gen_server:format_status/2. As a result, release_handler:get_supervisor_module1/1 fails with a bad match. > > get_supervisor_module1(SupPid) -> > ?{status, _Pid, {module, _Mod}, > ? [_PDict, _SysState, _Parent, _Dbg, Misc]} = sys:get_status(SupPid), > ?[_Name, State, _Type, _Time] = Misc, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?<--- bad match happens here > ?%% Cannot use #supervisor_state{module = Module} = State. > ?{ok, element(#supervisor_state.module, State)}. > > Misc used to be a list with 4 elements before 88b530ea24977081020feb2123124063e58dfc12, it now is a list with three elements and the actual state of the supervisor is deep inside the third element. Not trying to downplay the problems you've run into, but IMO the above code strikes me as a fairly undesirable coupling between sasl, sys, and gen_server. > Moreover, sys:get_status calls gen_server:format_status which in turn calls Module:format_status if it exists and uses that as the last element of Misc list, and as a consequence, we cannot be sure how to get the state (in order to find out the supervisor callback module). In other words, a quick fix that would match against the new result of sys:get_status might fail for application root supervisors that implement a custom format_status/2. I could be missing something, but wouldn't supervisor need to implement its own format_status/2 that allowed its callback modules to supply their own version of format_status/2? The gen_server code will only call its direct callback module's format_status if it has one, and supervisor doesn't have one. > However, format_status/2 callback itself is not documented in supervisor(3) (it is documented in gen_server(3)).... Right, because supervisor doesn't support a custom format_status. > I believe this deserves a rewrite (or a revert of 88b530ea24977081020feb2123124063e58dfc12). Not sure a revert or rewrite is needed, but obviously that's ultimately up to Bj?rn and crew. IMO, it would be best to eliminate the questionable coupling between sasl, sys, and gen_server, but that would need work (which I'd be quite happy to do, given I'm the source of the patches in question). But for a short term fix, perhaps this patch would work: diff --git a/lib/sasl/src/release_handler_1.erl b/lib/sasl/src/release_handler_1.erl index e3e3cab..6d6216d 100644 --- a/lib/sasl/src/release_handler_1.erl +++ b/lib/sasl/src/release_handler_1.erl @@ -554,7 +554,7 @@ get_supervisor_module(SupPid) -> get_supervisor_module1(SupPid) -> {status, _Pid, {module, _Mod}, [_PDict, _SysState, _Parent, _Dbg, Misc]} = sys:get_status(SupPid), - [_Name, State, _Type, _Time] = Misc, + [_Header, _Data, {data, [{"State", State}]}] = Misc, %% Cannot use #supervisor_state{module = Module} = State. {ok, element(#supervisor_state.module, State)}. Obviously this has just as much coupling as the original code, but this isn't intended as an official patch. Paul, maybe you could try it? Unfortunately I don't believe the sasl tests are released, so I can't check them. --steve From wglozer@REDACTED Sun Mar 21 00:11:11 2010 From: wglozer@REDACTED (Will) Date: Sat, 20 Mar 2010 16:11:11 -0700 Subject: [BUG] erlang:decode_packet/3 generates corrupt header names with httph_bin Message-ID: Hello, erlang:decode_packet/3 generates strange corrupted header names for unknown header types when using the httph_bin option. The cause seems related to the length of the header name, short ones work fine. Test Case: test() -> B = << "X-Transaction: 1269062039-39495-905\r\n" "X-RateLimit-Limit: 150\r\n" "Content-Type: application/json; charset=utf-8\r\n" "X-Foo: bar\r\n" "\r\n" >>, {ok, Headers, Rest} = decode_headers(B, []), io:format("HEADERS:~n~p~n", [Headers]), io:format("REST:~n~p~n", [Rest]). decode_headers(Bin, Acc) -> case erlang:decode_packet(httph_bin, Bin, []) of {ok, {http_header, _N, _Name, _, _V} = H, Rest} -> decode_headers(Rest, [H | Acc]); {ok, http_eoh, Rest} -> {ok, Acc, Rest} end. Result: Erlang R13B04 (erts-5.7.5) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] HEADERS: [{http_header,0,<<"X-Foo">>,undefined,<<"bar">>}, {http_header,42,'Content-Type',undefined, <<"application/json; charset=utf-8">>}, {http_header,0, <<88,45,70,111,111,50,14,0,64,190,14,1,10,0,0,0,14>>, undefined,<<"150">>}, {http_header,0, <<88,45,70,111,111,50,14,0,64,190,14,1,10>>, undefined,<<"1269062039-39495-905">>}] REST: <<>> From kenji.rikitake@REDACTED Sun Mar 21 06:35:16 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 21 Mar 2010 14:35:16 +0900 Subject: ssh_connection:send/4 on R13B04 with the last argument as "infinity" fails Message-ID: <20100321053516.GA18793@k2r.org> On R13B04, when using ssh_connection:send(ConnectionManager, ChannelId, Data, Timeout) with Timeout as 'infinity' (atom), the function crashes with the error on erlang:size([infinity]). The following small patch will fix this, by explicitly treating the 'infinity' atom in the pattern matching of lib/src/ssh_connection.erl. Kenji Rikitake --- ssh_connection.erl.old 2010-03-21 14:28:43.000000000 +0900 +++ ssh_connection.erl 2010-03-21 14:29:59.000000000 +0900 @@ -123,6 +123,8 @@ send(ConnectionManager, ChannelId, 0, Data, infinity). send(ConnectionManager, ChannelId, Data, TimeOut) when is_integer(TimeOut) -> send(ConnectionManager, ChannelId, 0, Data, TimeOut); +send(ConnectionManager, ChannelId, Data, infinity) -> + send(ConnectionManager, ChannelId, 0, Data, infinity); send(ConnectionManager, ChannelId, Type, Data) -> send(ConnectionManager, ChannelId, Type, Data, infinity). send(ConnectionManager, ChannelId, Type, Data, TimeOut) -> From kenji.rikitake@REDACTED Sun Mar 21 06:38:34 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 21 Mar 2010 14:38:34 +0900 Subject: R13B04: ssh:connect to an IPv6 address doesn't work Message-ID: <20100321053834.GB18793@k2r.org> A simple call to ssh:connect("::1", 22, []) fails with {error, nxdomain} I suspect something wrong with choosing the Callback variable in ssh_transport:do_connect/5, but no further tracking so far. Kenji Rikitake From nick@REDACTED Mon Mar 22 10:05:44 2010 From: nick@REDACTED (Niclas Eklund) Date: Mon, 22 Mar 2010 10:05:44 +0100 (CET) Subject: [erlang-patches] ssh_connection:send/4 on R13B04 with the last argument as "infinity" fails In-Reply-To: <20100321053516.GA18793@k2r.org> References: <20100321053516.GA18793@k2r.org> Message-ID: Hello! Thank you for pointing this out. I've applied the change you suggested. Best regards, Niclas @ Erlang/OTP On Sun, 21 Mar 2010, Kenji Rikitake wrote: > On R13B04, when using > ssh_connection:send(ConnectionManager, ChannelId, Data, Timeout) > with Timeout as 'infinity' (atom), the function crashes > with the error on erlang:size([infinity]). > > The following small patch will fix this, by explicitly treating > the 'infinity' atom in the pattern matching of > lib/src/ssh_connection.erl. > > Kenji Rikitake > > --- ssh_connection.erl.old 2010-03-21 14:28:43.000000000 +0900 > +++ ssh_connection.erl 2010-03-21 14:29:59.000000000 +0900 > @@ -123,6 +123,8 @@ > send(ConnectionManager, ChannelId, 0, Data, infinity). > send(ConnectionManager, ChannelId, Data, TimeOut) when is_integer(TimeOut) -> > send(ConnectionManager, ChannelId, 0, Data, TimeOut); > +send(ConnectionManager, ChannelId, Data, infinity) -> > + send(ConnectionManager, ChannelId, 0, Data, infinity); > send(ConnectionManager, ChannelId, Type, Data) -> > send(ConnectionManager, ChannelId, Type, Data, infinity). > send(ConnectionManager, ChannelId, Type, Data, TimeOut) -> > > ________________________________________________________________ > erlang-patches (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED > From nick@REDACTED Mon Mar 22 10:42:28 2010 From: nick@REDACTED (Niclas Eklund) Date: Mon, 22 Mar 2010 10:42:28 +0100 (CET) Subject: [erlang-bugs] R13B04: ssh:connect to an IPv6 address doesn't work In-Reply-To: <20100321053834.GB18793@k2r.org> References: <20100321053834.GB18793@k2r.org> Message-ID: Hello! It looks like you've found a bug. %% ssh:connect/4 DisableIpv6 = proplists:get_value(ip_v6_disabled, Opts, false), Inet = inetopt(DisableIpv6), Which invokes the local function: inetopt(true) -> inet6; inetopt(false) -> inet. I.e, the return values have been mixed up. If you try the following it should work for you: erl> ssh:connect("::1", 22, [{ip_v6_disabled, true}]). But this needs to be sorted out in the SSH application. /Niclas @ Erlang/OTP On Sun, 21 Mar 2010, Kenji Rikitake wrote: > A simple call to > ssh:connect("::1", 22, []) > fails with > {error, nxdomain} > > I suspect something wrong with choosing the Callback variable > in ssh_transport:do_connect/5, but no further tracking so far. > > Kenji Rikitake > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > From kenji.rikitake@REDACTED Mon Mar 22 12:34:40 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Mon, 22 Mar 2010 20:34:40 +0900 Subject: [erlang-bugs] R13B04: ssh:connect to an IPv6 address doesn't work In-Reply-To: References: <20100321053834.GB18793@k2r.org> Message-ID: <20100322113440.GA40925@k2r.org> Hello Niclas: you're right on the reversed ip_v6_disabled option. My sshrpc code worked OK when ip_v6_disabled is set to *true*. A confirmation and FYI. Kenji Rikitake In the message dated Mon, Mar 22, 2010 at 10:42:04AM +0100, Niclas Eklund writes: > Hello! > > It looks like you've found a bug. > > %% ssh:connect/4 > > DisableIpv6 = proplists:get_value(ip_v6_disabled, Opts, false), > Inet = inetopt(DisableIpv6), > > Which invokes the local function: > > inetopt(true) -> > inet6; > inetopt(false) -> > inet. > > I.e, the return values have been mixed up. If you try the following it > should work for you: > > erl> ssh:connect("::1", 22, [{ip_v6_disabled, true}]). > > But this needs to be sorted out in the SSH application. > > /Niclas @ Erlang/OTP > > On Sun, 21 Mar 2010, Kenji Rikitake wrote: > > >A simple call to > >ssh:connect("::1", 22, []) > >fails with > >{error, nxdomain} > > > >I suspect something wrong with choosing the Callback variable > >in ssh_transport:do_connect/5, but no further tracking so far. > > > >Kenji Rikitake From nick@REDACTED Mon Mar 22 15:44:38 2010 From: nick@REDACTED (Niclas Eklund) Date: Mon, 22 Mar 2010 15:44:38 +0100 (CET) Subject: [erlang-bugs] R13B04: ssh:connect to an IPv6 address doesn't work In-Reply-To: <20100322113440.GA40925@k2r.org> References: <20100321053834.GB18793@k2r.org> <20100322113440.GA40925@k2r.org> Message-ID: Hello! I've updated the internal function as follows: inetopt(true) -> inet; inetopt(false) -> inet6. The configuration parameter ip_v6_disabled is also documented now. As soon as this has been pushed to github, you can access this via the dev-branch. The correct usage will be: erl> ssh:connect("::1", 22, [{ip_v6_disabled, false}]). /Niclas @ Erlang/OTP On Mon, 22 Mar 2010, Kenji Rikitake wrote: > Hello Niclas: you're right on the reversed ip_v6_disabled option. > My sshrpc code worked OK when ip_v6_disabled is set to *true*. > A confirmation and FYI. > Kenji Rikitake > > In the message > dated Mon, Mar 22, 2010 at 10:42:04AM +0100, > Niclas Eklund writes: >> Hello! >> >> It looks like you've found a bug. >> >> %% ssh:connect/4 >> >> DisableIpv6 = proplists:get_value(ip_v6_disabled, Opts, false), >> Inet = inetopt(DisableIpv6), >> >> Which invokes the local function: >> >> inetopt(true) -> >> inet6; >> inetopt(false) -> >> inet. >> >> I.e, the return values have been mixed up. If you try the following it >> should work for you: >> >> erl> ssh:connect("::1", 22, [{ip_v6_disabled, true}]). >> >> But this needs to be sorted out in the SSH application. >> >> /Niclas @ Erlang/OTP >> >> On Sun, 21 Mar 2010, Kenji Rikitake wrote: >> >>> A simple call to >>> ssh:connect("::1", 22, []) >>> fails with >>> {error, nxdomain} >>> >>> I suspect something wrong with choosing the Callback variable >>> in ssh_transport:do_connect/5, but no further tracking so far. >>> >>> Kenji Rikitake > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > From zeno490@REDACTED Mon Mar 22 16:17:25 2010 From: zeno490@REDACTED (Nicholas Frechette) Date: Mon, 22 Mar 2010 11:17:25 -0400 Subject: [erlang-questions] epmd leaving ports in TIME_WAIT? In-Reply-To: References: Message-ID: Escalating to erlang-bugs. I've restarted both my server and laptop over the weekend. On both machines, I restarted my 2 erlang applications (4 nodes, connected in pairs: A <-> B, C <-> D, with pairs on the same computer) This was yesterday. This morning I did another netstat -t, and indeed, I have >100 sockets stuck in TIME_WAIT on both computers. Both with outgoing on localhost and the other pc, in about equal proportion. No node has crashed/restarted. None of the nodes does anything fancy, simply net_adm:ping to connect the nodes and then data is exchanged using messages. The problem seems somewhat related to the fact that epmd seems to restart from time to time as the OS gets confused and cannot retrieve the PID that originally opened the sockets (although port shows it is epmd) I briefly looked at the epmd code and did see a few comments in there about // should probably always close and a few other potential places where it might leak sockets. Unfortunately I ran out of time. Can anyone confirm if they see similar behavior? Note that on both computers, both nodes are started manually (not automated yet) and as such it isn't a race to see which node can start epmd first. Although, I wonder if it might be related to the problem of the epmd 100% cpu use, I believe another poster made the point that it would happen when epmd runs out of file descriptor (which would happen if it leaks sockets in TIME_WAIT). On Mon, Mar 15, 2010 at 2:53 PM, Nicholas Frechette wrote: > Hi, > I recently started running 2 erlang applications in distributed mode (with > -sname) on the same box. > I am noticing now (doing netstat -t) that a _LOT_ of ports are left open at > 4369 (the port used by epmd) on my ubuntu 9.10 box. > > In fact, of all active connections, 90%+ of my open ports will be > localhost:4369 -> culpritbox:randomport. > All are stuck in TIME_WAIT > > Any idea what could be causing this? I use a different computer to do my > development and I see a similar pattern emerging (again ubuntu 9.10). > > My erlang version is R13B01. > > Here is an example output of `netstat -t` (note that even with -p, netstat > doesn't display a program name for those ports). Any ideas? > > Active Internet connections (w/o servers) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 mercury:4369 mercury:49448 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:45420 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:41234 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:35179 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:44567 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:45846 > TIME_WAIT > tcp 0 0 localhost:4369 localhost:33424 > ESTABLISHED > tcp 0 0 mercury:4369 mercury:38486 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:38624 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:44724 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:44398 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:47189 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:45306 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:36997 > TIME_WAIT > tcp 0 0 localhost:48762 localhost:4369 > ESTABLISHED > tcp 0 0 mercury:4369 mercury:38627 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:37665 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:48427 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:57916 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:51098 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:55867 > TIME_WAIT > * something else > * something else > tcp 0 0 mercury:4369 mercury:36005 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:46053 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:35974 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:42211 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:33363 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:53662 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:37094 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:43824 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:51092 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:43258 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:43064 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:37111 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:54677 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:44286 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:49718 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:46809 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:46112 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:48825 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:44124 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:45203 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:51149 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:46636 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:48254 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:49424 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:59976 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:46730 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:44890 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:39385 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:57297 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:37066 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:50186 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:45703 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:42943 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:55328 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:44401 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:45791 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:56537 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:42194 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:33216 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:46544 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:47610 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:52892 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:38877 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:50983 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:45376 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:54394 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:45412 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:36546 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:32776 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:38289 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:35126 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:50964 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:47857 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:55772 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:41209 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:41426 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:52887 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:33961 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:58946 > TIME_WAIT > tcp 0 0 localhost:33424 localhost:4369 > ESTABLISHED > tcp 0 0 mercury:4369 mercury:46272 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:58219 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:60676 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:37091 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:34972 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:53706 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:52788 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:53221 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:57241 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:56398 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:40434 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:43636 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:41792 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:53162 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:41266 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:36990 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:37871 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:40089 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:58028 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:40347 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:55445 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:56130 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:37858 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:53709 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:45924 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:56969 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:33933 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:51305 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:53452 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:35840 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:49678 > TIME_WAIT > * something else > tcp 0 0 mercury:4369 mercury:57573 > TIME_WAIT > tcp 0 0 localhost:4369 localhost:48762 > ESTABLISHED > tcp 0 0 mercury:4369 mercury:46680 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:41095 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:44073 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:43461 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:39410 > TIME_WAIT > tcp 0 0 mercury:4369 mercury:38881 > TIME_WAIT > > From michael.santos@REDACTED Mon Mar 22 16:45:37 2010 From: michael.santos@REDACTED (Michael Santos) Date: Mon, 22 Mar 2010 11:45:37 -0400 Subject: [erlang-bugs] Re: [erlang-questions] epmd leaving ports in TIME_WAIT? In-Reply-To: References: Message-ID: <20100322154537.GB28937@ecn.lan> On Mon, Mar 22, 2010 at 11:17:25AM -0400, Nicholas Frechette wrote: > Escalating to erlang-bugs. > I've restarted both my server and laptop over the weekend. > On both machines, I restarted my 2 erlang applications (4 nodes, connected > in pairs: A <-> B, C <-> D, with pairs on the same computer) > > This was yesterday. This morning I did another netstat -t, and indeed, I > have >100 sockets stuck in TIME_WAIT on both computers. Sockets in TIME_WAIT state are normal. After the socket is closed, the OS puts the socket into TIME_WAIT to ensure any pending packets queued somewhere in the network for the socket pair have time to arrive. Usually TIME_WAIT is 2 or 4 minutes. It looks as if there a is a number of TCP connections that are being established and closed to your epmd. > Both with outgoing > on localhost and the other pc, in about equal proportion. > No node has crashed/restarted. None of the nodes does anything fancy, simply > net_adm:ping to connect the nodes and then data is exchanged using messages. > > The problem seems somewhat related to the fact that epmd seems to restart > from time to time as the OS gets confused and cannot retrieve the PID that > originally opened the sockets (although port shows it is epmd) What is restarting epmd? See anything in your logs? Maybe try running epmd in debug mode. Kill epmd if it is running and run: epmd -d > I briefly looked at the epmd code and did see a few comments in there about > // should probably always close and a few other potential places where it > might leak sockets. Unfortunately I ran out of time. Doesn't appear to be leaking fd's, but you can check with lsof. > Can anyone confirm if they see similar behavior? Note that on both > computers, both nodes are started manually (not automated yet) and as such > it isn't a race to see which node can start epmd first. Although, I wonder > if it might be related to the problem of the epmd 100% cpu use, I believe > another poster made the point that it would happen when epmd runs out of > file descriptor (which would happen if it leaks sockets in TIME_WAIT). That's just one error condition; for example, the connection could have been aborted or the socket could have been closed. Are you seeing a lot of CPU usage? From vlm@REDACTED Mon Mar 22 21:12:32 2010 From: vlm@REDACTED (Lev Walkin) Date: Mon, 22 Mar 2010 13:12:32 -0700 Subject: http:request memory leak in R12B04 Message-ID: <484B8939-A4BD-4F95-986B-973C82F84D54@lionet.info> Hi, The R12B04 release brought a reliable memory leak to http:request that was never in there before. Here's how it manifests itself: ======================== Erlang R13B04 (erts-5.7.5) [source] [rq:1] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.7.5 (abort with ^G) 1> inets:start(). ok 2> http:request("http://google.com/nonexistent"), [S || S = {size, _} <- ets:info(httpc_manager__handler_db)]. [{size,1}] 3> http:request("http://google.com/nonexistent"), [S || S = {size, _} <- ets:info(httpc_manager__handler_db)]. [{size,2}] 4> http:request("http://google.com/nonexistent"), [S || S = {size, _} <- ets:info(httpc_manager__handler_db)]. [{size,3}] 5> a=b. ** exception error: no match of right hand side value b 6> http:request("http://google.com/nonexistent"), [S || S = {size, _} <- ets:info(httpc_manager__handler_db)]. [{size,4}] 7> ======================== After a few (million) requests this stuff eats all available memory. I suppose this is not the intended behavior for the http module. Here's the cure: === --- ./httpc_handler.erl.orig 2010-03-22 12:34:07.000000000 +0300 +++ ./httpc_handler.erl 2010-03-22 16:50:34.000000000 +0300 @@ -1407,7 +1407,7 @@ State#state{status = close} end. -answer_request(Request, Msg, #state{timers = Timers} = State) -> +answer_request(Request, Msg, #state{timers = Timers, profile_name = ProfileName} = State) -> ?hcrt("answer request", [{request, Request}]), httpc_response:send(Request#request.from, Msg), RequestTimers = Timers#timers.request_timers, @@ -1415,6 +1415,7 @@ proplists:get_value(Request#request.id, RequestTimers, undefined), Timer = {Request#request.id, TimerRef}, cancel_timer(TimerRef, {timeout, Request#request.id}), + httpc_manager:request_done(Request#request.id, ProfileName), State#state{request = Request#request{from = answer_sent}, timers = Timers#timers{request_timers = --- ./httpc_manager.erl.orig 2010-03-22 12:36:58.000000000 +0300 +++ ./httpc_manager.erl 2010-03-22 16:50:46.000000000 +0300 @@ -30,6 +30,7 @@ request/2, cancel_request/2, request_canceled/2, + request_done/2, retry_request/2, redirect_request/2, insert_session/2, @@ -169,6 +170,9 @@ request_canceled(RequestId, ProfileName) -> cast(ProfileName, {request_canceled, RequestId}). +request_done(RequestId, ProfileName) -> + cast(ProfileName, {request_done, RequestId}). + %%-------------------------------------------------------------------- %% Function: insert_session(Session, ProfileName) -> _ @@ -486,6 +490,10 @@ {noreply, State} end; +handle_cast({request_done, RequestId}, State) -> + ets:delete(State#state.handler_db, RequestId), + {noreply, State}; + handle_cast({set_options, Options}, State = #state{options = OldOptions}) -> ?hcrv("set options", [{options, Options}, {old_options, OldOptions}]), NewOptions = === -- vlm From zeno490@REDACTED Tue Mar 23 18:15:18 2010 From: zeno490@REDACTED (Nicholas Frechette) Date: Tue, 23 Mar 2010 13:15:18 -0400 Subject: [erlang-bugs] Re: [erlang-questions] epmd leaving ports in TIME_WAIT? In-Reply-To: <20100322154537.GB28937@ecn.lan> References: <20100322154537.GB28937@ecn.lan> Message-ID: Hi, I did as you suggested and ran epmd -d. It ends up outputting something like: epmd: Tue Mar 23 09:26:39 2010: ** sent PORT2_RESP (error) for "rodc10" epmd: Tue Mar 23 09:26:40 2010: ** got PORT2_REQ Over and over. This is because one of my nodes pings (net_adm:ping) a node that doesn't exist from time to time. (Every couple seconds or so) Also, when epmd dies, the ports are closed properly. In any case, I find it surprising that epmd has to open so many sockets to ask around if someone has seen the missing node. On Mon, Mar 22, 2010 at 11:45 AM, Michael Santos wrote: > On Mon, Mar 22, 2010 at 11:17:25AM -0400, Nicholas Frechette wrote: > > Escalating to erlang-bugs. > > I've restarted both my server and laptop over the weekend. > > On both machines, I restarted my 2 erlang applications (4 nodes, > connected > > in pairs: A <-> B, C <-> D, with pairs on the same computer) > > > > This was yesterday. This morning I did another netstat -t, and indeed, I > > have >100 sockets stuck in TIME_WAIT on both computers. > > Sockets in TIME_WAIT state are normal. After the socket is closed, > the OS puts the socket into TIME_WAIT to ensure any pending packets > queued somewhere in the network for the socket pair have time to arrive. > Usually TIME_WAIT is 2 or 4 minutes. > > It looks as if there a is a number of TCP connections that are being > established and closed to your epmd. > > > Both with outgoing > > on localhost and the other pc, in about equal proportion. > > No node has crashed/restarted. None of the nodes does anything fancy, > simply > > net_adm:ping to connect the nodes and then data is exchanged using > messages. > > > > The problem seems somewhat related to the fact that epmd seems to restart > > from time to time as the OS gets confused and cannot retrieve the PID > that > > originally opened the sockets (although port shows it is epmd) > > What is restarting epmd? > > See anything in your logs? Maybe try running epmd in debug mode. Kill > epmd if it is running and run: epmd -d > > > I briefly looked at the epmd code and did see a few comments in there > about > > // should probably always close and a few other potential places where it > > might leak sockets. Unfortunately I ran out of time. > > Doesn't appear to be leaking fd's, but you can check with lsof. > > > Can anyone confirm if they see similar behavior? Note that on both > > computers, both nodes are started manually (not automated yet) and as > such > > it isn't a race to see which node can start epmd first. Although, I > wonder > > if it might be related to the problem of the epmd 100% cpu use, I believe > > another poster made the point that it would happen when epmd runs out of > > file descriptor (which would happen if it leaks sockets in TIME_WAIT). > > That's just one error condition; for example, the connection could have > been aborted or the socket could have been closed. Are you seeing a lot > of CPU usage? > > > From andrew@REDACTED Tue Mar 23 19:04:32 2010 From: andrew@REDACTED (Andrew Thompson) Date: Tue, 23 Mar 2010 14:04:32 -0400 Subject: Segfault in B_plus_minus beam/big.c:517 in R14B04 Message-ID: <20100323180432.GA12072@hijacked.us> I'm not sure what I need to provide to help figure this out, but I had my erlang VM coredump yesterday. Luckily I had enabled corefile generation, so I obtained a core file. Attached is the output of running a bt full on the thread I think caused the seg. If any more information would be helpful, let me know. This is a ubuntu-server install running amd64 and I built erlang from source myself. Andrew -------------- next part -------------- Script started on Tue Mar 23 13:58:00 2010 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/local/lib/erlang/lib/crypto-1.6.4/priv/lib/crypto_drv.so...done. Loaded symbols for /usr/local/lib/erlang/lib/crypto-1.6.4/priv/lib/crypto_drv.so Reading symbols from /usr/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib64/libcrypto.so.0.9.8 Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /usr/local/lib/erlang/lib/iconv-1.0/priv/iconv_drv.so...done. Loaded symbols for /usr/local/lib/erlang/lib/iconv-1.0/priv/iconv_drv.so Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Core was generated by `/usr/local/lib/erlang/erts-5.7.5/bin/beam.smp -K true -- -root /usr/local/lib/e'. Program terminated with signal 11, Segmentation fault. [New process 2914] [New process 2910] [New process 2892] [New process 2912] [New process 2913] [New process 2911] #0 B_plus_minus (x=0x7fe7227dddc8, xl=1, xsgn=0, y=0x7fe715137448, yl=0, ysgn=, r=0x7fe715137448) at beam/big.c:517 517 xr = *x++; (gdb) bt full #0 B_plus_minus (x=0x7fe7227dddc8, xl=1, xsgn=0, y=0x7fe715137448, yl=0, ysgn=, r=0x7fe715137448) at beam/big.c:517 No locals. #1 0x00000000004ece7f in big_plus (x=, y=1873727406551102227, r=) at beam/big.c:1922 No locals. #2 0x00000000004b14b4 in erts_gc_mixed_plus (p=0x7fe71760b378, reg=0x7fe7241e1978, live=1) at beam/erl_arith.c:1249 arg1 = 140630692847042 arg2 = 140630467769410 tmp_big1 = {72, 287} tmp_big2 = {140630692846864, 140630692847008} res = hdr = f1 = {fd = 6.948070196272688e-310, fb = "x?`\027?\177\000", fs = {45944, 5984, 32743, 0}, fw = {392213368, 32743}, fdw = 140630506386296} f2 = {fd = 6.9480794086511548e-310, fb = "@?}\"?\177\000", fs = {56640, 8829, 32743, 0}, fw = {578673984, 32743}, fdw = 140630692846912} need_heap = -583 ires = #3 0x000000000051cfe4 in process_main () at beam/beam_emu.c:2260 live = 1 c_p = (Process *) 0x7fe71760b378 reds_used = 605952376 x0 = 140630467769410 reg = (Eterm *) 0x7fe7241e1978 HTOP = (Eterm *) 0x7fe715137448 E = (Eterm *) 0x7fe71513f228 I = (Eterm *) 0x7fe71833d148 FCALLS = 1585 tmp_arg1 = 4607 tmp_arg2 = 140630467769410 tmp_big = {8, 8535072} freg = (FloatDef *) 0x7fe7241e3988 neg_o_reds = 0 arith_func = (Eterm (*)(Process *, Eterm *, Uint)) 0x1a00d12619647313 temp_bits = 140630720125304 EBS = (struct erl_bits_state *) 0x7fe7241e5990 init_done = 1 opcodes = {0x51f48f, 0x51f6ac, 0x51f5e4, 0x51f52e, 0x51f3d1, 0x51cc7e, 0x51da55, 0x51cc13, 0x522860, 0x51dbec, 0x51fdb1, 0x51fd36, 0x51b65f, 0x51b5fb, 0x51b64d, 0x51d468, 0x51d56b, 0x51bc2b, 0x51bbfc, 0x51bbd0, 0x51bb9c, 0x51bb7a, 0x51bb4d, 0x51bc77, 0x51bc4f, 0x51ff19, 0x51d393, 0x51d2a0, 0x51d0b1, 0x51e4d9, 0x51dae6, 0x51bfb3, 0x51eb7e, 0x51edf1, 0x51ed38, 0x51e464, 0x51bfef, 0x51f3c1, 0x51aaf3, 0x51f2a3, 0x51f27a, 0x51f388, 0x51f351, 0x51f310, 0x51f2d1, 0x51c590, 0x51c5b2, 0x51c6ba, 0x51c674, 0x51c625, 0x51f245, 0x51f215, 0x51f1e9, 0x51f1b1, 0x51ac7d, 0x521d9e, 0x521d66, 0x521d33, 0x521cfc, 0x521cc5, 0x521c8d, 0x521c3f, 0x521bf1, 0x521bb9, 0x521b6b, 0x521b22, 0x521aeb, 0x521ab9, 0x521a81, 0x521a38, 0x5219ef, 0x5219bc, 0x521973, 0x52192f, 0x51de79, 0x51dfd8, 0x51dfb8, 0x51e60b, 0x51dfae, 0x51dee0, 0x51cdb4, 0x51cbac, 0x51e2f0, 0x51e294, 0x51cd43, 0x51cce8, 0x51d056, 0x51feb6, 0x51fe65, 0x51d1bd, 0x51d590, 0x51d4e2, 0x51d71e, 0x51d660, 0x51d705, 0x51b2ff, 0x51b215, 0x51b088, 0x51b14d, 0x51b5e6, 0x51b53a, 0x51afd4, 0x51af18, 0x51ae28, 0x51ad46, 0x51b754, 0x51ba9d, 0x51b9e6, 0x51b945, 0x51ba7c, 0x51bb3b, 0x51bab2, 0x51b936, 0x51b8c9, 0x51b8a7, 0x51b838, 0x51b6d3, 0x51b672, 0x51b742, 0x51b6e5, 0x51d81f, 0x51ece2, 0x51ecc1, 0x51e698, 0x51e7ce, 0x51eccd, 0x51eced, 0x51e65a, 0x51d984, 0x51da20, 0x51e67b, 0x51d9f3, 0x51d730, 0x51d7f4, 0x51b528, 0x51b47d, 0x51d494, 0x51be5a, 0x51befc, 0x51b40c, 0x51b3e1, 0x51b45a, 0x51b42f, 0x51acb5, 0x522059, 0x521fc6, 0x521f32, 0x521e9e, 0x521e67, 0x521e28, 0x521df9, 0x521dc5, 0x51bda2, 0x51bd84, 0x51bc9a, 0x51bea1, 0x51bf3f, 0x51bdf6, 0x51bdb4, 0x5221a6, 0x51ce94, 0x51cf88, 0x51a950, 0x51a8e1, 0x51a915, 0x51a8b4, 0x51e228, 0x51e1be, 0x51a980, 0x51aa66, 0x51cb37, 0x51dcd5, 0x51ee90, 0x51c532, 0x51ee0f, 0x51c562, 0x51dc75, 0x52184a, 0x521823, 0x5217cc, 0x521794, 0x52175c, 0x52170f, 0x5216d7, 0x5216a4, 0x521876, 0x5217f8, 0x521736, 0x5218ea, 0x5218bf, 0x521899, 0x52190d, 0x52210f, 0x51dca5, 0x51dc42, 0x51c502, 0x51eb4e, 0x51fc89, 0x51ec23, 0x5220e5...} #4 0x0000000000499aab in sched_thread_func (vesdp=) at beam/erl_process.c:3060 No locals. #5 0x0000000000594a6b in thr_wrapper (vtwd=) at common/ethread.c:475 res = twd = (thr_wrap_data_ *) 0x7fff7205eec0 thr_func = (void *(*)(void *)) 0x499a20 ---Type to continue, or q to quit--- arg = (void *) 0x7fe7241e1978 #6 0x00007fe7248653ba in start_thread () from /lib/libpthread.so.0 No symbol table info available. #7 0x00007fe7243c9fcd in clone () from /lib/libc.so.6 No symbol table info available. #8 0x0000000000000000 in ?? () No symbol table info available. (gdb) info threads 6 process 2911 0x00007fe7248692e9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 process 2913 0x00007fe7248692e9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 process 2912 0x00007fe7248692e9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 2892 0x00007fe7243c2742 in select () from /lib/libc.so.6 2 process 2910 0x00007fe72486bedb in read () from /lib/libpthread.so.0 * 1 process 2914 B_plus_minus (x=0x7fe7227dddc8, xl=1, xsgn=0, y=0x7fe715137448, yl=0, ysgn=, r=0x7fe715137448) at beam/big.c:517 (gdb) q Script done on Tue Mar 23 13:58:19 2010 From michael.santos@REDACTED Tue Mar 23 22:04:03 2010 From: michael.santos@REDACTED (Michael Santos) Date: Tue, 23 Mar 2010 17:04:03 -0400 Subject: [erlang-bugs] Re: [erlang-questions] epmd leaving ports in TIME_WAIT? In-Reply-To: References: <20100322154537.GB28937@ecn.lan> Message-ID: <20100323210403.GA32441@ecn.lan> On Tue, Mar 23, 2010 at 01:15:18PM -0400, Nicholas Frechette wrote: > Hi, > I did as you suggested and ran epmd -d. > It ends up outputting something like: > epmd: Tue Mar 23 09:26:39 2010: ** sent PORT2_RESP (error) for "rodc10" > epmd: Tue Mar 23 09:26:40 2010: ** got PORT2_REQ > > Over and over. > This is because one of my nodes pings (net_adm:ping) a node that doesn't > exist from time to time. (Every couple seconds or so) Right, so every time the node connects and disconnects the TCP session will go into TIME_WAIT. > Also, when epmd dies, the ports are closed properly. In any case, I find it > surprising that epmd has to open so many sockets to ask around if someone > has seen the missing node. 1> [ begin {ok,S} = gen_tcp:connect({127,0,0,1},4369,[]), ok = gen_tcp:close(S) end || _ <- lists:seq(1,10000) ]. That will generate 10,000 sessions in TIME_WAIT :) I guess the question is why your nodes keep disappearing from the network. > On Mon, Mar 22, 2010 at 11:45 AM, Michael Santos > wrote: > > > On Mon, Mar 22, 2010 at 11:17:25AM -0400, Nicholas Frechette wrote: > > > Escalating to erlang-bugs. > > > I've restarted both my server and laptop over the weekend. > > > On both machines, I restarted my 2 erlang applications (4 nodes, > > connected > > > in pairs: A <-> B, C <-> D, with pairs on the same computer) > > > > > > This was yesterday. This morning I did another netstat -t, and indeed, I > > > have >100 sockets stuck in TIME_WAIT on both computers. > > > > Sockets in TIME_WAIT state are normal. After the socket is closed, > > the OS puts the socket into TIME_WAIT to ensure any pending packets > > queued somewhere in the network for the socket pair have time to arrive. > > Usually TIME_WAIT is 2 or 4 minutes. > > > > It looks as if there a is a number of TCP connections that are being > > established and closed to your epmd. > > > > > Both with outgoing > > > on localhost and the other pc, in about equal proportion. > > > No node has crashed/restarted. None of the nodes does anything fancy, > > simply > > > net_adm:ping to connect the nodes and then data is exchanged using > > messages. > > > > > > The problem seems somewhat related to the fact that epmd seems to restart > > > from time to time as the OS gets confused and cannot retrieve the PID > > that > > > originally opened the sockets (although port shows it is epmd) > > > > What is restarting epmd? > > > > See anything in your logs? Maybe try running epmd in debug mode. Kill > > epmd if it is running and run: epmd -d > > > > > I briefly looked at the epmd code and did see a few comments in there > > about > > > // should probably always close and a few other potential places where it > > > might leak sockets. Unfortunately I ran out of time. > > > > Doesn't appear to be leaking fd's, but you can check with lsof. > > > > > Can anyone confirm if they see similar behavior? Note that on both > > > computers, both nodes are started manually (not automated yet) and as > > such > > > it isn't a race to see which node can start epmd first. Although, I > > wonder > > > if it might be related to the problem of the epmd 100% cpu use, I believe > > > another poster made the point that it would happen when epmd runs out of > > > file descriptor (which would happen if it leaks sockets in TIME_WAIT). > > > > That's just one error condition; for example, the connection could have > > been aborted or the socket could have been closed. Are you seeing a lot > > of CPU usage? > > > > > > From zeno490@REDACTED Tue Mar 23 23:43:37 2010 From: zeno490@REDACTED (Nicholas Frechette) Date: Tue, 23 Mar 2010 18:43:37 -0400 Subject: [erlang-bugs] Re: [erlang-questions] epmd leaving ports in TIME_WAIT? In-Reply-To: <20100323210403.GA32441@ecn.lan> References: <20100322154537.GB28937@ecn.lan> <20100323210403.GA32441@ecn.lan> Message-ID: Yes, I know why my node isn't 'up', my question is why is epmd opening a socket to query if a node is up? ie: what does it attempt to connect to? Said node was never up in epmd's lifetime meaning it shouldn't be a cached value or the likes. Supposing it connects to my other epmd process on my other computer, why would it not keep it as a permanent tcp connection? It also attemps to connect to ports on the same host, not just the other computer so i'm a bit curious. Is epmd implemented as a soap over an http like protocol where queries are made over single use socket connections? On Tue, Mar 23, 2010 at 5:04 PM, Michael Santos wrote: > On Tue, Mar 23, 2010 at 01:15:18PM -0400, Nicholas Frechette wrote: > > Hi, > > I did as you suggested and ran epmd -d. > > It ends up outputting something like: > > epmd: Tue Mar 23 09:26:39 2010: ** sent PORT2_RESP (error) for "rodc10" > > epmd: Tue Mar 23 09:26:40 2010: ** got PORT2_REQ > > > > Over and over. > > This is because one of my nodes pings (net_adm:ping) a node that doesn't > > exist from time to time. (Every couple seconds or so) > > Right, so every time the node connects and disconnects the TCP session > will go into TIME_WAIT. > > > Also, when epmd dies, the ports are closed properly. In any case, I find > it > > surprising that epmd has to open so many sockets to ask around if someone > > has seen the missing node. > > 1> [ begin {ok,S} = gen_tcp:connect({127,0,0,1},4369,[]), ok = > gen_tcp:close(S) end || _ <- lists:seq(1,10000) ]. > > That will generate 10,000 sessions in TIME_WAIT :) I guess the question > is why your nodes keep disappearing from the network. > > > On Mon, Mar 22, 2010 at 11:45 AM, Michael Santos > > wrote: > > > > > On Mon, Mar 22, 2010 at 11:17:25AM -0400, Nicholas Frechette wrote: > > > > Escalating to erlang-bugs. > > > > I've restarted both my server and laptop over the weekend. > > > > On both machines, I restarted my 2 erlang applications (4 nodes, > > > connected > > > > in pairs: A <-> B, C <-> D, with pairs on the same computer) > > > > > > > > This was yesterday. This morning I did another netstat -t, and > indeed, I > > > > have >100 sockets stuck in TIME_WAIT on both computers. > > > > > > Sockets in TIME_WAIT state are normal. After the socket is closed, > > > the OS puts the socket into TIME_WAIT to ensure any pending packets > > > queued somewhere in the network for the socket pair have time to > arrive. > > > Usually TIME_WAIT is 2 or 4 minutes. > > > > > > It looks as if there a is a number of TCP connections that are being > > > established and closed to your epmd. > > > > > > > Both with outgoing > > > > on localhost and the other pc, in about equal proportion. > > > > No node has crashed/restarted. None of the nodes does anything fancy, > > > simply > > > > net_adm:ping to connect the nodes and then data is exchanged using > > > messages. > > > > > > > > The problem seems somewhat related to the fact that epmd seems to > restart > > > > from time to time as the OS gets confused and cannot retrieve the PID > > > that > > > > originally opened the sockets (although port shows it is epmd) > > > > > > What is restarting epmd? > > > > > > See anything in your logs? Maybe try running epmd in debug mode. Kill > > > epmd if it is running and run: epmd -d > > > > > > > I briefly looked at the epmd code and did see a few comments in there > > > about > > > > // should probably always close and a few other potential places > where it > > > > might leak sockets. Unfortunately I ran out of time. > > > > > > Doesn't appear to be leaking fd's, but you can check with lsof. > > > > > > > Can anyone confirm if they see similar behavior? Note that on both > > > > computers, both nodes are started manually (not automated yet) and as > > > such > > > > it isn't a race to see which node can start epmd first. Although, I > > > wonder > > > > if it might be related to the problem of the epmd 100% cpu use, I > believe > > > > another poster made the point that it would happen when epmd runs out > of > > > > file descriptor (which would happen if it leaks sockets in > TIME_WAIT). > > > > > > That's just one error condition; for example, the connection could have > > > been aborted or the socket could have been closed. Are you seeing a lot > > > of CPU usage? > > > > > > > > > > From steven.charles.davis@REDACTED Wed Mar 24 02:21:01 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Tue, 23 Mar 2010 20:21:01 -0500 Subject: Phased start behaviour on error Message-ID: <4BA968FD.7040802@gmail.com> When a start phase errors out, it leaves things in an inconsistent state.... boiling this down to the minimum: --- %%phased.app {application, phased, [ {description, "Unexpected behaviour"}, {vsn, "1.0"}, {applications, [kernel, stdlib]}, {mod, {phased, []}}, {start_phases, [ {first, []}, {second, []} ]}, {env, []} ]}. --- %% phased.erl -module(phased). -behaviour(application). -export([start/2, start_phase/3, config_change/3, prep_stop/1, stop/ 1]). -behaviour(supervisor). -export([init/1]). start(normal, []) -> io:format("start~n"), supervisor:start_link({local, phased_sup}, ?MODULE, []). start_phase(first, normal, []) -> io:format("start_phase: first~n"), ok; start_phase(second, normal, []) -> io:format("start_phase: second~n"), {error, intentional}. config_change(_, _, _) -> ok. prep_stop(State) -> State. stop(_State) -> ok. init([]) -> {ok, {{one_for_all, 0, 1}, []}}. --- Note that I'm intentionally failing phase 2 of the startup process... here's the console session: 4> application:start(phased). start start_phase: first start_phase: second =INFO REPORT==== 23-Mar-2010::04:11:25 === application: phased exited: {intentional,{phased,start_phase,[second,normal,[]]}} type: temporary {error,{intentional,{phased,start_phase, [second,normal,[]]}}} 5> application:which_applications(). [{stdlib,"ERTS CXC 138 10","1.16.5"}, {kernel,"ERTS CXC 138 10","2.13.5"}] 6> application:start(phased). start =INFO REPORT==== 23-Mar-2010::04:11:49 === application: phased exited: {{already_started,<0.45.0>},{phased,start,[normal,[]]}} type: temporary {error,{{already_started,<0.45.0>}, {phased,start,[normal,[]]}}} 7> application:stop(phased). {error,{not_started,phased}} 8> registered(). [global_group,init,erl_prim_loader,user,error_logger,rex, standard_error_sup,kernel_sup,global_name_server,inet_db, file_server_2,code_server,user_drv,phased_sup, standard_error,application_controller,kernel_safe_sup] Note that although the application is not started, it cannot be started, and since the sup (and, in fact, any child processes started by the sup) are still running. /s From michael.santos@REDACTED Thu Mar 25 01:25:03 2010 From: michael.santos@REDACTED (Michael Santos) Date: Wed, 24 Mar 2010 20:25:03 -0400 Subject: [erlang-bugs] Re: [erlang-questions] epmd leaving ports in TIME_WAIT? In-Reply-To: References: <20100322154537.GB28937@ecn.lan> <20100323210403.GA32441@ecn.lan> Message-ID: <20100325002503.GB1910@ecn.lan> On Tue, Mar 23, 2010 at 06:43:37PM -0400, Nicholas Frechette wrote: > Yes, I know why my node isn't 'up', my question is why is epmd opening a > socket to query if a node is up? ie: what does it attempt to connect to? epmd isn't opening the connection, a distributed erlang node is querying if a node exists on that host and the port it should connect to for that node. epmd maps local erlang nodes to a port. > Said node was never up in epmd's lifetime meaning it shouldn't be a cached > value or the likes. Supposing it connects to my other epmd process on my > other computer, why would it not keep it as a permanent tcp connection? It > also attemps to connect to ports on the same host, not just the other > computer so i'm a bit curious. > Is epmd implemented as a soap over an http like protocol where queries are > made over single use socket connections? When an erlang node is brought up as a distributed node, it connects to the local epmd with a persistent TCP connection. If the node dies, the TCP connection is closed and epmd deregisters the node (the atom that identifies the node). Queries to epmd about which registered nodes exist on a host are carried out in a single TCP transaction. See the comments in epmd_srv.c and: http://www.erlang.org/doc/apps/erts/erl_dist_protocol.html epmd_srv.c: * To keep track of when registered Erlang nodes are terminated this * server keeps the socket open where the request for registration was * made. * In all but one case there is only one request for each connection made * to this server so we can safely close the socket after sending the * reply. The exception is ALIVE_REQ where we keep the connection * open without sending any data. When we receive a "close" this is * an indication that the Erlang node was terminated. The termination * may have been "normal" or caused by a crash. The operating system * ensure that the connection is closed either way. From zerthurd@REDACTED Thu Mar 25 05:51:42 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Thu, 25 Mar 2010 10:51:42 +0600 Subject: [erlang-bugs] Dialyzer does not recognize erlang:list_to_integer/2 Message-ID: Hello Dialyzer prints out warning that erlang:list_to_integer/2 is Unknown. [zert@REDACTED]:/tmp $>> cat tt.erl -module(tt). -compile([export_all]). hex2i("0x" ++ L) -> erlang:list_to_integer(L, 16). [zert@REDACTED]:/tmp $>> erlc +debug_info tt.erl [zert@REDACTED]:/tmp $>> erl Erlang R13B04 (erts-5.7.5) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.7.5 (abort with ^G) 1> tt:hex2i("0x123"). 291 2> User switch command --> q [zert@REDACTED]:/tmp $>> dialyzer tt.beam Checking whether the PLT /home/zert/.dialyzer_plt is up-to-date... yes Proceeding with analysis... Unknown functions: erlang:list_to_integer/2 done in 0m3.19s done (passed successfully) -- Maxim Treskin From kostis@REDACTED Thu Mar 25 08:20:46 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 25 Mar 2010 09:20:46 +0200 Subject: [erlang-bugs] Dialyzer does not recognize erlang:list_to_integer/2 In-Reply-To: References: Message-ID: <4BAB0ECE.3010509@cs.ntua.gr> Maxim Treskin wrote: > Hello > > Dialyzer prints out warning that erlang:list_to_integer/2 is Unknown. Thanks for noticing this omission. A fix will appear in R14 and soon in the git dev branch. Kostis From zerthurd@REDACTED Fri Mar 26 08:01:26 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Fri, 26 Mar 2010 13:01:26 +0600 Subject: [erlang-bugs] Wrong emacs indentation of records with defined types Message-ID: Hello When I write record definition without member type, emacs has correct indentation: 
-record(state, {
          sequence_number = 1
         }).
But when I put type definition, it looks like: 
-record(state, {
          sequence_number = 1          :: integer()
                                                       }).
-- Maxim Treskin From sverker@REDACTED Mon Mar 29 10:48:38 2010 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 29 Mar 2010 10:48:38 +0200 Subject: [erlang-bugs] [BUG] erlang:decode_packet/3 generates corrupt header names with httph_bin In-Reply-To: References: Message-ID: <4BB06966.9080905@erix.ericsson.se> Fix included in pu branch: http://github.com/erlang/otp/commit/e7ab3b456ad489bc284153ed79105d3a8d17cafd Seems like the necessary conditions for provoking the bug are: erlang:decode_packet (not packet option for sockets), httph_bin, an unknown header string of length 16 to 20 characters and a 32-bit emulator. Thanks for reporting Will. /Sverker, Erlang/OTP Ericsson Will wrote: > Hello, > > erlang:decode_packet/3 generates strange corrupted header names for > unknown header types when using the httph_bin option. The cause seems > related to the length of the header name, short ones work fine. > > Test Case: > > test() -> > B = << > "X-Transaction: 1269062039-39495-905\r\n" > "X-RateLimit-Limit: 150\r\n" > "Content-Type: application/json; charset=utf-8\r\n" > "X-Foo: bar\r\n" > "\r\n" > >>, > {ok, Headers, Rest} = decode_headers(B, []), > io:format("HEADERS:~n~p~n", [Headers]), > io:format("REST:~n~p~n", [Rest]). > > decode_headers(Bin, Acc) -> > case erlang:decode_packet(httph_bin, Bin, []) of > {ok, {http_header, _N, _Name, _, _V} = H, Rest} -> > decode_headers(Rest, [H | Acc]); > {ok, http_eoh, Rest} -> > {ok, Acc, Rest} > end. > > Result: > > Erlang R13B04 (erts-5.7.5) [source] [smp:2:2] [rq:2] [async-threads:0] > [hipe] [kernel-poll:false] > > HEADERS: > [{http_header,0,<<"X-Foo">>,undefined,<<"bar">>}, > {http_header,42,'Content-Type',undefined, > <<"application/json; charset=utf-8">>}, > {http_header,0, > <<88,45,70,111,111,50,14,0,64,190,14,1,10,0,0,0,14>>, > undefined,<<"150">>}, > {http_header,0, > <<88,45,70,111,111,50,14,0,64,190,14,1,10>>, > undefined,<<"1269062039-39495-905">>}] > REST: > <<>> > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > >