From mikpelinux@REDACTED Sat Feb 1 16:34:00 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 1 Feb 2014 16:34:00 +0100 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <52EBDB74.5040308@erix.ericsson.se> References: <52EB9DFB.4090503@softlab.ntua.gr> <52EBDB74.5040308@erix.ericsson.se> Message-ID: <21229.5096.904706.927656@gargle.gargle.HOWL> Sverker Eriksson writes: > On 01/31/2014 01:58 PM, Yiannis Tsiouris wrote: > > Hey, > > > > While trying to locate a bug in our x86 backend that caused a segfault > > at load-time, we came at something that we think is a bug in the final > > address calculation. In functions hipe_patch_load_fe and > > hipe_patch_insn in erts/emulator/hipe/hipe_x86.c file we think that > > the final address should always be calculated as the sum of "address" > > and "value". We base this on our observation that "address" seems to > > be the offset and "value" seems to be the base address. > > > > The patch that works for us is attached. > > > > If any developer can confirm that this is a bug (and that the patch is > > the correct way to fix it) I can submit it properly (if needed). :-) > > > > Thanks, > > Yiannis (as member of the ErLLVM team) > > > > Thank for the patch, Yiannis > > (comments below) > > diff --git a/erts/emulator/hipe/hipe_x86.c b/erts/emulator/hipe/hipe_x86.c > index 327c74e..6c233cb 100644 > --- a/erts/emulator/hipe/hipe_x86.c > +++ b/erts/emulator/hipe/hipe_x86.c > @@ -36,7 +36,7 @@ > void hipe_patch_load_fe(Uint32 *address, Uint32 value) > { > /* address points to a disp32 or imm32 operand */ > - *address = value; > + *address += value; > } > > int hipe_patch_insn(void *address, Uint32 value, Eterm type) > @@ -46,14 +46,12 @@ int hipe_patch_insn(void *address, Uint32 value, > Eterm type) > case am_constant: > case am_atom: > case am_c_const: > - break; > case am_x86_abs_pcrel: > - value += (Uint)address; > break; > default: > return -1; > } > - *(Uint32*)address = value; > + *(Uint32*)address += value; > return 0; > } > > If this has worked before (which it has) then the old value of *address > must always have been zero. No. Both procedures implement plain assignment semantics. The old value of *address is not used. I believe the old values always will be zero, but that's only because we have to pad the instruction stream with zeros to make room for the to-be-patched immediates. /Mikael From mikpelinux@REDACTED Sat Feb 1 16:46:46 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 1 Feb 2014 16:46:46 +0100 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <52EB9DFB.4090503@softlab.ntua.gr> References: <52EB9DFB.4090503@softlab.ntua.gr> Message-ID: <21229.5862.278527.71924@gargle.gargle.HOWL> Yiannis Tsiouris writes: > Hey, > > While trying to locate a bug in our x86 backend that caused a segfault at > load-time, we came at something that we think is a bug in the final address > calculation. In functions hipe_patch_load_fe and hipe_patch_insn in > erts/emulator/hipe/hipe_x86.c file we think that the final address should always > be calculated as the sum of "address" and "value". We base this on our > observation that "address" seems to be the offset and "value" seems to be the > base address. > > The patch that works for us is attached. > > If any developer can confirm that this is a bug (and that the patch is the > correct way to fix it) I can submit it properly (if needed). :-) > > Thanks, > Yiannis (as member of the ErLLVM team) > > -- > Yiannis Tsiouris > Ph.D. student, > Software Engineering Laboratory, > National Technical University of Athens > WWW: http://www.softlab.ntua.gr/~gtsiour > > > ---------------------------------------------------------------------- > diff --git a/erts/emulator/hipe/hipe_x86.c b/erts/emulator/hipe/hipe_x86.c > index 327c74e..6c233cb 100644 > --- a/erts/emulator/hipe/hipe_x86.c > +++ b/erts/emulator/hipe/hipe_x86.c > @@ -36,7 +36,7 @@ > void hipe_patch_load_fe(Uint32 *address, Uint32 value) > { > /* address points to a disp32 or imm32 operand */ > - *address = value; > + *address += value; > } > > int hipe_patch_insn(void *address, Uint32 value, Eterm type) > @@ -46,14 +46,12 @@ int hipe_patch_insn(void *address, Uint32 value, Eterm type) > case am_constant: > case am_atom: > case am_c_const: > - break; > case am_x86_abs_pcrel: > - value += (Uint)address; > break; > default: > return -1; > } > - *(Uint32*)address = value; > + *(Uint32*)address += value; > return 0; > } I don't understand why you would make that inference. "address" is the address of the 32-bit immediate to be patched, "value" is the value to store there. Except for the x86_abs_pcrel case, "value" is unrelated to "address". This code is central to naive code loading, and if it indeed was broken then we would have seen hard crashes many years ago. However, it's been known to work (with the HiPE compiler and loader) for 10+ years. I belive your compiler and/or loader is doing something with relocations that differs from the HiPE compiler, and therefore doesn't work with the HiPE runtime. /Mikael From n.oxyde@REDACTED Sat Feb 1 17:10:01 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 1 Feb 2014 17:10:01 +0100 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <21229.5862.278527.71924@gargle.gargle.HOWL> References: <52EB9DFB.4090503@softlab.ntua.gr> <21229.5862.278527.71924@gargle.gargle.HOWL> Message-ID: <73738826-70AE-46D2-9372-47BC81320587@gmail.com> Hello, Don?t know if that is relevant, but there is already an addition of an offset and a base address in hipe_unified_loader: https://github.com/erlang/otp/blob/eec1d22c5aef21ad4606c79465084bbff46d42ee/lib/kernel/src/hipe_unified_loader.erl#L368-369 Regards, -- Anthony Ramine Le 1 f?vr. 2014 ? 16:46, Mikael Pettersson a ?crit : > Yiannis Tsiouris writes: >> Hey, >> >> While trying to locate a bug in our x86 backend that caused a segfault at >> load-time, we came at something that we think is a bug in the final address >> calculation. In functions hipe_patch_load_fe and hipe_patch_insn in >> erts/emulator/hipe/hipe_x86.c file we think that the final address should always >> be calculated as the sum of "address" and "value". We base this on our >> observation that "address" seems to be the offset and "value" seems to be the >> base address. >> >> The patch that works for us is attached. >> >> If any developer can confirm that this is a bug (and that the patch is the >> correct way to fix it) I can submit it properly (if needed). :-) >> >> Thanks, >> Yiannis (as member of the ErLLVM team) >> >> -- >> Yiannis Tsiouris >> Ph.D. student, >> Software Engineering Laboratory, >> National Technical University of Athens >> WWW: http://www.softlab.ntua.gr/~gtsiour >> >> >> ---------------------------------------------------------------------- >> diff --git a/erts/emulator/hipe/hipe_x86.c b/erts/emulator/hipe/hipe_x86.c >> index 327c74e..6c233cb 100644 >> --- a/erts/emulator/hipe/hipe_x86.c >> +++ b/erts/emulator/hipe/hipe_x86.c >> @@ -36,7 +36,7 @@ >> void hipe_patch_load_fe(Uint32 *address, Uint32 value) >> { >> /* address points to a disp32 or imm32 operand */ >> - *address = value; >> + *address += value; >> } >> >> int hipe_patch_insn(void *address, Uint32 value, Eterm type) >> @@ -46,14 +46,12 @@ int hipe_patch_insn(void *address, Uint32 value, Eterm type) >> case am_constant: >> case am_atom: >> case am_c_const: >> - break; >> case am_x86_abs_pcrel: >> - value += (Uint)address; >> break; >> default: >> return -1; >> } >> - *(Uint32*)address = value; >> + *(Uint32*)address += value; >> return 0; >> } > > I don't understand why you would make that inference. "address" is the > address of the 32-bit immediate to be patched, "value" is the value to > store there. Except for the x86_abs_pcrel case, "value" is unrelated > to "address". > > This code is central to naive code loading, and if it indeed was broken > then we would have seen hard crashes many years ago. However, it's been > known to work (with the HiPE compiler and loader) for 10+ years. > > I belive your compiler and/or loader is doing something with relocations > that differs from the HiPE compiler, and therefore doesn't work with the > HiPE runtime. > > /Mikael > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From gustav.simonsson@REDACTED Sat Feb 1 18:41:15 2014 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Sat, 1 Feb 2014 18:41:15 +0100 Subject: [erlang-bugs] Potential bug in OTP_17.0-rc1 when converting map to binary and back Message-ID: Hi, After the announcement of OTP_17.0-rc1 I compiled the source and started playing with maps and proper. After testing a bunch of stuff like maps:to_list(maps:from_list(List)) I replicated a classic proper example to verify binary_to_term(term_to_binary(T)). ======================================== ======================================== -module(t). -include_lib("proper/include/proper.hrl"). -compile([export_all]). prop_term_binary() -> ?FORALL(T, term(), T =:= binary_to_term(term_to_binary(T)) ). ======================================== ======================================== proper:quickcheck(t:prop_term_binary(), [{numtests, 10000}]). (alot of dots ...) OK: Passed 10000 test(s). All is well. Then, I created this property: prop_maps2() -> ?FORALL({PL}, {list({term(), term()})}, begin PropList1 = lists:ukeysort(1, PL), Map1 = maps:from_list(PropList1), Map1 =:= binary_to_term(term_to_binary(Map1)) end ). ======================================== ======================================== 18:33:05 batman ~/projects/erl_maps> erl Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source-fdcdaca] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> c(t). {ok,t} 2> proper:quickcheck(t:prop_maps2(), [{numtests, 10000}]). .................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................! Failed: After 4066 test(s). {[{[-3.916167101796315,5,-14.383620880842821,25,-11,-5,4,-10.251333004157411,-80,21,-11.9643845075958,-10,-16,-5,'\005?V?\027>T??23??n?',-4,<<229>>],6},{<<105,172,229,134,160,163,53,135,179,161,236,42,39,31:5>>,{-11.676717778419862,17.707585198254716,33,'\206\003-f\f\003?\236R',<<192,123,148,228,7:3>>,[],{[]},-9,-7,-6,{9,'\200m?',<<1:3>>,{},3.823878214590697},-20.191151612002688}},{-8,<<97,213,88,122,106,212,110,126,3:2>>},{[[[],[],14.928837856623751,{}],{},[]],{'\222?&?\203\204\217?\000u\206?\235!m',-19.469218108368914,'',[],{[10.946799426461407,[[-3.6593067623424336]],[],'?~\225\n?\207m\\'],[{}]},-56,-1.7371040930562214,3,9,-2,'\037E?8?,????@?@?U\221??','?)\004???F?',[]}},{<<112,8:4>>,'P?B\026\032zE:?\230d'},{20,'U?%V??'},{{8,-5,'?[?m\206?Y(\023\002?\200\201\f',5.860510875770583,-11.499743607476358,-14,78.9417958106197,23,-32},[]},{78.81062902366494,[16,'\n?\'?9O????\d',20,-28.505106763693114,'?\232?`?kB??\035???',9.491181213276489,-4.446055020279977,2,'??','???)?Q\026g',[],{22,[-49.87040520039398,{},20,'(??A\037?\v\203\031(M"??H?']},'?}??^',-190.16730030976382,{},-9]},{{-2,9,-15,'?\212m?\017\227',130,7.406083792942151,47.91530575448283,17,-56,-27,1.1696130495141,8,<<10,97,84,1,210,239,179,245,75,99,204,64,4:3>>,'','\024??\020b?\201>L'},{20,-8.728673595127718,5.131028941847757,{},-22.264422165841957,[[]]}},{-0.805323038965695,['?t]\002?B???]\236\207Jq&Gk',-23,'??\232{\016??g\016???\017?\036??\t','??',-23.674996673031742,3,5.511692289051506,-14,-18.02109289321752,0.7818131441815134]},{{[11.68346635783379,'??\225\032\232? ,?|\022 \205L\205',0,[{<<123:7>>}],-2.4217323982351866,1.1404903952928618,{[{}],{},'?n?\032?\b?+\e <;?f???'},12.184525559260809,-10.00845000093209,-13,[56],{}],'??',-4,26.708298789331433,4,<<255,6,0:1>>,'?',10,2.3535448113644706,'?',-112.15429185940658,4.322599970691285,20.556338272619058},{[-9.047222745894432,-6,[]]}},{{-10.004049310388854,'U','4p{J?k?p?\235',24,'??G??\034\020??','??qb8O??\b\220',-19,-45.108220054002054,'[q\022\fx\t\037a\005x?',-15,2.9443008897224243,<<4,150,219,33,213,112,8,171,0,154,124,45:7>>,-12.217387380533854,'\r@ '},{{{{}},{},0.9613990232005811,['.O\003\017?&?\txB-DV???',{}]},-5,7,-9,[{}],'[??\222;\205\r7?,6)?I\222?[','\213??xDp?',2,22,-62.085919420904354}},{[5,<<142,163,209,185,37,35:6>>,{'??\213??',{[],[],<<173,3:2>>},'',[]},-18.799834786170464],10.169565402950454}]} Shrinking .......Segmentation fault (core dumped) ======================================== ======================================== Erlang version: git tag OTP_17.0-rc1 OS: Ubuntu server 13.10 Arch: Intel(R) Core(TM) i7-3770T Please let me know if you need a core and/or more details. It should be easy to replicate given the above code though on various archs. Cheers, Gustav Simonsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Sat Feb 1 18:45:35 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 1 Feb 2014 18:45:35 +0100 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <73738826-70AE-46D2-9372-47BC81320587@gmail.com> References: <52EB9DFB.4090503@softlab.ntua.gr> <21229.5862.278527.71924@gargle.gargle.HOWL> <73738826-70AE-46D2-9372-47BC81320587@gmail.com> Message-ID: <21229.12991.180917.179970@gargle.gargle.HOWL> Anthony Ramine writes: > Hello, > > Don?t know if that is relevant, but there is already an addition of an offset and a base address in hipe_unified_loader: > > https://github.com/erlang/otp/blob/eec1d22c5aef21ad4606c79465084bbff46d42ee/lib/kernel/src/hipe_unified_loader.erl#L368-369 That converts from the "image offsets" used in the object file to actual runtime addresses, by adding the image's runtime load (base) address. /Mikael From kostis@REDACTED Sat Feb 1 19:37:39 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 01 Feb 2014 19:37:39 +0100 Subject: [erlang-bugs] [erlang-questions] Potential bug in OTP_17.0-rc1 when converting map to binary and back In-Reply-To: References: Message-ID: <52ED3EF3.9070802@cs.ntua.gr> On 02/01/2014 06:41 PM, Gustav Simonsson wrote: > After the announcement of OTP_17.0-rc1 I compiled the source and started > playing with maps and proper. > > After testing a bunch of stuff like maps:to_list(maps:from_list(List)) I > replicated a classic proper example to verify > binary_to_term(term_to_binary(T)). > .... > 2> proper:quickcheck(t:prop_maps2(), [{numtests, 10000}]). > ............ ............................................... > Shrinking .......Segmentation fault (core dumped) > .... > Please let me know if you need a core and/or more details. > It should be easy to replicate given the above code though on various archs. Indeed, this is very easy to replicate. On my first attempt, I got equally unlucky as Simon and OTP seg faulted when PropEr attempted to shrink the offending test case. On my second attempt, I had better luck and shrinking worked: Eshell V6.0 (abort with ^G) 1> proper:quickcheck(t:prop_maps2(), 10000). ...... ..... Failed: After 2090 test(s). {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015,9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7.568651682554733}]},{'?\204H?????',[[],[],[],-10,80,{},[]]},{{'?\211l\030x\220?\224?'},[-14.081931069838275,1,['\236J?',0],3,3.8086424574055755]},{{[],[{},[[{}]]],{},{}},{-7.668921456100702,-0.8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030',{-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22.021800217282916],-2,7.289863377212738,'?]?\d',10.348710823806195},{{[[{},[5.428258856857506],[],'O\030:',-2]],22.20548610862955,102}}},{[1.730805378918121,'\201\226o\032',-5,-4,0.21576771814263207],<<145,249,4,86,26,4:3>>}]} Shrinking ...................(19 time(s)) {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015,9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7.568651682554733}]},{'\037\204H?>w6?',[[],[],[],-8,80,{},[]]},{{'?\211l\030x\220?\224?'},[-14.081931069838275,1,['z\003-',0],3,3.8086424574055755]},{'\v?6\002',{-7.668921456100702,-0.8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030',{-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22.021800217282916],-2,7.289863377212738,'?]?\d',10.348710823806195},{{[[{},[5.428258856857506],[],'O\030:',-2]],22.20548610862955,102}}},{[1.730805378918121,'\030\023%\020',-5,-4,0.21576771814263207],<<145,249,4,49,26,4:3>>}]} false false PropEr can be obtained from: http://proper.softlab.ntua.gr/ Kostis From wallentin.dahlberg@REDACTED Sat Feb 1 22:49:59 2014 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 1 Feb 2014 22:49:59 +0100 Subject: [erlang-bugs] [erlang-questions] Potential bug in OTP_17.0-rc1 when converting map to binary and back In-Reply-To: <52ED3EF3.9070802@cs.ntua.gr> References: <52ED3EF3.9070802@cs.ntua.gr> Message-ID: Woho! Good catch with proper! Have I run proper on Maps? - Nope. Should I have done it - properly. =) I wrote the Maps code for external format encoding/decoding before the big rewrite of trappable binary_to_term - term_to_binary. We had some clashes when merging and it is entirely possible that we messed things up. It is also entirely possible I messed up well before the merge. I'll have a look at it. Thanks for reporting! // Bj?rn-Egil 2014-02-01 Kostis Sagonas : > On 02/01/2014 06:41 PM, Gustav Simonsson wrote: > >> After the announcement of OTP_17.0-rc1 I compiled the source and started >> playing with maps and proper. >> >> After testing a bunch of stuff like maps:to_list(maps:from_list(List)) I >> replicated a classic proper example to verify >> binary_to_term(term_to_binary(T)). >> > > .... > >> 2> proper:quickcheck(t:prop_maps2(), [{numtests, 10000}]). >> ............ ............................................... >> >> Shrinking .......Segmentation fault (core dumped) >> .... >> >> Please let me know if you need a core and/or more details. >> It should be easy to replicate given the above code though on various >> archs. >> > > > Indeed, this is very easy to replicate. On my first attempt, I got > equally unlucky as Simon and OTP seg faulted when PropEr attempted to > shrink the offending test case. On my second attempt, I had better luck and > shrinking worked: > > > Eshell V6.0 (abort with ^G) > 1> proper:quickcheck(t:prop_maps2(), 10000). > ...... ..... > Failed: After 2090 test(s). > {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015, > 9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7. > 568651682554733}]},{'?\204H?????',[[],[],[],-10,80,{},[]]},{ > {'?\211l\030x\220?\224?'},[-14.081931069838275,1,['\236J?' > ,0],3,3.8086424574055755]},{{[],[{},[[{}]]],{},{}},{-7.668921456100702,-0. > 8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030', > {-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22. > 021800217282916],-2,7.289863377212738,'?]?\d',10. > 348710823806195},{{[[{},[5.428258856857506],[],'O\030:',- > 2]],22.20548610862955,102}}},{[1.730805378918121,'\201\226o\032',-5,-4,0. > 21576771814263207],<<145,249,4,86,26,4:3>>}]} > > Shrinking ...................(19 time(s)) > {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015, > 9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7. > 568651682554733}]},{'\037\204H?>w6?',[[],[],[],-8,80,{}, > []]},{{'?\211l\030x\220?\224?'},[-14.081931069838275,1,['z\ > 003-',0],3,3.8086424574055755]},{'\v?6\002',{-7.668921456100702,-0. > 8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030', > {-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22. > 021800217282916],-2,7.289863377212738,'?]?\d',10. > 348710823806195},{{[[{},[5.428258856857506],[],'O\030:',- > 2]],22.20548610862955,102}}},{[1.730805378918121,'\030\023%\020',-5,-4,0. > 21576771814263207],<<145,249,4,49,26,4:3>>}]} > false > > false > > > PropEr can be obtained from: http://proper.softlab.ntua.gr/ > > Kostis > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Feb 2 14:48:36 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 2 Feb 2014 14:48:36 +0100 Subject: [erlang-bugs] Rewrite merge of clause variable tables (in case, try, etc) In-Reply-To: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> References: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> Message-ID: Thinking twice about this patch, it should probably be done another way, with a function taking the accumulated variable table from the merging of previous clauses, the variable table of the current clause, and the variable table of the surrounding environment. It currently relies too much on the implementation details of orddict, I think. -- Anthony Ramine Le 14 nov. 2013 ? 13:26, Anthony Ramine a ?crit : > Hello, > > I have finally got around fixing the two regressions reported in R16B02 with regard to unused variable warnings. > > The fix was more complicated than what I expected it to be. > > git fetch https://github.com/nox/otp.git fix-exporting-rules > > https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules > https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules.patch > > Regards, > > -- > Anthony Ramine > From gtsiour@REDACTED Sun Feb 2 20:06:15 2014 From: gtsiour@REDACTED (Yiannis Tsiouris) Date: Sun, 02 Feb 2014 21:06:15 +0200 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <21229.5862.278527.71924@gargle.gargle.HOWL> References: <52EB9DFB.4090503@softlab.ntua.gr> <21229.5862.278527.71924@gargle.gargle.HOWL> Message-ID: <52EE9727.8010600@softlab.ntua.gr> Hi all, I'll try to address both Mikael's and Sveker's comments. :) On 02/01/2014 05:46 PM, Mikael Pettersson wrote: > Yiannis Tsiouris writes: > > ---------------------------------------------------------------------- > > diff --git a/erts/emulator/hipe/hipe_x86.c b/erts/emulator/hipe/hipe_x86.c > > index 327c74e..6c233cb 100644 > > --- a/erts/emulator/hipe/hipe_x86.c > > +++ b/erts/emulator/hipe/hipe_x86.c > > @@ -36,7 +36,7 @@ > > void hipe_patch_load_fe(Uint32 *address, Uint32 value) > > { > > /* address points to a disp32 or imm32 operand */ > > - *address = value; > > + *address += value; > > } > > > > int hipe_patch_insn(void *address, Uint32 value, Eterm type) > > @@ -46,14 +46,12 @@ int hipe_patch_insn(void *address, Uint32 value, Eterm type) > > case am_constant: > > case am_atom: > > case am_c_const: > > - break; > > case am_x86_abs_pcrel: > > - value += (Uint)address; > > break; > > default: > > return -1; > > } > > - *(Uint32*)address = value; > > + *(Uint32*)address += value; > > return 0; > > } > > I don't understand why you would make that inference. "address" is the > address of the 32-bit immediate to be patched, "value" is the value to > store there. Except for the x86_abs_pcrel case, "value" is unrelated > to "address". > > This code is central to naive code loading, and if it indeed was broken > then we would have seen hard crashes many years ago. However, it's been > known to work (with the HiPE compiler and loader) for 10+ years. Mikael, you 're, of course right about what "address" and "value" are! The code works exactly because of *address being zero (as you explained in: "I believe the old values always will be zero, but that's only because we have to pad the instruction stream with zeros to make room for the to-be-patched immediates."). To verify that, I even tried adding an assert(*address == 0) in both hipe_patch_load_fe and hipe_patch_insn and, then, building the OTP with native libs (./configure --enable-native-libs); I also run the "usual tests" and everything worked like a charm. > I belive your compiler and/or loader is doing something with relocations > that differs from the HiPE compiler, and therefore doesn't work with the > HiPE runtime. After that, I tried to investigate why that doesn't work for us. One test that fails is fun04.erl (attached). A small diff in the assembly generated by vanilla hipe and ErLLVM hipe reveals: Vanilla HiPE: ------------- a3 | | ._58: a3 | b800000000 | mov ${{{fun04,'-test/0-fun-0-',1},71147871,0},closure}, %eax a8 | 894604 | mov %eax, 0x4(%esi) ab | 8b4828 | mov 0x28(%eax), %ecx ae | 894e0c | mov %ecx, 0xc(%esi) b1 | c7461001000000 | mov $0x1, 0x10(%esi) b8 | 83c034 | add $0x34, %eax bb | e800000000 | call atomic_inc # [] 0x2 0 [] not_remote ErLLVM HiPE: ------------ # BB#13: movl $_2D_test_2F_0_2D_fun_2D_1_2D_, 4(%esi) movl _2D_test_2F_0_2D_fun_2D_1_2D_+40, %eax movl %eax, 12(%esi) movl $1, 16(%esi) leal _2D_test_2F_0_2D_fun_2D_1_2D_+52, %eax calll atomic_inc That strange "_2D_test_2F_0_2D_fun_2D_1_2D_" is the name of the closure after some mangling to be LLVM-compatible. Our (ErLLVM) code seems semantically equivalent to (vanilla) HiPE's. However, the 2 additions that involve the closure symbol complicate address patching. HiPE doesn't face these problems because it always handles closures as shown above. IMHO, I don't think that we violate any kind of "runtime invariant" by generating code in that way. I'd love to hear your opinion, too! :-) On 01/31/2014 07:20 PM, Sverker Eriksson wrote: > If this has worked before (which it has) then the old value of *address > must always have been zero. > > But it looks like hipe_patch_insn() can be called in a module upgrade > scenario (see hipe_bifs_redirect_referred_from_1 in hipe_bif0.c) > and then the old value of *address must (I guess?) refer to something in > the old module instance. > Adding old and new values can not be right (whatever "value" may be). > > > Have you tried this patch with the existing x86 backend? And have you > tried upgrading a module and verified that it is reachable after the > upgrade? I copied m.erl (attached) from here [1] and tried running: gtsiour@REDACTED [~]>>= erl Erlang/OTP 17 [DEVELOPMENT] [erts-6.0] [source-dee9682] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> c(m). {ok,m} 2> hipe:c(m). {ok,m} 3> P = spawn(fun () -> m:loop() end). <0.51.0> 4> P ! "bar". Before: "bar" "bar" 5> P ! "foo". Before: "foo" "foo" 6> c(m). {ok,m} 7> hipe:c(m). {ok,m} 8> P ! "foo". Before: "foo" "foo" Then, I tried commenting-out line 9 and uncommenting line 10 and did: 9> P ! code_switch. code_switch 10> P ! "foo". After: "foo" "foo" 11> q(). ok 12> Do you think that this test suffices? I'd be happy to test more thoroughly... Just point me to some tests/scenarios! Thanks for the prompt replies! ~Y. [1]: http://www.erlang.org/doc/reference_manual/code_loading.html -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour -------------- next part -------------- A non-text attachment was scrubbed... Name: fun04.erl Type: text/x-erlang Size: 460 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: m.erl Type: text/x-erlang Size: 199 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From mikpelinux@REDACTED Mon Feb 3 14:00:51 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Mon, 3 Feb 2014 14:00:51 +0100 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <52EE9727.8010600@softlab.ntua.gr> References: <52EB9DFB.4090503@softlab.ntua.gr> <21229.5862.278527.71924@gargle.gargle.HOWL> <52EE9727.8010600@softlab.ntua.gr> Message-ID: <21231.37635.796179.810301@gargle.gargle.HOWL> Yiannis Tsiouris writes: > Hi all, > > I'll try to address both Mikael's and Sveker's comments. :) > > On 02/01/2014 05:46 PM, Mikael Pettersson wrote: > > Yiannis Tsiouris writes: > > > ---------------------------------------------------------------------- > > > diff --git a/erts/emulator/hipe/hipe_x86.c b/erts/emulator/hipe/hipe_x86.c > > > index 327c74e..6c233cb 100644 > > > --- a/erts/emulator/hipe/hipe_x86.c > > > +++ b/erts/emulator/hipe/hipe_x86.c > > > @@ -36,7 +36,7 @@ > > > void hipe_patch_load_fe(Uint32 *address, Uint32 value) > > > { > > > /* address points to a disp32 or imm32 operand */ > > > - *address = value; > > > + *address += value; > > > } > > > > > > int hipe_patch_insn(void *address, Uint32 value, Eterm type) > > > @@ -46,14 +46,12 @@ int hipe_patch_insn(void *address, Uint32 value, Eterm type) > > > case am_constant: > > > case am_atom: > > > case am_c_const: > > > - break; > > > case am_x86_abs_pcrel: > > > - value += (Uint)address; > > > break; > > > default: > > > return -1; > > > } > > > - *(Uint32*)address = value; > > > + *(Uint32*)address += value; > > > return 0; > > > } > > > > I don't understand why you would make that inference. "address" is the > > address of the 32-bit immediate to be patched, "value" is the value to > > store there. Except for the x86_abs_pcrel case, "value" is unrelated > > to "address". > > > > This code is central to naive code loading, and if it indeed was broken > > then we would have seen hard crashes many years ago. However, it's been > > known to work (with the HiPE compiler and loader) for 10+ years. > > Mikael, you 're, of course right about what "address" and "value" are! > The code works exactly because of *address being zero (as you explained > in: "I believe the old values always will be zero, but that's only > because we have to pad the instruction stream with zeros to make room > for the to-be-patched immediates."). The existing code works, yes, but it does not read or depend on the old value of *address in any way. You make it sound as if the old value of *address being zero is somehow significant; it is not. > To verify that, I even tried adding > an assert(*address == 0) in both hipe_patch_load_fe and hipe_patch_insn > and, then, building the OTP with native libs (./configure > --enable-native-libs); I also run the "usual tests" and everything > worked like a charm. > > > I belive your compiler and/or loader is doing something with relocations > > that differs from the HiPE compiler, and therefore doesn't work with the > > HiPE runtime. > > After that, I tried to investigate why that doesn't work for us. One > test that fails is fun04.erl (attached). A small diff in the assembly > generated by vanilla hipe and ErLLVM hipe reveals: > > Vanilla HiPE: > ------------- > a3 | | ._58: > a3 | b800000000 | mov > ${{{fun04,'-test/0-fun-0-',1},71147871,0},closure}, %eax > a8 | 894604 | mov %eax, 0x4(%esi) > ab | 8b4828 | mov 0x28(%eax), %ecx > ae | 894e0c | mov %ecx, 0xc(%esi) > b1 | c7461001000000 | mov $0x1, 0x10(%esi) > b8 | 83c034 | add $0x34, %eax > bb | e800000000 | call atomic_inc # [] 0x2 0 [] > not_remote > > > ErLLVM HiPE: > ------------ > # BB#13: > movl $_2D_test_2F_0_2D_fun_2D_1_2D_, 4(%esi) > movl _2D_test_2F_0_2D_fun_2D_1_2D_+40, %eax > movl %eax, 12(%esi) > movl $1, 16(%esi) > leal _2D_test_2F_0_2D_fun_2D_1_2D_+52, %eax > calll atomic_inc So for the 2nd and and 5th instructions above, I guess you generate inital object code with 40 and 52, respectively, in the imm32 fields, and then have relocation entries referring to those imm32s and the _2D_test_2F_0_2D_fun_2D_1_2D_ label. If so then I can see why you would want the runtime patcher to do += rather than =. In ELF terms, you're using Elf32_Rel while HiPE uses Elf32_Rela. > IMHO, I don't think that we violate any kind of "runtime invariant" by > generating code in that way. I'd love to hear your opinion, too! :-) Your approach is reasonable. My concern is only that you're changing the semantics of two HiPE runtime primitives, "justified" by the observation that HiPE/x86 works also with the changed semantics. However: - these two primitives are implemented separately for each HiPE backend, and there are currently 6 of those - there is only one high-level loader, and it expects these primitives to have essentially the same semantics for every backend - you have suggested to change x86, but haven't considered the other 5 backends; of those, at least 3 (ppc, ppc64, sparc) will need non-trivial coding to implement += rather than = semantics I would be much happier if you'd initially just store 0 in those imm32 fields, put label and offset in your relocation entries, and have your loader perform the add and then call the runtime to "=" the imm32s. If your change to the x86 version of these primitives is accepted, then we have to document that (a) x86 differs from the other backends, and (b) the initial value of a patchable immmediate MUST be zero. /Mikael From jose.valim@REDACTED Mon Feb 3 19:34:47 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Mon, 3 Feb 2014 19:34:47 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 Message-ID: There is a regression in 17.0-rc1. The following code will execute io:format/2 twice: -module(test). -export([test/0]). test() -> X = Y = io:format(<<"foo~n">>), X, Y. I ran it with: $ erlc test.erl $ erl -s test test Above is the minimum test case extracted from a more complex expression where I matched against a record: Value = #elixir_env{} = expr() Thank you, *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Feb 3 19:54:23 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 3 Feb 2014 19:54:23 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 In-Reply-To: References: Message-ID: <09CF3C9B-4231-4B27-9B10-1EBF2E5E9C21@gmail.com> Bug is in sys_core_fold. Culprit is probably e12b7d5331c58b41db06cadfa4af75b78b62a2b1. -- Anthony Ramine Le 3 f?vr. 2014 ? 19:34, Jos? Valim a ?crit : > There is a regression in 17.0-rc1. The following code will execute io:format/2 twice: > > -module(test). > -export([test/0]). > > test() -> > X = Y = io:format(<<"foo~n">>), > X, > Y. > > I ran it with: > > $ erlc test.erl > $ erl -s test test > > Above is the minimum test case extracted from a more complex expression where I matched against a record: > > Value = #elixir_env{} = expr() > > Thank you, > > Jos? Valim > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From kostis@REDACTED Mon Feb 3 20:11:42 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 03 Feb 2014 20:11:42 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 In-Reply-To: References: Message-ID: <52EFE9EE.3030005@cs.ntua.gr> On 02/03/2014 07:34 PM, Jos? Valim wrote: > There is a regression in 17.0-rc1. The following code will execute > io:format/2 twice: > > > -module(test). > -export([test/0]). > test() -> > X = Y = io:format(<<"foo~n">>), > X, > Y. Ouch! Kostis From n.oxyde@REDACTED Mon Feb 3 20:19:39 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 3 Feb 2014 20:19:39 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 In-Reply-To: <09CF3C9B-4231-4B27-9B10-1EBF2E5E9C21@gmail.com> References: <09CF3C9B-4231-4B27-9B10-1EBF2E5E9C21@gmail.com> Message-ID: <5C3016A8-F73F-4136-8ADA-C9A272A4D346@gmail.com> Smallest Core sample: module 'test' ['main'/1] attributes [] 'main'/1 = %% Line 6 fun (_cor0) -> case call 'io':'format' ([102|[110]]) of when 'true' -> Y end end Running this through sys_core_fold triggers the bug. -- Anthony Ramine Le 3 f?vr. 2014 ? 19:54, Anthony Ramine a ?crit : > Bug is in sys_core_fold. Culprit is probably e12b7d5331c58b41db06cadfa4af75b78b62a2b1. > > -- > Anthony Ramine > > Le 3 f?vr. 2014 ? 19:34, Jos? Valim a ?crit : > >> There is a regression in 17.0-rc1. The following code will execute io:format/2 twice: >> >> -module(test). >> -export([test/0]). >> >> test() -> >> X = Y = io:format(<<"foo~n">>), >> X, >> Y. >> >> I ran it with: >> >> $ erlc test.erl >> $ erl -s test test >> >> Above is the minimum test case extracted from a more complex expression where I matched against a record: >> >> Value = #elixir_env{} = expr() >> >> Thank you, >> >> Jos? Valim >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From sverker.eriksson@REDACTED Mon Feb 3 20:21:02 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 3 Feb 2014 20:21:02 +0100 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <52EE9727.8010600@softlab.ntua.gr> References: <52EB9DFB.4090503@softlab.ntua.gr> <21229.5862.278527.71924@gargle.gargle.HOWL> <52EE9727.8010600@softlab.ntua.gr> Message-ID: <52EFEC1E.8050102@ericsson.com> On 02/02/2014 08:06 PM, Yiannis Tsiouris wrote: > Do you think that this test suffices? I'd be happy to test more > thoroughly... Just point me to some tests/scenarios! > There is actually a test case that tests module upgrade with a lot of combinations of different function calls: lib/kernel/test/code_SUITE:upgrade. It only tests beam modules in its present form as it doesn't run clean with hipe compiled modules. git fetch https://github.com/sverker/otp.git code_SUITE-upgrade-hipe This commit enables hipe compiled modules and comments out all cases currently not working for hipe. However, even if your patch should pass the test above, I agree with Mikael that it would be better if it could be solved in a different way as the patch does not harmonize with the other architectures. /Sverker From eric.pailleau@REDACTED Mon Feb 3 23:29:03 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 03 Feb 2014 23:29:03 +0100 Subject: [erlang-bugs] R17 - Crash while closing crashdump viewer Message-ID: <52F0182F.2070506@wanadoo.fr> Hi Dan, by testing the new crashdump feature of observer in R17, I got below crash. To reproduce : - launch observer - File/Examine crashdump - Open a crashdump - Go to the crashdump viewer window - File/Quit ---> crash ---8<------------------------------------------------------------ {error,{badarg,[{erlang,register,[observer,<0.1275.0>],[]}, {observer_wx,init,1,[{file,"observer_wx.erl"},{line,89}]}, {wx_object,init_it,6,[{file,"wx_object.erl"},{line,299}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]}} Child (unknown) crashed exiting: <0.49.0> {badarg, [{erlang,port_control, [#Port<0.787>,1859, <<62,0,0,0,3,0,0,0,49,55,0,0,0, 0,0,0>>], []}, {wxe_util,cast,2, [{file,"wxe_util.erl"}, {line,61}]}, {observer_lib,update_info2,2, [{file,"observer_lib.erl"}, {line,201}]}, {observer_lib,update_info,2, [{file,"observer_lib.erl"}, {line,184}]}, {observer_sys_wx,update_syspage, 1, [{file,"observer_sys_wx.erl"}, {line,84}]}, {observer_sys_wx,handle_info,2, [{file,"observer_sys_wx.erl"}, {line,209}]}, {wx_object,handle_msg,5, [{file,"wx_object.erl"}, {line,394}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"}, {line,239}]}]} From n.oxyde@REDACTED Tue Feb 4 01:05:16 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 4 Feb 2014 01:05:16 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 In-Reply-To: <5C3016A8-F73F-4136-8ADA-C9A272A4D346@gmail.com> References: <09CF3C9B-4231-4B27-9B10-1EBF2E5E9C21@gmail.com> <5C3016A8-F73F-4136-8ADA-C9A272A4D346@gmail.com> Message-ID: <419DE9E1-65D9-46BA-B69E-B7CD24207D7B@gmail.com> The problem comes from cerl_clauses. The more I look at it, the more I think this module shouldn?t be used like this. -- Anthony Ramine Le 3 f?vr. 2014 ? 20:19, Anthony Ramine a ?crit : > Smallest Core sample: > > module 'test' ['main'/1] > attributes [] > 'main'/1 = > %% Line 6 > fun (_cor0) -> > case call 'io':'format' ([102|[110]]) of > when 'true' -> > Y > end > end > > Running this through sys_core_fold triggers the bug. > > -- > Anthony Ramine > > Le 3 f?vr. 2014 ? 19:54, Anthony Ramine a ?crit : > >> Bug is in sys_core_fold. Culprit is probably e12b7d5331c58b41db06cadfa4af75b78b62a2b1. >> >> -- >> Anthony Ramine >> >> Le 3 f?vr. 2014 ? 19:34, Jos? Valim a ?crit : >> >>> There is a regression in 17.0-rc1. The following code will execute io:format/2 twice: >>> >>> -module(test). >>> -export([test/0]). >>> >>> test() -> >>> X = Y = io:format(<<"foo~n">>), >>> X, >>> Y. >>> >>> I ran it with: >>> >>> $ erlc test.erl >>> $ erl -s test test >>> >>> Above is the minimum test case extracted from a more complex expression where I matched against a record: >>> >>> Value = #elixir_env{} = expr() >>> >>> Thank you, >>> >>> Jos? Valim >>> www.plataformatec.com.br >>> Skype: jv.ptec >>> Founder and Lead Developer >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> > From dangud@REDACTED Tue Feb 4 09:21:58 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Tue, 4 Feb 2014 09:21:58 +0100 Subject: [erlang-bugs] R17 - Crash while closing crashdump viewer In-Reply-To: <52F0182F.2070506@wanadoo.fr> References: <52F0182F.2070506@wanadoo.fr> Message-ID: Thanks. Found and fixed. /Dan On Mon, Feb 3, 2014 at 11:29 PM, PAILLEAU Eric wrote: > Hi Dan, > > by testing the new crashdump feature of observer in R17, > I got below crash. > To reproduce : > - launch observer > - File/Examine crashdump > - Open a crashdump > - Go to the crashdump viewer window > - File/Quit ---> crash > > > ---8<------------------------------------------------------------ > {error,{badarg,[{erlang,register,[observer,<0.1275.0>],[]}, > {observer_wx,init,1,[{file,"observer_wx.erl"},{line,89}]}, > {wx_object,init_it,6,[{file,"wx_object.erl"},{line,299}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]}} > Child (unknown) crashed exiting: <0.49.0> {badarg, > [{erlang,port_control, > [#Port<0.787>,1859, > > <<62,0,0,0,3,0,0,0,49,55,0,0,0, > 0,0,0>>], > []}, > {wxe_util,cast,2, > [{file,"wxe_util.erl"}, > {line,61}]}, > {observer_lib,update_info2,2, > [{file,"observer_lib.erl"}, > {line,201}]}, > {observer_lib,update_info,2, > [{file,"observer_lib.erl"}, > {line,184}]}, > > {observer_sys_wx,update_syspage, > 1, > > [{file,"observer_sys_wx.erl"}, > {line,84}]}, > > {observer_sys_wx,handle_info,2, > > [{file,"observer_sys_wx.erl"}, > {line,209}]}, > {wx_object,handle_msg,5, > [{file,"wx_object.erl"}, > {line,394}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"}, > {line,239}]}]} > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Tue Feb 4 10:52:17 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 4 Feb 2014 10:52:17 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 In-Reply-To: References: Message-ID: On Mon, Feb 3, 2014 at 7:34 PM, Jos? Valim wrote: > > There is a regression in 17.0-rc1. The following code will execute io:format/2 twice: > > > -module(test). > -export([test/0]). > > test() -> > X = Y = io:format(<<"foo~n">>), > X, > Y. Thanks for the bug report (and thanks Anthony for pointing out the commit). Here is a correction: git fetch git@REDACTED:bjorng/otp.git bjorn/compiler/optimizations/OTP-11584 Please try it out. We will run it for a couple of days in our daily builds before merging it to master. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bjorn@REDACTED Tue Feb 4 10:54:39 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 4 Feb 2014 10:54:39 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 In-Reply-To: <419DE9E1-65D9-46BA-B69E-B7CD24207D7B@gmail.com> References: <09CF3C9B-4231-4B27-9B10-1EBF2E5E9C21@gmail.com> <5C3016A8-F73F-4136-8ADA-C9A272A4D346@gmail.com> <419DE9E1-65D9-46BA-B69E-B7CD24207D7B@gmail.com> Message-ID: On Tue, Feb 4, 2014 at 1:05 AM, Anthony Ramine wrote: > The problem comes from cerl_clauses. The more I look at it, the more I think this module shouldn?t be used like this. Except for use of cerl_clauses in eval_case(), did you find any more places where it is not used in a safe way? /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Tue Feb 4 11:17:10 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 4 Feb 2014 11:17:10 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 In-Reply-To: References: <09CF3C9B-4231-4B27-9B10-1EBF2E5E9C21@gmail.com> <5C3016A8-F73F-4136-8ADA-C9A272A4D346@gmail.com> <419DE9E1-65D9-46BA-B69E-B7CD24207D7B@gmail.com> Message-ID: <6ADF97C1-E0F6-4F79-9A5E-B34932A654E8@gmail.com> Hello Bj?rn, I am wary of the call to cerl_clauses:match_list in cerl_inline, given that the returned bindings appear to be used. What do you think of making cerl_clauses:match_list returns {boolean(),Bindings,Aliases}? Regards, -- Anthony Ramine Le 4 f?vr. 2014 ? 10:54, Bj?rn Gustavsson a ?crit : > On Tue, Feb 4, 2014 at 1:05 AM, Anthony Ramine wrote: >> The problem comes from cerl_clauses. The more I look at it, the more I think this module shouldn?t be used like this. > > Except for use of cerl_clauses in eval_case(), did you find any more places > where it is not used in a safe way? > > /Bjorn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From egil@REDACTED Tue Feb 4 12:34:25 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 4 Feb 2014 12:34:25 +0100 Subject: [erlang-bugs] [erlang-questions] Potential bug in OTP_17.0-rc1 when converting map to binary and back In-Reply-To: <52ED3EF3.9070802@cs.ntua.gr> References: <52ED3EF3.9070802@cs.ntua.gr> Message-ID: <52F0D041.9040209@erlang.org> This bug is now corrected on master with: commit 9171d1886015e4d36601ed360f6d479a5a95abab Merge: 52e15d7 9ae4a52 Author: Sverker Eriksson Date: Mon Feb 3 18:07:09 2014 +0100 Merge branch 'sverk/erts/binary_to_term-maps-bug' * sverk/erts/binary_to_term-maps-bug: erts: Fix bug in binary_to_term for maps // Bj?rn-Egil On 2014-02-01 19:37, Kostis Sagonas wrote: > On 02/01/2014 06:41 PM, Gustav Simonsson wrote: >> After the announcement of OTP_17.0-rc1 I compiled the source and started >> playing with maps and proper. >> >> After testing a bunch of stuff like maps:to_list(maps:from_list(List)) I >> replicated a classic proper example to verify >> binary_to_term(term_to_binary(T)). > > .... >> 2> proper:quickcheck(t:prop_maps2(), [{numtests, 10000}]). >> ............ ............................................... >> Shrinking .......Segmentation fault (core dumped) >> .... >> Please let me know if you need a core and/or more details. >> It should be easy to replicate given the above code though on various >> archs. > > > Indeed, this is very easy to replicate. On my first attempt, I got > equally unlucky as Simon and OTP seg faulted when PropEr attempted to > shrink the offending test case. On my second attempt, I had better > luck and shrinking worked: > > Eshell V6.0 (abort with ^G) > 1> proper:quickcheck(t:prop_maps2(), 10000). > ...... ..... > Failed: After 2090 test(s). > {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015,9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7.568651682554733}]},{'?\204H?????',[[],[],[],-10,80,{},[]]},{{'?\211l\030x\220?\224?'},[-14.081931069838275,1,['\236J?',0],3,3.8086424574055755]},{{[],[{},[[{}]]],{},{}},{-7.668921456100702,-0.8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030',{-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22.021800217282916],-2,7.289863377212738,'?]?\d',10.348710823806195},{{[[{},[5.428258856857506],[],'O\030:',-2]],22.20548610862955,102}}},{[1.730805378918121,'\201\226o\032',-5,-4,0.21576771814263207],<<145,249,4,86,26,4:3>>}]} > > > Shrinking ...................(19 time(s)) > {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015,9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7.568651682554733}]},{'\037\204H?>w6?',[[],[],[],-8,80,{},[]]},{{'?\211l\030x\220?\224?'},[-14.081931069838275,1,['z\003-',0],3,3.8086424574055755]},{'\v?6\002',{-7.668921456100702,-0.8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030',{-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22.021800217282916],-2,7.289863377212738,'?]?\d',10.348710823806195},{{[[{},[5.428258856857506],[],'O\030:',-2]],22.20548610862955,102}}},{[1.730805378918121,'\030\023%\020',-5,-4,0.21576771814263207],<<145,249,4,49,26,4:3>>}]} > > false > > false > > > PropEr can be obtained from: http://proper.softlab.ntua.gr/ > > Kostis > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From bjorn@REDACTED Tue Feb 4 13:42:14 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 4 Feb 2014 13:42:14 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 In-Reply-To: <6ADF97C1-E0F6-4F79-9A5E-B34932A654E8@gmail.com> References: <09CF3C9B-4231-4B27-9B10-1EBF2E5E9C21@gmail.com> <5C3016A8-F73F-4136-8ADA-C9A272A4D346@gmail.com> <419DE9E1-65D9-46BA-B69E-B7CD24207D7B@gmail.com> <6ADF97C1-E0F6-4F79-9A5E-B34932A654E8@gmail.com> Message-ID: (I am CC:ing Richard Carlsson since he wrote the cerl modules and the inliner.) On Tue, Feb 4, 2014 at 11:17 AM, Anthony Ramine wrote: > Hello Bj?rn, > > I am wary of the call to cerl_clauses:match_list in cerl_inline, given that the returned bindings appear to be used. > The important thing is the expressions passed to cerl_clauses:match_list/2. If the inliner make sure hoisting any expression with a side-effect to an enclosing 'let' as I did in my fix it will still be safe. > What do you think of making cerl_clauses:match_list returns {boolean(),Bindings,Aliases}? Perhaps. If there is a clear need for it. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Tue Feb 4 14:52:49 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 4 Feb 2014 14:52:49 +0100 Subject: [erlang-bugs] Regression on match in 17.0-rc1 In-Reply-To: References: <09CF3C9B-4231-4B27-9B10-1EBF2E5E9C21@gmail.com> <5C3016A8-F73F-4136-8ADA-C9A272A4D346@gmail.com> <419DE9E1-65D9-46BA-B69E-B7CD24207D7B@gmail.com> <6ADF97C1-E0F6-4F79-9A5E-B34932A654E8@gmail.com> Message-ID: You fixed it already? Cool. Regarding cerl_clauses:match_list, I don?t see the point of making it return clearly wrong or misleading values. Why would it return [{X,io:format?},{Y,io:format?}] in the first place? That result is all but useful. Making it return a list of aliases would reduce the work needed in callers, don?t you think? -- Anthony Ramine Le 4 f?vr. 2014 ? 13:42, Bj?rn Gustavsson a ?crit : > (I am CC:ing Richard Carlsson since he wrote the cerl modules and the inliner.) > > On Tue, Feb 4, 2014 at 11:17 AM, Anthony Ramine wrote: >> Hello Bj?rn, >> >> I am wary of the call to cerl_clauses:match_list in cerl_inline, given that the returned bindings appear to be used. >> > > The important thing is the expressions passed to cerl_clauses:match_list/2. If > the inliner make sure hoisting any expression with a side-effect to an enclosing > 'let' as I did in my fix it will still be safe. > >> What do you think of making cerl_clauses:match_list returns {boolean(),Bindings,Aliases}? > > Perhaps. If there is a clear need for it. > > /Bjorn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From gtsiour@REDACTED Tue Feb 4 17:24:32 2014 From: gtsiour@REDACTED (Yiannis Tsiouris) Date: Tue, 04 Feb 2014 18:24:32 +0200 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <21231.37635.796179.810301@gargle.gargle.HOWL> References: <52EB9DFB.4090503@softlab.ntua.gr> <21229.5862.278527.71924@gargle.gargle.HOWL> <52EE9727.8010600@softlab.ntua.gr> <21231.37635.796179.810301@gargle.gargle.HOWL> Message-ID: <52F11440.1070103@softlab.ntua.gr> Hi all, On 02/03/2014 03:00 PM, Mikael Pettersson wrote: > Yiannis Tsiouris writes: > > > I belive your compiler and/or loader is doing something with relocations > > > that differs from the HiPE compiler, and therefore doesn't work with the > > > HiPE runtime. > > > > After that, I tried to investigate why that doesn't work for us. One > > test that fails is fun04.erl (attached). A small diff in the assembly > > generated by vanilla hipe and ErLLVM hipe reveals: > > > > Vanilla HiPE: > > ------------- > > a3 | | ._58: > > a3 | b800000000 | mov > > ${{{fun04,'-test/0-fun-0-',1},71147871,0},closure}, %eax > > a8 | 894604 | mov %eax, 0x4(%esi) > > ab | 8b4828 | mov 0x28(%eax), %ecx > > ae | 894e0c | mov %ecx, 0xc(%esi) > > b1 | c7461001000000 | mov $0x1, 0x10(%esi) > > b8 | 83c034 | add $0x34, %eax > > bb | e800000000 | call atomic_inc # [] 0x2 0 [] > > not_remote > > > > > > ErLLVM HiPE: > > ------------ > > # BB#13: > > movl $_2D_test_2F_0_2D_fun_2D_1_2D_, 4(%esi) > > movl _2D_test_2F_0_2D_fun_2D_1_2D_+40, %eax > > movl %eax, 12(%esi) > > movl $1, 16(%esi) > > leal _2D_test_2F_0_2D_fun_2D_1_2D_+52, %eax > > calll atomic_inc > > So for the 2nd and and 5th instructions above, I guess you generate > inital object code with 40 and 52, respectively, in the imm32 fields, > and then have relocation entries referring to those imm32s and the > _2D_test_2F_0_2D_fun_2D_1_2D_ label. If so then I can see why you > would want the runtime patcher to do += rather than =. > > In ELF terms, you're using Elf32_Rel while HiPE uses Elf32_Rela. > > > IMHO, I don't think that we violate any kind of "runtime invariant" by > > generating code in that way. I'd love to hear your opinion, too! :-) > > Your approach is reasonable. My concern is only that you're changing > the semantics of two HiPE runtime primitives, "justified" by the observation > that HiPE/x86 works also with the changed semantics. However: > > - these two primitives are implemented separately for each HiPE backend, > and there are currently 6 of those > - there is only one high-level loader, and it expects these primitives > to have essentially the same semantics for every backend > - you have suggested to change x86, but haven't considered the other > 5 backends; of those, at least 3 (ppc, ppc64, sparc) will need > non-trivial coding to implement += rather than = semantics > > I would be much happier if you'd initially just store 0 in those imm32 > fields, put label and offset in your relocation entries, and have your > loader perform the add and then call the runtime to "=" the imm32s. > > If your change to the x86 version of these primitives is accepted, > then we have to document that (a) x86 differs from the other backends, > and (b) the initial value of a patchable immmediate MUST be zero. Firstly, let me confess that I'd love to be able to solve this problem by passing a flag to the compiler (llc or gcc) that says: "please use the RELA relocations scheme". This would be by far the easiest and clearest solution of all! :-) However,... I 've been searching the web for hours to verify that this is a reasonable demand, i.e. a compiler should have a flag that sets the relocation model to something more than "static", "pic" or "dynamic-no-pic", and I couldn't find anything! Thus, I've been wondering: "WHY, dear god, can't I find this anywhere? Am I the first one to need that?". The clearest explanation that I've found [1] is that on x86 the ELF ABI *only* uses REL for relocations: > "REL relocations thus take 2 words of storage, and RELA relocations, 3. On > x86, the ELF ABI only uses REL relocations, and words are 32 bits, making > each relocation take 8 bytes ; on x86-64, the ELF ABI only uses RELA > relocations, and words are 64 bits, thus making each relocation take 24 > bytes, 3 times that of x86 relocations. On ARM, both may be used, but > apparently the compiler and the linker only use REL relocations." All things considered, I believe that the most clear solution would be to change the loader wherever needed. IMO, there's no reason to modify the other backends; documenting this behavior would be more than enough. Nevertheless, If you think that those changes increase the code complexity of the backend, I _might_ be able to hack a way around this by extracting the "addend" from the code segment and turning our "REL"s to "RELA"s, just before I feed them to hipe_unified_loader. The reason I say "I might" is that I 'm not 100% sure that I will be able to modify the "value" that will be patched by the loader in such a way that the addendum is effectively added, without changing the format of this value or adding an extra parameter here-and-there. ~Y. [1]: http://glandium.org/blog/?m=201011 -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Wed Feb 5 00:10:48 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 05 Feb 2014 01:10:48 +0200 Subject: [erlang-bugs] Use of public_key:private_key() in OTP_17.0-rc1 Message-ID: <52F17378.3030205@cs.ntua.gr> Various specs of file ssl/src/ssl_handshake.erl are referring to type public_key:private_key() but no such type is defined in this file. In fact, the public_key module does not export any type at all. The system is clearly in an inconsistent state. Can this please be fixed? Kostis From mikpelinux@REDACTED Wed Feb 5 09:46:44 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 5 Feb 2014 09:46:44 +0100 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <52F11440.1070103@softlab.ntua.gr> References: <52EB9DFB.4090503@softlab.ntua.gr> <21229.5862.278527.71924@gargle.gargle.HOWL> <52EE9727.8010600@softlab.ntua.gr> <21231.37635.796179.810301@gargle.gargle.HOWL> <52F11440.1070103@softlab.ntua.gr> Message-ID: <21233.64116.492109.647481@gargle.gargle.HOWL> Yiannis Tsiouris writes: > Hi all, > > On 02/03/2014 03:00 PM, Mikael Pettersson wrote: > > Yiannis Tsiouris writes: > > > > > I belive your compiler and/or loader is doing something with relocations > > > > that differs from the HiPE compiler, and therefore doesn't work with the > > > > HiPE runtime. > > > > > > After that, I tried to investigate why that doesn't work for us. One > > > test that fails is fun04.erl (attached). A small diff in the assembly > > > generated by vanilla hipe and ErLLVM hipe reveals: > > > > > > Vanilla HiPE: > > > ------------- > > > a3 | | ._58: > > > a3 | b800000000 | mov > > > ${{{fun04,'-test/0-fun-0-',1},71147871,0},closure}, %eax > > > a8 | 894604 | mov %eax, 0x4(%esi) > > > ab | 8b4828 | mov 0x28(%eax), %ecx > > > ae | 894e0c | mov %ecx, 0xc(%esi) > > > b1 | c7461001000000 | mov $0x1, 0x10(%esi) > > > b8 | 83c034 | add $0x34, %eax > > > bb | e800000000 | call atomic_inc # [] 0x2 0 [] > > > not_remote > > > > > > > > > ErLLVM HiPE: > > > ------------ > > > # BB#13: > > > movl $_2D_test_2F_0_2D_fun_2D_1_2D_, 4(%esi) > > > movl _2D_test_2F_0_2D_fun_2D_1_2D_+40, %eax > > > movl %eax, 12(%esi) > > > movl $1, 16(%esi) > > > leal _2D_test_2F_0_2D_fun_2D_1_2D_+52, %eax > > > calll atomic_inc > > > > So for the 2nd and and 5th instructions above, I guess you generate > > inital object code with 40 and 52, respectively, in the imm32 fields, > > and then have relocation entries referring to those imm32s and the > > _2D_test_2F_0_2D_fun_2D_1_2D_ label. If so then I can see why you > > would want the runtime patcher to do += rather than =. > > > > In ELF terms, you're using Elf32_Rel while HiPE uses Elf32_Rela. > > > > > IMHO, I don't think that we violate any kind of "runtime invariant" by > > > generating code in that way. I'd love to hear your opinion, too! :-) > > > > Your approach is reasonable. My concern is only that you're changing > > the semantics of two HiPE runtime primitives, "justified" by the observation > > that HiPE/x86 works also with the changed semantics. However: > > > > - these two primitives are implemented separately for each HiPE backend, > > and there are currently 6 of those > > - there is only one high-level loader, and it expects these primitives > > to have essentially the same semantics for every backend > > - you have suggested to change x86, but haven't considered the other > > 5 backends; of those, at least 3 (ppc, ppc64, sparc) will need > > non-trivial coding to implement += rather than = semantics > > > > I would be much happier if you'd initially just store 0 in those imm32 > > fields, put label and offset in your relocation entries, and have your > > loader perform the add and then call the runtime to "=" the imm32s. > > > > If your change to the x86 version of these primitives is accepted, > > then we have to document that (a) x86 differs from the other backends, > > and (b) the initial value of a patchable immmediate MUST be zero. > Firstly, let me confess that I'd love to be able to solve this problem by > passing a flag to the compiler (llc or gcc) that says: "please use the RELA > relocations scheme". This would be by far the easiest and clearest solution of > all! :-) However,... > > I 've been searching the web for hours to verify that this is a reasonable > demand, i.e. a compiler should have a flag that sets the relocation model to > something more than "static", "pic" or "dynamic-no-pic", and I couldn't find > anything! Thus, I've been wondering: "WHY, dear god, can't I find this anywhere? > Am I the first one to need that?". The clearest explanation that I've found [1] is > that on x86 the ELF ABI *only* uses REL for relocations: Note that it's ultimately the assembler not GCC that creates the relocations. I infer from the above that you're not using your own assembler, but instead are relying on GNU binutils or something like that to produce the object code. How lazy :-) > > "REL relocations thus take 2 words of storage, and RELA relocations, 3. On > > x86, the ELF ABI only uses REL relocations, and words are 32 bits, making > > each relocation take 8 bytes ; on x86-64, the ELF ABI only uses RELA > > relocations, and words are 64 bits, thus making each relocation take 24 > > bytes, 3 times that of x86 relocations. On ARM, both may be used, but > > apparently the compiler and the linker only use REL relocations." > > All things considered, I believe that the most clear solution would be to > change the loader wherever needed. IMO, there's no reason to modify the other > backends; documenting this behavior would be more than enough. Nevertheless, > If you think that those changes increase the code complexity of the backend, > I _might_ be able to hack a way around this by extracting the "addend" from the > code segment and turning our "REL"s to "RELA"s, just before I feed them to > hipe_unified_loader. The reason I say "I might" is that I 'm not 100% sure that > I will > be able to modify the "value" that will be patched by the loader in such a way that > the addendum is effectively added, without changing the format of this value or > adding an extra parameter here-and-there. If your loader has an reloc entry, then it could load address-of-imm32 into addend and send to the existing loader BIFs. /Mikael From essen@REDACTED Wed Feb 5 16:04:51 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 05 Feb 2014 16:04:51 +0100 Subject: [erlang-bugs] VM crash when using a matched binary as function Message-ID: <52F25313.8010000@ninenines.eu> Hello, The following code crashes the VM: -module(crashing). -compile(export_all). crash(Bin) -> crash(Bin, <<>>). crash(<<>>, Acc) -> Acc; crash(<< C, Rest/bits >>, Acc) -> %% There is no crash if we print the variable Rest before using it. %% Uncomment to see the difference. % io:format("~p~n", [Rest]), Rest(<< Acc/binary, C >>). The following happens: % erlc crashing.erl % erl Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source-8d71ab4] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> crashing:crash(<<"abc">>). size_object: matchstate term not allowedzsh: abort (core dumped) erl This is today's master, but it also happens at least with R16B02. While the code is clearly nonsense when you read it, it would be better if it wouldn't crash anymore in R17. -- Lo?c Hoguin http://ninenines.eu From bjorn@REDACTED Wed Feb 5 17:25:03 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 5 Feb 2014 17:25:03 +0100 Subject: [erlang-bugs] VM crash when using a matched binary as function In-Reply-To: <52F25313.8010000@ninenines.eu> References: <52F25313.8010000@ninenines.eu> Message-ID: On Wed, Feb 5, 2014 at 4:04 PM, Lo?c Hoguin wrote: > Hello, > > The following code crashes the VM: > > > -module(crashing). > -compile(export_all). > > crash(Bin) -> > crash(Bin, <<>>). > > crash(<<>>, Acc) -> > Acc; > crash(<< C, Rest/bits >>, Acc) -> > %% There is no crash if we print the variable Rest before using it. > %% Uncomment to see the difference. > % io:format("~p~n", [Rest]), > Rest(<< Acc/binary, C >>). > > Thanks for the bug report. Will fix (in the compiler). /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From schintke@REDACTED Wed Feb 5 17:39:32 2014 From: schintke@REDACTED (Florian Schintke) Date: Wed, 5 Feb 2014 17:39:32 +0100 Subject: [erlang-bugs] ets:new/2 and ets:all/0 concurrency issue Message-ID: <20140205163932.GA5399@csr-pc9.zib.de> Hi, suppose we call ets:new() and ets:all() in sequence. We expect to see the newly created table in the output of ets:all(). If a single process calls ets:new() and ets:all() in sequence everything works as expected. If two concurrent processes A and B call ets:new() and ets:all(), it can happen that the table created by process A is not listed in ets:all() output of process A, or the table created by process B is not listed in ets:all() of process B. This violates the sequential semantics one would expect from sequential code. Below is a minimal example to reproduce the issue. Tested with Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Typical output of the example: --- Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table not listed in ets:all() a bit later!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table not listed in ets:all() a bit later!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! Table not listed in ets:all()!!! Table listed shortly after!!! ... --- Kind regards, Florian -module(etstest). -export([test/0]). test() -> spawn(fun() -> test1() end), test1(), ok. test1() -> Table = ets:new(any_table_name, []), case lists:member(Table, ets:all()) of false -> io:format("Table not listed in ets:all()!!!~n"), timer:sleep(15), case lists:member(Table, ets:all()) of false -> io:format("Table not listed in ets:all() a bit later!!!~n"), false; true -> io:format("Table listed shortly after!!!~n"), true end; true -> ets:delete(Table) end, test1(). From jose.valim@REDACTED Wed Feb 5 18:16:40 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Wed, 5 Feb 2014 18:16:40 +0100 Subject: [erlang-bugs] Maps behaving oddly on update syntax with literal Message-ID: Hello folks, Maps are not working properly on update with a literal (via a var): -module(foo). -compile(export_all). %% This function does not fail (and it should) bar() -> M = #{}, M#{a := b}. %% This function fails horribly %% %% =ERROR REPORT==== 5-Feb-2014::18:10:18 === %% beam/beam_load.c(2065): Error loading function foo:baz/0: op update_map_exact p a r u u a a: %% no specific operation found baz() -> M = nil, M#{a := b}. I assume there is some sort of inlining happening and discarding useful information. As far as I can see, the Erlang Abstract Format is correct. Thank you! * Jos? Valimwww.plataformatec.com.br Founder and Lead Developer* -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Wed Feb 5 18:25:12 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Wed, 5 Feb 2014 18:25:12 +0100 Subject: [erlang-bugs] Maps behaving oddly on update syntax with literal In-Reply-To: References: Message-ID: Actually, it seems M#{a := b} always work when M is an empty map: -module(foo). -compile(export_all). bat(M) -> M#{a := b}. Here is my session: 1> foo:bat(#{a => b}). #{a => b} 2> foo:bat(#{b => b}). ** exception error: bad argument in function foo:bat/1 (foo.erl, line 5) 3> foo:bat(#{}). #{a => b} 3> was supposed to fail. Note (#{})#{a := b} works in the shell (eval). * Jos? Valimwww.plataformatec.com.br Founder and Lead Developer* On Wed, Feb 5, 2014 at 6:16 PM, Jos? Valim wrote: > Hello folks, > > Maps are not working properly on update with a literal (via a var): > > -module(foo). > -compile(export_all). > > %% This function does not fail (and it should) > bar() -> > M = #{}, > M#{a := b}. > > %% This function fails horribly > %% > %% =ERROR REPORT==== 5-Feb-2014::18:10:18 === > %% beam/beam_load.c(2065): Error loading function foo:baz/0: op > update_map_exact p a r u u a a: > %% no specific operation found > baz() -> > M = nil, > M#{a := b}. > > > I assume there is some sort of inlining happening and discarding useful > information. > As far as I can see, the Erlang Abstract Format is correct. > > Thank you! > > > * Jos? Valimwww.plataformatec.com.br > Founder and Lead Developer* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Wed Feb 5 18:29:13 2014 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 5 Feb 2014 18:29:13 +0100 Subject: [erlang-bugs] ets:new/2 and ets:all/0 concurrency issue In-Reply-To: <20140205163932.GA5399@csr-pc9.zib.de> References: <20140205163932.GA5399@csr-pc9.zib.de> Message-ID: <52F274E9.20009@erlang.org> Hello! Very nice and reproducible bug report! We've identified the problem and are aiming to have a fix for it by the 17.0 release. Thanks! Lukas On 05/02/14 17:39, Florian Schintke wrote: > Hi, > > suppose we call ets:new() and ets:all() in sequence. We expect to see > the newly created table in the output of ets:all(). > > If a single process calls ets:new() and ets:all() in sequence > everything works as expected. > > If two concurrent processes A and B call ets:new() and ets:all(), it > can happen that the table created by process A is not listed in > ets:all() output of process A, or the table created by process B is > not listed in ets:all() of process B. This violates the sequential > semantics one would expect from sequential code. > > Below is a minimal example to reproduce the issue. > > Tested with > > Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] > > Typical output of the example: > --- > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table not listed in ets:all() a bit later!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table not listed in ets:all() a bit later!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > Table not listed in ets:all()!!! > Table listed shortly after!!! > ... > --- > > Kind regards, > Florian > > > > > -module(etstest). > > -export([test/0]). > > test() -> > spawn(fun() -> test1() end), > test1(), > ok. > > test1() -> > Table = ets:new(any_table_name, []), > case lists:member(Table, ets:all()) of > false -> > io:format("Table not listed in ets:all()!!!~n"), > timer:sleep(15), > case lists:member(Table, ets:all()) of > false -> > io:format("Table not listed in ets:all() a bit later!!!~n"), > false; > true -> > io:format("Table listed shortly after!!!~n"), > true > end; > true -> > ets:delete(Table) > end, > test1(). > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From n.oxyde@REDACTED Wed Feb 5 18:39:18 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 5 Feb 2014 18:39:18 +0100 Subject: [erlang-bugs] Maps behaving oddly on update syntax with literal In-Reply-To: References: Message-ID: In erl_eval we have: ({map_assoc,K,V}, Mi) -> maps:put(K,V,Mi); ({map_exact,K,V}, Mi) -> maps:update(K,V,Mi) Shouldn?t it be the opposite? -- Anthony Ramine Le 5 f?vr. 2014 ? 18:25, Jos? Valim a ?crit : > 3> was supposed to fail. Note (#{})#{a := b} works in the shell (eval). From n.oxyde@REDACTED Wed Feb 5 18:40:43 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 5 Feb 2014 18:40:43 +0100 Subject: [erlang-bugs] Maps behaving oddly on update syntax with literal In-Reply-To: References: Message-ID: Nevermind, I understood by ? works in the shell ? that it didn?t fail. -- Anthony Ramine Le 5 f?vr. 2014 ? 18:39, Anthony Ramine a ?crit : > Shouldn?t it be the opposite? From egil@REDACTED Wed Feb 5 19:19:41 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 5 Feb 2014 19:19:41 +0100 Subject: [erlang-bugs] Maps behaving oddly on update syntax with literal In-Reply-To: References: Message-ID: <52F280BD.4060608@erlang.org> Thank you for reporting. =) The linter should realize it's not a map when dealing with literals. It's just pass-through atm which is plainly obvious. Try this: https://github.com/psyeugenic/otp/commits/egil/erts/fix-maps-beam_load .. heading back to compiler fixes .. // Bj?rn-Egil On 2014-02-05 18:25, Jos? Valim wrote: > Actually, it seems M#{a := b} always work when M is an empty map: > > -module(foo). > -compile(export_all). > > bat(M) -> > M#{a := b}. > > > Here is my session: > > 1> foo:bat(#{a => b}). > #{a => b} > 2> foo:bat(#{b => b}). > ** exception error: bad argument > in function foo:bat/1 (foo.erl, line 5) > 3> foo:bat(#{}). > #{a => b} > > > 3> was supposed to fail. Note (#{})#{a := b} works in the shell (eval). > > > > * > *Jos? Valim* > www.plataformatec.com.br > Founder and Lead Developer > * > > > On Wed, Feb 5, 2014 at 6:16 PM, Jos? Valim > wrote: > > Hello folks, > > Maps are not working properly on update with a literal (via a var): > > -module(foo). > -compile(export_all). > > %% This function does not fail (and it should) > bar() -> > M = #{}, > M#{a := b}. > > %% This function fails horribly > %% > %% =ERROR REPORT==== 5-Feb-2014::18:10:18 === > %% beam/beam_load.c(2065): Error loading function foo:baz/0: > op update_map_exact p a r u u a a: > %% no specific operation found > baz() -> > M = nil, > M#{a := b}. > > > I assume there is some sort of inlining happening and discarding > useful information. > As far as I can see, the Erlang Abstract Format is correct. > > Thank you! > > > * > *Jos? Valim* > www.plataformatec.com.br > Founder and Lead Developer > * > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Wed Feb 5 20:09:56 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Wed, 5 Feb 2014 20:09:56 +0100 Subject: [erlang-bugs] Maps behaving oddly on update syntax with literal In-Reply-To: <52F280BD.4060608@erlang.org> References: <52F280BD.4060608@erlang.org> Message-ID: Oops, now replying to the mailing list (sorry Bj?rn for getting this twice). I have tried the branch and both issues were fixed, thanks! Is M#{...} going to be changed to raise { badmap, M }? The examples above just raise: 1> foo:bar(). ** exception error: bad argument in function foo:bar/0 (foo.erl, line 6) And it would be nice to get a more detailed message. :) *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Wed Feb 5 20:17:35 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 5 Feb 2014 20:17:35 +0100 Subject: [erlang-bugs] Maps behaving oddly on update syntax with literal In-Reply-To: References: <52F280BD.4060608@erlang.org> Message-ID: <52F28E4F.20306@erlang.org> On 2014-02-05 20:09, Jos? Valim wrote: > Oops, now replying to the mailing list (sorry Bj?rn for getting this > twice). Aww. > > I have tried the branch and both issues were fixed, thanks! Great! > > Is M#{...} going to be changed to raise { badmap, M }? The examples > above just raise: Probably. > > 1> foo:bar(). > ** exception error: bad argument > in function foo:bar/0 (foo.erl, line 6) > > And it would be nice to get a more detailed message. :) The demands .. =D Hopefully this should be in place for RC2 .. but I haven't gotten to it yet. // Bj?rn-Egil > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schintke@REDACTED Wed Feb 5 20:20:54 2014 From: schintke@REDACTED (Florian Schintke) Date: Wed, 5 Feb 2014 20:20:54 +0100 Subject: [erlang-bugs] ets:new/2 and ets:all/0 concurrency issue In-Reply-To: <52F274E9.20009@erlang.org> References: <20140205163932.GA5399@csr-pc9.zib.de> <52F274E9.20009@erlang.org> Message-ID: <20140205192054.GD5399@csr-pc9.zib.de> Hi, thanks for the fast and positive reply, cool. Florian > Hello! > > Very nice and reproducible bug report! We've identified the problem > and are aiming to have a fix for it by the 17.0 release. > > Thanks! > Lukas From pgsql@REDACTED Thu Feb 6 06:20:49 2014 From: pgsql@REDACTED (Jeff Davis) Date: Wed, 05 Feb 2014 21:20:49 -0800 Subject: [erlang-bugs] Crash in wxErlang (17 rc1) Message-ID: <1391664049.15160.34.camel@jdavis> Attached program segfaults. I compiled erlang myself, so I could have done something wrong, but it seems to work otherwise. How I compiled it: ./configure --prefix=/home/jdavis/install/otp \ --enable-dirty-schedulers make && make install System: $ uname -a Linux jdavis 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=13.10 DISTRIB_CODENAME=saucy DISTRIB_DESCRIPTION="Ubuntu 13.10" $ aptitude search -F '%c %p' wx | grep ^i i libwxbase2.8-0 i libwxbase2.8-dev i libwxgtk-media2.8-0 libwxgtk2.8-0 i libwxgtk2.8-dev i python-wxgtk2.8 i python-wxversion i wx-common i wx2.8-headers Erlang: $ /home/jdavis/install/otp/bin/erl Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> c(crash). crash.erl:5: Warning: variable 'WX' is unused crash.erl:7: Warning: variable 'DC' is unused {ok,crash} 2> crash:draw(). Segmentation fault (core dumped) Regards, Jeff Davis -------------- next part -------------- A non-text attachment was scrubbed... Name: crash.erl Type: text/x-erlang Size: 121 bytes Desc: not available URL: From dangud@REDACTED Thu Feb 6 08:35:24 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Thu, 6 Feb 2014 08:35:24 +0100 Subject: [erlang-bugs] Crash in wxErlang (17 rc1) In-Reply-To: <1391664049.15160.34.camel@jdavis> References: <1391664049.15160.34.camel@jdavis> Message-ID: What are you trying to do? That code seg faults on all releases, you will always be able to crash wx if you try. If you write that code in C++ it will crash as well. /Dan On Thu, Feb 6, 2014 at 6:20 AM, Jeff Davis wrote: > Attached program segfaults. > > I compiled erlang myself, so I could have done something wrong, but it > seems to work otherwise. > > How I compiled it: > ./configure --prefix=/home/jdavis/install/otp \ > --enable-dirty-schedulers > make && make install > > System: > $ uname -a > Linux jdavis 3.11.0-15-generic #23-Ubuntu SMP > Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > $ cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=13.10 > DISTRIB_CODENAME=saucy > DISTRIB_DESCRIPTION="Ubuntu 13.10" > $ aptitude search -F '%c %p' wx | grep ^i > i libwxbase2.8-0 > i libwxbase2.8-dev > i libwxgtk-media2.8-0 libwxgtk2.8-0 > i libwxgtk2.8-dev > i python-wxgtk2.8 > i python-wxversion > i wx-common > i wx2.8-headers > > Erlang: > $ /home/jdavis/install/otp/bin/erl > Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source] [64-bit] > [smp:8:8] [ds:8:8:10] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V6.0 (abort with ^G) > 1> c(crash). > crash.erl:5: Warning: variable 'WX' is unused > crash.erl:7: Warning: variable 'DC' is unused > {ok,crash} > 2> crash:draw(). > Segmentation fault (core dumped) > > Regards, > Jeff Davis > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgud@REDACTED Thu Feb 6 09:19:43 2014 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 6 Feb 2014 09:19:43 +0100 Subject: [erlang-bugs] Segmentation fault when destroying a wx_object In-Reply-To: <59F5021A-72F1-4199-A525-1BFDA9F5A105@not2cool.com> References: <2640F898-792B-4769-A51F-034332E5A7FE@not2cool.com> <9E767FB5-E6C8-46F5-955E-5E7DC4E43792@not2cool.com> <1EFB37D9-C44E-492E-9933-A3BA2A838966@not2cool.com> <5A2FE278-10A9-4ADB-BC5E-FF3C327CF275@not2cool.com> <6F92D3FC-B862-44D7-A32E-F95290CDF782@not2cool.com> <59F5021A-72F1-4199-A525-1BFDA9F5A105@not2cool.com> Message-ID: Ok the previous patch I sent (off list) did not got through my own tests. I had to re-write the event handling but I think it got better. Can you please test https://github.com/dgud/otp/compare/erlang:master...dgud%2Fwx%2Ffix-cb-cleanup Or https://github.com/dgud/otp/tree/dgud/wx/fix-cb-cleanup /Dan On Tue, Feb 4, 2014 at 9:50 PM, Erlang wrote: > Dan > > Great job, it works perfectly now. > > Many thanks, > > Tom > > On 4 Feb 2014, at 15:42, Dan Gudmundsson wrote: > > Ok figured out was it is, wx tries to disconnect the eventhandler i.e. the > callback on the wxTextCtrl > when wxTextCtrl have been deleted already when the dialog was deleted. > > Since wx did not create the textctrl (xrc does that) the cleanup > mechanisms > doesn't get invoked when it is destructed. > > Workaround is disconnect the callbacks to such objects before, destroying > them.. > > Or delete the line: > Disconnect andalso (catch wxEvtHandler:disconnect_impl(CbH,O)), > in wxe_server > > Which I will do in R17 > > Thanks for the bug report and test case. > /Dan > > > On Fri, Jan 31, 2014 at 6:30 PM, Dan Gudmundsson wrote: > >> Ok, well then I will test more, write a test loop and see if I can >> reproduce it. >> Den 31 jan 2014 17:57 skrev "Erlang" : >> >> It does't matter which way it's closed. It's the call to destroy that >>> causes the crash (it doesn't occur every time). >>> >>> Tom >>> >>> >>> On 31 Jan 2014, at 16:50, Dan Gudmundsson wrote: >>> >>> No just configure should work now. >>> How do you close the window? >>> I just pressed the ok button.. >>> Den 31 jan 2014 17:38 skrev "Erlang" : >>> >>>> Yeah with wx3.0 64bit. Are there any specific flags you pass to wx when >>>> building? >>>> >>>> Cheers, >>>> >>>> Tom >>>> >>>> >>>> On 31 Jan 2014, at 16:23, Dan Gudmundsson wrote: >>>> >>>> Ok with wx 3.0? 64 bit? >>>> I will test some more on monday, don't have a Mac at home. >>>> >>>> Cheers >>>> Den 31 jan 2014 16:31 skrev "Erlang" : >>>> >>>>> Just tested on the pushed changes. The crash still occurs. >>>>> >>>>> Regards, >>>>> Tom >>>>> >>>>> >>>>> On 31 Jan 2014, at 08:54, Dan Gudmundsson wrote: >>>>> >>>>> A new master branch have been pushed to github can you please test if >>>>> it works now. >>>>> I guess you are already using wxWidgets-3.* something, or if not >>>>> upgrade. >>>>> >>>>> Regards >>>>> Dan >>>>> >>>>> >>>>> On Wed, Jan 29, 2014 at 6:07 PM, Dan Gudmundsson wrote: >>>>> >>>>>> I only tested with our internal master, give us a day or two to push >>>>>> the new things github. >>>>>> >>>>>> I will do another tomorrow with github master. >>>>>> Thanks for the good report. >>>>>> Den 29 jan 2014 17:42 skrev "Erlang" : >>>>>> >>>>>> Dan >>>>>>> >>>>>>> I've just built the mater branch from GitHub, and the fault still >>>>>>> occurs. I can prevent the fault occurring if I attach events to the >>>>>>> wxDialog (parent), and not a child control, but this isn't a complete >>>>>>> solution. >>>>>>> >>>>>>> Erlang solutions build with wx2.8 as far as I know. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> On 29 Jan 2014, at 16:00, Dan Gudmundsson wrote: >>>>>>> >>>>>>> Can not reproduce with linux and wxWidgets-2.8.12 or wxWidgets-3.1 >>>>>>> (i.e. master branch on github) >>>>>>> nor on darwin with erlang-r17-rc (coming soon) and wxWidgets-3.0 >>>>>>> >>>>>>> What wxWidgets is included in Mac R16B03 (32b) from erlang >>>>>>> solutions? >>>>>>> Is that still wxWidgets-2.8 or is it wxWidgets-3.0? >>>>>>> >>>>>>> I fixed some wx bugs in R16B03-1 and even more in the coming 17-rc >>>>>>> so hopefully it should be fixed now. >>>>>>> >>>>>>> Regards >>>>>>> /Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 29, 2014 at 10:37 AM, Erlang wrote: >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> Operating system: OSX 10.9.1 >>>>>>>> Erlang version: R16B03 >>>>>>>> Configure flags: --enable-darwin-64bit >>>>>>>> >>>>>>>> I'm getting a seg fault when the XRC dialog is destroyed. This also >>>>>>>> occurs on the 32bit pre-built binary of R16B03 from erlang-solutions (it >>>>>>>> does not occur on previous 32bit versions). It only occurs when event >>>>>>>> handlers are attached, and isn't specifically related to XRC as I get the >>>>>>>> same error when I destroy a wx_object contained within a wxAuiNotebook (the >>>>>>>> XRC sample was easier to reproduce). >>>>>>>> >>>>>>>> Run xrc:test/0 and simply close the dialog in the provided sample >>>>>>>> to reproduce the bug (it might require a few attempts). >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> erlang-bugs mailing list >>>>>>>> erlang-bugs@REDACTED >>>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuelrivas@REDACTED Thu Feb 6 09:50:22 2014 From: samuelrivas@REDACTED (Samuel) Date: Thu, 6 Feb 2014 09:50:22 +0100 Subject: [erlang-bugs] eunit_surefire doesn't ensure proper UTF-8 encoding In-Reply-To: References: <87r4ak1noc.fsf@mia.config> Message-ID: I have a patch somewhere that partially solves it by removing the wrong characters from the generated xml document. The real issue is in eunit however and is a bit more hairy to fix (not because the fix itself but because it is difficult to test), I also have an email explaining that somewhere. I can try to dig them up if it is of some use, but I cannot promise a patch for the root cause any soon. On 31 January 2014 14:28, Siri Hansen wrote: > Thanks for the report - I have written a ticket for this. A contribution > will of course speed up the handling... :) > /siri@REDACTED > > > 2013-11-15 Samuel : > >> We have seen this in the past, but we fixed it in our own surefire >> rebar plugin. If I remember right, the problem is not in >> eunit_surefire.erl but in eunit itself. Below some information I dug >> out of my emal (unfortunately I never found time to produce a proper >> patch for this: >> >> ------ >> I am pretty sure the patch >> >> https://github.com/richcarl/eunit/commit/9f505f1b8881f44c1e5d37df005533b2af6d6a7e >> does not solve the right problem. >> >> As far as I can understand, the output is already in binary state when >> it reaches the eunit_surefile code, which means that it is already >> encoded. The patch seems to work because the encoding happened to be >> latin1 (by coincidence) and then re-encoding to UTF8 works. >> >> The root issue seems to be in eunit_proc, that ignores the encoding of >> the io_requests and then buffer_to_binary just does list_to_binary. >> >> The patch seems to work because it does the right thing for codepoints >> between 127 and 255, as they are the same as the latin1 encoding for >> them. Thus they get properly encoded to utf-8 when writing the xml >> file, but will probably fail if the binary passed to eunit_surefile >> were properly encoded in utf-8. >> >> There is a major issue with that, and is that eunit_proc will crash if >> any test outputs a codepoint higher than 255, I think I have a proper >> fix for that but I haven't had the time to test it thoroughly yet. >> When fixed, the surefile report must be written in raw again, as the >> binaries should be utf8 encoded already. >> >> Next patch makes it work again, but is a hack, as it assumes the >> strings to be unicode in the list form and utf8 in the binary form >> (which I guess is true in current OTP implementation): >> >> -buffer_to_binary(Buf) -> list_to_binary(lists:reverse(Buf)). >> +buffer_to_binary(Buf) -> >> unicode:characters_to_binary(lists:reverse(Buf)). >> >> >> As an example, the attached suite causes this when run: >> >> > eunit_unicode_crash:test(). >> >> =ERROR REPORT==== 27-Aug-2012::14:26:49 === >> Error in process <0.78.0> with exit value: >> >> {badarg,[{erlang,list_to_binary,[[[[1013],"\n"]]],[]},{eunit_proc,buffer_to_binary,1,[{file,"eunit_proc.erl"},{line,276}]},{eunit_proc,group_leader_loop,3,[{file,"eunit_proc.erl"},{line,600}]}]} >> >> eunit_unicode_crash: unicode_test (module >> 'eunit_unicode_crash')...*skipped* >> undefined >> *unexpected termination of test process* >> ::{badarg,[{erlang,list_to_binary,[[[[1013],"\n"]]],[]}, >> {eunit_proc,buffer_to_binary,1, >> [{file,"eunit_proc.erl"},{line,276}]}, >> {eunit_proc,group_leader_loop,3, >> [{file,"eunit_proc.erl"},{line,600}]}]} >> >> On 13 November 2013 13:38, Magnus Henoch >> wrote: >> > Compile the following module and run eunit_xml_encoding_bug:doit() from >> > an Erlang shell: >> > >> > -module(eunit_xml_encoding_bug). >> > >> > -compile(export_all). >> > >> > -include_lib("eunit/include/eunit.hrl"). >> > >> > doit() -> >> > eunit:test(?MODULE, [{report, {eunit_surefire,[]}}]). >> > >> > my_test_() -> >> > ?_test(io:format([128,10])). >> > >> > This creates a file called TEST-eunit_xml_encoding_bug.xml which claims >> > to be in UTF-8 (its first line is '> > ?>') >> > but contains an improperly encoded character. Most XML tools will >> > refuse to do anything with such an XML file. For example xmllint says: >> > >> > $ xmllint /tmp/TEST-eunit_xml_encoding_bug.xml >> > /tmp/TEST-eunit_xml_encoding_bug.xml:4: parser error : Input is not >> > proper UTF-8, indicate encoding ! >> > >> > And opening the file in Firefox yields: >> > >> > XML Parsing Error: not well-formed >> > Location: file:///tmp/TEST-eunit_xml_encoding_bug.xml >> > Line Number 4, Column 17: >> > >> > I came across this problem when running a Quickcheck property inside >> > Eunit. The Quickcheck property would output random binary data with >> > io:format("~p"), and sometimes that would end up being high bytes which >> > were valid Latin-1 but invalid UTF-8. >> > >> > As eunit_surefire declares its output files to be in UTF-8 encoding, I >> > think it should check that the contents of etc are properly >> > encoded, and if not do something about it, e.g. convert from Latin-1 to >> > UTF-8 or insert replacement characters (U+FFFD). >> > >> > Regards, >> > Magnus >> > _______________________________________________ >> > erlang-bugs mailing list >> > erlang-bugs@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-bugs >> >> >> >> -- >> Samuel >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > -- Samuel From samuelrivas@REDACTED Thu Feb 6 09:52:23 2014 From: samuelrivas@REDACTED (Samuel) Date: Thu, 6 Feb 2014 09:52:23 +0100 Subject: [erlang-bugs] eunit_surefire doesn't ensure proper UTF-8 encoding In-Reply-To: References: <87r4ak1noc.fsf@mia.config> Message-ID: well, the email was already dug up by some past version of myself :), I should reread my own threads before responding On 6 February 2014 09:50, Samuel wrote: > I have a patch somewhere that partially solves it by removing the > wrong characters from the generated xml document. The real issue is in > eunit however and is a bit more hairy to fix (not because the fix > itself but because it is difficult to test), I also have an email > explaining that somewhere. > > I can try to dig them up if it is of some use, but I cannot promise a > patch for the root cause any soon. > > On 31 January 2014 14:28, Siri Hansen wrote: >> Thanks for the report - I have written a ticket for this. A contribution >> will of course speed up the handling... :) >> /siri@REDACTED >> >> >> 2013-11-15 Samuel : >> >>> We have seen this in the past, but we fixed it in our own surefire >>> rebar plugin. If I remember right, the problem is not in >>> eunit_surefire.erl but in eunit itself. Below some information I dug >>> out of my emal (unfortunately I never found time to produce a proper >>> patch for this: >>> >>> ------ >>> I am pretty sure the patch >>> >>> https://github.com/richcarl/eunit/commit/9f505f1b8881f44c1e5d37df005533b2af6d6a7e >>> does not solve the right problem. >>> >>> As far as I can understand, the output is already in binary state when >>> it reaches the eunit_surefile code, which means that it is already >>> encoded. The patch seems to work because the encoding happened to be >>> latin1 (by coincidence) and then re-encoding to UTF8 works. >>> >>> The root issue seems to be in eunit_proc, that ignores the encoding of >>> the io_requests and then buffer_to_binary just does list_to_binary. >>> >>> The patch seems to work because it does the right thing for codepoints >>> between 127 and 255, as they are the same as the latin1 encoding for >>> them. Thus they get properly encoded to utf-8 when writing the xml >>> file, but will probably fail if the binary passed to eunit_surefile >>> were properly encoded in utf-8. >>> >>> There is a major issue with that, and is that eunit_proc will crash if >>> any test outputs a codepoint higher than 255, I think I have a proper >>> fix for that but I haven't had the time to test it thoroughly yet. >>> When fixed, the surefile report must be written in raw again, as the >>> binaries should be utf8 encoded already. >>> >>> Next patch makes it work again, but is a hack, as it assumes the >>> strings to be unicode in the list form and utf8 in the binary form >>> (which I guess is true in current OTP implementation): >>> >>> -buffer_to_binary(Buf) -> list_to_binary(lists:reverse(Buf)). >>> +buffer_to_binary(Buf) -> >>> unicode:characters_to_binary(lists:reverse(Buf)). >>> >>> >>> As an example, the attached suite causes this when run: >>> >>> > eunit_unicode_crash:test(). >>> >>> =ERROR REPORT==== 27-Aug-2012::14:26:49 === >>> Error in process <0.78.0> with exit value: >>> >>> {badarg,[{erlang,list_to_binary,[[[[1013],"\n"]]],[]},{eunit_proc,buffer_to_binary,1,[{file,"eunit_proc.erl"},{line,276}]},{eunit_proc,group_leader_loop,3,[{file,"eunit_proc.erl"},{line,600}]}]} >>> >>> eunit_unicode_crash: unicode_test (module >>> 'eunit_unicode_crash')...*skipped* >>> undefined >>> *unexpected termination of test process* >>> ::{badarg,[{erlang,list_to_binary,[[[[1013],"\n"]]],[]}, >>> {eunit_proc,buffer_to_binary,1, >>> [{file,"eunit_proc.erl"},{line,276}]}, >>> {eunit_proc,group_leader_loop,3, >>> [{file,"eunit_proc.erl"},{line,600}]}]} >>> >>> On 13 November 2013 13:38, Magnus Henoch >>> wrote: >>> > Compile the following module and run eunit_xml_encoding_bug:doit() from >>> > an Erlang shell: >>> > >>> > -module(eunit_xml_encoding_bug). >>> > >>> > -compile(export_all). >>> > >>> > -include_lib("eunit/include/eunit.hrl"). >>> > >>> > doit() -> >>> > eunit:test(?MODULE, [{report, {eunit_surefire,[]}}]). >>> > >>> > my_test_() -> >>> > ?_test(io:format([128,10])). >>> > >>> > This creates a file called TEST-eunit_xml_encoding_bug.xml which claims >>> > to be in UTF-8 (its first line is '>> > ?>') >>> > but contains an improperly encoded character. Most XML tools will >>> > refuse to do anything with such an XML file. For example xmllint says: >>> > >>> > $ xmllint /tmp/TEST-eunit_xml_encoding_bug.xml >>> > /tmp/TEST-eunit_xml_encoding_bug.xml:4: parser error : Input is not >>> > proper UTF-8, indicate encoding ! >>> > >>> > And opening the file in Firefox yields: >>> > >>> > XML Parsing Error: not well-formed >>> > Location: file:///tmp/TEST-eunit_xml_encoding_bug.xml >>> > Line Number 4, Column 17: >>> > >>> > I came across this problem when running a Quickcheck property inside >>> > Eunit. The Quickcheck property would output random binary data with >>> > io:format("~p"), and sometimes that would end up being high bytes which >>> > were valid Latin-1 but invalid UTF-8. >>> > >>> > As eunit_surefire declares its output files to be in UTF-8 encoding, I >>> > think it should check that the contents of etc are properly >>> > encoded, and if not do something about it, e.g. convert from Latin-1 to >>> > UTF-8 or insert replacement characters (U+FFFD). >>> > >>> > Regards, >>> > Magnus >>> > _______________________________________________ >>> > erlang-bugs mailing list >>> > erlang-bugs@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-bugs >>> >>> >>> >>> -- >>> Samuel >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> > > > > -- > Samuel -- Samuel From sverker.eriksson@REDACTED Thu Feb 6 12:11:03 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 6 Feb 2014 12:11:03 +0100 Subject: [erlang-bugs] ets:new/2 and ets:all/0 concurrency issue In-Reply-To: <20140205163932.GA5399@csr-pc9.zib.de> References: <20140205163932.GA5399@csr-pc9.zib.de> Message-ID: <52F36DC7.5010907@erix.ericsson.se> On 02/05/2014 05:39 PM, Florian Schintke wrote: > Hi, > > suppose we call ets:new() and ets:all() in sequence. We expect to see > the newly created table in the output of ets:all(). > > If a single process calls ets:new() and ets:all() in sequence > everything works as expected. > > If two concurrent processes A and B call ets:new() and ets:all(), it > can happen that the table created by process A is not listed in > ets:all() output of process A, or the table created by process B is > not listed in ets:all() of process B. This violates the sequential > semantics one would expect from sequential code. > Just to clearify on the subject of ets:all() and concurrency. ets:all() does not give any guarantee of consistency. Each table created or deleted by other processes "during" the ets:all() call may or may not be included in the result. However, as pointed out, tables known to have been created/deleted *before* the call to ets:all() should of course be included/excluded in the result (or so they will in 17.0). /Sverker, Erlang/OTP From schintke@REDACTED Thu Feb 6 12:57:14 2014 From: schintke@REDACTED (Florian Schintke) Date: Thu, 6 Feb 2014 12:57:14 +0100 Subject: [erlang-bugs] ets:new/2 and ets:all/0 concurrency issue In-Reply-To: <52F36DC7.5010907@erix.ericsson.se> References: <20140205163932.GA5399@csr-pc9.zib.de> <52F36DC7.5010907@erix.ericsson.se> Message-ID: <20140206115714.GC7066@csr-pc9.zib.de> > Just to clearify on the subject of ets:all() and concurrency. > > ets:all() does not give any guarantee of consistency. Each table > created or deleted by other processes "during" the ets:all() call > may or may not be included in the result. > > However, as pointed out, tables known to have been created/deleted > *before* the call to ets:all() should of course be included/excluded > in the result (or so they will in 17.0). To 'know' may be a bit vague, so please could you clarify further which guarantee ets:all() should provide (and may be include it in the documentation then: (1) When process A creates/deletes a table T and sends a message to process B with the table id, process B will always see the change in the result of ets:all()? or (2) Inside a single process ets:all() represents locally known changes to table-existence (create/delete)? Cheers, Florian From sverker.eriksson@REDACTED Thu Feb 6 14:55:48 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 6 Feb 2014 14:55:48 +0100 Subject: [erlang-bugs] ets:new/2 and ets:all/0 concurrency issue In-Reply-To: <20140206115714.GC7066@csr-pc9.zib.de> References: <20140205163932.GA5399@csr-pc9.zib.de> <52F36DC7.5010907@erix.ericsson.se> <20140206115714.GC7066@csr-pc9.zib.de> Message-ID: <52F39464.9050004@erix.ericsson.se> On 02/06/2014 12:57 PM, Florian Schintke wrote: >> Just to clearify on the subject of ets:all() and concurrency. >> >> ets:all() does not give any guarantee of consistency. Each table >> created or deleted by other processes "during" the ets:all() call >> may or may not be included in the result. >> >> However, as pointed out, tables known to have been created/deleted >> *before* the call to ets:all() should of course be included/excluded >> in the result (or so they will in 17.0). > To 'know' may be a bit vague, so please could you clarify further > which guarantee ets:all() should provide (and may be include it in the > documentation then: > > (1) When process A creates/deletes a table T and sends a message to > process B with the table id, process B will always see the change in > the result of ets:all()? > > or > > (2) Inside a single process ets:all() represents locally known changes > to table-existence (create/delete)? > > By 'know' I mean your (1) with the extension that "sends a message to" can be any inter processes communication (!, TCP, ETS or any other protocol or shared memory) and "with the table id" is irrelevant. The important thing is that process B must 'know', when calling ets:all(), that process A has returned from ets:new or ets:delete to be guaranteed to see the result. Clear and precise formulations to be included in the docs are welcome :-) /Sverker From Ingela.Anderton.Andin@REDACTED Thu Feb 6 16:31:01 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 6 Feb 2014 16:31:01 +0100 Subject: [erlang-bugs] Fwd: Re: httpc keep-alive bug In-Reply-To: <52F3A530.1020900@ericsson.com> References: <52F3A530.1020900@ericsson.com> Message-ID: <52F3AAB5.2070000@ericsson.com> For the list also! -------- Original Message -------- Subject: Re: [erlang-bugs] httpc keep-alive bug Date: Thu, 6 Feb 2014 16:07:28 +0100 From: Ingela Anderton Andin To: jan_kowalski6669 Hi! I have created a ticket to look into and solve this problem, however I alas do not have time to personally track it down just at the moment as I am at home with my sick kid and have lots of other things to tend to also. If you are in hurry I suggest using the observer application to debug the situation and maybe come up with a patch. Regards Ingela Erlang/OTP team - Ericsson AB On 02/06/2014 03:30 PM, jan_kowalski6669 wrote: > Hi, > > did you receive my e-mail? > > W dniu 2014-02-03 11:21:21 u?ytkownik jan_kowalski6669 napisa?: >> Hi, >> >> Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [async-threads:10] [kernel-poll:false] >> >> ls /usr/local/lib/erlang/lib | grep inets >> inets-5.9.8 >> >> same error. >> >> >> W dniu 2014-01-31 17:45:07 u?ytkownik Ingela Anderton Andin napisa?: >>> Hi! >>> >>> Could you check if this is a problem even in the latest version, >>> inets-5.9.8? The code handling this has been changed since inets-5.9.5. >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> On 01/30/2014 12:14 PM, jan_kowalski6669 wrote: >>>> Hi, >>>> >>>> Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false] >>>> >>>> ls /usr/lib/erlang/lib/ | grep inets >>>> inets-5.9.5 >>>> >>>> W dniu 2014-01-30 12:01:45 u?ytkownik Ingela Anderton Andin napisa?: >>>>> Hi! >>>>> >>>>> Please state what version of inets application that you are using. >>>>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>> >>>>> >>>>> On 01/30/2014 11:04 AM, jan_kowalski6669 wrote: >>>>>> I have function: >>>>>> some_function(Url, Cookie, Command, Command2) -> >>>>>> httpc:request(post, {Url, [{"Cookie", Cookie}], "text/xml", Command}, >>>>>> [], [{socket_opts, [{keepalive, true}]}]), >>>>>> httpc:request(post, {Url, [{"Cookie", Cookie}], "text/xml", Command2}, >>>>>> [], [{socket_opts, [{keepalive, true}]}]). >>>>>> which sends two request to same Url with different command, one after >>>>>> another. >>>>>> Screenshot from wireshark: http://tinypic.com/view.php?pic=9s8m03&s=8 >>>>>> As you can see, in last call of some_function, first request is ok, but >>>>>> second is send to nowhere, and i got no response because first result >>>>>> was without keep-alive header, so second request should open new >>>>>> connection, but it didn't >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-bugs mailing list >>>>>> erlang-bugs@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > > > From essen@REDACTED Thu Feb 6 17:08:46 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Feb 2014 17:08:46 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? Message-ID: <52F3B38E.8050603@ninenines.eu> Hello, While trying to debug a separate SSL issue I added {versions, [sslv3]} to the listen call of the Cowboy test suite. This made everything break with huge error reports and the following stack trace: ** Reason for termination = ** {{case_clause,{4}}, [{ssl_v3,mac_hash,3,[{file,"ssl_v3.erl"},{line,163}]}, {tls_record,encode_plain_text,4,[{file,"tls_record.erl"},{line,134}]}, {tls_connection,encode_handshake,4, [{file,"tls_connection.erl"},{line,362}]}, {tls_connection,send_handshake,2, [{file,"tls_connection.erl"},{line,108}]}, {ssl_connection,client_certify_and_key_exchange,2, [{file,"ssl_connection.erl"},{line,1038}]}, {tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,458}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} It pretty much does that for every test. I'm guessing this is not intended. Does it with R16B02 and master from yesterday. Enjoy, -- Lo?c Hoguin http://ninenines.eu From n.oxyde@REDACTED Thu Feb 6 17:19:14 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 6 Feb 2014 17:19:14 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52F3B38E.8050603@ninenines.eu> References: <52F3B38E.8050603@ninenines.eu> Message-ID: The function ssl_v3:pad_1/1 and pad_2/1 don?t handle -define(SHA256, 4). -- Anthony Ramine Le 6 f?vr. 2014 ? 17:08, Lo?c Hoguin a ?crit : > Hello, > > While trying to debug a separate SSL issue I added {versions, [sslv3]} to the listen call of the Cowboy test suite. This made everything break with huge error reports and the following stack trace: > > ** Reason for termination = > ** {{case_clause,{4}}, > [{ssl_v3,mac_hash,3,[{file,"ssl_v3.erl"},{line,163}]}, > {tls_record,encode_plain_text,4,[{file,"tls_record.erl"},{line,134}]}, > {tls_connection,encode_handshake,4, > [{file,"tls_connection.erl"},{line,362}]}, > {tls_connection,send_handshake,2, > [{file,"tls_connection.erl"},{line,108}]}, > {ssl_connection,client_certify_and_key_exchange,2, > [{file,"ssl_connection.erl"},{line,1038}]}, > {tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,458}]}, > {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} > > It pretty much does that for every test. I'm guessing this is not intended. > > Does it with R16B02 and master from yesterday. > > Enjoy, > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From n.oxyde@REDACTED Thu Feb 6 17:33:14 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 6 Feb 2014 17:33:14 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: References: <52F3B38E.8050603@ninenines.eu> Message-ID: And judging from the spec, it shouldn?t handle it as only SHA1 and MD5 can be used there. -- Anthony Ramine Le 6 f?vr. 2014 ? 17:19, Anthony Ramine a ?crit : > The function ssl_v3:pad_1/1 and pad_2/1 don?t handle -define(SHA256, 4). > > -- > Anthony Ramine > > Le 6 f?vr. 2014 ? 17:08, Lo?c Hoguin a ?crit : > >> Hello, >> >> While trying to debug a separate SSL issue I added {versions, [sslv3]} to the listen call of the Cowboy test suite. This made everything break with huge error reports and the following stack trace: >> >> ** Reason for termination = >> ** {{case_clause,{4}}, >> [{ssl_v3,mac_hash,3,[{file,"ssl_v3.erl"},{line,163}]}, >> {tls_record,encode_plain_text,4,[{file,"tls_record.erl"},{line,134}]}, >> {tls_connection,encode_handshake,4, >> [{file,"tls_connection.erl"},{line,362}]}, >> {tls_connection,send_handshake,2, >> [{file,"tls_connection.erl"},{line,108}]}, >> {ssl_connection,client_certify_and_key_exchange,2, >> [{file,"ssl_connection.erl"},{line,1038}]}, >> {tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,458}]}, >> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, >> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} >> >> It pretty much does that for every test. I'm guessing this is not intended. >> >> Does it with R16B02 and master from yesterday. >> >> Enjoy, >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From essen@REDACTED Thu Feb 6 17:34:28 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Feb 2014 17:34:28 +0100 Subject: [erlang-bugs] SSL socket gets closed abruptly Message-ID: <52F3B994.6010203@ninenines.eu> Hello, I had the weirdest experience today. Let me describe it. I added a test to the Cowboy test suite. That test sends more or less 19MB of data to the server, which replies with 200 OK and no body. The test worked for HTTP, but not for HTTPS (and similarly, worked with HTTP + reply compression but not HTTPS + reply compression). Instead of getting a response, the test received {error, closed}. Here is where it starts to get interesting: Changing the reponse status code from 200 to anything else made the response be sent successfully. Everything other than 200 that I tried worked. But sending 200 was leading to the socket being closed before anything got sent. On the other hand, on the Cowboy side of things, everything looked like it was sent. No errors or anything. And adding a few timer:sleep here and there didn't change a thing, it was still failing. So I tried changing which tests were ran and reduced their number. Below a certain number of tests ran in parallel the test passed. Above a certain number the test failed. Running the tests sequential made the test succeed. Then another weird thing. Removing the test that reads from /dev/urandom made the failing test succeed. But leaving only these 2 tests in made the test pass successfully. I continued to investigate and tried all Erlang versions from R15B01 to master. The failure occurred only from R16B onward. Then I tried a few other things (see previous mail) but for some reason the failure doesn't occur anymore. I cannot reproduce my previous issue. I do not know what the issue was. Perhaps cosmic rays. I did not try going into a bunker to see if it happened there too. But I figured you might have a clue about it and potentially figure out a very weird bug in the SSL code. Since my issue magically fixed itself I can continue with my work, at least. Enjoy! -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Thu Feb 6 17:38:04 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Feb 2014 17:38:04 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: References: <52F3B38E.8050603@ninenines.eu> Message-ID: <52F3BA6C.8070705@ninenines.eu> Not sure if it matters but the issue happens regardless of 'ciphers' being specified. On 02/06/2014 05:33 PM, Anthony Ramine wrote: > And judging from the spec, it shouldn?t handle it as only SHA1 and MD5 can be used there. > -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Thu Feb 6 17:46:15 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Feb 2014 17:46:15 +0100 Subject: [erlang-bugs] SSL socket gets closed abruptly In-Reply-To: <52F3B994.6010203@ninenines.eu> References: <52F3B994.6010203@ninenines.eu> Message-ID: <52F3BC57.6020700@ninenines.eu> On 02/06/2014 05:34 PM, Lo?c Hoguin wrote: > Since my issue magically fixed itself I can continue with my work, at > least. Scratch that, I forgot that I attempted to reduce the size being sent (2MB instead of 19MB) and sending less "fixed it". So I'm back to being able to reproduce. I will attempt to bisect tomorrow. Note that when I tried doing a simpler example in its own module I wasn't able to reproduce it, so I'm pretty much stuck with trying the test suite until I find the faulty commit, and won't be able to give much more than that. -- Lo?c Hoguin http://ninenines.eu From ingela.anderton.andin@REDACTED Thu Feb 6 17:46:16 2014 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Thu, 6 Feb 2014 17:46:16 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: References: <52F3B38E.8050603@ninenines.eu> Message-ID: <52F3BC58.2060009@erix.ericsson.se> Hi! In SSL V3 you are not supposed to get sha256! Have you tried running our test cases? We have a lot of test cases that run SSL-v3 that passes in our environment. I suppose it could be an option handling bug somehow as ssl have lots of options and we could have missed some combination of options. Regards Ingela Erlang/OTP team - Ericsson AB On 02/06/2014 05:33 PM, Anthony Ramine wrote: > And judging from the spec, it shouldn?t handle it as only SHA1 and MD5 can be used there. > From essen@REDACTED Thu Feb 6 17:59:34 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Feb 2014 17:59:34 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52F3BC58.2060009@erix.ericsson.se> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> Message-ID: <52F3BF76.2070507@ninenines.eu> Just [{cert, Cert}, {key, Key}, {port, 0}, {versions, [sslv3]}] does it. The certificate and key are generated using the module from the SSL test suite for generating test certificates. I have not tried to run the SSL test suite yet, I will take a look tomorrow. On 02/06/2014 05:46 PM, Ingela Anderton Andin wrote: > Hi! > > In SSL V3 you are not supposed to get sha256! Have you tried running > our test cases? We have a lot of test cases that run SSL-v3 that passes > in our environment. I suppose it could be an option handling bug somehow > as ssl have lots of options and we could have missed > some combination of options. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > On 02/06/2014 05:33 PM, Anthony Ramine wrote: >> And judging from the spec, it shouldn?t handle it as only SHA1 and MD5 >> can be used there. >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- Lo?c Hoguin http://ninenines.eu From tuncer.ayaz@REDACTED Thu Feb 6 19:45:55 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 6 Feb 2014 19:45:55 +0100 Subject: [erlang-bugs] Use of public_key:private_key() in OTP_17.0-rc1 In-Reply-To: <52F17378.3030205@cs.ntua.gr> References: <52F17378.3030205@cs.ntua.gr> Message-ID: On Wed, Feb 5, 2014 at 12:10 AM, Kostis Sagonas wrote: > Various specs of file ssl/src/ssl_handshake.erl are referring to > type public_key:private_key() but no such type is defined in this > file. > > In fact, the public_key module does not export any type at all. > > The system is clearly in an inconsistent state. Can this please be > fixed? Kostis, can you please verify https://github.com/erlang/otp/pull/227 works for you? From ingela.anderton.andin@REDACTED Thu Feb 6 21:29:50 2014 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Thu, 6 Feb 2014 21:29:50 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52F3BF76.2070507@ninenines.eu> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> Message-ID: <52F3F0BE.9090409@erix.ericsson.se> Hi! On 02/06/2014 05:59 PM, Lo?c Hoguin wrote: > Just [{cert, Cert}, {key, Key}, {port, 0}, {versions, [sslv3]}] does it. You mean that you get it when you input certs as binaries? Could it be related to https://github.com/erlang/otp/pull/163 We want to include this pull request but it solves two problems and only one persists and we are waiting for the pull request to be updated. Regards Ingela Erlang/OTP team - Ericsson AB > > The certificate and key are generated using the module from the SSL > test suite for generating test certificates. > > I have not tried to run the SSL test suite yet, I will take a look > tomorrow. > > On 02/06/2014 05:46 PM, Ingela Anderton Andin wrote: >> Hi! >> >> In SSL V3 you are not supposed to get sha256! Have you tried running >> our test cases? We have a lot of test cases that run SSL-v3 that passes >> in our environment. I suppose it could be an option handling bug somehow >> as ssl have lots of options and we could have missed >> some combination of options. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> On 02/06/2014 05:33 PM, Anthony Ramine wrote: >>> And judging from the spec, it shouldn?t handle it as only SHA1 and MD5 >>> can be used there. >>> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From andrew@REDACTED Thu Feb 6 22:26:47 2014 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 6 Feb 2014 16:26:47 -0500 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52F3F0BE.9090409@erix.ericsson.se> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> Message-ID: <20140206212647.GP9655@hijacked.us> On Thu, Feb 06, 2014 at 09:29:50PM +0100, Ingela Anderton Andin wrote: > Hi! > > On 02/06/2014 05:59 PM, Lo?c Hoguin wrote: > >Just [{cert, Cert}, {key, Key}, {port, 0}, {versions, [sslv3]}] does it. > > You mean that you get it when you input certs as binaries? Could it > be related to https://github.com/erlang/otp/pull/163 > We want to include this pull request but it solves two problems and > only one persists and we are waiting for the pull > request to be updated. Why is the discussion for that PR not happening in that PR? Andrew From EMcDowell@REDACTED Thu Feb 6 22:28:57 2014 From: EMcDowell@REDACTED (McDowell, Edward D.) Date: Thu, 6 Feb 2014 16:28:57 -0500 Subject: [erlang-bugs] Inserting new keys into maps is very slow (R17rc1) Message-ID: <79EEF8FD7A3DA9458F4886A20D3F35B4025389F2E653@mailsvr4.RICOL.EDU> maps:put/3 in R17rc1 on Windows (64 bit) runs slowly when a large number of randomly generated keys are inserted into a map. The following table shows that the time to insert n keys grows quadratically, so the time to insert a single key grows linearly. Note that performance is greatly improved by using a dict (from stdlib). Number Insert into map Insert into dict of keys (milliseconds) (milliseconds) 10000 969 16 20000 4031 62 40000 15937 172 80000 63734 453 The following code was used for these tests. The dict tests used the same code with dict:new/0 and dict:store/3 replacing maps:new/0 and maps:put/3, respectively. -module(testmap). -export([start/1]). loop(Map, 0) -> Map; loop(Map, Times) -> Key = random:uniform(999999), loop(maps:put(Key, true, Map), Times - 1). start(NumKeys) -> {A, B, C} = now(), random:seed(A, B, C), Before = (1000000 * A + B) * 1000 + C div 1000, loop(maps:new(), NumKeys), {E, F, G} = now(), After = (1000000 * E + F) * 1000 + G div 1000, io:format("Elapsed time: ~w milliseconds.~n", [After - Before]). -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ingela.Anderton.Andin@REDACTED Thu Feb 6 22:36:13 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 6 Feb 2014 22:36:13 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <20140206212647.GP9655@hijacked.us> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <20140206212647.GP9655@hijacked.us> Message-ID: <52F4004D.8060109@ericsson.com> Hi! On 02/06/2014 10:26 PM, Andrew Thompson wrote: > On Thu, Feb 06, 2014 at 09:29:50PM +0100, Ingela Anderton Andin wrote: >> Hi! >> >> On 02/06/2014 05:59 PM, Lo?c Hoguin wrote: >>> Just [{cert, Cert}, {key, Key}, {port, 0}, {versions, [sslv3]}] does it. >> >> You mean that you get it when you input certs as binaries? Could it >> be related to https://github.com/erlang/otp/pull/163 >> We want to include this pull request but it solves two problems and >> only one persists and we are waiting for the pull >> request to be updated. > > Why is the discussion for that PR not happening in that PR? Humm strange, it is our opens source maintainer that usually adds the comments to the pull requests, I will have to ask him about that. I will add a comment to the pull request. Regards Ingela Eralng/OTP team - Ericsson AB From dangud@REDACTED Thu Feb 6 22:37:24 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Thu, 6 Feb 2014 22:37:24 +0100 Subject: [erlang-bugs] Inserting new keys into maps is very slow (R17rc1) In-Reply-To: <79EEF8FD7A3DA9458F4886A20D3F35B4025389F2E653@mailsvr4.RICOL.EDU> References: <79EEF8FD7A3DA9458F4886A20D3F35B4025389F2E653@mailsvr4.RICOL.EDU> Message-ID: Large maps are currently not optimized, that part is not implemented yet, you should currently only use them for less than 100 keys... It is on the todo list.. On Thu, Feb 6, 2014 at 10:28 PM, McDowell, Edward D. wrote: > maps:put/3 in R17rc1 on Windows (64 bit) runs slowly when a > > large number of randomly generated keys are inserted into a > > map. The following table shows that the time to insert n > > keys grows quadratically, so the time to insert a single key > > grows linearly. Note that performance is greatly improved > > by using a dict (from stdlib). > > > > Number Insert into map Insert into dict > > of keys (milliseconds) (milliseconds) > > 10000 969 16 > > 20000 4031 62 > > 40000 15937 172 > > 80000 63734 453 > > > > The following code was used for these tests. The dict > > tests used the same code with dict:new/0 and dict:store/3 > > replacing maps:new/0 and maps:put/3, respectively. > > > > -module(testmap). > > -export([start/1]). > > > > loop(Map, 0) -> Map; > > loop(Map, Times) -> > > Key = random:uniform(999999), > > loop(maps:put(Key, true, Map), Times - 1). > > > > start(NumKeys) -> > > {A, B, C} = now(), > > random:seed(A, B, C), > > Before = (1000000 * A + B) * 1000 + C div 1000, > > loop(maps:new(), NumKeys), > > {E, F, G} = now(), > > After = (1000000 * E + F) * 1000 + G div 1000, > > io:format("Elapsed time: ~w milliseconds.~n", > > [After - Before]). > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nekotaroh@REDACTED Fri Feb 7 02:21:40 2014 From: nekotaroh@REDACTED (yoshiyuki kanno) Date: Fri, 7 Feb 2014 10:21:40 +0900 Subject: [erlang-bugs] Segfault on Erlang VM Message-ID: Hello I'm getting some segfaults on some Erlang VMs while I have tested LeoFS(http://www.leofs.org) that is a distributed file sytem written in Erlang. I could reproduce this issue on a LeoFS cluster with specific workroads, but it's difficult to reproduce and survey for others. So I tried to make reproducable code as minimum as possible and put codes, environments, how to reproduce, backtrace when segfault occured into below gist. - Case1: Segfault in case using file:pread https://gist.github.com/mocchira/5be2d86033a408c113d1 - Case2: Segfault in case constructing Binary https://gist.github.com/mocchira/2dc016c2c0630b95821b Please let me know if you have any questions. BR. -------------------------------------------------------- Yoshiyuki Kanno LeoFS Committer(http://www.leofs.org) -------------------------------------------------------- Stoic Corp. URL: http://www.stoic.co.jp/ E-mail: yoshiyuki.kanno@REDACTED From pgsql@REDACTED Fri Feb 7 07:29:25 2014 From: pgsql@REDACTED (Jeff Davis) Date: Thu, 06 Feb 2014 22:29:25 -0800 Subject: [erlang-bugs] Crash in wxErlang (17 rc1) In-Reply-To: References: <1391664049.15160.34.camel@jdavis> Message-ID: <1391754565.15160.37.camel@jdavis> On Thu, 2014-02-06 at 08:35 +0100, Dan Gudmundsson wrote: > What are you trying to do? > > > That code seg faults on all releases, > you will always be able to crash wx if you try. > > > If you write that code in C++ it will crash as well. > I'm trying to learn both erlang and wx. As a user, my understanding of erlang is that it is not supposed to segfault unless I have some misbehaving NIF or something. Are there other built-in libraries that can cause crashes? I was actually pretty happy with gs because it's so simple, but I see that it's deprecated now. Regards, Jeff Davis From dangud@REDACTED Fri Feb 7 07:59:36 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 7 Feb 2014 07:59:36 +0100 Subject: [erlang-bugs] Crash in wxErlang (17 rc1) In-Reply-To: <1391754565.15160.37.camel@jdavis> References: <1391664049.15160.34.camel@jdavis> <1391754565.15160.37.camel@jdavis> Message-ID: Well the documentation is minimal, so I suggest you take a look at the samples in the wx/examples directory. After the minimal and hello world examples: Run wx:demo(). which have exemplifies some more widgets with code displayed. The demo needs more examples, so if you want to start with something simple patches are accepted :-) Larger and probably better code is in observer, as we/I learn wxWidgets the more we use it. But yes wx is a just a thin wrapper on top of wxWidgets so if you do stuff that is not expected or wrong it will crash. I have tried to hinder crashes as much as I could. To be safe from crashes somebody will have to write a layer on top wx which keeps a state of what is happening and what is allowed, a gs on top wx.. /Dan PS: Steve I have set you up here :-) On Fri, Feb 7, 2014 at 7:29 AM, Jeff Davis wrote: > On Thu, 2014-02-06 at 08:35 +0100, Dan Gudmundsson wrote: > > What are you trying to do? > > > > > > That code seg faults on all releases, > > you will always be able to crash wx if you try. > > > > > > If you write that code in C++ it will crash as well. > > > I'm trying to learn both erlang and wx. > > As a user, my understanding of erlang is that it is not supposed to > segfault unless I have some misbehaving NIF or something. Are there > other built-in libraries that can cause crashes? > > I was actually pretty happy with gs because it's so simple, but I see > that it's deprecated now. > > Regards, > Jeff Davis > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Feb 7 11:01:33 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 11:01:33 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52F3F0BE.9090409@erix.ericsson.se> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> Message-ID: <52F4AEFD.4090802@ninenines.eu> On 02/06/2014 09:29 PM, Ingela Anderton Andin wrote: > Hi! > > On 02/06/2014 05:59 PM, Lo?c Hoguin wrote: >> Just [{cert, Cert}, {key, Key}, {port, 0}, {versions, [sslv3]}] does it. > > You mean that you get it when you input certs as binaries? Could it be > related to https://github.com/erlang/otp/pull/163 > We want to include this pull request but it solves two problems and > only one persists and we are waiting for the pull > request to be updated. I don't have any idea what that pull request is about. I am not too well versed in SSL-fu. I narrowed it down a little. The previously mentioned issue only happens with a test certificate generated by erl_make_certs.erl. A different report happens with a certificate generated by OpenSSL (again, setting versions to [sslv3]). =ERROR REPORT==== 7-Feb-2014::10:55:57 === SSL: certify: tls_connection.erl:2286:Fatal error: decrypt error =ERROR REPORT==== 7-Feb-2014::10:55:57 === SSL: certify: tls_connection.erl:2055:Fatal error: decrypt error {error,{tls_alert,"decrypt error"}} The client in all cases is always: ssl:connect("localhost", 44443, []). I can provide a test case for either or both of them if you want. -- Lo?c Hoguin http://ninenines.eu From Ingela.Anderton.Andin@REDACTED Fri Feb 7 11:10:17 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Fri, 7 Feb 2014 11:10:17 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52F4AEFD.4090802@ninenines.eu> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> Message-ID: <52F4B109.3060602@ericsson.com> Hi! If you can provide a failing test case that is a good place to start. I will not have time to look at it until Monday as I am looking after my sick daughter today, and just quickly answering some mails. Regards Ingela Erlang/OTP team On 02/07/2014 11:01 AM, Lo?c Hoguin wrote: > On 02/06/2014 09:29 PM, Ingela Anderton Andin wrote: >> Hi! >> >> On 02/06/2014 05:59 PM, Lo?c Hoguin wrote: >>> Just [{cert, Cert}, {key, Key}, {port, 0}, {versions, [sslv3]}] does it. >> >> You mean that you get it when you input certs as binaries? Could it be >> related to https://github.com/erlang/otp/pull/163 >> We want to include this pull request but it solves two problems and >> only one persists and we are waiting for the pull >> request to be updated. > > I don't have any idea what that pull request is about. I am not too well > versed in SSL-fu. > > I narrowed it down a little. > > The previously mentioned issue only happens with a test certificate > generated by erl_make_certs.erl. > > A different report happens with a certificate generated by OpenSSL > (again, setting versions to [sslv3]). > > =ERROR REPORT==== 7-Feb-2014::10:55:57 === > SSL: certify: tls_connection.erl:2286:Fatal error: decrypt error > > =ERROR REPORT==== 7-Feb-2014::10:55:57 === > SSL: certify: tls_connection.erl:2055:Fatal error: decrypt error > {error,{tls_alert,"decrypt error"}} > > The client in all cases is always: > > ssl:connect("localhost", 44443, []). > > I can provide a test case for either or both of them if you want. > From essen@REDACTED Fri Feb 7 14:39:09 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 14:39:09 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52F4B109.3060602@ericsson.com> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> <52F4B109.3060602@ericsson.com> Message-ID: <52F4E1FD.30600@ninenines.eu> Please see attached. For the first test, you need the certificate files you can find in Cowboy's SSL example (link is in the source). I just noticed that the error for that test is more verbose in master. Not sure if that's a good thing. For the second test, you need the erl_make_certs module found in OTP's SSL application's test directory. The output should be as follow. (YES people I am aware certificates and keys are included in the error reports. They are either generated or already public. You do not need to warn me about it. Thank you.) Enjoy! % erl Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source-8d71ab4] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> c(sslv3bug_1). {ok,sslv3bug_1} 2> c(sslv3bug_2). {ok,sslv3bug_2} 3> c(erl_make_certs). {ok,erl_make_certs} 4> sslv3bug_1:server(). <0.68.0> 5> sslv3bug_1:client(). =ERROR REPORT==== 7-Feb-2014::14:35:36 === ** State machine <0.74.0> terminating ** Last message in was {tcp,#Port<0.2567>, <<37,242,6,108,56,11,13,53,8,124,121,177,224,225, 74,202,119,55,113,255,149,182,187,112,63,249,32, 228,11,30,87,232,165,85,99,178,130,29,69,122, 197,117,97,20,209,0,128,136,95,242,23,13,180,70, 30,115,142,31,209,46,215,77,113,218,250,191,165, 223,25,10,73,119,196,193,108,146,14,209,250,122, 14,168,170,188,149,168,235,67,252,6,247,29,253, 203,253,219,114,161,112,19,44,197,60,251,26,190, 160,118,235,40,75,100,81,153,153,107,93,130,70, 102,64,164,164,36,39,3,163,252,87,176,128,254, 50,178,252,223,25,107,98,52,145,153,209,255,18, 204,185,75,211,101,202,78,164,43,82,238,252,120, 56,137,64,208,253,151,232,123,135,223,95,130, 171,67,78,244,44,22,3,0,0,4,14,0,0,0>>} ** When State == certify ** Data == {state,client, {#Ref<0.0.0.971>,<0.33.0>}, gen_tcp,tls_connection,tcp,tcp_closed,tcp_error, "localhost",44443,#Port<0.2567>, {ssl_options,undefined, [{3,3},{3,2},{3,1},{3,0}], verify_none, {#Fun,[]}, false,false,undefined,1,<<>>,undefined,<<>>, undefined,undefined,undefined,<<>>,undefined, undefined,undefined,undefined,undefined, [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, <<0,107>>, <<0,106>>, <<0,61>>, <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, <<0,103>>, <<0,64>>, <<0,60>>, <<"?\n">>, <<192,20>>, <<0,57>>, <<0,56>>, <<192,5>>, <<192,15>>, <<0,53>>, <<"?\b">>, <<192,18>>, <<0,22>>, <<0,19>>, <<192,3>>, <<"?\r">>, <<0,10>>, <<"?\t">>, <<192,19>>, <<0,51>>, <<0,50>>, <<192,4>>, <<192,14>>, <<0,47>>, <<192,7>>, <<192,17>>, <<0,5>>, <<0,4>>, <<0,21>>, <<192,2>>, <<"?\f">>, <<0,9>>], #Fun,true,268435456,false,undefined, undefined,false,undefined,undefined,true,undefined, false}, {socket_options,list,0,0,0,true}, {connection_states, {connection_state, {security_parameters, <<0,0>>, 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, undefined,undefined}, undefined,undefined,undefined,undefined,2,true, undefined,undefined}, {connection_state, {security_parameters,<<"?(">>,1,7,1,16,256,32, unknown,5,5,48,0,undefined, <<82,244,225,40,177,238,52,250,53,57,12,72,96, 92,157,86,51,250,227,239,173,167,250,154,25, 29,237,89,176,188,61,181>>, <<82,244,225,40,43,69,20,224,136,14,240,93, 225,76,191,156,202,163,215,89,28,56,98,213, 12,49,173,48,191,102,81,223>>, undefined}, undefined,undefined,undefined,undefined, undefined,true,undefined,undefined}, {connection_state, {security_parameters, <<0,0>>, 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, undefined,undefined}, undefined,undefined,undefined,undefined,1,true, undefined,undefined}, {connection_state, {security_parameters,<<"?(">>,1,7,1,16,256,32, unknown,5,5,48,0,undefined, <<82,244,225,40,177,238,52,250,53,57,12,72,96, 92,157,86,51,250,227,239,173,167,250,154,25, 29,237,89,176,188,61,181>>, <<82,244,225,40,43,69,20,224,136,14,240,93, 225,76,191,156,202,163,215,89,28,56,98,213, 12,49,173,48,191,102,81,223>>, undefined}, undefined,undefined,undefined,undefined, undefined,true,undefined,undefined}}, {protocol_buffers,[], <<22,3,0,0,203,12,0,0,199,3,0,23,65,4,112,42,53,141, 46,236,29,236,36,128,99,108,209,39,230,153,96,212,8>>, <<>>,[]}, {[<<11,0,5,46,0,5,43,0,2,169,48,130,2,165,48,130,2,14,160, 3,2,1,2,2,9,0,235,233,83,76,182,123,146,121,48,13,6,9, 42,134,72,134,247,13,1,1,5,5,0,48,85,49,11,48,9,6,3, 85,4,6,19,2,85,83,49,14,48,12,6,3,85,4,8,12,5,84,101, 120,97,115,49,19,48,17,6,3,85,4,10,12,10,78,105,110, 101,32,78,105,110,101,115,49,15,48,13,6,3,85,4,11,12, 6,67,111,119,98,111,121,49,16,48,14,6,3,85,4,3,12,7, 82,79,79,84,32,67,65,48,30,23,13,49,51,48,50,50,56,48, 53,50,51,51,52,90,23,13,51,51,48,50,50,51,48,53,50,51, 51,52,90,48,87,49,11,48,9,6,3,85,4,6,19,2,85,83,49,14, 48,12,6,3,85,4,8,12,5,84,101,120,97,115,49,19,48,17,6, 3,85,4,10,12,10,78,105,110,101,32,78,105,110,101,115, 49,15,48,13,6,3,85,4,11,12,6,67,111,119,98,111,121,49, 18,48,16,6,3,85,4,3,12,9,108,111,99,97,108,104,111, 115,116,48,129,159,48,13,6,9,42,134,72,134,247,13,1,1, 1,5,0,3,129,141,0,48,129,137,2,129,129,0,205,181,181, 26,49,2,204,117,28,253,100,147,168,184,128,26,168,194, 53,199,17,230,198,149,75,236,168,207,100,143,70,26, 104,201,253,63,168,26,215,228,22,52,183,57,160,163,58, 19,137,23,196,227,0,162,84,63,125,9,207,131,174,159, 197,51,143,107,224,74,89,118,135,8,162,250,107,152, 233,175,254,12,36,162,63,121,205,160,58,60,163,103, 212,231,102,14,157,161,192,155,23,217,153,183,146,150, 198,81,148,241,140,57,36,113,201,160,81,190,4,140,190, 234,52,122,187,177,164,45,138,245,2,3,1,0,1,163,123, 48,121,48,9,6,3,85,29,19,4,2,48,0,48,44,6,9,96,134,72, 1,134,248,66,1,13,4,31,22,29,79,112,101,110,83,83,76, 32,71,101,110,101,114,97,116,101,100,32,67,101,114, 116,105,102,105,99,97,116,101,48,29,6,3,85,29,14,4,22, 4,20,30,163,76,66,22,35,196,245,114,67,145,3,129,158, 205,188,152,198,214,239,48,31,6,3,85,29,35,4,24,48,22, 128,20,74,125,159,10,23,104,229,44,16,230,52,190,136, 184,75,134,99,74,93,111,48,13,6,9,42,134,72,134,247, 13,1,1,5,5,0,3,129,129,0,35,27,161,84,35,175,31,46, 253,249,55,130,95,236,71,75,91,3,69,159,252,215,18, 216,60,236,203,103,51,157,216,21,80,1,184,74,166,254, 133,248,39,209,218,128,201,66,160,133,26,227,220,144, 220,99,22,36,176,99,200,146,80,223,63,54,91,239,34, 119,246,93,122,235,30,89,136,140,225,167,192,128,85, 211,239,71,20,115,159,14,107,103,6,151,122,202,242,94, 237,99,85,38,113,78,189,204,97,151,100,27,162,154,0, 205,45,247,79,152,148,98,217,80,111,31,2,39,49,208,23, 254,0,2,124,48,130,2,120,48,130,1,225,160,3,2,1,2,2,9, 0,235,233,83,76,182,123,146,120,48,13,6,9,42,134,72, 134,247,13,1,1,5,5,0,48,85,49,11,48,9,6,3,85,4,6,19,2, 85,83,49,14,48,12,6,3,85,4,8,12,5,84,101,120,97,115, 49,19,48,17,6,3,85,4,10,12,10,78,105,110,101,32,78, 105,110,101,115,49,15,48,13,6,3,85,4,11,12,6,67,111, 119,98,111,121,49,16,48,14,6,3,85,4,3,12,7,82,79,79, 84,32,67,65,48,30,23,13,49,51,48,50,50,56,48,53,49,48, 48,49,90,23,13,51,51,48,50,50,51,48,53,49,48,48,49,90, 48,85,49,11,48,9,6,3,85,4,6,19,2,85,83,49,14,48,12,6, 3,85,4,8,12,5,84,101,120,97,115,49,19,48,17,6,3,85,4, 10,12,10,78,105,110,101,32,78,105,110,101,115,49,15, 48,13,6,3,85,4,11,12,6,67,111,119,98,111,121,49,16,48, 14,6,3,85,4,3,12,7,82,79,79,84,32,67,65,48,129,159,48, 13,6,9,42,134,72,134,247,13,1,1,1,5,0,3,129,141,0,48, 129,137,2,129,129,0,204,230,99,181,44,211,172,163,201, 70,233,171,3,241,34,255,177,135,248,55,87,188,30,211, 176,165,11,209,132,98,123,235,220,228,47,116,13,99,20, 65,220,112,192,84,82,52,104,67,192,207,119,171,146, 200,174,84,146,44,64,6,205,60,78,222,65,221,91,39,24, 170,244,12,131,126,32,238,18,55,99,228,152,26,136,83, 240,77,220,167,92,192,222,185,96,218,247,136,205,10, 176,165,158,22,208,25,117,140,120,9,169,23,237,17,27, 59,76,35,43,109,0,31,124,82,6,125,238,20,104,129,2,3, 1,0,1,163,80,48,78,48,29,6,3,85,29,14,4,22,4,20,74, 125,159,10,23,104,229,44,16,230,52,190,136,184,75,134, 99,74,93,111,48,31,6,3,85,29,35,4,24,48,22,128,20,74, 125,159,10,23,104,229,44,16,230,52,190,136,184,75,134, 99,74,93,111,48,12,6,3,85,29,19,4,5,48,3,1,1,255,48, 13,6,9,42,134,72,134,247,13,1,1,5,5,0,3,129,129,0,109, 72,210,64,113,94,34,228,51,86,251,174,93,179,60,184, 179,68,70,32,214,111,154,141,190,171,91,51,206,6,14, 147,94,59,249,240,23,190,31,139,106,160,114,11,252, 207,220,174,44,94,195,151,166,126,208,100,184,1,163, 136,163,33,108,138,36,142,246,167,104,244,194,87,197, 58,28,123,205,191,63,92,235,193,233,17,37,155,119,238, 122,112,122,159,177,46,87,8,170,117,58,149,185,181, 178,246,81,6,41,20,163,15,226,169,155,191,113,26,164, 23,207,62,100,133,48,22,245,139,96,8>>, <<2,0,0,83,3,0,82,244,225,40,43,69,20,224,136,14,240,93, 225,76,191,156,202,163,215,89,28,56,98,213,12,49,173, 48,191,102,81,223,32,104,211,174,230,197,6,57,224,137, 46,198,34,208,111,149,153,186,243,247,151,78,31,200, 228,94,87,239,178,48,249,204,99,192,40,0,0,11,0,11,0, 2,1,0,255,1,0,1,0>>, [1, <<0,0,245>>, <<3,3,82,244,225,40,177,238,52,250,53,57,12,72,96,92, 157,86,51,250,227,239,173,167,250,154,25,29,237,89, 176,188,61,181,0,0,88,0,255,192,36,192,40,192,38, 192,42,0,107,0,106,0,61,192,35,192,39,192,37,192, 41,0,103,0,64,0,60,192,10,192,20,0,57,0,56,192,5, 192,15,0,53,192,8,192,18,0,22,0,19,192,3,192,13,0, 10,192,9,192,19,0,51,0,50,192,4,192,14,0,47,192,7, 192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0,0,116,0,0, 0,14,0,12,0,0,9,108,111,99,97,108,104,111,115,116, 0,10,0,58,0,56,0,14,0,13,0,25,0,28,0,11,0,12,0,27, 0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6,0,7,0,20,0,21, 0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15,0,16,0,17,0,11, 0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3,5,1,4,3,4,1,3,3, 3,1,2,3,2,1,2,2,1,1>>]], [<<2,0,0,83,3,0,82,244,225,40,43,69,20,224,136,14,240,93, 225,76,191,156,202,163,215,89,28,56,98,213,12,49,173, 48,191,102,81,223,32,104,211,174,230,197,6,57,224,137, 46,198,34,208,111,149,153,186,243,247,151,78,31,200, 228,94,87,239,178,48,249,204,99,192,40,0,0,11,0,11,0, 2,1,0,255,1,0,1,0>>, [1, <<0,0,245>>, <<3,3,82,244,225,40,177,238,52,250,53,57,12,72,96, 92,157,86,51,250,227,239,173,167,250,154,25,29, 237,89,176,188,61,181,0,0,88,0,255,192,36,192,40, 192,38,192,42,0,107,0,106,0,61,192,35,192,39,192, 37,192,41,0,103,0,64,0,60,192,10,192,20,0,57,0,56, 192,5,192,15,0,53,192,8,192,18,0,22,0,19,192,3, 192,13,0,10,192,9,192,19,0,51,0,50,192,4,192,14,0, 47,192,7,192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0, 0,116,0,0,0,14,0,12,0,0,9,108,111,99,97,108,104, 111,115,116,0,10,0,58,0,56,0,14,0,13,0,25,0,28,0, 11,0,12,0,27,0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6, 0,7,0,20,0,21,0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15, 0,16,0,17,0,11,0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3, 5,1,4,3,4,1,3,3,3,1,2,3,2,1,2,2,1,1>>]]}, 16400, {session, <<104,211,174,230,197,6,57,224,137,46,198,34,208,111, 149,153,186,243,247,151,78,31,200,228,94,87,239,178, 48,249,204,99>>, <<48,130,2,165,48,130,2,14,160,3,2,1,2,2,9,0,235,233, 83,76,182,123,146,121,48,13,6,9,42,134,72,134,247, 13,1,1,5,5,0,48,85,49,11,48,9,6,3,85,4,6,19,2,85,83, 49,14,48,12,6,3,85,4,8,12,5,84,101,120,97,115,49,19, 48,17,6,3,85,4,10,12,10,78,105,110,101,32,78,105, 110,101,115,49,15,48,13,6,3,85,4,11,12,6,67,111,119, 98,111,121,49,16,48,14,6,3,85,4,3,12,7,82,79,79,84, 32,67,65,48,30,23,13,49,51,48,50,50,56,48,53,50,51, 51,52,90,23,13,51,51,48,50,50,51,48,53,50,51,51,52, 90,48,87,49,11,48,9,6,3,85,4,6,19,2,85,83,49,14,48, 12,6,3,85,4,8,12,5,84,101,120,97,115,49,19,48,17,6, 3,85,4,10,12,10,78,105,110,101,32,78,105,110,101, 115,49,15,48,13,6,3,85,4,11,12,6,67,111,119,98,111, 121,49,18,48,16,6,3,85,4,3,12,9,108,111,99,97,108, 104,111,115,116,48,129,159,48,13,6,9,42,134,72,134, 247,13,1,1,1,5,0,3,129,141,0,48,129,137,2,129,129,0, 205,181,181,26,49,2,204,117,28,253,100,147,168,184, 128,26,168,194,53,199,17,230,198,149,75,236,168,207, 100,143,70,26,104,201,253,63,168,26,215,228,22,52, 183,57,160,163,58,19,137,23,196,227,0,162,84,63,125, 9,207,131,174,159,197,51,143,107,224,74,89,118,135, 8,162,250,107,152,233,175,254,12,36,162,63,121,205, 160,58,60,163,103,212,231,102,14,157,161,192,155,23, 217,153,183,146,150,198,81,148,241,140,57,36,113, 201,160,81,190,4,140,190,234,52,122,187,177,164,45, 138,245,2,3,1,0,1,163,123,48,121,48,9,6,3,85,29,19, 4,2,48,0,48,44,6,9,96,134,72,1,134,248,66,1,13,4,31, 22,29,79,112,101,110,83,83,76,32,71,101,110,101,114, 97,116,101,100,32,67,101,114,116,105,102,105,99,97, 116,101,48,29,6,3,85,29,14,4,22,4,20,30,163,76,66, 22,35,196,245,114,67,145,3,129,158,205,188,152,198, 214,239,48,31,6,3,85,29,35,4,24,48,22,128,20,74,125, 159,10,23,104,229,44,16,230,52,190,136,184,75,134, 99,74,93,111,48,13,6,9,42,134,72,134,247,13,1,1,5,5, 0,3,129,129,0,35,27,161,84,35,175,31,46,253,249,55, 130,95,236,71,75,91,3,69,159,252,215,18,216,60,236, 203,103,51,157,216,21,80,1,184,74,166,254,133,248, 39,209,218,128,201,66,160,133,26,227,220,144,220,99, 22,36,176,99,200,146,80,223,63,54,91,239,34,119,246, 93,122,235,30,89,136,140,225,167,192,128,85,211,239, 71,20,115,159,14,107,103,6,151,122,202,242,94,237, 99,85,38,113,78,189,204,97,151,100,27,162,154,0,205, 45,247,79,152,148,98,217,80,111,31,2,39,49,208,23, 254>>, undefined,0,<<"?(">>,undefined,undefined,new, 63559002936,undefined}, 28691,ssl_session_cache, {3,0}, false,ecdhe_rsa, {undefined,undefined}, undefined, {{1,2,840,113549,1,1,1}, {'RSAPublicKey', 144454330320215406279953568628491651436272064667760200600239478371082943052406671504117055906783067021801616968245536600804524397616119868619607006483647544685500850941126623013107537763694736146580312576904568190966271012889302320531771708303887413277040358538410888392437638452540396352971161638449355524853, 65537}, 'NULL'}, undefined,undefined,undefined,undefined,undefined, undefined,undefined,20497,#Ref<0.0.0.977>,undefined,<<>>, {false,first}, {<0.33.0>,#Ref<0.0.0.968>}, undefined, {[],[]}, false,true,false,undefined,undefined} ** Reason for termination = ** {bad_return_value,{alert,2,51,{"ssl_connection.erl",420}}} ** exception exit: {{bad_return_value,{alert,2,51,{"ssl_connection.erl",420}}}, {gen_fsm,sync_send_all_state_event, [<0.74.0>,{start,infinity},infinity]}} in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 240) in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1630) in call from ssl_connection:handshake/2 (ssl_connection.erl, line 96) in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) in call from ssl_connection:connect/8 (ssl_connection.erl, line 67) 6> sslv3bug_2:server(). <0.78.0> 7> sslv3bug_2:client(). ** exception exit: {{{case_clause,{4}}, [{ssl_v3,mac_hash,3,[{file,"ssl_v3.erl"},{line,163}]}, {tls_record,encode_plain_text,4, [{file,"tls_record.erl"},{line,134}]}, {tls_connection,encode_handshake,4, [{file,"tls_connection.erl"}, {line,362}]}, {tls_connection,send_handshake,2, [{file,"tls_connection.erl"}, {line,108}]}, {ssl_connection,client_certify_and_key_exchange,2, [{file,"ssl_connection.erl"}, {line,1038}]}, {tls_connection,next_state,4, [{file,"tls_connection.erl"}, {line,458}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]}, {gen_fsm,sync_send_all_state_event, [<0.81.0>,{start,infinity},infinity]}} in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 240) in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1630) in call from ssl_connection:handshake/2 (ssl_connection.erl, line 96) in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) in call from ssl_connection:connect/8 (ssl_connection.erl, line 67) 8> =ERROR REPORT==== 7-Feb-2014::14:35:59 === ** State machine <0.81.0> terminating ** Last message in was {tcp,#Port<0.2911>, <<255,201,15,218,162,33,104,194,52,196,198,98,139, 128,220,28,209,41,2,78,8,138,103,204,116,2,11, 190,166,59,19,155,34,81,74,8,121,142,52,4,221, 239,149,25,179,205,58,67,27,48,43,10,109,242,95, 20,55,79,225,53,109,109,81,194,69,228,133,181, 118,98,94,126,198,244,76,66,233,166,55,237,107, 11,255,92,182,244,6,183,237,238,56,107,251,90, 137,159,165,174,159,36,17,124,75,31,230,73,40, 102,81,236,230,83,129,255,255,255,255,255,255, 255,255,0,1,2,0,128,216,166,31,174,121,159,156, 152,74,250,106,59,107,235,224,100,58,223,33,83, 118,28,193,65,121,227,4,83,159,162,248,251,156, 228,77,141,104,34,249,116,173,104,186,118,133, 43,79,55,213,103,22,79,162,165,3,251,2,252,106, 104,78,101,255,40,203,145,80,207,182,133,98,55, 49,1,80,68,54,12,31,138,6,235,74,72,16,106,4,17, 92,123,162,154,192,198,115,233,224,185,226,144, 225,241,68,141,237,16,159,212,2,60,232,186,100, 159,38,105,250,242,33,153,95,246,14,177,170,244, 86,41,0,47,48,45,2,20,78,183,247,114,172,238, 108,236,172,199,38,160,32,215,236,141,241,69, 232,195,2,21,0,206,237,39,58,180,66,46,147,245, 175,250,151,208,4,205,60,242,87,255,177,22,3,0, 0,4,14,0,0,0>>} ** When State == certify ** Data == {state,client, {#Ref<0.0.0.1012>,<0.76.0>}, gen_tcp,tls_connection,tcp,tcp_closed,tcp_error, "localhost",44443,#Port<0.2911>, {ssl_options,undefined, [{3,3},{3,2},{3,1},{3,0}], verify_none, {#Fun,[]}, false,false,undefined,1,<<>>,undefined,<<>>, undefined,undefined,undefined,<<>>,undefined, undefined,undefined,undefined,undefined, [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, <<0,107>>, <<0,106>>, <<0,61>>, <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, <<0,103>>, <<0,64>>, <<0,60>>, <<"?\n">>, <<192,20>>, <<0,57>>, <<0,56>>, <<192,5>>, <<192,15>>, <<0,53>>, <<"?\b">>, <<192,18>>, <<0,22>>, <<0,19>>, <<192,3>>, <<"?\r">>, <<0,10>>, <<"?\t">>, <<192,19>>, <<0,51>>, <<0,50>>, <<192,4>>, <<192,14>>, <<0,47>>, <<192,7>>, <<192,17>>, <<0,5>>, <<0,4>>, <<0,21>>, <<192,2>>, <<"?\f">>, <<0,9>>], #Fun,true,268435456,false,undefined, undefined,false,undefined,undefined,true,undefined, false}, {socket_options,list,0,0,0,true}, {connection_states, {connection_state, {security_parameters, <<0,0>>, 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, undefined,undefined}, undefined,undefined,undefined,undefined,2,true, undefined,undefined}, {connection_state, {security_parameters, <<0,106>>, 1,7,1,16,256,32,unknown,4,4711,32,0, undefined, <<82,244,225,63,101,215,80,75,202,30,236,75, 214,92,173,239,61,137,174,226,135,182,38, 168,60,36,24,219,50,94,16,198>>, <<82,244,225,63,188,177,3,238,107,25,107,72, 243,243,32,133,171,156,145,181,53,121,188, 56,69,37,1,65,127,169,225,11>>, undefined}, undefined,undefined,undefined,undefined, undefined,true,undefined,undefined}, {connection_state, {security_parameters, <<0,0>>, 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, undefined,undefined}, undefined,undefined,undefined,undefined,1,true, undefined,undefined}, {connection_state, {security_parameters, <<0,106>>, 1,7,1,16,256,32,unknown,4,4711,32,0, undefined, <<82,244,225,63,101,215,80,75,202,30,236,75, 214,92,173,239,61,137,174,226,135,182,38, 168,60,36,24,219,50,94,16,198>>, <<82,244,225,63,188,177,3,238,107,25,107,72, 243,243,32,133,171,156,145,181,53,121,188, 56,69,37,1,65,127,169,225,11>>, undefined}, undefined,undefined,undefined,undefined, undefined,true,undefined,undefined}}, {protocol_buffers,[], <<22,3,0,1,60,12,0,1,56,0,128,255,255,255,255,255,255, 255>>, <<>>,[]}, {[<<11,0,5,153,0,5,150,0,5,147,48,130,5,143,48,130,4,41, 160,3,2,1,2,2,6,0,168,88,141,229,65,48,130,1,44,6,7, 42,134,72,206,56,4,3,48,130,1,31,2,129,129,0,232,148, 166,31,193,7,156,37,221,185,181,134,210,206,133,125, 228,157,66,197,142,159,163,53,134,75,44,121,95,112, 171,141,10,111,6,104,28,68,249,89,51,210,135,202,124, 137,39,248,58,33,142,102,238,53,87,191,54,173,119,76, 14,129,52,149,215,77,223,78,247,64,247,138,164,116,37, 226,84,65,234,101,56,68,165,160,128,238,161,159,24, 216,48,172,183,209,100,143,141,107,100,45,29,108,193, 215,105,37,171,150,125,122,202,252,36,144,93,68,243, 192,32,114,86,101,122,253,217,161,54,81,2,21,0,214, 110,187,124,141,25,20,86,167,217,74,223,208,214,158, 82,129,45,229,129,2,129,129,0,145,148,122,39,49,43,61, 30,153,81,106,86,228,252,211,63,233,231,52,125,126, 210,184,201,77,113,188,219,174,151,155,7,34,93,62,234, 185,143,184,96,42,159,6,159,4,210,162,131,209,153,105, 125,172,202,235,169,97,78,193,237,51,92,122,0,44,226, 15,154,4,66,171,170,119,180,104,229,6,197,143,62,152, 192,216,215,209,189,218,27,42,199,48,112,73,125,55, 156,44,47,95,167,75,90,70,97,42,109,255,161,229,57, 246,0,172,207,230,62,211,188,197,8,250,139,25,71,57, 132,252,175,48,123,49,32,48,30,6,9,42,134,72,134,247, 13,1,9,1,22,17,82,111,111,116,67,65,64,101,114,108,97, 110,103,46,111,114,103,49,15,48,13,6,3,85,4,3,19,6,82, 111,111,116,67,65,49,18,48,16,6,3,85,4,7,19,9,83,116, 111,99,107,104,111,108,109,49,11,48,9,6,3,85,4,6,19,2, 83,69,49,15,48,13,6,3,85,4,10,19,6,101,114,108,97,110, 103,49,20,48,18,6,3,85,4,11,19,11,116,101,115,116,105, 110,103,32,100,101,112,48,34,24,15,50,48,49,52,48,50, 48,54,48,48,48,48,48,48,90,24,15,50,48,49,52,48,50,49, 52,48,48,48,48,48,48,90,48,121,49,31,48,29,6,9,42,134, 72,134,247,13,1,9,1,22,16,101,115,115,101,110,64,101, 114,108,97,110,103,46,111,114,103,49,14,48,12,6,3,85, 4,3,19,5,101,115,115,101,110,49,18,48,16,6,3,85,4,7, 19,9,83,116,111,99,107,104,111,108,109,49,11,48,9,6,3, 85,4,6,19,2,83,69,49,15,48,13,6,3,85,4,10,19,6,101, 114,108,97,110,103,49,20,48,18,6,3,85,4,11,19,11,116, 101,115,116,105,110,103,32,100,101,112,48,130,1,183, 48,130,1,43,6,7,42,134,72,206,56,4,1,48,130,1,30,2, 129,129,0,172,20,101,160,1,130,221,238,24,42,170,3,17, 62,230,231,15,182,23,122,127,202,54,148,36,32,27,64, 221,180,126,41,187,207,133,60,140,0,116,50,56,250,210, 130,36,42,1,0,254,74,15,125,231,23,199,145,185,91,88, 223,179,52,215,22,36,165,226,0,4,236,135,79,246,221, 81,124,230,72,58,212,233,186,42,201,32,47,115,113,22, 251,228,179,170,88,91,55,151,16,150,103,0,88,136,40, 89,52,202,162,205,187,89,154,57,76,34,101,146,109,244, 232,72,134,127,42,102,7,189,43,2,21,0,213,146,169,239, 217,145,225,127,111,174,189,211,177,222,47,248,104,29, 27,237,2,129,128,16,109,41,186,123,49,80,129,242,62, 70,145,216,15,131,72,58,194,148,147,221,175,54,65,123, 227,5,114,111,40,176,249,196,244,205,13,12,7,135,99, 54,234,160,44,233,6,117,17,196,162,142,213,141,109, 141,148,108,149,217,138,200,100,108,254,98,41,241,147, 214,217,252,186,131,40,26,118,255,17,241,219,101,166, 161,62,43,20,24,120,204,242,70,63,190,208,134,173,160, 196,206,225,255,223,8,180,115,245,128,7,193,136,7,151, 36,154,246,240,187,218,72,139,23,18,21,7,129,20,230, 72,3,129,133,0,2,129,129,0,152,168,223,43,127,77,1, 215,72,34,80,184,125,73,66,28,78,154,60,68,31,82,235, 252,250,73,183,249,83,189,159,48,60,60,11,88,52,57,55, 84,243,40,204,232,50,91,126,196,126,2,122,90,71,151, 148,135,145,192,163,23,244,154,184,151,79,14,206,64, 64,35,67,18,185,8,91,8,83,21,25,76,69,76,247,134,107, 112,103,204,60,192,28,158,224,106,64,18,14,43,24,212, 137,199,141,103,252,93,241,32,110,212,33,89,251,137, 28,144,197,212,76,219,135,208,21,252,243,184,104,67, 163,19,48,17,48,15,6,3,85,29,19,1,1,255,4,5,48,3,1,1, 255,48,130,1,44,6,7,42,134,72,206,56,4,3,48,130,1,31, 2,129,129,0,232,148,166,31,193,7,156,37,221,185,181, 134,210,206,133,125,228,157,66,197,142,159,163,53,134, 75,44,121,95,112,171,141,10,111,6,104,28,68,249,89,51, 210,135,202,124,137,39,248,58,33,142,102,238,53,87, 191,54,173,119,76,14,129,52,149,215,77,223,78,247,64, 247,138,164,116,37,226,84,65,234,101,56,68,165,160, 128,238,161,159,24,216,48,172,183,209,100,143,141,107, 100,45,29,108,193,215,105,37,171,150,125,122,202,252, 36,144,93,68,243,192,32,114,86,101,122,253,217,161,54, 81,2,21,0,214,110,187,124,141,25,20,86,167,217,74,223, 208,214,158,82,129,45,229,129,2,129,129,0,145,148,122, 39,49,43,61,30,153,81,106,86,228,252,211,63,233,231, 52,125,126,210,184,201,77,113,188,219,174,151,155,7, 34,93,62,234,185,143,184,96,42,159,6,159,4,210,162, 131,209,153,105,125,172,202,235,169,97,78,193,237,51, 92,122,0,44,226,15,154,4,66,171,170,119,180,104,229,6, 197,143,62,152,192,216,215,209,189,218,27,42,199,48, 112,73,125,55,156,44,47,95,167,75,90,70,97,42,109,255, 161,229,57,246,0,172,207,230,62,211,188,197,8,250,139, 25,71,57,132,252,175,3,48,0,48,45,2,21,0,182,82,58, 106,122,13,155,122,152,41,77,231,69,191,61,48,195,179, 189,65,2,20,18,41,247,30,218,157,162,131,0,182,220, 145,199,117,186,83,112,21,220,12>>, <<2,0,0,83,3,0,82,244,225,63,188,177,3,238,107,25,107, 72,243,243,32,133,171,156,145,181,53,121,188,56,69,37, 1,65,127,169,225,11,32,190,94,115,98,18,255,115,139, 99,87,33,75,186,233,22,47,165,75,129,175,177,99,152, 60,150,43,93,150,146,202,73,169,0,106,0,0,11,0,11,0,2, 1,0,255,1,0,1,0>>, [1, <<0,0,245>>, <<3,3,82,244,225,63,101,215,80,75,202,30,236,75,214, 92,173,239,61,137,174,226,135,182,38,168,60,36,24, 219,50,94,16,198,0,0,88,0,255,192,36,192,40,192,38, 192,42,0,107,0,106,0,61,192,35,192,39,192,37,192, 41,0,103,0,64,0,60,192,10,192,20,0,57,0,56,192,5, 192,15,0,53,192,8,192,18,0,22,0,19,192,3,192,13,0, 10,192,9,192,19,0,51,0,50,192,4,192,14,0,47,192,7, 192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0,0,116,0,0, 0,14,0,12,0,0,9,108,111,99,97,108,104,111,115,116, 0,10,0,58,0,56,0,14,0,13,0,25,0,28,0,11,0,12,0,27, 0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6,0,7,0,20,0,21, 0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15,0,16,0,17,0,11, 0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3,5,1,4,3,4,1,3,3, 3,1,2,3,2,1,2,2,1,1>>]], [<<2,0,0,83,3,0,82,244,225,63,188,177,3,238,107,25,107, 72,243,243,32,133,171,156,145,181,53,121,188,56,69,37, 1,65,127,169,225,11,32,190,94,115,98,18,255,115,139, 99,87,33,75,186,233,22,47,165,75,129,175,177,99,152, 60,150,43,93,150,146,202,73,169,0,106,0,0,11,0,11,0,2, 1,0,255,1,0,1,0>>, [1, <<0,0,245>>, <<3,3,82,244,225,63,101,215,80,75,202,30,236,75,214, 92,173,239,61,137,174,226,135,182,38,168,60,36,24, 219,50,94,16,198,0,0,88,0,255,192,36,192,40,192, 38,192,42,0,107,0,106,0,61,192,35,192,39,192,37, 192,41,0,103,0,64,0,60,192,10,192,20,0,57,0,56, 192,5,192,15,0,53,192,8,192,18,0,22,0,19,192,3, 192,13,0,10,192,9,192,19,0,51,0,50,192,4,192,14,0, 47,192,7,192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0, 0,116,0,0,0,14,0,12,0,0,9,108,111,99,97,108,104, 111,115,116,0,10,0,58,0,56,0,14,0,13,0,25,0,28,0, 11,0,12,0,27,0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6, 0,7,0,20,0,21,0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15, 0,16,0,17,0,11,0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3, 5,1,4,3,4,1,3,3,3,1,2,3,2,1,2,2,1,1>>]]}, 16400, {session, <<190,94,115,98,18,255,115,139,99,87,33,75,186,233,22, 47,165,75,129,175,177,99,152,60,150,43,93,150,146, 202,73,169>>, <<48,130,5,143,48,130,4,41,160,3,2,1,2,2,6,0,168,88, 141,229,65,48,130,1,44,6,7,42,134,72,206,56,4,3,48, 130,1,31,2,129,129,0,232,148,166,31,193,7,156,37, 221,185,181,134,210,206,133,125,228,157,66,197,142, 159,163,53,134,75,44,121,95,112,171,141,10,111,6, 104,28,68,249,89,51,210,135,202,124,137,39,248,58, 33,142,102,238,53,87,191,54,173,119,76,14,129,52, 149,215,77,223,78,247,64,247,138,164,116,37,226,84, 65,234,101,56,68,165,160,128,238,161,159,24,216,48, 172,183,209,100,143,141,107,100,45,29,108,193,215, 105,37,171,150,125,122,202,252,36,144,93,68,243,192, 32,114,86,101,122,253,217,161,54,81,2,21,0,214,110, 187,124,141,25,20,86,167,217,74,223,208,214,158,82, 129,45,229,129,2,129,129,0,145,148,122,39,49,43,61, 30,153,81,106,86,228,252,211,63,233,231,52,125,126, 210,184,201,77,113,188,219,174,151,155,7,34,93,62, 234,185,143,184,96,42,159,6,159,4,210,162,131,209, 153,105,125,172,202,235,169,97,78,193,237,51,92,122, 0,44,226,15,154,4,66,171,170,119,180,104,229,6,197, 143,62,152,192,216,215,209,189,218,27,42,199,48,112, 73,125,55,156,44,47,95,167,75,90,70,97,42,109,255, 161,229,57,246,0,172,207,230,62,211,188,197,8,250, 139,25,71,57,132,252,175,48,123,49,32,48,30,6,9,42, 134,72,134,247,13,1,9,1,22,17,82,111,111,116,67,65, 64,101,114,108,97,110,103,46,111,114,103,49,15,48, 13,6,3,85,4,3,19,6,82,111,111,116,67,65,49,18,48,16, 6,3,85,4,7,19,9,83,116,111,99,107,104,111,108,109, 49,11,48,9,6,3,85,4,6,19,2,83,69,49,15,48,13,6,3,85, 4,10,19,6,101,114,108,97,110,103,49,20,48,18,6,3,85, 4,11,19,11,116,101,115,116,105,110,103,32,100,101, 112,48,34,24,15,50,48,49,52,48,50,48,54,48,48,48,48, 48,48,90,24,15,50,48,49,52,48,50,49,52,48,48,48,48, 48,48,90,48,121,49,31,48,29,6,9,42,134,72,134,247, 13,1,9,1,22,16,101,115,115,101,110,64,101,114,108, 97,110,103,46,111,114,103,49,14,48,12,6,3,85,4,3,19, 5,101,115,115,101,110,49,18,48,16,6,3,85,4,7,19,9, 83,116,111,99,107,104,111,108,109,49,11,48,9,6,3,85, 4,6,19,2,83,69,49,15,48,13,6,3,85,4,10,19,6,101,114, 108,97,110,103,49,20,48,18,6,3,85,4,11,19,11,116, 101,115,116,105,110,103,32,100,101,112,48,130,1,183, 48,130,1,43,6,7,42,134,72,206,56,4,1,48,130,1,30,2, 129,129,0,172,20,101,160,1,130,221,238,24,42,170,3, 17,62,230,231,15,182,23,122,127,202,54,148,36,32,27, 64,221,180,126,41,187,207,133,60,140,0,116,50,56, 250,210,130,36,42,1,0,254,74,15,125,231,23,199,145, 185,91,88,223,179,52,215,22,36,165,226,0,4,236,135, 79,246,221,81,124,230,72,58,212,233,186,42,201,32, 47,115,113,22,251,228,179,170,88,91,55,151,16,150, 103,0,88,136,40,89,52,202,162,205,187,89,154,57,76, 34,101,146,109,244,232,72,134,127,42,102,7,189,43,2, 21,0,213,146,169,239,217,145,225,127,111,174,189, 211,177,222,47,248,104,29,27,237,2,129,128,16,109, 41,186,123,49,80,129,242,62,70,145,216,15,131,72,58, 194,148,147,221,175,54,65,123,227,5,114,111,40,176, 249,196,244,205,13,12,7,135,99,54,234,160,44,233,6, 117,17,196,162,142,213,141,109,141,148,108,149,217, 138,200,100,108,254,98,41,241,147,214,217,252,186, 131,40,26,118,255,17,241,219,101,166,161,62,43,20, 24,120,204,242,70,63,190,208,134,173,160,196,206, 225,255,223,8,180,115,245,128,7,193,136,7,151,36, 154,246,240,187,218,72,139,23,18,21,7,129,20,230,72, 3,129,133,0,2,129,129,0,152,168,223,43,127,77,1,215, 72,34,80,184,125,73,66,28,78,154,60,68,31,82,235, 252,250,73,183,249,83,189,159,48,60,60,11,88,52,57, 55,84,243,40,204,232,50,91,126,196,126,2,122,90,71, 151,148,135,145,192,163,23,244,154,184,151,79,14, 206,64,64,35,67,18,185,8,91,8,83,21,25,76,69,76,247, 134,107,112,103,204,60,192,28,158,224,106,64,18,14, 43,24,212,137,199,141,103,252,93,241,32,110,212,33, 89,251,137,28,144,197,212,76,219,135,208,21,252,243, 184,104,67,163,19,48,17,48,15,6,3,85,29,19,1,1,255, 4,5,48,3,1,1,255,48,130,1,44,6,7,42,134,72,206,56,4, 3,48,130,1,31,2,129,129,0,232,148,166,31,193,7,156, 37,221,185,181,134,210,206,133,125,228,157,66,197, 142,159,163,53,134,75,44,121,95,112,171,141,10,111, 6,104,28,68,249,89,51,210,135,202,124,137,39,248,58, 33,142,102,238,53,87,191,54,173,119,76,14,129,52, 149,215,77,223,78,247,64,247,138,164,116,37,226,84, 65,234,101,56,68,165,160,128,238,161,159,24,216,48, 172,183,209,100,143,141,107,100,45,29,108,193,215, 105,37,171,150,125,122,202,252,36,144,93,68,243,192, 32,114,86,101,122,253,217,161,54,81,2,21,0,214,110, 187,124,141,25,20,86,167,217,74,223,208,214,158,82, 129,45,229,129,2,129,129,0,145,148,122,39,49,43,61, 30,153,81,106,86,228,252,211,63,233,231,52,125,126, 210,184,201,77,113,188,219,174,151,155,7,34,93,62, 234,185,143,184,96,42,159,6,159,4,210,162,131,209, 153,105,125,172,202,235,169,97,78,193,237,51,92,122, 0,44,226,15,154,4,66,171,170,119,180,104,229,6,197, 143,62,152,192,216,215,209,189,218,27,42,199,48,112, 73,125,55,156,44,47,95,167,75,90,70,97,42,109,255, 161,229,57,246,0,172,207,230,62,211,188,197,8,250, 139,25,71,57,132,252,175,3,48,0,48,45,2,21,0,182,82, 58,106,122,13,155,122,152,41,77,231,69,191,61,48, 195,179,189,65,2,20,18,41,247,30,218,157,162,131,0, 182,220,145,199,117,186,83,112,21,220,12>>, undefined,0, <<0,106>>, undefined,undefined,new,63559002959,undefined}, 28691,ssl_session_cache, {3,0}, false,dhe_dss, {undefined,undefined}, undefined, {{1,2,840,10040,4,1}, 107201255589035901224095606533558326562411652347289232035103542030345159420839486230268504779574656171583558015264296286449883604707549621612623958146832751634671347771456676561935478712661717567833349731571068193127995126983390616249150208033231204136081889066713700820639352472736328354631788188647982393411, {'Dss-Parms', 120838457660118919847784105390049937477281231873987813527469753170393689289232527428167218258880467891327129458677867506421714970972002253380733557408691307378960985768079995491587653331614446765301506047915886847153350641972403963007845318607852639159131694882003981406543445440571784899938168852566501735723, 1219285746577471382994815749003130182104667462637, 11535022978489302833643653962713113424104775336555003172828907456342498068622451037206915043471103346423380726835531941532378578411298596088596278301950468270328767064787145526948017146253629314732272784540599889965624014006517245965850597974665875953436492876504607797788574892832624787243340450198197691976}}, undefined,undefined,undefined,undefined,undefined, undefined,undefined,20497,#Ref<0.0.0.1014>,undefined, <<>>, {false,first}, {<0.76.0>,#Ref<0.0.0.1008>}, undefined, {[],[]}, false,true,false,undefined,undefined} ** Reason for termination = ** {{case_clause,{4}}, [{ssl_v3,mac_hash,3,[{file,"ssl_v3.erl"},{line,163}]}, {tls_record,encode_plain_text,4,[{file,"tls_record.erl"},{line,134}]}, {tls_connection,encode_handshake,4, [{file,"tls_connection.erl"},{line,362}]}, {tls_connection,send_handshake,2, [{file,"tls_connection.erl"},{line,108}]}, {ssl_connection,client_certify_and_key_exchange,2, [{file,"ssl_connection.erl"},{line,1038}]}, {tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,458}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} On 02/07/2014 11:10 AM, Ingela Anderton Andin wrote: > Hi! > > If you can provide a failing test case that is a good place to start. I > will not have time to look at it until Monday as I am looking after my > sick daughter today, and just quickly answering some mails. > > Regards Ingela Erlang/OTP team > > On 02/07/2014 11:01 AM, Lo?c Hoguin wrote: >> On 02/06/2014 09:29 PM, Ingela Anderton Andin wrote: >>> Hi! >>> >>> On 02/06/2014 05:59 PM, Lo?c Hoguin wrote: >>>> Just [{cert, Cert}, {key, Key}, {port, 0}, {versions, [sslv3]}] does >>>> it. >>> >>> You mean that you get it when you input certs as binaries? Could it be >>> related to https://github.com/erlang/otp/pull/163 >>> We want to include this pull request but it solves two problems and >>> only one persists and we are waiting for the pull >>> request to be updated. >> >> I don't have any idea what that pull request is about. I am not too well >> versed in SSL-fu. >> >> I narrowed it down a little. >> >> The previously mentioned issue only happens with a test certificate >> generated by erl_make_certs.erl. >> >> A different report happens with a certificate generated by OpenSSL >> (again, setting versions to [sslv3]). >> >> =ERROR REPORT==== 7-Feb-2014::10:55:57 === >> SSL: certify: tls_connection.erl:2286:Fatal error: decrypt error >> >> =ERROR REPORT==== 7-Feb-2014::10:55:57 === >> SSL: certify: tls_connection.erl:2055:Fatal error: decrypt error >> {error,{tls_alert,"decrypt error"}} >> >> The client in all cases is always: >> >> ssl:connect("localhost", 44443, []). >> >> I can provide a test case for either or both of them if you want. >> > -- Lo?c Hoguin http://ninenines.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: sslv3bug_1.erl Type: text/x-erlang Size: 562 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sslv3bug_2.erl Type: text/x-erlang Size: 582 bytes Desc: not available URL: From henrik@REDACTED Fri Feb 7 14:52:39 2014 From: henrik@REDACTED (Henrik Nord) Date: Fri, 7 Feb 2014 14:52:39 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <20140206212647.GP9655@hijacked.us> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <20140206212647.GP9655@hijacked.us> Message-ID: <52F4E527.5050506@erlang.org> > Why is the discussion for that PR not happening in that PR? > > Andrew > _______________________________________________ That patch was sent as a mailpatch to the erlang-patches list. I created the pullrequest as you can see on github, to make sure that the patch makes it into our system for monitoring patches, without manual labor. The comments on said patch, has been sent to the mailinglist, and to the author. So all we can do now is wait. Or submit a patch to fix the issues raised in said patch. If the original author does nothing for a long time. -- /Henrik Nord Erlang/OTP From essen@REDACTED Fri Feb 7 16:32:12 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 16:32:12 +0100 Subject: [erlang-bugs] SSL socket gets closed abruptly In-Reply-To: <52F3BC57.6020700@ninenines.eu> References: <52F3B994.6010203@ninenines.eu> <52F3BC57.6020700@ninenines.eu> Message-ID: <52F4FC7C.8060907@ninenines.eu> On 02/06/2014 05:46 PM, Lo?c Hoguin wrote: > On 02/06/2014 05:34 PM, Lo?c Hoguin wrote: >> Since my issue magically fixed itself I can continue with my work, at >> least. > > Scratch that, I forgot that I attempted to reduce the size being sent > (2MB instead of 19MB) and sending less "fixed it". So I'm back to being > able to reproduce. I will attempt to bisect tomorrow. > > Note that when I tried doing a simpler example in its own module I > wasn't able to reproduce it, so I'm pretty much stuck with trying the > test suite until I find the faulty commit, and won't be able to give > much more than that. Bisect leads me to https://github.com/erlang/otp/commit/5cd05af9b0ed994cf44bbd8ad7c5ee3119f952ff Yeah I got nothing. Ingela can you try fetching Cowboy and running the test suite (make tests) and then look at the ct logs to see if you also got the issue? the multipart_large tests should fail with SSL. I really don't have a clue on where to go from here. I am not even sure the commit is relevant. Have a nice week-end! -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Fri Feb 7 17:42:23 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 17:42:23 +0100 Subject: [erlang-bugs] SSL socket gets closed abruptly In-Reply-To: <52F4FC7C.8060907@ninenines.eu> References: <52F3B994.6010203@ninenines.eu> <52F3BC57.6020700@ninenines.eu> <52F4FC7C.8060907@ninenines.eu> Message-ID: <52F50CEF.7040602@ninenines.eu> On 02/07/2014 04:32 PM, Lo?c Hoguin wrote: > On 02/06/2014 05:46 PM, Lo?c Hoguin wrote: >> On 02/06/2014 05:34 PM, Lo?c Hoguin wrote: >>> Since my issue magically fixed itself I can continue with my work, at >>> least. >> >> Scratch that, I forgot that I attempted to reduce the size being sent >> (2MB instead of 19MB) and sending less "fixed it". So I'm back to being >> able to reproduce. I will attempt to bisect tomorrow. >> >> Note that when I tried doing a simpler example in its own module I >> wasn't able to reproduce it, so I'm pretty much stuck with trying the >> test suite until I find the faulty commit, and won't be able to give >> much more than that. > > Bisect leads me to > https://github.com/erlang/otp/commit/5cd05af9b0ed994cf44bbd8ad7c5ee3119f952ff > > > Yeah I got nothing. > > Ingela can you try fetching Cowboy and running the test suite (make > tests) and then look at the ct logs to see if you also got the issue? > the multipart_large tests should fail with SSL. > > I really don't have a clue on where to go from here. I am not even sure > the commit is relevant. The commit is irrelevant. I just had the test fail for the same reason on R15B02. It just happens a lot less frequently before R16B. -- Lo?c Hoguin http://ninenines.eu From jugg@REDACTED Fri Feb 7 18:47:20 2014 From: jugg@REDACTED (chris) Date: Fri, 7 Feb 2014 09:47:20 -0800 Subject: [erlang-bugs] Revert commit 6189bc07 Message-ID: Hello, The commit 6189bc07 "inets: httpc improve pipelining" needs to be reverted. It introduces a crashing bug into the http client by inserting a session prior to a connection even being established, which will cause subsequent requests to crash that attempt to reuse that session. In httpc_manager:start_handler/2, the session must not be inserted at that point, as there may not yet, nor ever be, a valid connection. In the httpc_handler:handle_response(#state{status = new} = State) call chain from where the original call to insert_session was removed from httpc_handler:try_to_enable_pipeline_or_keep_alive, is actually where the session should be inserted. >From the test case modification in that commit, it looks like the motivation was to get rid of a sleep(4000).? But out of the entire commit, what actually caused the ability to remove the sleep from the test, was simply that every session was now marked as 'available' (renamed 'persistent' in that commit) as soon as the request received a response, if the request established a persistent connection. In other words, a one line code change to the original httpc_handler:try_to_enable_pipeline_or_keep_alive (renamed to httpc_handler:check_persistent and broken) could have had the same result - by always setting the 'available' session field to true for persistent connections.? Which would end up being for all stored sessions, as only persistent connections should have stored sessions anyway.? So given that, I question whether the result of such a modifictation is actually the proper thing to do, or whether the original code had its reasons for not making all persistent connections available until later in their life cycle. In general the entire commit was ill-conceived, and introduces other subtle bugs as well. Please revert the commit, as previously functional production code running for years against R16B02 and earlier releases is now crashing under R16B03(-1). Regards, Chris ps. appologies if this message comes through twice, the first attempt through gmane seems to not have made it. From jugg@REDACTED Sat Feb 8 03:48:43 2014 From: jugg@REDACTED (chris) Date: Sat, 8 Feb 2014 02:48:43 +0000 (UTC) Subject: [erlang-bugs] httpc keep-alive bug References: <62864128-379c4315a16cef0e97632d2760f8e439@pmq5.m5r2.onet> Message-ID: jan_kowalski6669 onet.pl> writes: > I have function: > which sends two request to same Url with different command, one after another. > ? > Screenshot from wireshark: http://tinypic.com/view.php?pic=9s8m03&s=8 > ? > As you can see, in last call of some_function, first request is ok, but second is send to nowhere, and i got no response because first result was without keep-alive header, so second request should open new connection, but it didn't Setting socket_opts keepalive does nothing explicitly for HTTP and will not affect whether the HTTP 'Connection: keep-alive' header is set or not. Chris From prof3ta@REDACTED Sat Feb 8 14:43:44 2014 From: prof3ta@REDACTED (Roberto Aloi) Date: Sat, 8 Feb 2014 14:43:44 +0100 Subject: [erlang-bugs] SSH misleading error messages and potential bugs Message-ID: Hi all, I've been playing around with the SSH application a bit and found the following three weird behaviours. You can read also read this in Markdown at: https://gist.github.com/robertoaloi/8861758 ### Misleading error message on ssh_sftp:start_channel/1 in case user does not have a shell When starting a SFTP channel towards a system where user does not have a shell (i.e. it has `/bin/false` or equilvalent assigned in the `/etc/passwd` a misleading error message is returned to the user: ```` 1> test:go(). ** exception exit: {normal,{gen_server,call, [<0.53.0>, {{timeout,infinity}, wait_for_version_negotiation}, infinity]}} in function gen_server:call/3 (gen_server.erl, line 188) in call from ssh_channel:call/3 (ssh_channel.erl, line 88) in call from ssh_sftp:start_channel/2 (ssh_sftp.erl, line 93) in call from test:connect/1 (test.erl, line 14) ```` Where: ```` -module(test). -compile(export_all). go() -> ok = application:start(crypto), ok = application:start(asn1), ok = application:start(public_key), ok = application:start(ssh), connect("rabbitmq"). connect(Username) -> {ok, SSHRef} = ssh:connect("localhost", 22, [{user, Username}]), {ok, _SFTPChannelRef} = ssh_sftp:start_channel(SSHRef), ok. ```` This has been experienced in both R16B03 and R15B03. ### Crash on SSH connect On R16B03, when connecting via SSH on OS X Mavericks I get: ```` 1> test:go(). ** exception error: no match of right hand side value {error,"Internal error"} in function test:connect/1 (test.erl, line 13) 3> =ERROR REPORT==== 7-Feb-2014::13:38:06 === Erlang ssh connection handler failed with reason: function_clause , Stacktace: [{ssh_connection_handler,userauth, [{ssh_msg_userauth_pk_ok,<<>>, ... ```` ### Internal Crash is not real when using the `key_cb` option When using the 'key_cb' option on `ssh:connect/3` the user should implement a series of callback functions. Not implementing them and trying to connect results in an "internal error" which invites the user to send a bug report. The undef callback function should be catched and reported as a normal error, not an internal one. ```` please report this to erlang-bugs@REDACTED ```` Hope this help, -- Roberto Aloi --- Website: http://roberto-aloi.com Twitter: @robertoaloi -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat Feb 8 19:50:40 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 08 Feb 2014 19:50:40 +0100 Subject: [erlang-bugs] SSL fails at sending a short message while receiving a big one Message-ID: <52F67C80.7070205@ninenines.eu> Hello, While investigating a solution for TCP linger issues with Cowboy, I was surprised when I saw that the solution that worked perfectly well for TCP didn't for SSL. It *may* be related to what fails in my other "SSL socket gets closed abruptly" thread, as both cases send large data. However that other thread is a little more crazy (as sending any non-200 response does work there, while in this case I never got any response). Please see a test case attached. It's a simpler simulation of what may actually happen with HTTP. First a few small packets (often one) are sent for the headers, and then a potentially huge body. The server may not want to receive the body, but it always needs to send a response. Problem is, if we don't read the body, that response is never sent with SSL. It's interesting to note that incorrect behavior occurs regardless of the shutdown call being there. That call is used for the lingering solution mentioned above so I tried with and without. In both cases the response isn't received by the client. If the shutdown call is there, the recv call will eventually say {error, closed} (it may or may not take a while, I had both). If the shutdown call isn't there, recv will just timeout. You need erl_make_certs from the SSL test suite for this test case too. Below output is for R16B02 but the issue also occurs with master updated sometimes this week too. % erl Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.3 (abort with ^G) 1> c(erl_make_certs). {ok,erl_make_certs} 2> c(sslbig). {ok,sslbig} 3> "With shutdown write". "With shutdown write" 4> sslbig:server(). <0.69.0> 5> sslbig:client(). ** exception error: no match of right hand side value {error,closed} in function sslbig:client/0 (sslbig.erl, line 29) 6> c(sslbig). {ok,sslbig} 7> "Without shutdown write". "Without shutdown write" 8> sslbig:server(). <0.84.0> 9> sslbig:client(). ** exception error: no match of right hand side value {error,timeout} in function sslbig:client/0 (sslbig.erl, line 29) 10> Enjoy! -- Lo?c Hoguin http://ninenines.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: sslbig.erl Type: text/x-erlang Size: 774 bytes Desc: not available URL: From essen@REDACTED Sun Feb 9 11:44:15 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 09 Feb 2014 11:44:15 +0100 Subject: [erlang-bugs] SSL fails at sending a short message while receiving a big one In-Reply-To: <52F67C80.7070205@ninenines.eu> References: <52F67C80.7070205@ninenines.eu> Message-ID: <52F75BFF.20109@ninenines.eu> Hello, Here's another test case. This time we do read the data sent by the client, print it, and then send some data ourselves. The client receives nothing. When the shutdown call is there, the client receives an {error, closed} immediately. When the shutdown call isn't there, the client waits 30 seconds before receiving {error, closed}. Which is crazy considering the client has a recv timeout of 5 seconds. Other than that, I also matched the return of the server's ssl:send to make sure it returns ok, and I use the binary option because otherwise Erlang ran out of memory (sounds excessive for 100MB of data but whatever). Please see the attached module. Like previous test cases, you need erl_make_certs from the SSL test suite. Without shutdown. 1> c(erl_make_certs). {ok,erl_make_certs} 2> c(sslbig2). {ok,sslbig2} 3> sslbig2:server(). <0.68.0> 4> sslbig2:client(). A = <<"some data before a big body">> byte_size(B) = 100000000 ** exception error: no match of right hand side value {error,closed} in function sslbig2:client/0 (sslbig2.erl, line 32) With shutdown. 5> c(sslbig2). {ok,sslbig2} 6> sslbig2:server(). 7> sslbig2:server(). <0.116.0> 8> sslbig2:client(). A = <<"some data before a big body">> byte_size(B) = 100000000 ** exception error: no match of right hand side value {error,closed} in function sslbig2:client/0 (sslbig2.erl, line 32) 9> Enjoy! On 02/08/2014 07:50 PM, Lo?c Hoguin wrote: > Hello, > > While investigating a solution for TCP linger issues with Cowboy, I was > surprised when I saw that the solution that worked perfectly well for > TCP didn't for SSL. > > It *may* be related to what fails in my other "SSL socket gets closed > abruptly" thread, as both cases send large data. However that other > thread is a little more crazy (as sending any non-200 response does work > there, while in this case I never got any response). > > Please see a test case attached. It's a simpler simulation of what may > actually happen with HTTP. First a few small packets (often one) are > sent for the headers, and then a potentially huge body. The server may > not want to receive the body, but it always needs to send a response. > Problem is, if we don't read the body, that response is never sent with > SSL. > > It's interesting to note that incorrect behavior occurs regardless of > the shutdown call being there. That call is used for the lingering > solution mentioned above so I tried with and without. In both cases the > response isn't received by the client. If the shutdown call is there, > the recv call will eventually say {error, closed} (it may or may not > take a while, I had both). If the shutdown call isn't there, recv will > just timeout. > > You need erl_make_certs from the SSL test suite for this test case too. > > Below output is for R16B02 but the issue also occurs with master updated > sometimes this week too. > > % erl > Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:4:4] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10.3 (abort with ^G) > 1> c(erl_make_certs). > {ok,erl_make_certs} > 2> c(sslbig). > {ok,sslbig} > 3> "With shutdown write". > "With shutdown write" > 4> sslbig:server(). > <0.69.0> > 5> sslbig:client(). > ** exception error: no match of right hand side value {error,closed} > in function sslbig:client/0 (sslbig.erl, line 29) > 6> c(sslbig). > {ok,sslbig} > 7> "Without shutdown write". > "Without shutdown write" > 8> sslbig:server(). > <0.84.0> > 9> sslbig:client(). > ** exception error: no match of right hand side value {error,timeout} > in function sslbig:client/0 (sslbig.erl, line 29) > 10> > > Enjoy! > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -- Lo?c Hoguin http://ninenines.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: sslbig2.erl Type: text/x-erlang Size: 896 bytes Desc: not available URL: From lars@REDACTED Sun Feb 9 14:37:55 2014 From: lars@REDACTED (Lars Hesel Christensen) Date: Sun, 09 Feb 2014 05:37:55 -0800 Subject: [erlang-bugs] Updating key in empty map doesn't fail Message-ID: <1391953075.1743.81160117.3059E0DD@webmail.messagingengine.com> Hi All I'm playing around with the maps in Erlang R17 rc1, and discovered something unexpected (at least for me): When updating an empty map with a key, the runtime system doesn't complain! If I define a module with one function that updates a key in the map given as an argument: -module(maps_test). -compile(export_all). update_key(Map) -> Map#{key := val}. Then updating an existing key works as expected: 1> maps_test:update_key(#{key => hello}). #{key => val} Trying to update a non-existing key in a non-empty map fails as expected as well: 2> maps_test:update_key(#{non_existing_key => hello}). ** exception error: bad argument in function maps_test:update_key/1 (maps_test.erl, line 4) Updating a non-existing key in an emtpy-map does NOT fail as expected: 3> maps_test:update_key(#{}). #{key => val} I would expect ':=' to behave the same regardless if it is operating on an empty map or not. Maybe this has already been noticed, discussed, explained here or somewhere else, but so far I didn't find anything about this behaviour. A bug, maybe? Cheers, Lars From sgolovan@REDACTED Sun Feb 9 20:16:43 2014 From: sgolovan@REDACTED (Sergei Golovan) Date: Sun, 9 Feb 2014 23:16:43 +0400 Subject: [erlang-bugs] FTP command injection vulnerability in module "ftp" In-Reply-To: References: <52E7D862.2090405@erix.ericsson.se> Message-ID: Hi! I've created a pull request https://github.com/erlang/otp/pull/233 with changes which return error if or are found in filenames or dirnames or whatever. Hope it'll help with fixing this bug. On Thu, Jan 30, 2014 at 11:59 AM, Seba wrote: > Thanks! > > FYI, this issue has been assigned with the following CVE id (common > vulnerabilities and exposures) by cve.mitre.org: CVE-2014-1693 > > -Sebasti?n. > > 2014-01-28 Hans Nilsson : >> >> Hi! >> >> Thanks for the report! I have written a ticket about it. >> >> It is however not highly prioritized, because it does not really solve a >> security hole. Everything that comes from a client must be regarded as >> "evil" by the server and sanitized by the server. Many bad users could write >> a client that misbehaves... >> >> But since a client is supposed to send correct data, we will fix this in the >> future. >> >> - Hans Nilsson >> >> >> >> >> On 01/27/2014 12:10 PM, Seba wrote: >>> >>> Hi! >>> >>> There is an FTP Command Injection vulnerability in the "ftp" module. >>> >>> All those functions that write any string argument in the control >>> socket seem to be vulnerable: >>> >>> >>> user/3 >>> user/4 >>> account/2 >>> cd/2 >>> ls/2 >>> nlist/2 >>> rename/3 >>> delete/2 >>> mkdir/2 >>> rmdir/2 >>> recv/2 >>> recv/3 >>> recv_bin/2, >>> recv_chunk_start/2 >>> send/3 >>> send_bin/3 >>> send_chunk_start/2 >>> append_chunk_start/2 >>> append/2 >>> append/3 >>> append_bin/3 >>> >>> >>> Vulnerability Description >>> ------------------------- >>> >>> An FTP communication consists of two channels: >>> * A TCP control channel: Text-based, and served by the FTP Server. >>> * A TCP data channel: Which is created either by the FTP Client or >>> the FTP Server depending on data being transmitted using active or >>> passive mode. >>> The control channel works in a request-response fashion. Each command >>> is issued by the client in a single line (ending with a carriage >>> return and a new line: \r\n). >>> >>> By injecting a \r\n sequence followed by a new command in a function >>> argument you get the ftp module to write the whole string in the >>> socket. >>> >>> E.g. the following erlang shell session: >>> >>> 1> inets:start(). >>> ok >>> 2> {ok, Pid} = inets:start(ftpc, [{host, "127.0.0.1"}]). >>> {ok,<0.46.0>} >>> 3> ftp:user(Pid, "anonymous", "password\r\nCWD pub\r\nMKD new_dir"). >>> ok >>> 4> ftp:cd(Pid, "/pub\r\nRMD new_dir\r\nPASV"). >>> ok >>> >>> >>> Generates the following FTP session: >>> >>> FTP command: Client "127.0.0.1", "USER anonymous" >>> FTP response: Client "127.0.0.1", "331 Please specify the password." >>> FTP command: Client "127.0.0.1", "PASS " >>> FTP response: Client "127.0.0.1", "230 Login successful." >>> FTP command: Client "127.0.0.1", "CWD pub" >>> FTP response: Client "127.0.0.1", "250 Directory successfully changed." >>> FTP command: Client "127.0.0.1", "MKD new_dir" >>> FTP response: Client "127.0.0.1", "257 "/pub/new_dir" created" >>> FTP command: Client "127.0.0.1", "CWD /pub" >>> FTP response: Client "127.0.0.1", "250 Directory successfully changed." >>> FTP command: Client "127.0.0.1", "RMD new_dir" >>> FTP response: Client "127.0.0.1", "250 Remove directory operation >>> successful." >>> FTP command: Client "127.0.0.1", "PASV" >>> FTP response: Client "127.0.0.1", "227 Entering Passive Mode >>> (127,0,0,1,130,161)." >>> >>> >>> Attack Scenario Example >>> ----------------------- >>> >>> A web server allow users to navigate and download documents. >>> Internally the web server connects to a private ftp server using OTP >>> "ftp" module. >>> An attacker might take advantage of the vulnerability to execute >>> actions that aren't supposed to be exposed. E.g. delete a directory by >>> requesting: >>> >>> http://www.example.com/list_dir.yaws?dir=/docs/%0d%0aRMD+/docs >>> >>> Tested on >>> --------- >>> - R15B03 >>> - Ubuntu 12.04 x86_64 >>> - FTP Sever: vsftpd >>> >>> Fixing >>> ------ >>> >>> String arguments used to create the command request should be >>> sanitized first (by removing "\r" and "\n"). >>> >>> >>> >>> Sebasti?n Tello >>> _______________________________________________ >>> 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 -- Sergei Golovan From wallentin.dahlberg@REDACTED Sun Feb 9 20:37:42 2014 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sun, 9 Feb 2014 20:37:42 +0100 Subject: [erlang-bugs] Updating key in empty map doesn't fail In-Reply-To: <1391953075.1743.81160117.3059E0DD@webmail.messagingengine.com> References: <1391953075.1743.81160117.3059E0DD@webmail.messagingengine.com> Message-ID: Thank you for reporting. I believe that this particular bug (among others) has already been fixed: https://github.com/erlang/otp/commit/963c06a5b72c2ac8d88a6910ee60248d6dca747d I aim to have rc2 even more stable. =) // Bj?rn-Egil 2014-02-09 14:37 GMT+01:00 Lars Hesel Christensen : > Hi All > > I'm playing around with the maps in Erlang R17 rc1, and discovered > something unexpected (at least for me): When updating an empty map with > a key, the runtime system doesn't complain! > > If I define a module with one function that updates a key in the map > given as an argument: > > -module(maps_test). > -compile(export_all). > update_key(Map) -> > Map#{key := val}. > > Then updating an existing key works as expected: > > 1> maps_test:update_key(#{key => hello}). > #{key => val} > > Trying to update a non-existing key in a non-empty map fails as expected > as well: > > 2> maps_test:update_key(#{non_existing_key => hello}). > ** exception error: bad argument > in function maps_test:update_key/1 (maps_test.erl, line 4) > > Updating a non-existing key in an emtpy-map does NOT fail as expected: > > 3> maps_test:update_key(#{}). > #{key => val} > > I would expect ':=' to behave the same regardless if it is operating on > an empty map or not. > > Maybe this has already been noticed, discussed, explained here or > somewhere else, but so far I didn't find anything about this behaviour. > > A bug, maybe? > > Cheers, > Lars > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hirotnkg@REDACTED Mon Feb 10 04:30:19 2014 From: hirotnkg@REDACTED (Yoshihiro Tanaka) Date: Sun, 9 Feb 2014 19:30:19 -0800 Subject: [erlang-bugs] Document of lists:append/2 Message-ID: Hi, In the document :http://www.erlang.org/doc/man/lists.html#append-2 It says: append(List1, List2) -> List3, List1 = List2 = List3 = [T], T = term. But considering the following behavior, it does not look correct: 1> [] ++ undef. undef 2> undef ++ []. ** exception error: bad argument in operator ++/2 called as undef ++ [] 3> [a,b] ++ undef. [a,b|undef] 4> Thoughts ? Thank you Yoshihiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From hirotnkg@REDACTED Mon Feb 10 04:58:36 2014 From: hirotnkg@REDACTED (Yoshihiro Tanaka) Date: Sun, 9 Feb 2014 19:58:36 -0800 Subject: [erlang-bugs] Document of lists:append/2 In-Reply-To: <52F84CEE.2060609@khandkar.net> References: <52F84CEE.2060609@khandkar.net> Message-ID: Right. I guess I'm questioning the accuracy of the document. On Sun, Feb 9, 2014 at 7:52 PM, Siraaj Khandkar wrote: > This is just a surprising side effect of dynamic typing. To perform the > append, the left list is traversed and the right is just blindly used as > a tail, so it is never introspected and thus never has an opportunity to > crash. > > > On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote: > > Hi, > > > > In the document :http://www.erlang.org/doc/man/lists.html#append-2 > > It says: > > append(List1, List2) -> List3, List1 = List2 = List3 = [T], T = term. > > > > But considering the following behavior, it does not look correct: > > > > 1> [] ++ undef. > > undef > > 2> undef ++ []. > > ** exception error: bad argument > > in operator ++/2 > > called as undef ++ [] > > 3> [a,b] ++ undef. > > [a,b|undef] > > 4> > > > > > > Thoughts ? > > > > > > Thank you > > Yoshihiro > -------------- next part -------------- An HTML attachment was scrubbed... URL: From siraaj@REDACTED Mon Feb 10 04:52:14 2014 From: siraaj@REDACTED (Siraaj Khandkar) Date: Sun, 09 Feb 2014 22:52:14 -0500 Subject: [erlang-bugs] Document of lists:append/2 In-Reply-To: References: Message-ID: <52F84CEE.2060609@khandkar.net> This is just a surprising side effect of dynamic typing. To perform the append, the left list is traversed and the right is just blindly used as a tail, so it is never introspected and thus never has an opportunity to crash. On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote: > Hi, > > In the document :http://www.erlang.org/doc/man/lists.html#append-2 > It says: > append(List1, List2) -> List3, List1 = List2 = List3 = [T], T = term. > > But considering the following behavior, it does not look correct: > > 1> [] ++ undef. > undef > 2> undef ++ []. > ** exception error: bad argument > in operator ++/2 > called as undef ++ [] > 3> [a,b] ++ undef. > [a,b|undef] > 4> > > > Thoughts ? > > > Thank you > Yoshihiro From bob@REDACTED Mon Feb 10 05:43:58 2014 From: bob@REDACTED (Bob Ippolito) Date: Sun, 9 Feb 2014 20:43:58 -0800 Subject: [erlang-bugs] Document of lists:append/2 In-Reply-To: References: <52F84CEE.2060609@khandkar.net> Message-ID: If you assume that all functions have undefined behavior when given incorrectly typed inputs, it's perfectly consistent. Erlang code tends to assume correctly typed input because it's simpler to implement and the types can often be checked mechanically with tools such as dialyzer. On Sunday, February 9, 2014, Yoshihiro Tanaka wrote: > Right. I guess I'm questioning the accuracy of the document. > > > On Sun, Feb 9, 2014 at 7:52 PM, Siraaj Khandkar > > wrote: > >> This is just a surprising side effect of dynamic typing. To perform the >> append, the left list is traversed and the right is just blindly used as >> a tail, so it is never introspected and thus never has an opportunity to >> crash. >> >> >> On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote: >> > Hi, >> > >> > In the document :http://www.erlang.org/doc/man/lists.html#append-2 >> > It says: >> > append(List1, List2) -> List3, List1 = List2 = List3 = [T], T = term. >> > >> > But considering the following behavior, it does not look correct: >> > >> > 1> [] ++ undef. >> > undef >> > 2> undef ++ []. >> > ** exception error: bad argument >> > in operator ++/2 >> > called as undef ++ [] >> > 3> [a,b] ++ undef. >> > [a,b|undef] >> > 4> >> > >> > >> > Thoughts ? >> > >> > >> > Thank you >> > Yoshihiro >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hirotnkg@REDACTED Mon Feb 10 06:48:11 2014 From: hirotnkg@REDACTED (Yoshihiro Tanaka) Date: Sun, 9 Feb 2014 21:48:11 -0800 Subject: [erlang-bugs] Document of lists:append/2 In-Reply-To: References: <52F84CEE.2060609@khandkar.net> Message-ID: Okay, that makes sense. Thank you. On Sun, Feb 9, 2014 at 8:43 PM, Bob Ippolito wrote: > If you assume that all functions have undefined behavior when given > incorrectly typed inputs, it's perfectly consistent. Erlang code tends to > assume correctly typed input because it's simpler to implement and the > types can often be checked mechanically with tools such as dialyzer. > > > On Sunday, February 9, 2014, Yoshihiro Tanaka wrote: > >> Right. I guess I'm questioning the accuracy of the document. >> >> >> On Sun, Feb 9, 2014 at 7:52 PM, Siraaj Khandkar wrote: >> >>> This is just a surprising side effect of dynamic typing. To perform the >>> append, the left list is traversed and the right is just blindly used as >>> a tail, so it is never introspected and thus never has an opportunity to >>> crash. >>> >>> >>> On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote: >>> > Hi, >>> > >>> > In the document :http://www.erlang.org/doc/man/lists.html#append-2 >>> > It says: >>> > append(List1, List2) -> List3, List1 = List2 = List3 = [T], T = term. >>> > >>> > But considering the following behavior, it does not look correct: >>> > >>> > 1> [] ++ undef. >>> > undef >>> > 2> undef ++ []. >>> > ** exception error: bad argument >>> > in operator ++/2 >>> > called as undef ++ [] >>> > 3> [a,b] ++ undef. >>> > [a,b|undef] >>> > 4> >>> > >>> > >>> > Thoughts ? >>> > >>> > >>> > Thank you >>> > Yoshihiro >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz@REDACTED Mon Feb 10 07:37:23 2014 From: heinz@REDACTED (Heinz Nikolaus Gies) Date: Mon, 10 Feb 2014 01:37:23 -0500 Subject: [erlang-bugs] Document of lists:append/2 In-Reply-To: References: <52F84CEE.2060609@khandkar.net> Message-ID: I somewhat disagree on that point. Shouldn?t functions crash given badly typed inputs? That sounds like the reasonable thing to to when following the fail early paradigm and I always got the impression a lot of the functions in the core libraries happily die a tragic death if a wrong input comes too close to them. --- Cheers, Heinz Nikolaus Gies heinz@REDACTED On Feb 9, 2014, at 11:43 PM, Bob Ippolito wrote: > If you assume that all functions have undefined behavior when given incorrectly typed inputs, it's perfectly consistent. Erlang code tends to assume correctly typed input because it's simpler to implement and the types can often be checked mechanically with tools such as dialyzer. > > On Sunday, February 9, 2014, Yoshihiro Tanaka wrote: > Right. I guess I'm questioning the accuracy of the document. > > > On Sun, Feb 9, 2014 at 7:52 PM, Siraaj Khandkar wrote: > This is just a surprising side effect of dynamic typing. To perform the > append, the left list is traversed and the right is just blindly used as > a tail, so it is never introspected and thus never has an opportunity to > crash. > > > On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote: > > Hi, > > > > In the document :http://www.erlang.org/doc/man/lists.html#append-2 > > It says: > > append(List1, List2) -> List3, List1 = List2 = List3 = [T], T = term. > > > > But considering the following behavior, it does not look correct: > > > > 1> [] ++ undef. > > undef > > 2> undef ++ []. > > ** exception error: bad argument > > in operator ++/2 > > called as undef ++ [] > > 3> [a,b] ++ undef. > > [a,b|undef] > > 4> > > > > > > Thoughts ? > > > > > > Thank you > > Yoshihiro > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bob@REDACTED Mon Feb 10 07:44:10 2014 From: bob@REDACTED (Bob Ippolito) Date: Sun, 9 Feb 2014 22:44:10 -0800 Subject: [erlang-bugs] Document of lists:append/2 In-Reply-To: References: <52F84CEE.2060609@khandkar.net> Message-ID: Maybe they should, but there's a large cost to that and that's not how things actually work today. Sometimes bad inputs will crash, but only because they are forced to. On Sunday, February 9, 2014, Heinz Nikolaus Gies wrote: > I somewhat disagree on that point. Shouldn?t functions crash given badly > typed inputs? That sounds like the reasonable thing to to when following > the fail early paradigm and I always got the impression a lot of the > functions in the core libraries happily die a tragic death if a wrong input > comes too close to them. > --- > Cheers, > Heinz Nikolaus Gies > heinz@REDACTED > > > > On Feb 9, 2014, at 11:43 PM, Bob Ippolito > > wrote: > > If you assume that all functions have undefined behavior when given > incorrectly typed inputs, it's perfectly consistent. Erlang code tends to > assume correctly typed input because it's simpler to implement and the > types can often be checked mechanically with tools such as dialyzer. > > On Sunday, February 9, 2014, Yoshihiro Tanaka > > wrote: > >> Right. I guess I'm questioning the accuracy of the document. >> >> >> On Sun, Feb 9, 2014 at 7:52 PM, Siraaj Khandkar wrote: >> >>> This is just a surprising side effect of dynamic typing. To perform the >>> append, the left list is traversed and the right is just blindly used as >>> a tail, so it is never introspected and thus never has an opportunity to >>> crash. >>> >>> >>> On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote: >>> > Hi, >>> > >>> > In the document :http://www.erlang.org/doc/man/lists.html#append-2 >>> > It says: >>> > append(List1, List2) -> List3, List1 = List2 = List3 = [T], T = term. >>> > >>> > But considering the following behavior, it does not look correct: >>> > >>> > 1> [] ++ undef. >>> > undef >>> > 2> undef ++ []. >>> > ** exception error: bad argument >>> > in operator ++/2 >>> > called as undef ++ [] >>> > 3> [a,b] ++ undef. >>> > [a,b|undef] >>> > 4> >>> > >>> > >>> > Thoughts ? >>> > >>> > >>> > Thank you >>> > Yoshihiro >>> >> >> _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Mon Feb 10 07:45:40 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 10 Feb 2014 07:45:40 +0100 Subject: [erlang-bugs] Document of lists:append/2 In-Reply-To: References: <52F84CEE.2060609@khandkar.net> Message-ID: <1392014740.4926.7.camel@sekic1152.release> Greetings, Some functions have arguments that would be time consuming to check for correctness. This might be a reason for not mandating a check of all arguments. bengt On Mon, 2014-02-10 at 01:37 -0500, Heinz Nikolaus Gies wrote: > I somewhat disagree on that point. Shouldn?t functions crash given > badly typed inputs? That sounds like the reasonable thing to to when > following the fail early paradigm and I always got the impression a > lot of the functions in the core libraries happily die a tragic death > if a wrong input comes too close to them. > --- > Cheers, > Heinz Nikolaus Gies > heinz@REDACTED > > > > > > On Feb 9, 2014, at 11:43 PM, Bob Ippolito wrote: > > > If you assume that all functions have undefined behavior when given > > incorrectly typed inputs, it's perfectly consistent. Erlang code > > tends to assume correctly typed input because it's simpler to > > implement and the types can often be checked mechanically with tools > > such as dialyzer. > > > > On Sunday, February 9, 2014, Yoshihiro Tanaka > > wrote: > > Right. I guess I'm questioning the accuracy of the document. > > > > > > On Sun, Feb 9, 2014 at 7:52 PM, Siraaj Khandkar > > wrote: > > This is just a surprising side effect of dynamic > > typing. To perform the > > append, the left list is traversed and the right is > > just blindly used as > > a tail, so it is never introspected and thus never > > has an opportunity to > > crash. > > > > > > On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote: > > > Hi, > > > > > > In the > > document :http://www.erlang.org/doc/man/lists.html#append-2 > > > It says: > > > append(List1, List2) -> List3, List1 = List2 = > > List3 = [T], T = term. > > > > > > But considering the following behavior, it does > > not look correct: > > > > > > 1> [] ++ undef. > > > undef > > > 2> undef ++ []. > > > ** exception error: bad argument > > > in operator ++/2 > > > called as undef ++ [] > > > 3> [a,b] ++ undef. > > > [a,b|undef] > > > 4> > > > > > > > > > Thoughts ? > > > > > > > > > Thank you > > > Yoshihiro > > > > > > > > _______________________________________________ > > 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 siraaj@REDACTED Mon Feb 10 07:48:05 2014 From: siraaj@REDACTED (Siraaj Khandkar) Date: Mon, 10 Feb 2014 01:48:05 -0500 Subject: [erlang-bugs] Document of lists:append/2 In-Reply-To: References: <52F84CEE.2060609@khandkar.net> Message-ID: <52F87625.6010502@khandkar.net> Generally, it might be desirable to guard it with is_list/1, but in this particular case - a bunch of people rely on improper lists for optimizations, so it isn't so straight forward :/ On 2/10/14, 1:37 AM, Heinz Nikolaus Gies wrote: > I somewhat disagree on that point. Shouldn?t functions crash given > badly typed inputs? That sounds like the reasonable thing to to > when following the fail early paradigm and I always got the > impression a lot of the functions in the core libraries happily die > a tragic death if a wrong input comes too close to them. --- > Cheers, Heinz Nikolaus Gies heinz@REDACTED > > > > On Feb 9, 2014, at 11:43 PM, Bob Ippolito wrote: > >> If you assume that all functions have undefined behavior when >> given incorrectly typed inputs, it's perfectly consistent. Erlang >> code tends to assume correctly typed input because it's simpler >> to implement and the types can often be checked mechanically with >> tools such as dialyzer. >> >> On Sunday, February 9, 2014, Yoshihiro Tanaka >> wrote: Right. I guess I'm questioning the >> accuracy of the document. >> >> >> On Sun, Feb 9, 2014 at 7:52 PM, Siraaj Khandkar >> wrote: This is just a surprising side >> effect of dynamic typing. To perform the append, the left list is >> traversed and the right is just blindly used as a tail, so it is >> never introspected and thus never has an opportunity to crash. >> >> >> On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote: >>> Hi, >>> >>> In the document >>> :http://www.erlang.org/doc/man/lists.html#append-2 It says: >>> append(List1, List2) -> List3, List1 = List2 = List3 = [T], T = >>> term. >>> >>> But considering the following behavior, it does not look >>> correct: >>> >>> 1> [] ++ undef. undef 2> undef ++ []. ** exception error: bad >>> argument in operator ++/2 called as undef ++ [] 3> [a,b] ++ >>> undef. [a,b|undef] 4> >>> >>> >>> Thoughts ? >>> >>> >>> Thank you Yoshihiro From essen@REDACTED Mon Feb 10 10:11:19 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 10 Feb 2014 10:11:19 +0100 Subject: [erlang-bugs] Document of lists:append/2 In-Reply-To: References: <52F84CEE.2060609@khandkar.net> Message-ID: <52F897B7.8030406@ninenines.eu> Ensuring that input is correct is a lot harder to do than relying on Dialyzer. Checking that you have a list is easy, checking that you have a list of ascii characters is hard and expensive. You can rarely check more than the outer layer of the arguments because it's otherwise very expensive. You have to rely on Dialyzer to make sure that was is passed is actually the correct type. Since you have to rely on Dialyzer, why not speed up your program a little by removing the half-assed checks and using Dialyzer for them instead? A notable exception to that is when your function has side effects. You usually don't want to start saving data to a database if it's going to fail further down the line, for example. On 02/10/2014 07:37 AM, Heinz Nikolaus Gies wrote: > I somewhat disagree on that point. Shouldn?t functions crash given badly > typed inputs? That sounds like the reasonable thing to to when following > the fail early paradigm and I always got the impression a lot of the > functions in the core libraries happily die a tragic death if a wrong > input comes too close to them. > --- > Cheers, > Heinz Nikolaus Gies > heinz@REDACTED > > > > On Feb 9, 2014, at 11:43 PM, Bob Ippolito > wrote: > >> If you assume that all functions have undefined behavior when given >> incorrectly typed inputs, it's perfectly consistent. Erlang code tends >> to assume correctly typed input because it's simpler to implement and >> the types can often be checked mechanically with tools such as dialyzer. >> >> On Sunday, February 9, 2014, Yoshihiro Tanaka > > wrote: >> >> Right. I guess I'm questioning the accuracy of the document. >> >> >> On Sun, Feb 9, 2014 at 7:52 PM, Siraaj Khandkar >> > > wrote: >> >> This is just a surprising side effect of dynamic typing. To >> perform the >> append, the left list is traversed and the right is just >> blindly used as >> a tail, so it is never introspected and thus never has an >> opportunity to >> crash. >> >> >> On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote: >> > Hi, >> > >> > In the document >> :http://www.erlang.org/doc/man/lists.html#append-2 >> > It says: >> > append(List1, List2) -> List3, List1 = List2 = List3 = [T], >> T = term. >> > >> > But considering the following behavior, it does not look >> correct: >> > >> > 1> [] ++ undef. >> > undef >> > 2> undef ++ []. >> > ** exception error: bad argument >> > in operator ++/2 >> > called as undef ++ [] >> > 3> [a,b] ++ undef. >> > [a,b|undef] >> > 4> >> > >> > >> > Thoughts ? >> > >> > >> > Thank you >> > Yoshihiro >> >> >> _______________________________________________ >> 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 > -- Lo?c Hoguin http://ninenines.eu From carlsson.richard@REDACTED Mon Feb 10 18:30:49 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Mon, 10 Feb 2014 18:30:49 +0100 Subject: [erlang-bugs] system_limit: erlc passing options as atoms to erl Message-ID: <52F90CC9.2050702@gmail.com> The erlc program (erts/etc/common/erlc.c) invokes the erlang compiler as "erl ... -s erl_compile compile_cmdline ...", which means that the command line options are passed as atoms (due to -s). If an option string gets too long, erlc crashes with reason 'system_limit' because atoms cannot be longer than 255 characters. Case in point: the erlc option -MT ... gets passed as {makedep_target,"..."}, where the target string is a list of one or more filenames, typically generated from a Makefile. If the filenames are long (in particular if absolute paths are used), this string can get longer than 255 characters. Suggested solution: rewrite erlc (and other similar executables) to pass options using the -run or -eval flag instead of -s. /Richard From jonas.falkevik@REDACTED Mon Feb 10 18:33:47 2014 From: jonas.falkevik@REDACTED (Jonas Falkevik) Date: Mon, 10 Feb 2014 18:33:47 +0100 Subject: [erlang-bugs] VM locks up on write to socket (and now it seems to file too) In-Reply-To: <50C08922.5050801@erlang.org> References: <50AEC81B.2000908@ninenines.eu> <50AFA09D.4060100@erlang.org> <50B633C7.7000709@erlang.org> <50B64897.2050300@erlang.org> <50B7AD7C.3060809@erlang.org> <50C08922.5050801@erlang.org> Message-ID: Hi Patrik & Peter, do you know if this issue has been fixed in any later release of RHEL? Any ticket id that could be shared? Thanks, Jonas On Dec 6, 2012, at 13:01 , Patrik Nyblom wrote: > Hi! > > Good! The workaround isn't all that costly either, so I think we could put that in R16 as is. It would be good if the OS bug got fixed though, but I think that's also on it's way. > > Cheers, > /Patrik > > On 12/05/2012 02:20 PM, Peter Membrey wrote: >> Hi Patrik, >> >> Really sorry for the delay in getting back to you! >> >> I tried the same test on RHEL 6.3 using the patched version and >> everything seems fine. No stuck threads and the VM is still happy and >> responsive. >> >> I'm currently working on a load testing app to try and trigger the >> issue on demand in the application itself, but I suspect your patch >> has done the trick! >> >> Thanks for fixing this so fast and sorry again for the delay in >> getting back in touch! >> >> Cheers, >> >> Pete >> >> >> >> On 30 November 2012 02:46, Patrik Nyblom wrote: >>> Hi! >>> >>> On 11/29/2012 04:41 AM, Peter Membrey wrote: >>>> Hi Patrik, >>>> >>>> I can also confirm that this bug exists on Red Hat Enterprise Linux >>>> 6.3. I'll raise a support ticket with them as well. >>>> >>>> A workaround in the vm would be nice if you have time? :-) >>> Could you try the attached diff and see if it works for your environment? It >>> would seem nothing is written when 0 is returned, so it should be safe to >>> try again... >>> >>> Cheers, >>> /Patrik >>> >>> >>>> Cheers, >>>> >>>> Pete >>>> >>>> >>>> On 29 November 2012 01:23, Patrik Nyblom wrote: >>>>> Hi again! >>>>> >>>>> No problem reproducing when I've got CentOS 6.3... The following commands >>>>> in >>>>> the Erlang shell: >>>>> {ok,L} = gen_tcp:listen(4747,[{active,false}]). >>>>> {ok,S} = gen_tcp:connect("localhost",4747,[{active,false}]). >>>>> {ok,A} = gen_tcp:accept(L). >>>>> gen_tcp:send(A,binary:copy(<<$a:8>>,2158022464)). >>>>> >>>>> gives the following strace: >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., >>>>> 2158022464}], 1) = 0 >>>>> [.....] >>>>> >>>>> While on ubuntu for example it works like it should...Looks like a kernel >>>>> bug to me... I wonder if this should be worked around or just reported... >>>>> I >>>>> suppose both... Sigh... >>>>> >>>>> /Patrik >>>>> >>>>> >>>>> On 11/28/2012 05:23 PM, Peter Membrey wrote: >>>>>> Hi, >>>>>> >>>>>> No problem, I'll do what I can to help - thanks for looking into this >>>>>> so quickly! >>>>>> >>>>>> Any idea what might be causing it? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Pete >>>>>> >>>>>> On 28 November 2012 23:54, Patrik Nyblom wrote: >>>>>>> Hi! >>>>>>> >>>>>>> I'll upgrade the CentOS VM I have to 6.3 (only had 6.1 :() and see if I >>>>>>> can >>>>>>> reproduce. If that fails, could you run a VM with a patch to try to >>>>>>> handle >>>>>>> the unexpected case and see if that fixes it? >>>>>>> >>>>>>> Cheers, >>>>>>> /Patrik >>>>>>> >>>>>>> On 11/24/2012 02:57 PM, Peter Membrey wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> Thanks for getting back in touch so quickly! >>>>>>>> >>>>>>>> I did do an lsof on the process and I can confirm that it was >>>>>>>> definitely a socket. However by that time the application it had been >>>>>>>> trying to send to had been killed. When I checked the sockets were >>>>>>>> showing as waiting to close. Unfortunately I didn't think to do an >>>>>>>> lsof until after the apps had been shut down. I was hoping the VM >>>>>>>> would recover if I killed the app that had upset it. However even >>>>>>>> after all the apps connected had been shut down, the issue didn't >>>>>>>> resolve. >>>>>>>> >>>>>>>> The application receives requests from a client, which contains two >>>>>>>> data items. The stream ID and a timestamp. Both are encoded as big >>>>>>>> integer unsigned numbers. The server then looks through the file >>>>>>>> referenced by the stream ID and uses the timestamp as an index. The >>>>>>>> file format is currently really simple, in the form of: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> There is an index file that provides an offset into the file based on >>>>>>>> time stamp, but basically it opens the file, and reads sequentially >>>>>>>> through it until it finds the timestamps that it cares about. In this >>>>>>>> case it reads all data with a greater timestamp until the end of the >>>>>>>> file is reached. It's possible the client is sending an incorrect >>>>>>>> timestamp, and maybe too much data is being read. However the loop is >>>>>>>> very primitive - it reads all the data in one go before passing it >>>>>>>> back to the protocol handler to send down the socket; so by that time >>>>>>>> even though the response is technically incorrect and the app has >>>>>>>> failed, it should still not cause the VM any issues. >>>>>>>> >>>>>>>> The data is polled every 10 seconds by the client app so I would not >>>>>>>> expect there to be 2GB of new data to send. I'm afraid my C skills are >>>>>>>> somewhat limited, so I'm not sure how to put together a sample app to >>>>>>>> try out writev. The platform is 64bit CentOS 6.3 (equivalent to RHEL >>>>>>>> 6.3) so I'm not expecting any strange or weird behaviour from the OS >>>>>>>> level but of course I could be completely wrong there. The OS is >>>>>>>> running directly on hardware, so there's no VM layer to worry about. >>>>>>>> >>>>>>>> Hope this might offer some additional clues? >>>>>>>> >>>>>>>> Thanks again! >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> >>>>>>>> Peter Membrey >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 24 November 2012 00:13, Patrik Nyblom wrote: >>>>>>>>> Hi again! >>>>>>>>> >>>>>>>>> Could you go back to the version without the printouts and get back >>>>>>>>> to >>>>>>>>> the >>>>>>>>> situation where writev loops returning 0 (as in the strace)? If so, >>>>>>>>> it >>>>>>>>> would >>>>>>>>> be really interesting to see an 'lsof' of the beam process, to see if >>>>>>>>> this >>>>>>>>> file descriptor really is open and is a socket... >>>>>>>>> >>>>>>>>> The thing is that writev with a vector that is not empty, would never >>>>>>>>> return >>>>>>>>> 0 for a non blocking socket. Not on any modern (i.e. not ancient) >>>>>>>>> POSIX >>>>>>>>> compliant system anyway. Of course it is a *really* large item you >>>>>>>>> are >>>>>>>>> trying to write there, but it should be no problem for a 64bit linux. >>>>>>>>> >>>>>>>>> Also I think there is no use finding the Erlang code, I'll take that >>>>>>>>> back, >>>>>>>>> It would be more interesting to see what really happens at the OS/VM >>>>>>>>> level >>>>>>>>> in this case. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Patrik >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/23/2012 01:49 AM, Lo?c Hoguin wrote: >>>>>>>>>> Sending this on behalf of someone who didn't manage to get the email >>>>>>>>>> sent >>>>>>>>>> to this list after 2 attempts. If someone can check if he's hold up >>>>>>>>>> or >>>>>>>>>> something that'd be great. >>>>>>>>>> >>>>>>>>>> Anyway he has a big issue so I hope I can relay the conversation >>>>>>>>>> reliably. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> On 11/23/2012 01:45 AM, Peter Membrey wrote: >>>>>>>>>>> From: Peter Membrey >>>>>>>>>>> Date: 22 November 2012 19:02 >>>>>>>>>>> Subject: VM locks up on write to socket (and now it seems to file >>>>>>>>>>> too) >>>>>>>>>>> To: erlang-bugs@REDACTED >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi guys, >>>>>>>>>>> >>>>>>>>>>> I wrote a simple database application called CakeDB >>>>>>>>>>> (https://github.com/pmembrey/cakedb) that basically spends its time >>>>>>>>>>> reading and writing files and sockets. There's very little in the >>>>>>>>>>> way >>>>>>>>>>> of complex logic. It is running on CentOS 6.3 with all the updates >>>>>>>>>>> applied. I hit this problem on R15B02 so I rolled back to R15B01 >>>>>>>>>>> but >>>>>>>>>>> the issue remained. Erlang was built from source. >>>>>>>>>>> >>>>>>>>>>> The machine has two Intel X5690 CPUs giving 12 cores plus HT. I've >>>>>>>>>>> tried various arguments for the VM but so far nothing has prevented >>>>>>>>>>> the problem. At the moment I'm using: >>>>>>>>>>> >>>>>>>>>>> +K >>>>>>>>>>> +A 6 >>>>>>>>>>> +sbt tnnps >>>>>>>>>>> >>>>>>>>>>> The issue I'm seeing is that one of the scheduler threads will hit >>>>>>>>>>> 100% cpu usage and the entire VM will become unresponsive. When >>>>>>>>>>> this >>>>>>>>>>> happens, I am not able to connect via the console with attach and >>>>>>>>>>> entop is also unable to connect. I can still establish TCP >>>>>>>>>>> connections >>>>>>>>>>> to the application, but I never receive a response. A standard kill >>>>>>>>>>> signal will cause the VM to shut down (it doesn't need -9). >>>>>>>>>>> >>>>>>>>>>> Due to the pedigree of the VM I am quite willing to accept that >>>>>>>>>>> I've >>>>>>>>>>> made a fundamental mistake in my code. I am pretty sure that the >>>>>>>>>>> way >>>>>>>>>>> I >>>>>>>>>>> am doing the file IO could result in some race conditions. However, >>>>>>>>>>> my >>>>>>>>>>> poor code aside, from what I understand, I still shouldn't be able >>>>>>>>>>> to >>>>>>>>>>> crash / deadlock the VM like this. >>>>>>>>>>> >>>>>>>>>>> The issue doesn't seem to be caused by load. The app can fail when >>>>>>>>>>> it's very busy, but also when it is practically idle. I haven't >>>>>>>>>>> been >>>>>>>>>>> able to find a trigger or any other explanation for the failure. >>>>>>>>>>> >>>>>>>>>>> The thread maxing out the CPU is attempting to write data to the >>>>>>>>>>> socket: >>>>>>>>>>> >>>>>>>>>>> (gdb) bt >>>>>>>>>>> #0 0x00007f9882ab6377 in writev () from /lib64/libc.so.6 >>>>>>>>>>> #1 0x000000000058a81f in tcp_inet_output (data=0x2407570, >>>>>>>>>>> event=) at drivers/common/inet_drv.c:9681 >>>>>>>>>>> #2 tcp_inet_drv_output (data=0x2407570, event=>>>>>>>>>> out>) >>>>>>>>>>> at drivers/common/inet_drv.c:9601 >>>>>>>>>>> #3 0x00000000004b773f in erts_port_task_execute >>>>>>>>>>> (runq=0x7f98826019c0, >>>>>>>>>>> curr_port_pp=0x7f9881639338) at beam/erl_port_task.c:858 >>>>>>>>>>> #4 0x00000000004afd83 in schedule (p=, >>>>>>>>>>> calls=) at beam/erl_process.c:6533 >>>>>>>>>>> #5 0x0000000000539ca2 in process_main () at beam/beam_emu.c:1268 >>>>>>>>>>> #6 0x00000000004b1279 in sched_thread_func (vesdp=0x7f9881639280) >>>>>>>>>>> at >>>>>>>>>>> beam/erl_process.c:4834 >>>>>>>>>>> #7 0x00000000005ba726 in thr_wrapper (vtwd=0x7fff6cfe2300) at >>>>>>>>>>> pthread/ethread.c:106 >>>>>>>>>>> #8 0x00007f9882f78851 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #9 0x00007f9882abe11d in clone () from /lib64/libc.so.6 >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> I then tried running strace on that thread and got (indefinitely): >>>>>>>>>>> >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> writev(15, [{"", 2158022464}], 1) = 0 >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> From what I can tell, it's trying to write data to a socket, >>>>>>>>>>> which >>>>>>>>>>> is >>>>>>>>>>> succeeding, but writing 0 bytes. From the earlier definitions in >>>>>>>>>>> the >>>>>>>>>>> source file, an error condition would be signified by a negative >>>>>>>>>>> number. Any other result is the number of bytes written, in this >>>>>>>>>>> case >>>>>>>>>>> 0. I'm not sure if this is desired behaviour or not. I've tried >>>>>>>>>>> killing the application on the other end of the socket, but it has >>>>>>>>>>> no >>>>>>>>>>> effect on the VM. >>>>>>>>>>> >>>>>>>>>>> I have enabled debugging for the inet code, so hopefully this will >>>>>>>>>>> give a little more insight. I am currently trying to reproduce the >>>>>>>>>>> condition, but as I really have no idea what causes it, it's pretty >>>>>>>>>>> much a case of wait and see. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> **** UPDATE **** >>>>>>>>>>> >>>>>>>>>>> I managed to lock up the VM again, but this time it was caused by >>>>>>>>>>> file >>>>>>>>>>> IO, >>>>>>>>>>> probably from the debugging statements. Although it worked fine for >>>>>>>>>>> some >>>>>>>>>>> time >>>>>>>>>>> the last entry in the file was cut off. >>>>>>>>>>> >>>>>>>>>>> From GDB: >>>>>>>>>>> >>>>>>>>>>> (gdb) info threads >>>>>>>>>>> 53 Thread 0x7f83e988b700 (LWP 8621) 0x00007f83ea6da54d in >>>>>>>>>>> read >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>> 52 Thread 0x7f83e8c8f700 (LWP 8622) 0x00007f83ea6d743c in >>>>>>>>>>> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>>>>>>>>>> 51 Thread 0x7f83e818d700 (LWP 8623) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 50 Thread 0x7f83e816b700 (LWP 8624) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 49 Thread 0x7f83e8149700 (LWP 8625) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 48 Thread 0x7f83e8127700 (LWP 8626) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 47 Thread 0x7f83e8105700 (LWP 8627) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 46 Thread 0x7f83e80e3700 (LWP 8628) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 45 Thread 0x7f83e80c1700 (LWP 8629) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 44 Thread 0x7f83e809f700 (LWP 8630) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 43 Thread 0x7f83e807d700 (LWP 8631) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 42 Thread 0x7f83e805b700 (LWP 8632) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 41 Thread 0x7f83e8039700 (LWP 8633) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 40 Thread 0x7f83e8017700 (LWP 8634) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 39 Thread 0x7f83e7ff5700 (LWP 8635) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 38 Thread 0x7f83e7fd3700 (LWP 8636) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 37 Thread 0x7f83e7fb1700 (LWP 8637) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 36 Thread 0x7f83e7f8f700 (LWP 8638) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 35 Thread 0x7f83e7f6d700 (LWP 8639) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 34 Thread 0x7f83e7f4b700 (LWP 8640) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 33 Thread 0x7f83e7f29700 (LWP 8641) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 32 Thread 0x7f83e7f07700 (LWP 8642) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 31 Thread 0x7f83e7ee5700 (LWP 8643) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 30 Thread 0x7f83e7ec3700 (LWP 8644) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 29 Thread 0x7f83e7ea1700 (LWP 8645) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 28 Thread 0x7f83e7e7f700 (LWP 8646) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 27 Thread 0x7f83d7c5a700 (LWP 8647) 0x00007f83ea6db09d in >>>>>>>>>>> waitpid >>>>>>>>>>> () from /lib64/libpthread.so.0 >>>>>>>>>>> 26 Thread 0x7f83d7c53700 (LWP 8648) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 25 Thread 0x7f83d7252700 (LWP 8649) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 24 Thread 0x7f83d6851700 (LWP 8650) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 23 Thread 0x7f83d5e50700 (LWP 8651) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 22 Thread 0x7f83d544f700 (LWP 8652) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 21 Thread 0x7f83d4a4e700 (LWP 8653) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 20 Thread 0x7f83d404d700 (LWP 8654) 0x00007f83ea20be7d in >>>>>>>>>>> write >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> 19 Thread 0x7f83d364c700 (LWP 8655) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 18 Thread 0x7f83d2c4b700 (LWP 8656) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 17 Thread 0x7f83d224a700 (LWP 8657) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 16 Thread 0x7f83d1849700 (LWP 8658) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 15 Thread 0x7f83d0e48700 (LWP 8659) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 14 Thread 0x7f83d0447700 (LWP 8660) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 13 Thread 0x7f83cfa46700 (LWP 8661) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 12 Thread 0x7f83cf045700 (LWP 8662) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 11 Thread 0x7f83ce644700 (LWP 8663) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 10 Thread 0x7f83cdc43700 (LWP 8664) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () from /lib64/libc.so.6 >>>>>>>>>>> 9 Thread 0x7f83cd242700 (LWP 8665) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> 8 Thread 0x7f83cc841700 (LWP 8666) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> 7 Thread 0x7f83cbe40700 (LWP 8667) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> 6 Thread 0x7f83cb43f700 (LWP 8668) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> 5 Thread 0x7f83caa3e700 (LWP 8669) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> 4 Thread 0x7f83ca03d700 (LWP 8670) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> 3 Thread 0x7f83c963c700 (LWP 8671) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> 2 Thread 0x7f83c8c3b700 (LWP 8672) 0x00007f83ea215ae9 in >>>>>>>>>>> syscall >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> * 1 Thread 0x7f83eb3a8700 (LWP 8597) 0x00007f83ea211d03 in select >>>>>>>>>>> () >>>>>>>>>>> from /lib64/libc.so.6 >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (gdb) bt >>>>>>>>>>> #0 0x00007f83ea20be7d in write () from /lib64/libc.so.6 >>>>>>>>>>> #1 0x00007f83ea1a2583 in _IO_new_file_write () from >>>>>>>>>>> /lib64/libc.so.6 >>>>>>>>>>> #2 0x00007f83ea1a3b35 in _IO_new_do_write () from /lib64/libc.so.6 >>>>>>>>>>> #3 0x00007f83ea1a21fd in _IO_new_file_xsputn () from >>>>>>>>>>> /lib64/libc.so.6 >>>>>>>>>>> #4 0x00007f83ea17589d in vfprintf () from /lib64/libc.so.6 >>>>>>>>>>> #5 0x00007f83ea18003a in printf () from /lib64/libc.so.6 >>>>>>>>>>> #6 0x000000000058f0e8 in tcp_recv (desc=0x2c3d350, request_len=0) >>>>>>>>>>> at >>>>>>>>>>> drivers/common/inet_drv.c:8976 >>>>>>>>>>> #7 0x000000000058f63a in tcp_inet_input (data=0x2c3d350, >>>>>>>>>>> event=>>>>>>>>>> optimized out>) at drivers/common/inet_drv.c:9326 >>>>>>>>>>> #8 tcp_inet_drv_input (data=0x2c3d350, event=>>>>>>>>>> out>) >>>>>>>>>>> at drivers/common/inet_drv.c:9604 >>>>>>>>>>> #9 0x00000000004b770f in erts_port_task_execute >>>>>>>>>>> (runq=0x7f83e9d5d3c0, >>>>>>>>>>> curr_port_pp=0x7f83e8dc6e78) at beam/erl_port_task.c:851 >>>>>>>>>>> #10 0x00000000004afd83 in schedule (p=, >>>>>>>>>>> calls=) at beam/erl_process.c:6533 >>>>>>>>>>> #11 0x0000000000539ca2 in process_main () at beam/beam_emu.c:1268 >>>>>>>>>>> #12 0x00000000004b1279 in sched_thread_func (vesdp=0x7f83e8dc6dc0) >>>>>>>>>>> at >>>>>>>>>>> beam/erl_process.c:4834 >>>>>>>>>>> #13 0x00000000005bb3e6 in thr_wrapper (vtwd=0x7fffe8266da0) at >>>>>>>>>>> pthread/ethread.c:106 >>>>>>>>>>> #14 0x00007f83ea6d3851 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #15 0x00007f83ea21911d in clone () from /lib64/libc.so.6 >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> (gdb) bt >>>>>>>>>>> #0 0x00007f83ea6da54d in read () from /lib64/libpthread.so.0 >>>>>>>>>>> #1 0x0000000000554b6e in signal_dispatcher_thread_func >>>>>>>>>>> (unused=>>>>>>>>>> optimized out>) at sys/unix/sys.c:2776 >>>>>>>>>>> #2 0x00000000005bb3e6 in thr_wrapper (vtwd=0x7fffe8266c80) at >>>>>>>>>>> pthread/ethread.c:106 >>>>>>>>>>> #3 0x00007f83ea6d3851 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #4 0x00007f83ea21911d in clone () from /lib64/libc.so.6 >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> (gdb) bt >>>>>>>>>>> #0 0x00007f83ea215ae9 in syscall () from /lib64/libc.so.6 >>>>>>>>>>> #1 0x00000000005bba35 in wait__ (e=0x2989390) at >>>>>>>>>>> pthread/ethr_event.c:92 >>>>>>>>>>> #2 ethr_event_wait (e=0x2989390) at pthread/ethr_event.c:218 >>>>>>>>>>> #3 0x00000000004ae5bd in erts_tse_wait (fcalls=>>>>>>>>>> out>, >>>>>>>>>>> esdp=0x7f83e8e2c440, rq=0x7f83e9d5e7c0) at beam/erl_threads.h:2319 >>>>>>>>>>> #4 scheduler_wait (fcalls=, >>>>>>>>>>> esdp=0x7f83e8e2c440, >>>>>>>>>>> rq=0x7f83e9d5e7c0) at beam/erl_process.c:2087 >>>>>>>>>>> #5 0x00000000004afb94 in schedule (p=, >>>>>>>>>>> calls=) at beam/erl_process.c:6467 >>>>>>>>>>> #6 0x0000000000539ca2 in process_main () at beam/beam_emu.c:1268 >>>>>>>>>>> #7 0x00000000004b1279 in sched_thread_func (vesdp=0x7f83e8e2c440) >>>>>>>>>>> at >>>>>>>>>>> beam/erl_process.c:4834 >>>>>>>>>>> #8 0x00000000005bb3e6 in thr_wrapper (vtwd=0x7fffe8266da0) at >>>>>>>>>>> pthread/ethread.c:106 >>>>>>>>>>> #9 0x00007f83ea6d3851 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #10 0x00007f83ea21911d in clone () from /lib64/libc.so.6 >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (gdb) bt >>>>>>>>>>> #0 0x00007f83ea6db09d in waitpid () from /lib64/libpthread.so.0 >>>>>>>>>>> #1 0x0000000000555a9f in child_waiter (unused=>>>>>>>>>> out>) >>>>>>>>>>> at sys/unix/sys.c:2700 >>>>>>>>>>> #2 0x00000000005bb3e6 in thr_wrapper (vtwd=0x7fffe8266d50) at >>>>>>>>>>> pthread/ethread.c:106 >>>>>>>>>>> #3 0x00007f83ea6d3851 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #4 0x00007f83ea21911d in clone () from /lib64/libc.so.6 >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> **** END UPDATE **** >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm happy to provide any information I can, so please don't >>>>>>>>>>> hesitate >>>>>>>>>>> to >>>>>>>>>>> ask. >>>>>>>>>>> >>>>>>>>>>> Thanks in advance! >>>>>>>>>>> >>>>>>>>>>> Kind Regards, >>>>>>>>>>> >>>>>>>>>>> Peter Membrey >>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 bjorn@REDACTED Tue Feb 11 07:06:09 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 11 Feb 2014 07:06:09 +0100 Subject: [erlang-bugs] system_limit: erlc passing options as atoms to erl In-Reply-To: <52F90CC9.2050702@gmail.com> References: <52F90CC9.2050702@gmail.com> Message-ID: On Mon, Feb 10, 2014 at 6:30 PM, Richard Carlsson wrote: > The erlc program (erts/etc/common/erlc.c) invokes the erlang compiler as > "erl ... -s erl_compile compile_cmdline ...", which means that the command > line options are passed as atoms (due to -s). If an option string gets too > long, erlc crashes with reason 'system_limit' because atoms cannot be longer > than 255 characters. > > Case in point: the erlc option -MT ... gets passed as > {makedep_target,"..."}, where the target string is a list of one or more > filenames, typically generated from a Makefile. If the filenames are long > (in particular if absolute paths are used), this string can get longer than > 255 characters. > > Suggested solution: rewrite erlc (and other similar executables) to pass > options using the -run or -eval flag instead of -s. > Already fixed in the upcoming Erlang/OTP 17.0 (and included in 17.0-rc1). Except for a few special arguments, erlc now passes the complete command to erlang use the -extra option, and the command line is then retrieved by erl_compile using init:get_plain_arguments/0. The other executables (dialyzer, typer, etc) already use use -extra and init:get_plain_arguments/0. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kostis@REDACTED Tue Feb 11 15:47:25 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 11 Feb 2014 15:47:25 +0100 Subject: [erlang-bugs] Unstated limits of random:uniform/1 Message-ID: <52FA37FD.4000300@cs.ntua.gr> The documentation of random:uniform/1 reads: uniform(N) -> integer() >= 1 Types: N = integer() >= 1 Given an integer N >= 1, uniform/1 returns a random integer uniformly distributed between 1 and N, updating the state in the process dictionary. and from it a (naive?) Erlang programmer would assume that it works for Erlang integers. However, apparently there is an (unstated) upper limit. ======================================================================== Eshell V6.0 (abort with ^G) 1> random:uniform(1 bsl 42). 1950905779137 2> random:uniform(1 bsl 1023). 64990220693815292632299777453770053245701880982584490305757715776780176648584151835529728245903303858071465265235635364507930685677056366431569479144084789774752709050314473717035731429737215919311815680621634352115003928201262448305879457258028874562676857884269587024825648343920396535221283000212783104001 3> random:uniform(1 bsl 1024). ** exception error: an error occurred when evaluating an arithmetic expression in function random:uniform/1 in call from erl_eval:do_apply/6 in call from shell:exprs/7 in call from shell:eval_exprs/7 in call from shell:eval_loop/3 in call from prim_file:set_cwd/2 ======================================================================== Minimally, the published documentation (and the types of all functions of this module) has to be updated to explicitly mention this limit. Ideally, the implementation has to change to avoid use of floats when manipulating Erlang integers. IMO, it does not really have to do this and result in crashes like that. Kostis From mjtruog@REDACTED Tue Feb 11 16:28:22 2014 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 11 Feb 2014 07:28:22 -0800 Subject: [erlang-bugs] Unstated limits of random:uniform/1 In-Reply-To: <52FA37FD.4000300@cs.ntua.gr> References: <52FA37FD.4000300@cs.ntua.gr> Message-ID: <52FA4196.8010808@gmail.com> 27817185604309 == 30269 * 30307 * 30323 is the highest N should ever be, otherwise the result is garbage. On 02/11/2014 06:47 AM, Kostis Sagonas wrote: > The documentation of random:uniform/1 reads: > > uniform(N) -> integer() >= 1 > > Types: > > N = integer() >= 1 > > Given an integer N >= 1, uniform/1 returns a random integer uniformly distributed between 1 and N, updating the state in the process dictionary. > > and from it a (naive?) Erlang programmer would assume that it works for Erlang integers. However, apparently there is an (unstated) upper limit. > > ======================================================================== > Eshell V6.0 (abort with ^G) > 1> random:uniform(1 bsl 42). > 1950905779137 > 2> random:uniform(1 bsl 1023). > 64990220693815292632299777453770053245701880982584490305757715776780176648584151835529728245903303858071465265235635364507930685677056366431569479144084789774752709050314473717035731429737215919311815680621634352115003928201262448305879457258028874562676857884269587024825648343920396535221283000212783104001 > 3> random:uniform(1 bsl 1024). > ** exception error: an error occurred when evaluating an arithmetic expression > in function random:uniform/1 > in call from erl_eval:do_apply/6 > in call from shell:exprs/7 > in call from shell:eval_exprs/7 > in call from shell:eval_loop/3 > in call from prim_file:set_cwd/2 > ======================================================================== > > Minimally, the published documentation (and the types of all functions of this module) has to be updated to explicitly mention this limit. > > Ideally, the implementation has to change to avoid use of floats when manipulating Erlang integers. IMO, it does not really have to do this and result in crashes like that. > > Kostis > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From Ingela.Anderton.Andin@REDACTED Thu Feb 13 12:23:32 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 13 Feb 2014 12:23:32 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52F4E1FD.30600@ninenines.eu> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> <52F4B109.3060602@ericsson.com> <52F4E1FD.30600@ninenines.eu> Message-ID: <52FCAB34.4060104@ericsson.com> Hi! The following patch will solve the problem below. diff --git a/lib/ssl/src/ssl.erl b/lib/ssl/src/ssl.erl index 7edc655..c4fa52c 100644 --- a/lib/ssl/src/ssl.erl +++ b/lib/ssl/src/ssl.erl @@ -771,7 +771,9 @@ validate_option(srp_identity, {Username, Password}) validate_option(ciphers, Value) when is_list(Value) -> Version = tls_record:highest_protocol_version([]), - try cipher_suites(Version, Value) + try cipher_suites(Version, Value) of + _-> + Value catch exit:_ -> throw({error, {options, {ciphers, Value}}}); Regards Ingela Erlang/OTP team - Ericsson AB On 02/07/2014 02:39 PM, Lo?c Hoguin wrote: > Please see attached. > > For the first test, you need the certificate files you can find in > Cowboy's SSL example (link is in the source). I just noticed that the > error for that test is more verbose in master. Not sure if that's a good > thing. > > For the second test, you need the erl_make_certs module found in OTP's > SSL application's test directory. > > The output should be as follow. (YES people I am aware certificates and > keys are included in the error reports. They are either generated or > already public. You do not need to warn me about it. Thank you.) > > Enjoy! > > % erl > Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source-8d71ab4] [64-bit] > [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V6.0 (abort with ^G) > 1> c(sslv3bug_1). > {ok,sslv3bug_1} > 2> c(sslv3bug_2). > {ok,sslv3bug_2} > 3> c(erl_make_certs). > {ok,erl_make_certs} > 4> sslv3bug_1:server(). > <0.68.0> > 5> sslv3bug_1:client(). > > =ERROR REPORT==== 7-Feb-2014::14:35:36 === > ** State machine <0.74.0> terminating > ** Last message in was {tcp,#Port<0.2567>, > > <<37,242,6,108,56,11,13,53,8,124,121,177,224,225, > > 74,202,119,55,113,255,149,182,187,112,63,249,32, > > 228,11,30,87,232,165,85,99,178,130,29,69,122, > > 197,117,97,20,209,0,128,136,95,242,23,13,180,70, > > 30,115,142,31,209,46,215,77,113,218,250,191,165, > > 223,25,10,73,119,196,193,108,146,14,209,250,122, > > 14,168,170,188,149,168,235,67,252,6,247,29,253, > > 203,253,219,114,161,112,19,44,197,60,251,26,190, > > 160,118,235,40,75,100,81,153,153,107,93,130,70, > > 102,64,164,164,36,39,3,163,252,87,176,128,254, > > 50,178,252,223,25,107,98,52,145,153,209,255,18, > > 204,185,75,211,101,202,78,164,43,82,238,252,120, > > 56,137,64,208,253,151,232,123,135,223,95,130, > 171,67,78,244,44,22,3,0,0,4,14,0,0,0>>} > ** When State == certify > ** Data == {state,client, > {#Ref<0.0.0.971>,<0.33.0>}, > gen_tcp,tls_connection,tcp,tcp_closed,tcp_error, > "localhost",44443,#Port<0.2567>, > {ssl_options,undefined, > [{3,3},{3,2},{3,1},{3,0}], > verify_none, > {#Fun,[]}, > false,false,undefined,1,<<>>,undefined,<<>>, > undefined,undefined,undefined,<<>>,undefined, > undefined,undefined,undefined,undefined, > [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, > <<0,107>>, > <<0,106>>, > <<0,61>>, > <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, > <<0,103>>, > <<0,64>>, > <<0,60>>, > <<"?\n">>, > <<192,20>>, > <<0,57>>, > <<0,56>>, > <<192,5>>, > <<192,15>>, > <<0,53>>, > <<"?\b">>, > <<192,18>>, > <<0,22>>, > <<0,19>>, > <<192,3>>, > <<"?\r">>, > <<0,10>>, > <<"?\t">>, > <<192,19>>, > <<0,51>>, > <<0,50>>, > <<192,4>>, > <<192,14>>, > <<0,47>>, > <<192,7>>, > <<192,17>>, > <<0,5>>, > <<0,4>>, > <<0,21>>, > <<192,2>>, > <<"?\f">>, > <<0,9>>], > > #Fun,true,268435456,false,undefined, > > undefined,false,undefined,undefined,true,undefined, > false}, > {socket_options,list,0,0,0,true}, > {connection_states, > {connection_state, > {security_parameters, > <<0,0>>, > > 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, > undefined,undefined}, > > undefined,undefined,undefined,undefined,2,true, > undefined,undefined}, > {connection_state, > > {security_parameters,<<"?(">>,1,7,1,16,256,32, > unknown,5,5,48,0,undefined, > > <<82,244,225,40,177,238,52,250,53,57,12,72,96, > > 92,157,86,51,250,227,239,173,167,250,154,25, > 29,237,89,176,188,61,181>>, > > <<82,244,225,40,43,69,20,224,136,14,240,93, > > 225,76,191,156,202,163,215,89,28,56,98,213, > 12,49,173,48,191,102,81,223>>, > undefined}, > undefined,undefined,undefined,undefined, > undefined,true,undefined,undefined}, > {connection_state, > {security_parameters, > <<0,0>>, > > 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, > undefined,undefined}, > > undefined,undefined,undefined,undefined,1,true, > undefined,undefined}, > {connection_state, > > {security_parameters,<<"?(">>,1,7,1,16,256,32, > unknown,5,5,48,0,undefined, > > <<82,244,225,40,177,238,52,250,53,57,12,72,96, > > 92,157,86,51,250,227,239,173,167,250,154,25, > 29,237,89,176,188,61,181>>, > > <<82,244,225,40,43,69,20,224,136,14,240,93, > > 225,76,191,156,202,163,215,89,28,56,98,213, > 12,49,173,48,191,102,81,223>>, > undefined}, > undefined,undefined,undefined,undefined, > undefined,true,undefined,undefined}}, > {protocol_buffers,[], > > <<22,3,0,0,203,12,0,0,199,3,0,23,65,4,112,42,53,141, > > 46,236,29,236,36,128,99,108,209,39,230,153,96,212,8>>, > <<>>,[]}, > > {[<<11,0,5,46,0,5,43,0,2,169,48,130,2,165,48,130,2,14,160, > > 3,2,1,2,2,9,0,235,233,83,76,182,123,146,121,48,13,6,9, > > 42,134,72,134,247,13,1,1,5,5,0,48,85,49,11,48,9,6,3, > > 85,4,6,19,2,85,83,49,14,48,12,6,3,85,4,8,12,5,84,101, > > 120,97,115,49,19,48,17,6,3,85,4,10,12,10,78,105,110, > > 101,32,78,105,110,101,115,49,15,48,13,6,3,85,4,11,12, > > 6,67,111,119,98,111,121,49,16,48,14,6,3,85,4,3,12,7, > > 82,79,79,84,32,67,65,48,30,23,13,49,51,48,50,50,56,48, > > 53,50,51,51,52,90,23,13,51,51,48,50,50,51,48,53,50,51, > > 51,52,90,48,87,49,11,48,9,6,3,85,4,6,19,2,85,83,49,14, > > 48,12,6,3,85,4,8,12,5,84,101,120,97,115,49,19,48,17,6, > > 3,85,4,10,12,10,78,105,110,101,32,78,105,110,101,115, > > 49,15,48,13,6,3,85,4,11,12,6,67,111,119,98,111,121,49, > > 18,48,16,6,3,85,4,3,12,9,108,111,99,97,108,104,111, > > 115,116,48,129,159,48,13,6,9,42,134,72,134,247,13,1,1, > > 1,5,0,3,129,141,0,48,129,137,2,129,129,0,205,181,181, > > 26,49,2,204,117,28,253,100,147,168,184,128,26,168,194, > > 53,199,17,230,198,149,75,236,168,207,100,143,70,26, > > 104,201,253,63,168,26,215,228,22,52,183,57,160,163,58, > > 19,137,23,196,227,0,162,84,63,125,9,207,131,174,159, > > 197,51,143,107,224,74,89,118,135,8,162,250,107,152, > > 233,175,254,12,36,162,63,121,205,160,58,60,163,103, > > 212,231,102,14,157,161,192,155,23,217,153,183,146,150, > > 198,81,148,241,140,57,36,113,201,160,81,190,4,140,190, > > 234,52,122,187,177,164,45,138,245,2,3,1,0,1,163,123, > > 48,121,48,9,6,3,85,29,19,4,2,48,0,48,44,6,9,96,134,72, > > 1,134,248,66,1,13,4,31,22,29,79,112,101,110,83,83,76, > > 32,71,101,110,101,114,97,116,101,100,32,67,101,114, > > 116,105,102,105,99,97,116,101,48,29,6,3,85,29,14,4,22, > > 4,20,30,163,76,66,22,35,196,245,114,67,145,3,129,158, > > 205,188,152,198,214,239,48,31,6,3,85,29,35,4,24,48,22, > > 128,20,74,125,159,10,23,104,229,44,16,230,52,190,136, > > 184,75,134,99,74,93,111,48,13,6,9,42,134,72,134,247, > > 13,1,1,5,5,0,3,129,129,0,35,27,161,84,35,175,31,46, > > 253,249,55,130,95,236,71,75,91,3,69,159,252,215,18, > > 216,60,236,203,103,51,157,216,21,80,1,184,74,166,254, > > 133,248,39,209,218,128,201,66,160,133,26,227,220,144, > > 220,99,22,36,176,99,200,146,80,223,63,54,91,239,34, > > 119,246,93,122,235,30,89,136,140,225,167,192,128,85, > > 211,239,71,20,115,159,14,107,103,6,151,122,202,242,94, > > 237,99,85,38,113,78,189,204,97,151,100,27,162,154,0, > > 205,45,247,79,152,148,98,217,80,111,31,2,39,49,208,23, > > 254,0,2,124,48,130,2,120,48,130,1,225,160,3,2,1,2,2,9, > > 0,235,233,83,76,182,123,146,120,48,13,6,9,42,134,72, > > 134,247,13,1,1,5,5,0,48,85,49,11,48,9,6,3,85,4,6,19,2, > > 85,83,49,14,48,12,6,3,85,4,8,12,5,84,101,120,97,115, > > 49,19,48,17,6,3,85,4,10,12,10,78,105,110,101,32,78, > > 105,110,101,115,49,15,48,13,6,3,85,4,11,12,6,67,111, > > 119,98,111,121,49,16,48,14,6,3,85,4,3,12,7,82,79,79, > > 84,32,67,65,48,30,23,13,49,51,48,50,50,56,48,53,49,48, > > 48,49,90,23,13,51,51,48,50,50,51,48,53,49,48,48,49,90, > > 48,85,49,11,48,9,6,3,85,4,6,19,2,85,83,49,14,48,12,6, > > 3,85,4,8,12,5,84,101,120,97,115,49,19,48,17,6,3,85,4, > > 10,12,10,78,105,110,101,32,78,105,110,101,115,49,15, > > 48,13,6,3,85,4,11,12,6,67,111,119,98,111,121,49,16,48, > > 14,6,3,85,4,3,12,7,82,79,79,84,32,67,65,48,129,159,48, > > 13,6,9,42,134,72,134,247,13,1,1,1,5,0,3,129,141,0,48, > > 129,137,2,129,129,0,204,230,99,181,44,211,172,163,201, > > 70,233,171,3,241,34,255,177,135,248,55,87,188,30,211, > > 176,165,11,209,132,98,123,235,220,228,47,116,13,99,20, > > 65,220,112,192,84,82,52,104,67,192,207,119,171,146, > > 200,174,84,146,44,64,6,205,60,78,222,65,221,91,39,24, > > 170,244,12,131,126,32,238,18,55,99,228,152,26,136,83, > > 240,77,220,167,92,192,222,185,96,218,247,136,205,10, > > 176,165,158,22,208,25,117,140,120,9,169,23,237,17,27, > > 59,76,35,43,109,0,31,124,82,6,125,238,20,104,129,2,3, > > 1,0,1,163,80,48,78,48,29,6,3,85,29,14,4,22,4,20,74, > > 125,159,10,23,104,229,44,16,230,52,190,136,184,75,134, > > 99,74,93,111,48,31,6,3,85,29,35,4,24,48,22,128,20,74, > > 125,159,10,23,104,229,44,16,230,52,190,136,184,75,134, > > 99,74,93,111,48,12,6,3,85,29,19,4,5,48,3,1,1,255,48, > > 13,6,9,42,134,72,134,247,13,1,1,5,5,0,3,129,129,0,109, > > 72,210,64,113,94,34,228,51,86,251,174,93,179,60,184, > > 179,68,70,32,214,111,154,141,190,171,91,51,206,6,14, > > 147,94,59,249,240,23,190,31,139,106,160,114,11,252, > > 207,220,174,44,94,195,151,166,126,208,100,184,1,163, > > 136,163,33,108,138,36,142,246,167,104,244,194,87,197, > > 58,28,123,205,191,63,92,235,193,233,17,37,155,119,238, > > 122,112,122,159,177,46,87,8,170,117,58,149,185,181, > > 178,246,81,6,41,20,163,15,226,169,155,191,113,26,164, > 23,207,62,100,133,48,22,245,139,96,8>>, > > <<2,0,0,83,3,0,82,244,225,40,43,69,20,224,136,14,240,93, > > 225,76,191,156,202,163,215,89,28,56,98,213,12,49,173, > > 48,191,102,81,223,32,104,211,174,230,197,6,57,224,137, > > 46,198,34,208,111,149,153,186,243,247,151,78,31,200, > > 228,94,87,239,178,48,249,204,99,192,40,0,0,11,0,11,0, > 2,1,0,255,1,0,1,0>>, > [1, > <<0,0,245>>, > > <<3,3,82,244,225,40,177,238,52,250,53,57,12,72,96,92, > > 157,86,51,250,227,239,173,167,250,154,25,29,237,89, > > 176,188,61,181,0,0,88,0,255,192,36,192,40,192,38, > > 192,42,0,107,0,106,0,61,192,35,192,39,192,37,192, > > 41,0,103,0,64,0,60,192,10,192,20,0,57,0,56,192,5, > > 192,15,0,53,192,8,192,18,0,22,0,19,192,3,192,13,0, > > 10,192,9,192,19,0,51,0,50,192,4,192,14,0,47,192,7, > > 192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0,0,116,0,0, > > 0,14,0,12,0,0,9,108,111,99,97,108,104,111,115,116, > > 0,10,0,58,0,56,0,14,0,13,0,25,0,28,0,11,0,12,0,27, > > 0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6,0,7,0,20,0,21, > > 0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15,0,16,0,17,0,11, > > 0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3,5,1,4,3,4,1,3,3, > 3,1,2,3,2,1,2,2,1,1>>]], > > [<<2,0,0,83,3,0,82,244,225,40,43,69,20,224,136,14,240,93, > > 225,76,191,156,202,163,215,89,28,56,98,213,12,49,173, > > 48,191,102,81,223,32,104,211,174,230,197,6,57,224,137, > > 46,198,34,208,111,149,153,186,243,247,151,78,31,200, > > 228,94,87,239,178,48,249,204,99,192,40,0,0,11,0,11,0, > 2,1,0,255,1,0,1,0>>, > [1, > <<0,0,245>>, > <<3,3,82,244,225,40,177,238,52,250,53,57,12,72,96, > 92,157,86,51,250,227,239,173,167,250,154,25,29, > > 237,89,176,188,61,181,0,0,88,0,255,192,36,192,40, > > 192,38,192,42,0,107,0,106,0,61,192,35,192,39,192, > > 37,192,41,0,103,0,64,0,60,192,10,192,20,0,57,0,56, > 192,5,192,15,0,53,192,8,192,18,0,22,0,19,192,3, > > 192,13,0,10,192,9,192,19,0,51,0,50,192,4,192,14,0, > > 47,192,7,192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0, > 0,116,0,0,0,14,0,12,0,0,9,108,111,99,97,108,104, > > 111,115,116,0,10,0,58,0,56,0,14,0,13,0,25,0,28,0, > > 11,0,12,0,27,0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6, > > 0,7,0,20,0,21,0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15, > > 0,16,0,17,0,11,0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3, > 5,1,4,3,4,1,3,3,3,1,2,3,2,1,2,2,1,1>>]]}, > 16400, > {session, > > <<104,211,174,230,197,6,57,224,137,46,198,34,208,111, > > 149,153,186,243,247,151,78,31,200,228,94,87,239,178, > 48,249,204,99>>, > > <<48,130,2,165,48,130,2,14,160,3,2,1,2,2,9,0,235,233, > > 83,76,182,123,146,121,48,13,6,9,42,134,72,134,247, > > 13,1,1,5,5,0,48,85,49,11,48,9,6,3,85,4,6,19,2,85,83, > > 49,14,48,12,6,3,85,4,8,12,5,84,101,120,97,115,49,19, > > 48,17,6,3,85,4,10,12,10,78,105,110,101,32,78,105, > > 110,101,115,49,15,48,13,6,3,85,4,11,12,6,67,111,119, > > 98,111,121,49,16,48,14,6,3,85,4,3,12,7,82,79,79,84, > > 32,67,65,48,30,23,13,49,51,48,50,50,56,48,53,50,51, > > 51,52,90,23,13,51,51,48,50,50,51,48,53,50,51,51,52, > > 90,48,87,49,11,48,9,6,3,85,4,6,19,2,85,83,49,14,48, > > 12,6,3,85,4,8,12,5,84,101,120,97,115,49,19,48,17,6, > > 3,85,4,10,12,10,78,105,110,101,32,78,105,110,101, > > 115,49,15,48,13,6,3,85,4,11,12,6,67,111,119,98,111, > > 121,49,18,48,16,6,3,85,4,3,12,9,108,111,99,97,108, > > 104,111,115,116,48,129,159,48,13,6,9,42,134,72,134, > > 247,13,1,1,1,5,0,3,129,141,0,48,129,137,2,129,129,0, > > 205,181,181,26,49,2,204,117,28,253,100,147,168,184, > > 128,26,168,194,53,199,17,230,198,149,75,236,168,207, > > 100,143,70,26,104,201,253,63,168,26,215,228,22,52, > > 183,57,160,163,58,19,137,23,196,227,0,162,84,63,125, > > 9,207,131,174,159,197,51,143,107,224,74,89,118,135, > > 8,162,250,107,152,233,175,254,12,36,162,63,121,205, > > 160,58,60,163,103,212,231,102,14,157,161,192,155,23, > > 217,153,183,146,150,198,81,148,241,140,57,36,113, > > 201,160,81,190,4,140,190,234,52,122,187,177,164,45, > > 138,245,2,3,1,0,1,163,123,48,121,48,9,6,3,85,29,19, > > 4,2,48,0,48,44,6,9,96,134,72,1,134,248,66,1,13,4,31, > > 22,29,79,112,101,110,83,83,76,32,71,101,110,101,114, > > 97,116,101,100,32,67,101,114,116,105,102,105,99,97, > > 116,101,48,29,6,3,85,29,14,4,22,4,20,30,163,76,66, > > 22,35,196,245,114,67,145,3,129,158,205,188,152,198, > > 214,239,48,31,6,3,85,29,35,4,24,48,22,128,20,74,125, > > 159,10,23,104,229,44,16,230,52,190,136,184,75,134, > > 99,74,93,111,48,13,6,9,42,134,72,134,247,13,1,1,5,5, > > 0,3,129,129,0,35,27,161,84,35,175,31,46,253,249,55, > > 130,95,236,71,75,91,3,69,159,252,215,18,216,60,236, > > 203,103,51,157,216,21,80,1,184,74,166,254,133,248, > > 39,209,218,128,201,66,160,133,26,227,220,144,220,99, > > 22,36,176,99,200,146,80,223,63,54,91,239,34,119,246, > > 93,122,235,30,89,136,140,225,167,192,128,85,211,239, > > 71,20,115,159,14,107,103,6,151,122,202,242,94,237, > > 99,85,38,113,78,189,204,97,151,100,27,162,154,0,205, > > 45,247,79,152,148,98,217,80,111,31,2,39,49,208,23, > 254>>, > undefined,0,<<"?(">>,undefined,undefined,new, > 63559002936,undefined}, > 28691,ssl_session_cache, > {3,0}, > false,ecdhe_rsa, > {undefined,undefined}, > undefined, > {{1,2,840,113549,1,1,1}, > {'RSAPublicKey', > > 144454330320215406279953568628491651436272064667760200600239478371082943052406671504117055906783067021801616968245536600804524397616119868619607006483647544685500850941126623013107537763694736146580312576904568190966271012889302320531771708303887413277040358538410888392437638452540396352971161638449355524853, > > 65537}, > 'NULL'}, > undefined,undefined,undefined,undefined,undefined, > > undefined,undefined,20497,#Ref<0.0.0.977>,undefined,<<>>, > {false,first}, > {<0.33.0>,#Ref<0.0.0.968>}, > undefined, > {[],[]}, > false,true,false,undefined,undefined} > ** Reason for termination = > ** {bad_return_value,{alert,2,51,{"ssl_connection.erl",420}}} > ** exception exit: > {{bad_return_value,{alert,2,51,{"ssl_connection.erl",420}}}, > {gen_fsm,sync_send_all_state_event, > [<0.74.0>,{start,infinity},infinity]}} > in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, > line 240) > in call from ssl_connection:sync_send_all_state_event/2 > (ssl_connection.erl, line 1630) > in call from ssl_connection:handshake/2 (ssl_connection.erl, line 96) > in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) > in call from ssl_connection:connect/8 (ssl_connection.erl, line 67) > 6> sslv3bug_2:server(). > <0.78.0> > 7> sslv3bug_2:client(). > ** exception exit: {{{case_clause,{4}}, > > [{ssl_v3,mac_hash,3,[{file,"ssl_v3.erl"},{line,163}]}, > {tls_record,encode_plain_text,4, > [{file,"tls_record.erl"},{line,134}]}, > {tls_connection,encode_handshake,4, > [{file,"tls_connection.erl"}, > {line,362}]}, > {tls_connection,send_handshake,2, > [{file,"tls_connection.erl"}, > {line,108}]}, > {ssl_connection,client_certify_and_key_exchange,2, > [{file,"ssl_connection.erl"}, > {line,1038}]}, > {tls_connection,next_state,4, > [{file,"tls_connection.erl"}, > {line,458}]}, > > {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]}, > {gen_fsm,sync_send_all_state_event, > [<0.81.0>,{start,infinity},infinity]}} > in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, > line 240) > in call from ssl_connection:sync_send_all_state_event/2 > (ssl_connection.erl, line 1630) > in call from ssl_connection:handshake/2 (ssl_connection.erl, line 96) > in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) > in call from ssl_connection:connect/8 (ssl_connection.erl, line 67) > 8> > =ERROR REPORT==== 7-Feb-2014::14:35:59 === > ** State machine <0.81.0> terminating > ** Last message in was {tcp,#Port<0.2911>, > > <<255,201,15,218,162,33,104,194,52,196,198,98,139, > > 128,220,28,209,41,2,78,8,138,103,204,116,2,11, > > 190,166,59,19,155,34,81,74,8,121,142,52,4,221, > > 239,149,25,179,205,58,67,27,48,43,10,109,242,95, > > 20,55,79,225,53,109,109,81,194,69,228,133,181, > > 118,98,94,126,198,244,76,66,233,166,55,237,107, > > 11,255,92,182,244,6,183,237,238,56,107,251,90, > > 137,159,165,174,159,36,17,124,75,31,230,73,40, > > 102,81,236,230,83,129,255,255,255,255,255,255, > > 255,255,0,1,2,0,128,216,166,31,174,121,159,156, > > 152,74,250,106,59,107,235,224,100,58,223,33,83, > > 118,28,193,65,121,227,4,83,159,162,248,251,156, > > 228,77,141,104,34,249,116,173,104,186,118,133, > > 43,79,55,213,103,22,79,162,165,3,251,2,252,106, > > 104,78,101,255,40,203,145,80,207,182,133,98,55, > > 49,1,80,68,54,12,31,138,6,235,74,72,16,106,4,17, > > 92,123,162,154,192,198,115,233,224,185,226,144, > > 225,241,68,141,237,16,159,212,2,60,232,186,100, > > 159,38,105,250,242,33,153,95,246,14,177,170,244, > > 86,41,0,47,48,45,2,20,78,183,247,114,172,238, > > 108,236,172,199,38,160,32,215,236,141,241,69, > > 232,195,2,21,0,206,237,39,58,180,66,46,147,245, > > 175,250,151,208,4,205,60,242,87,255,177,22,3,0, > 0,4,14,0,0,0>>} > ** When State == certify > ** Data == {state,client, > {#Ref<0.0.0.1012>,<0.76.0>}, > gen_tcp,tls_connection,tcp,tcp_closed,tcp_error, > "localhost",44443,#Port<0.2911>, > {ssl_options,undefined, > [{3,3},{3,2},{3,1},{3,0}], > verify_none, > {#Fun,[]}, > false,false,undefined,1,<<>>,undefined,<<>>, > undefined,undefined,undefined,<<>>,undefined, > undefined,undefined,undefined,undefined, > [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, > <<0,107>>, > <<0,106>>, > <<0,61>>, > <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, > <<0,103>>, > <<0,64>>, > <<0,60>>, > <<"?\n">>, > <<192,20>>, > <<0,57>>, > <<0,56>>, > <<192,5>>, > <<192,15>>, > <<0,53>>, > <<"?\b">>, > <<192,18>>, > <<0,22>>, > <<0,19>>, > <<192,3>>, > <<"?\r">>, > <<0,10>>, > <<"?\t">>, > <<192,19>>, > <<0,51>>, > <<0,50>>, > <<192,4>>, > <<192,14>>, > <<0,47>>, > <<192,7>>, > <<192,17>>, > <<0,5>>, > <<0,4>>, > <<0,21>>, > <<192,2>>, > <<"?\f">>, > <<0,9>>], > > #Fun,true,268435456,false,undefined, > > undefined,false,undefined,undefined,true,undefined, > false}, > {socket_options,list,0,0,0,true}, > {connection_states, > {connection_state, > {security_parameters, > <<0,0>>, > > 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, > undefined,undefined}, > > undefined,undefined,undefined,undefined,2,true, > undefined,undefined}, > {connection_state, > {security_parameters, > <<0,106>>, > 1,7,1,16,256,32,unknown,4,4711,32,0, > undefined, > > <<82,244,225,63,101,215,80,75,202,30,236,75, > > 214,92,173,239,61,137,174,226,135,182,38, > 168,60,36,24,219,50,94,16,198>>, > > <<82,244,225,63,188,177,3,238,107,25,107,72, > > 243,243,32,133,171,156,145,181,53,121,188, > 56,69,37,1,65,127,169,225,11>>, > undefined}, > undefined,undefined,undefined,undefined, > undefined,true,undefined,undefined}, > {connection_state, > {security_parameters, > <<0,0>>, > > 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, > undefined,undefined}, > > undefined,undefined,undefined,undefined,1,true, > undefined,undefined}, > {connection_state, > {security_parameters, > <<0,106>>, > 1,7,1,16,256,32,unknown,4,4711,32,0, > undefined, > > <<82,244,225,63,101,215,80,75,202,30,236,75, > > 214,92,173,239,61,137,174,226,135,182,38, > 168,60,36,24,219,50,94,16,198>>, > > <<82,244,225,63,188,177,3,238,107,25,107,72, > > 243,243,32,133,171,156,145,181,53,121,188, > 56,69,37,1,65,127,169,225,11>>, > undefined}, > undefined,undefined,undefined,undefined, > undefined,true,undefined,undefined}}, > {protocol_buffers,[], > > <<22,3,0,1,60,12,0,1,56,0,128,255,255,255,255,255,255, > 255>>, > <<>>,[]}, > > {[<<11,0,5,153,0,5,150,0,5,147,48,130,5,143,48,130,4,41, > > 160,3,2,1,2,2,6,0,168,88,141,229,65,48,130,1,44,6,7, > > 42,134,72,206,56,4,3,48,130,1,31,2,129,129,0,232,148, > > 166,31,193,7,156,37,221,185,181,134,210,206,133,125, > > 228,157,66,197,142,159,163,53,134,75,44,121,95,112, > > 171,141,10,111,6,104,28,68,249,89,51,210,135,202,124, > > 137,39,248,58,33,142,102,238,53,87,191,54,173,119,76, > > 14,129,52,149,215,77,223,78,247,64,247,138,164,116,37, > > 226,84,65,234,101,56,68,165,160,128,238,161,159,24, > > 216,48,172,183,209,100,143,141,107,100,45,29,108,193, > > 215,105,37,171,150,125,122,202,252,36,144,93,68,243, > > 192,32,114,86,101,122,253,217,161,54,81,2,21,0,214, > > 110,187,124,141,25,20,86,167,217,74,223,208,214,158, > > 82,129,45,229,129,2,129,129,0,145,148,122,39,49,43,61, > > 30,153,81,106,86,228,252,211,63,233,231,52,125,126, > > 210,184,201,77,113,188,219,174,151,155,7,34,93,62,234, > > 185,143,184,96,42,159,6,159,4,210,162,131,209,153,105, > > 125,172,202,235,169,97,78,193,237,51,92,122,0,44,226, > > 15,154,4,66,171,170,119,180,104,229,6,197,143,62,152, > > 192,216,215,209,189,218,27,42,199,48,112,73,125,55, > > 156,44,47,95,167,75,90,70,97,42,109,255,161,229,57, > > 246,0,172,207,230,62,211,188,197,8,250,139,25,71,57, > > 132,252,175,48,123,49,32,48,30,6,9,42,134,72,134,247, > > 13,1,9,1,22,17,82,111,111,116,67,65,64,101,114,108,97, > > 110,103,46,111,114,103,49,15,48,13,6,3,85,4,3,19,6,82, > > 111,111,116,67,65,49,18,48,16,6,3,85,4,7,19,9,83,116, > > 111,99,107,104,111,108,109,49,11,48,9,6,3,85,4,6,19,2, > > 83,69,49,15,48,13,6,3,85,4,10,19,6,101,114,108,97,110, > > 103,49,20,48,18,6,3,85,4,11,19,11,116,101,115,116,105, > > 110,103,32,100,101,112,48,34,24,15,50,48,49,52,48,50, > > 48,54,48,48,48,48,48,48,90,24,15,50,48,49,52,48,50,49, > > 52,48,48,48,48,48,48,90,48,121,49,31,48,29,6,9,42,134, > > 72,134,247,13,1,9,1,22,16,101,115,115,101,110,64,101, > > 114,108,97,110,103,46,111,114,103,49,14,48,12,6,3,85, > > 4,3,19,5,101,115,115,101,110,49,18,48,16,6,3,85,4,7, > > 19,9,83,116,111,99,107,104,111,108,109,49,11,48,9,6,3, > > 85,4,6,19,2,83,69,49,15,48,13,6,3,85,4,10,19,6,101, > > 114,108,97,110,103,49,20,48,18,6,3,85,4,11,19,11,116, > > 101,115,116,105,110,103,32,100,101,112,48,130,1,183, > > 48,130,1,43,6,7,42,134,72,206,56,4,1,48,130,1,30,2, > > 129,129,0,172,20,101,160,1,130,221,238,24,42,170,3,17, > > 62,230,231,15,182,23,122,127,202,54,148,36,32,27,64, > > 221,180,126,41,187,207,133,60,140,0,116,50,56,250,210, > > 130,36,42,1,0,254,74,15,125,231,23,199,145,185,91,88, > > 223,179,52,215,22,36,165,226,0,4,236,135,79,246,221, > > 81,124,230,72,58,212,233,186,42,201,32,47,115,113,22, > > 251,228,179,170,88,91,55,151,16,150,103,0,88,136,40, > > 89,52,202,162,205,187,89,154,57,76,34,101,146,109,244, > > 232,72,134,127,42,102,7,189,43,2,21,0,213,146,169,239, > > 217,145,225,127,111,174,189,211,177,222,47,248,104,29, > > 27,237,2,129,128,16,109,41,186,123,49,80,129,242,62, > > 70,145,216,15,131,72,58,194,148,147,221,175,54,65,123, > > 227,5,114,111,40,176,249,196,244,205,13,12,7,135,99, > > 54,234,160,44,233,6,117,17,196,162,142,213,141,109, > > 141,148,108,149,217,138,200,100,108,254,98,41,241,147, > > 214,217,252,186,131,40,26,118,255,17,241,219,101,166, > > 161,62,43,20,24,120,204,242,70,63,190,208,134,173,160, > > 196,206,225,255,223,8,180,115,245,128,7,193,136,7,151, > > 36,154,246,240,187,218,72,139,23,18,21,7,129,20,230, > > 72,3,129,133,0,2,129,129,0,152,168,223,43,127,77,1, > > 215,72,34,80,184,125,73,66,28,78,154,60,68,31,82,235, > > 252,250,73,183,249,83,189,159,48,60,60,11,88,52,57,55, > > 84,243,40,204,232,50,91,126,196,126,2,122,90,71,151, > > 148,135,145,192,163,23,244,154,184,151,79,14,206,64, > > 64,35,67,18,185,8,91,8,83,21,25,76,69,76,247,134,107, > > 112,103,204,60,192,28,158,224,106,64,18,14,43,24,212, > > 137,199,141,103,252,93,241,32,110,212,33,89,251,137, > > 28,144,197,212,76,219,135,208,21,252,243,184,104,67, > > 163,19,48,17,48,15,6,3,85,29,19,1,1,255,4,5,48,3,1,1, > > 255,48,130,1,44,6,7,42,134,72,206,56,4,3,48,130,1,31, > > 2,129,129,0,232,148,166,31,193,7,156,37,221,185,181, > > 134,210,206,133,125,228,157,66,197,142,159,163,53,134, > > 75,44,121,95,112,171,141,10,111,6,104,28,68,249,89,51, > > 210,135,202,124,137,39,248,58,33,142,102,238,53,87, > > 191,54,173,119,76,14,129,52,149,215,77,223,78,247,64, > > 247,138,164,116,37,226,84,65,234,101,56,68,165,160, > > 128,238,161,159,24,216,48,172,183,209,100,143,141,107, > > 100,45,29,108,193,215,105,37,171,150,125,122,202,252, > > 36,144,93,68,243,192,32,114,86,101,122,253,217,161,54, > > 81,2,21,0,214,110,187,124,141,25,20,86,167,217,74,223, > > 208,214,158,82,129,45,229,129,2,129,129,0,145,148,122, > > 39,49,43,61,30,153,81,106,86,228,252,211,63,233,231, > > 52,125,126,210,184,201,77,113,188,219,174,151,155,7, > > 34,93,62,234,185,143,184,96,42,159,6,159,4,210,162, > > 131,209,153,105,125,172,202,235,169,97,78,193,237,51, > > 92,122,0,44,226,15,154,4,66,171,170,119,180,104,229,6, > > 197,143,62,152,192,216,215,209,189,218,27,42,199,48, > > 112,73,125,55,156,44,47,95,167,75,90,70,97,42,109,255, > > 161,229,57,246,0,172,207,230,62,211,188,197,8,250,139, > > 25,71,57,132,252,175,3,48,0,48,45,2,21,0,182,82,58, > > 106,122,13,155,122,152,41,77,231,69,191,61,48,195,179, > > 189,65,2,20,18,41,247,30,218,157,162,131,0,182,220, > 145,199,117,186,83,112,21,220,12>>, > > <<2,0,0,83,3,0,82,244,225,63,188,177,3,238,107,25,107, > > 72,243,243,32,133,171,156,145,181,53,121,188,56,69,37, > > 1,65,127,169,225,11,32,190,94,115,98,18,255,115,139, > > 99,87,33,75,186,233,22,47,165,75,129,175,177,99,152, > > 60,150,43,93,150,146,202,73,169,0,106,0,0,11,0,11,0,2, > 1,0,255,1,0,1,0>>, > [1, > <<0,0,245>>, > > <<3,3,82,244,225,63,101,215,80,75,202,30,236,75,214, > > 92,173,239,61,137,174,226,135,182,38,168,60,36,24, > > 219,50,94,16,198,0,0,88,0,255,192,36,192,40,192,38, > > 192,42,0,107,0,106,0,61,192,35,192,39,192,37,192, > > 41,0,103,0,64,0,60,192,10,192,20,0,57,0,56,192,5, > > 192,15,0,53,192,8,192,18,0,22,0,19,192,3,192,13,0, > > 10,192,9,192,19,0,51,0,50,192,4,192,14,0,47,192,7, > > 192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0,0,116,0,0, > > 0,14,0,12,0,0,9,108,111,99,97,108,104,111,115,116, > > 0,10,0,58,0,56,0,14,0,13,0,25,0,28,0,11,0,12,0,27, > > 0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6,0,7,0,20,0,21, > > 0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15,0,16,0,17,0,11, > > 0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3,5,1,4,3,4,1,3,3, > 3,1,2,3,2,1,2,2,1,1>>]], > > [<<2,0,0,83,3,0,82,244,225,63,188,177,3,238,107,25,107, > > 72,243,243,32,133,171,156,145,181,53,121,188,56,69,37, > > 1,65,127,169,225,11,32,190,94,115,98,18,255,115,139, > > 99,87,33,75,186,233,22,47,165,75,129,175,177,99,152, > > 60,150,43,93,150,146,202,73,169,0,106,0,0,11,0,11,0,2, > 1,0,255,1,0,1,0>>, > [1, > <<0,0,245>>, > > <<3,3,82,244,225,63,101,215,80,75,202,30,236,75,214, > > 92,173,239,61,137,174,226,135,182,38,168,60,36,24, > 219,50,94,16,198,0,0,88,0,255,192,36,192,40,192, > 38,192,42,0,107,0,106,0,61,192,35,192,39,192,37, > 192,41,0,103,0,64,0,60,192,10,192,20,0,57,0,56, > 192,5,192,15,0,53,192,8,192,18,0,22,0,19,192,3, > > 192,13,0,10,192,9,192,19,0,51,0,50,192,4,192,14,0, > > 47,192,7,192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0, > 0,116,0,0,0,14,0,12,0,0,9,108,111,99,97,108,104, > > 111,115,116,0,10,0,58,0,56,0,14,0,13,0,25,0,28,0, > > 11,0,12,0,27,0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6, > > 0,7,0,20,0,21,0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15, > > 0,16,0,17,0,11,0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3, > 5,1,4,3,4,1,3,3,3,1,2,3,2,1,2,2,1,1>>]]}, > 16400, > {session, > > <<190,94,115,98,18,255,115,139,99,87,33,75,186,233,22, > > 47,165,75,129,175,177,99,152,60,150,43,93,150,146, > 202,73,169>>, > > <<48,130,5,143,48,130,4,41,160,3,2,1,2,2,6,0,168,88, > > 141,229,65,48,130,1,44,6,7,42,134,72,206,56,4,3,48, > > 130,1,31,2,129,129,0,232,148,166,31,193,7,156,37, > > 221,185,181,134,210,206,133,125,228,157,66,197,142, > > 159,163,53,134,75,44,121,95,112,171,141,10,111,6, > > 104,28,68,249,89,51,210,135,202,124,137,39,248,58, > > 33,142,102,238,53,87,191,54,173,119,76,14,129,52, > > 149,215,77,223,78,247,64,247,138,164,116,37,226,84, > > 65,234,101,56,68,165,160,128,238,161,159,24,216,48, > > 172,183,209,100,143,141,107,100,45,29,108,193,215, > > 105,37,171,150,125,122,202,252,36,144,93,68,243,192, > > 32,114,86,101,122,253,217,161,54,81,2,21,0,214,110, > > 187,124,141,25,20,86,167,217,74,223,208,214,158,82, > > 129,45,229,129,2,129,129,0,145,148,122,39,49,43,61, > > 30,153,81,106,86,228,252,211,63,233,231,52,125,126, > > 210,184,201,77,113,188,219,174,151,155,7,34,93,62, > > 234,185,143,184,96,42,159,6,159,4,210,162,131,209, > > 153,105,125,172,202,235,169,97,78,193,237,51,92,122, > > 0,44,226,15,154,4,66,171,170,119,180,104,229,6,197, > > 143,62,152,192,216,215,209,189,218,27,42,199,48,112, > > 73,125,55,156,44,47,95,167,75,90,70,97,42,109,255, > > 161,229,57,246,0,172,207,230,62,211,188,197,8,250, > > 139,25,71,57,132,252,175,48,123,49,32,48,30,6,9,42, > > 134,72,134,247,13,1,9,1,22,17,82,111,111,116,67,65, > > 64,101,114,108,97,110,103,46,111,114,103,49,15,48, > > 13,6,3,85,4,3,19,6,82,111,111,116,67,65,49,18,48,16, > > 6,3,85,4,7,19,9,83,116,111,99,107,104,111,108,109, > > 49,11,48,9,6,3,85,4,6,19,2,83,69,49,15,48,13,6,3,85, > > 4,10,19,6,101,114,108,97,110,103,49,20,48,18,6,3,85, > > 4,11,19,11,116,101,115,116,105,110,103,32,100,101, > > 112,48,34,24,15,50,48,49,52,48,50,48,54,48,48,48,48, > > 48,48,90,24,15,50,48,49,52,48,50,49,52,48,48,48,48, > > 48,48,90,48,121,49,31,48,29,6,9,42,134,72,134,247, > > 13,1,9,1,22,16,101,115,115,101,110,64,101,114,108, > > 97,110,103,46,111,114,103,49,14,48,12,6,3,85,4,3,19, > > 5,101,115,115,101,110,49,18,48,16,6,3,85,4,7,19,9, > > 83,116,111,99,107,104,111,108,109,49,11,48,9,6,3,85, > > 4,6,19,2,83,69,49,15,48,13,6,3,85,4,10,19,6,101,114, > > 108,97,110,103,49,20,48,18,6,3,85,4,11,19,11,116, > > 101,115,116,105,110,103,32,100,101,112,48,130,1,183, > > 48,130,1,43,6,7,42,134,72,206,56,4,1,48,130,1,30,2, > > 129,129,0,172,20,101,160,1,130,221,238,24,42,170,3, > > 17,62,230,231,15,182,23,122,127,202,54,148,36,32,27, > > 64,221,180,126,41,187,207,133,60,140,0,116,50,56, > > 250,210,130,36,42,1,0,254,74,15,125,231,23,199,145, > > 185,91,88,223,179,52,215,22,36,165,226,0,4,236,135, > > 79,246,221,81,124,230,72,58,212,233,186,42,201,32, > > 47,115,113,22,251,228,179,170,88,91,55,151,16,150, > > 103,0,88,136,40,89,52,202,162,205,187,89,154,57,76, > > 34,101,146,109,244,232,72,134,127,42,102,7,189,43,2, > > 21,0,213,146,169,239,217,145,225,127,111,174,189, > > 211,177,222,47,248,104,29,27,237,2,129,128,16,109, > > 41,186,123,49,80,129,242,62,70,145,216,15,131,72,58, > > 194,148,147,221,175,54,65,123,227,5,114,111,40,176, > > 249,196,244,205,13,12,7,135,99,54,234,160,44,233,6, > > 117,17,196,162,142,213,141,109,141,148,108,149,217, > > 138,200,100,108,254,98,41,241,147,214,217,252,186, > > 131,40,26,118,255,17,241,219,101,166,161,62,43,20, > > 24,120,204,242,70,63,190,208,134,173,160,196,206, > > 225,255,223,8,180,115,245,128,7,193,136,7,151,36, > > 154,246,240,187,218,72,139,23,18,21,7,129,20,230,72, > > 3,129,133,0,2,129,129,0,152,168,223,43,127,77,1,215, > > 72,34,80,184,125,73,66,28,78,154,60,68,31,82,235, > > 252,250,73,183,249,83,189,159,48,60,60,11,88,52,57, > > 55,84,243,40,204,232,50,91,126,196,126,2,122,90,71, > > 151,148,135,145,192,163,23,244,154,184,151,79,14, > > 206,64,64,35,67,18,185,8,91,8,83,21,25,76,69,76,247, > > 134,107,112,103,204,60,192,28,158,224,106,64,18,14, > > 43,24,212,137,199,141,103,252,93,241,32,110,212,33, > > 89,251,137,28,144,197,212,76,219,135,208,21,252,243, > > 184,104,67,163,19,48,17,48,15,6,3,85,29,19,1,1,255, > > 4,5,48,3,1,1,255,48,130,1,44,6,7,42,134,72,206,56,4, > > 3,48,130,1,31,2,129,129,0,232,148,166,31,193,7,156, > > 37,221,185,181,134,210,206,133,125,228,157,66,197, > > 142,159,163,53,134,75,44,121,95,112,171,141,10,111, > > 6,104,28,68,249,89,51,210,135,202,124,137,39,248,58, > > 33,142,102,238,53,87,191,54,173,119,76,14,129,52, > > 149,215,77,223,78,247,64,247,138,164,116,37,226,84, > > 65,234,101,56,68,165,160,128,238,161,159,24,216,48, > > 172,183,209,100,143,141,107,100,45,29,108,193,215, > > 105,37,171,150,125,122,202,252,36,144,93,68,243,192, > > 32,114,86,101,122,253,217,161,54,81,2,21,0,214,110, > > 187,124,141,25,20,86,167,217,74,223,208,214,158,82, > > 129,45,229,129,2,129,129,0,145,148,122,39,49,43,61, > > 30,153,81,106,86,228,252,211,63,233,231,52,125,126, > > 210,184,201,77,113,188,219,174,151,155,7,34,93,62, > > 234,185,143,184,96,42,159,6,159,4,210,162,131,209, > > 153,105,125,172,202,235,169,97,78,193,237,51,92,122, > > 0,44,226,15,154,4,66,171,170,119,180,104,229,6,197, > > 143,62,152,192,216,215,209,189,218,27,42,199,48,112, > > 73,125,55,156,44,47,95,167,75,90,70,97,42,109,255, > > 161,229,57,246,0,172,207,230,62,211,188,197,8,250, > > 139,25,71,57,132,252,175,3,48,0,48,45,2,21,0,182,82, > > 58,106,122,13,155,122,152,41,77,231,69,191,61,48, > > 195,179,189,65,2,20,18,41,247,30,218,157,162,131,0, > 182,220,145,199,117,186,83,112,21,220,12>>, > undefined,0, > <<0,106>>, > undefined,undefined,new,63559002959,undefined}, > 28691,ssl_session_cache, > {3,0}, > false,dhe_dss, > {undefined,undefined}, > undefined, > {{1,2,840,10040,4,1}, > > 107201255589035901224095606533558326562411652347289232035103542030345159420839486230268504779574656171583558015264296286449883604707549621612623958146832751634671347771456676561935478712661717567833349731571068193127995126983390616249150208033231204136081889066713700820639352472736328354631788188647982393411, > > {'Dss-Parms', > > 120838457660118919847784105390049937477281231873987813527469753170393689289232527428167218258880467891327129458677867506421714970972002253380733557408691307378960985768079995491587653331614446765301506047915886847153350641972403963007845318607852639159131694882003981406543445440571784899938168852566501735723, > > > 1219285746577471382994815749003130182104667462637, > > 11535022978489302833643653962713113424104775336555003172828907456342498068622451037206915043471103346423380726835531941532378578411298596088596278301950468270328767064787145526948017146253629314732272784540599889965624014006517245965850597974665875953436492876504607797788574892832624787243340450198197691976}}, > > undefined,undefined,undefined,undefined,undefined, > undefined,undefined,20497,#Ref<0.0.0.1014>,undefined, > <<>>, > {false,first}, > {<0.76.0>,#Ref<0.0.0.1008>}, > undefined, > {[],[]}, > false,true,false,undefined,undefined} > ** Reason for termination = > ** {{case_clause,{4}}, > [{ssl_v3,mac_hash,3,[{file,"ssl_v3.erl"},{line,163}]}, > > {tls_record,encode_plain_text,4,[{file,"tls_record.erl"},{line,134}]}, > {tls_connection,encode_handshake,4, > [{file,"tls_connection.erl"},{line,362}]}, > {tls_connection,send_handshake,2, > [{file,"tls_connection.erl"},{line,108}]}, > {ssl_connection,client_certify_and_key_exchange,2, > [{file,"ssl_connection.erl"},{line,1038}]}, > > {tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,458}]}, > {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} > > > On 02/07/2014 11:10 AM, Ingela Anderton Andin wrote: >> Hi! >> >> If you can provide a failing test case that is a good place to start. I >> will not have time to look at it until Monday as I am looking after my >> sick daughter today, and just quickly answering some mails. >> >> Regards Ingela Erlang/OTP team >> >> On 02/07/2014 11:01 AM, Lo?c Hoguin wrote: >>> On 02/06/2014 09:29 PM, Ingela Anderton Andin wrote: >>>> Hi! >>>> >>>> On 02/06/2014 05:59 PM, Lo?c Hoguin wrote: >>>>> Just [{cert, Cert}, {key, Key}, {port, 0}, {versions, [sslv3]}] does >>>>> it. >>>> >>>> You mean that you get it when you input certs as binaries? Could it be >>>> related to https://github.com/erlang/otp/pull/163 >>>> We want to include this pull request but it solves two problems and >>>> only one persists and we are waiting for the pull >>>> request to be updated. >>> >>> I don't have any idea what that pull request is about. I am not too well >>> versed in SSL-fu. >>> >>> I narrowed it down a little. >>> >>> The previously mentioned issue only happens with a test certificate >>> generated by erl_make_certs.erl. >>> >>> A different report happens with a certificate generated by OpenSSL >>> (again, setting versions to [sslv3]). >>> >>> =ERROR REPORT==== 7-Feb-2014::10:55:57 === >>> SSL: certify: tls_connection.erl:2286:Fatal error: decrypt error >>> >>> =ERROR REPORT==== 7-Feb-2014::10:55:57 === >>> SSL: certify: tls_connection.erl:2055:Fatal error: decrypt error >>> {error,{tls_alert,"decrypt error"}} >>> >>> The client in all cases is always: >>> >>> ssl:connect("localhost", 44443, []). >>> >>> I can provide a test case for either or both of them if you want. >>> >> > From n.oxyde@REDACTED Thu Feb 13 12:32:44 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 12:32:44 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52FCAB34.4060104@ericsson.com> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> <52F4B109.3060602@ericsson.com> <52F4E1FD.30600@ninenines.eu> <52FCAB34.4060104@ericsson.com> Message-ID: <1E80C311-AD62-456E-834C-5756B6687068@gmail.com> Hello Ingela, Out of curiosity, given that this clause is called from 629: ciphers = handle_option(ciphers, Opts, []), where the default list of ciphers is empty, and given this clause 939: cipher_suites(Version, []) -> 940: ssl_cipher:suites(Version); which calls ssl_cipher:suites/1 suites({3, 0}) -> ssl_v3:suites(); why would the ciphers list not be the empty list as in this patch? Or does your patch mean that ssl_v3 is actually really called, but that its return value should be ignored and the empty list be used instead? Given that ssl:cipher_suites/2 is only called from there, why does it even return something if the return value isn?t used? -- Anthony Ramine Le 13 f?vr. 2014 ? 12:23, Ingela Anderton Andin a ?crit : > Hi! > > The following patch will solve the problem below. > > diff --git a/lib/ssl/src/ssl.erl b/lib/ssl/src/ssl.erl > index 7edc655..c4fa52c 100644 > --- a/lib/ssl/src/ssl.erl > +++ b/lib/ssl/src/ssl.erl > @@ -771,7 +771,9 @@ validate_option(srp_identity, {Username, Password}) > > validate_option(ciphers, Value) when is_list(Value) -> > Version = tls_record:highest_protocol_version([]), > - try cipher_suites(Version, Value) > + try cipher_suites(Version, Value) of > + _-> > + Value > catch > exit:_ -> > throw({error, {options, {ciphers, Value}}}); > > > > Regards Ingela Erlang/OTP team - Ericsson AB > > On 02/07/2014 02:39 PM, Lo?c Hoguin wrote: >> Please see attached. >> >> For the first test, you need the certificate files you can find in >> Cowboy's SSL example (link is in the source). I just noticed that the >> error for that test is more verbose in master. Not sure if that's a good >> thing. >> >> For the second test, you need the erl_make_certs module found in OTP's >> SSL application's test directory. >> >> The output should be as follow. (YES people I am aware certificates and >> keys are included in the error reports. They are either generated or >> already public. You do not need to warn me about it. Thank you.) >> >> Enjoy! >> >> % erl >> Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source-8d71ab4] [64-bit] >> [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V6.0 (abort with ^G) >> 1> c(sslv3bug_1). >> {ok,sslv3bug_1} >> 2> c(sslv3bug_2). >> {ok,sslv3bug_2} >> 3> c(erl_make_certs). >> {ok,erl_make_certs} >> 4> sslv3bug_1:server(). >> <0.68.0> >> 5> sslv3bug_1:client(). >> >> =ERROR REPORT==== 7-Feb-2014::14:35:36 === >> ** State machine <0.74.0> terminating >> ** Last message in was {tcp,#Port<0.2567>, >> >> <<37,242,6,108,56,11,13,53,8,124,121,177,224,225, >> >> 74,202,119,55,113,255,149,182,187,112,63,249,32, >> >> 228,11,30,87,232,165,85,99,178,130,29,69,122, >> >> 197,117,97,20,209,0,128,136,95,242,23,13,180,70, >> >> 30,115,142,31,209,46,215,77,113,218,250,191,165, >> >> 223,25,10,73,119,196,193,108,146,14,209,250,122, >> >> 14,168,170,188,149,168,235,67,252,6,247,29,253, >> >> 203,253,219,114,161,112,19,44,197,60,251,26,190, >> >> 160,118,235,40,75,100,81,153,153,107,93,130,70, >> >> 102,64,164,164,36,39,3,163,252,87,176,128,254, >> >> 50,178,252,223,25,107,98,52,145,153,209,255,18, >> >> 204,185,75,211,101,202,78,164,43,82,238,252,120, >> >> 56,137,64,208,253,151,232,123,135,223,95,130, >> 171,67,78,244,44,22,3,0,0,4,14,0,0,0>>} >> ** When State == certify >> ** Data == {state,client, >> {#Ref<0.0.0.971>,<0.33.0>}, >> gen_tcp,tls_connection,tcp,tcp_closed,tcp_error, >> "localhost",44443,#Port<0.2567>, >> {ssl_options,undefined, >> [{3,3},{3,2},{3,1},{3,0}], >> verify_none, >> {#Fun,[]}, >> false,false,undefined,1,<<>>,undefined,<<>>, >> undefined,undefined,undefined,<<>>,undefined, >> undefined,undefined,undefined,undefined, >> [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, >> <<0,107>>, >> <<0,106>>, >> <<0,61>>, >> <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, >> <<0,103>>, >> <<0,64>>, >> <<0,60>>, >> <<"?\n">>, >> <<192,20>>, >> <<0,57>>, >> <<0,56>>, >> <<192,5>>, >> <<192,15>>, >> <<0,53>>, >> <<"?\b">>, >> <<192,18>>, >> <<0,22>>, >> <<0,19>>, >> <<192,3>>, >> <<"?\r">>, >> <<0,10>>, >> <<"?\t">>, >> <<192,19>>, >> <<0,51>>, >> <<0,50>>, >> <<192,4>>, >> <<192,14>>, >> <<0,47>>, >> <<192,7>>, >> <<192,17>>, >> <<0,5>>, >> <<0,4>>, >> <<0,21>>, >> <<192,2>>, >> <<"?\f">>, >> <<0,9>>], >> >> #Fun,true,268435456,false,undefined, >> >> undefined,false,undefined,undefined,true,undefined, >> false}, >> {socket_options,list,0,0,0,true}, >> {connection_states, >> {connection_state, >> {security_parameters, >> <<0,0>>, >> >> 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, >> undefined,undefined}, >> >> undefined,undefined,undefined,undefined,2,true, >> undefined,undefined}, >> {connection_state, >> >> {security_parameters,<<"?(">>,1,7,1,16,256,32, >> unknown,5,5,48,0,undefined, >> >> <<82,244,225,40,177,238,52,250,53,57,12,72,96, >> >> 92,157,86,51,250,227,239,173,167,250,154,25, >> 29,237,89,176,188,61,181>>, >> >> <<82,244,225,40,43,69,20,224,136,14,240,93, >> >> 225,76,191,156,202,163,215,89,28,56,98,213, >> 12,49,173,48,191,102,81,223>>, >> undefined}, >> undefined,undefined,undefined,undefined, >> undefined,true,undefined,undefined}, >> {connection_state, >> {security_parameters, >> <<0,0>>, >> >> 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, >> undefined,undefined}, >> >> undefined,undefined,undefined,undefined,1,true, >> undefined,undefined}, >> {connection_state, >> >> {security_parameters,<<"?(">>,1,7,1,16,256,32, >> unknown,5,5,48,0,undefined, >> >> <<82,244,225,40,177,238,52,250,53,57,12,72,96, >> >> 92,157,86,51,250,227,239,173,167,250,154,25, >> 29,237,89,176,188,61,181>>, >> >> <<82,244,225,40,43,69,20,224,136,14,240,93, >> >> 225,76,191,156,202,163,215,89,28,56,98,213, >> 12,49,173,48,191,102,81,223>>, >> undefined}, >> undefined,undefined,undefined,undefined, >> undefined,true,undefined,undefined}}, >> {protocol_buffers,[], >> >> <<22,3,0,0,203,12,0,0,199,3,0,23,65,4,112,42,53,141, >> >> 46,236,29,236,36,128,99,108,209,39,230,153,96,212,8>>, >> <<>>,[]}, >> >> {[<<11,0,5,46,0,5,43,0,2,169,48,130,2,165,48,130,2,14,160, >> >> 3,2,1,2,2,9,0,235,233,83,76,182,123,146,121,48,13,6,9, >> >> 42,134,72,134,247,13,1,1,5,5,0,48,85,49,11,48,9,6,3, >> >> 85,4,6,19,2,85,83,49,14,48,12,6,3,85,4,8,12,5,84,101, >> >> 120,97,115,49,19,48,17,6,3,85,4,10,12,10,78,105,110, >> >> 101,32,78,105,110,101,115,49,15,48,13,6,3,85,4,11,12, >> >> 6,67,111,119,98,111,121,49,16,48,14,6,3,85,4,3,12,7, >> >> 82,79,79,84,32,67,65,48,30,23,13,49,51,48,50,50,56,48, >> >> 53,50,51,51,52,90,23,13,51,51,48,50,50,51,48,53,50,51, >> >> 51,52,90,48,87,49,11,48,9,6,3,85,4,6,19,2,85,83,49,14, >> >> 48,12,6,3,85,4,8,12,5,84,101,120,97,115,49,19,48,17,6, >> >> 3,85,4,10,12,10,78,105,110,101,32,78,105,110,101,115, >> >> 49,15,48,13,6,3,85,4,11,12,6,67,111,119,98,111,121,49, >> >> 18,48,16,6,3,85,4,3,12,9,108,111,99,97,108,104,111, >> >> 115,116,48,129,159,48,13,6,9,42,134,72,134,247,13,1,1, >> >> 1,5,0,3,129,141,0,48,129,137,2,129,129,0,205,181,181, >> >> 26,49,2,204,117,28,253,100,147,168,184,128,26,168,194, >> >> 53,199,17,230,198,149,75,236,168,207,100,143,70,26, >> >> 104,201,253,63,168,26,215,228,22,52,183,57,160,163,58, >> >> 19,137,23,196,227,0,162,84,63,125,9,207,131,174,159, >> >> 197,51,143,107,224,74,89,118,135,8,162,250,107,152, >> >> 233,175,254,12,36,162,63,121,205,160,58,60,163,103, >> >> 212,231,102,14,157,161,192,155,23,217,153,183,146,150, >> >> 198,81,148,241,140,57,36,113,201,160,81,190,4,140,190, >> >> 234,52,122,187,177,164,45,138,245,2,3,1,0,1,163,123, >> >> 48,121,48,9,6,3,85,29,19,4,2,48,0,48,44,6,9,96,134,72, >> >> 1,134,248,66,1,13,4,31,22,29,79,112,101,110,83,83,76, >> >> 32,71,101,110,101,114,97,116,101,100,32,67,101,114, >> >> 116,105,102,105,99,97,116,101,48,29,6,3,85,29,14,4,22, >> >> 4,20,30,163,76,66,22,35,196,245,114,67,145,3,129,158, >> >> 205,188,152,198,214,239,48,31,6,3,85,29,35,4,24,48,22, >> >> 128,20,74,125,159,10,23,104,229,44,16,230,52,190,136, >> >> 184,75,134,99,74,93,111,48,13,6,9,42,134,72,134,247, >> >> 13,1,1,5,5,0,3,129,129,0,35,27,161,84,35,175,31,46, >> >> 253,249,55,130,95,236,71,75,91,3,69,159,252,215,18, >> >> 216,60,236,203,103,51,157,216,21,80,1,184,74,166,254, >> >> 133,248,39,209,218,128,201,66,160,133,26,227,220,144, >> >> 220,99,22,36,176,99,200,146,80,223,63,54,91,239,34, >> >> 119,246,93,122,235,30,89,136,140,225,167,192,128,85, >> >> 211,239,71,20,115,159,14,107,103,6,151,122,202,242,94, >> >> 237,99,85,38,113,78,189,204,97,151,100,27,162,154,0, >> >> 205,45,247,79,152,148,98,217,80,111,31,2,39,49,208,23, >> >> 254,0,2,124,48,130,2,120,48,130,1,225,160,3,2,1,2,2,9, >> >> 0,235,233,83,76,182,123,146,120,48,13,6,9,42,134,72, >> >> 134,247,13,1,1,5,5,0,48,85,49,11,48,9,6,3,85,4,6,19,2, >> >> 85,83,49,14,48,12,6,3,85,4,8,12,5,84,101,120,97,115, >> >> 49,19,48,17,6,3,85,4,10,12,10,78,105,110,101,32,78, >> >> 105,110,101,115,49,15,48,13,6,3,85,4,11,12,6,67,111, >> >> 119,98,111,121,49,16,48,14,6,3,85,4,3,12,7,82,79,79, >> >> 84,32,67,65,48,30,23,13,49,51,48,50,50,56,48,53,49,48, >> >> 48,49,90,23,13,51,51,48,50,50,51,48,53,49,48,48,49,90, >> >> 48,85,49,11,48,9,6,3,85,4,6,19,2,85,83,49,14,48,12,6, >> >> 3,85,4,8,12,5,84,101,120,97,115,49,19,48,17,6,3,85,4, >> >> 10,12,10,78,105,110,101,32,78,105,110,101,115,49,15, >> >> 48,13,6,3,85,4,11,12,6,67,111,119,98,111,121,49,16,48, >> >> 14,6,3,85,4,3,12,7,82,79,79,84,32,67,65,48,129,159,48, >> >> 13,6,9,42,134,72,134,247,13,1,1,1,5,0,3,129,141,0,48, >> >> 129,137,2,129,129,0,204,230,99,181,44,211,172,163,201, >> >> 70,233,171,3,241,34,255,177,135,248,55,87,188,30,211, >> >> 176,165,11,209,132,98,123,235,220,228,47,116,13,99,20, >> >> 65,220,112,192,84,82,52,104,67,192,207,119,171,146, >> >> 200,174,84,146,44,64,6,205,60,78,222,65,221,91,39,24, >> >> 170,244,12,131,126,32,238,18,55,99,228,152,26,136,83, >> >> 240,77,220,167,92,192,222,185,96,218,247,136,205,10, >> >> 176,165,158,22,208,25,117,140,120,9,169,23,237,17,27, >> >> 59,76,35,43,109,0,31,124,82,6,125,238,20,104,129,2,3, >> >> 1,0,1,163,80,48,78,48,29,6,3,85,29,14,4,22,4,20,74, >> >> 125,159,10,23,104,229,44,16,230,52,190,136,184,75,134, >> >> 99,74,93,111,48,31,6,3,85,29,35,4,24,48,22,128,20,74, >> >> 125,159,10,23,104,229,44,16,230,52,190,136,184,75,134, >> >> 99,74,93,111,48,12,6,3,85,29,19,4,5,48,3,1,1,255,48, >> >> 13,6,9,42,134,72,134,247,13,1,1,5,5,0,3,129,129,0,109, >> >> 72,210,64,113,94,34,228,51,86,251,174,93,179,60,184, >> >> 179,68,70,32,214,111,154,141,190,171,91,51,206,6,14, >> >> 147,94,59,249,240,23,190,31,139,106,160,114,11,252, >> >> 207,220,174,44,94,195,151,166,126,208,100,184,1,163, >> >> 136,163,33,108,138,36,142,246,167,104,244,194,87,197, >> >> 58,28,123,205,191,63,92,235,193,233,17,37,155,119,238, >> >> 122,112,122,159,177,46,87,8,170,117,58,149,185,181, >> >> 178,246,81,6,41,20,163,15,226,169,155,191,113,26,164, >> 23,207,62,100,133,48,22,245,139,96,8>>, >> >> <<2,0,0,83,3,0,82,244,225,40,43,69,20,224,136,14,240,93, >> >> 225,76,191,156,202,163,215,89,28,56,98,213,12,49,173, >> >> 48,191,102,81,223,32,104,211,174,230,197,6,57,224,137, >> >> 46,198,34,208,111,149,153,186,243,247,151,78,31,200, >> >> 228,94,87,239,178,48,249,204,99,192,40,0,0,11,0,11,0, >> 2,1,0,255,1,0,1,0>>, >> [1, >> <<0,0,245>>, >> >> <<3,3,82,244,225,40,177,238,52,250,53,57,12,72,96,92, >> >> 157,86,51,250,227,239,173,167,250,154,25,29,237,89, >> >> 176,188,61,181,0,0,88,0,255,192,36,192,40,192,38, >> >> 192,42,0,107,0,106,0,61,192,35,192,39,192,37,192, >> >> 41,0,103,0,64,0,60,192,10,192,20,0,57,0,56,192,5, >> >> 192,15,0,53,192,8,192,18,0,22,0,19,192,3,192,13,0, >> >> 10,192,9,192,19,0,51,0,50,192,4,192,14,0,47,192,7, >> >> 192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0,0,116,0,0, >> >> 0,14,0,12,0,0,9,108,111,99,97,108,104,111,115,116, >> >> 0,10,0,58,0,56,0,14,0,13,0,25,0,28,0,11,0,12,0,27, >> >> 0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6,0,7,0,20,0,21, >> >> 0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15,0,16,0,17,0,11, >> >> 0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3,5,1,4,3,4,1,3,3, >> 3,1,2,3,2,1,2,2,1,1>>]], >> >> [<<2,0,0,83,3,0,82,244,225,40,43,69,20,224,136,14,240,93, >> >> 225,76,191,156,202,163,215,89,28,56,98,213,12,49,173, >> >> 48,191,102,81,223,32,104,211,174,230,197,6,57,224,137, >> >> 46,198,34,208,111,149,153,186,243,247,151,78,31,200, >> >> 228,94,87,239,178,48,249,204,99,192,40,0,0,11,0,11,0, >> 2,1,0,255,1,0,1,0>>, >> [1, >> <<0,0,245>>, >> <<3,3,82,244,225,40,177,238,52,250,53,57,12,72,96, >> 92,157,86,51,250,227,239,173,167,250,154,25,29, >> >> 237,89,176,188,61,181,0,0,88,0,255,192,36,192,40, >> >> 192,38,192,42,0,107,0,106,0,61,192,35,192,39,192, >> >> 37,192,41,0,103,0,64,0,60,192,10,192,20,0,57,0,56, >> 192,5,192,15,0,53,192,8,192,18,0,22,0,19,192,3, >> >> 192,13,0,10,192,9,192,19,0,51,0,50,192,4,192,14,0, >> >> 47,192,7,192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0, >> 0,116,0,0,0,14,0,12,0,0,9,108,111,99,97,108,104, >> >> 111,115,116,0,10,0,58,0,56,0,14,0,13,0,25,0,28,0, >> >> 11,0,12,0,27,0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6, >> >> 0,7,0,20,0,21,0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15, >> >> 0,16,0,17,0,11,0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3, >> 5,1,4,3,4,1,3,3,3,1,2,3,2,1,2,2,1,1>>]]}, >> 16400, >> {session, >> >> <<104,211,174,230,197,6,57,224,137,46,198,34,208,111, >> >> 149,153,186,243,247,151,78,31,200,228,94,87,239,178, >> 48,249,204,99>>, >> >> <<48,130,2,165,48,130,2,14,160,3,2,1,2,2,9,0,235,233, >> >> 83,76,182,123,146,121,48,13,6,9,42,134,72,134,247, >> >> 13,1,1,5,5,0,48,85,49,11,48,9,6,3,85,4,6,19,2,85,83, >> >> 49,14,48,12,6,3,85,4,8,12,5,84,101,120,97,115,49,19, >> >> 48,17,6,3,85,4,10,12,10,78,105,110,101,32,78,105, >> >> 110,101,115,49,15,48,13,6,3,85,4,11,12,6,67,111,119, >> >> 98,111,121,49,16,48,14,6,3,85,4,3,12,7,82,79,79,84, >> >> 32,67,65,48,30,23,13,49,51,48,50,50,56,48,53,50,51, >> >> 51,52,90,23,13,51,51,48,50,50,51,48,53,50,51,51,52, >> >> 90,48,87,49,11,48,9,6,3,85,4,6,19,2,85,83,49,14,48, >> >> 12,6,3,85,4,8,12,5,84,101,120,97,115,49,19,48,17,6, >> >> 3,85,4,10,12,10,78,105,110,101,32,78,105,110,101, >> >> 115,49,15,48,13,6,3,85,4,11,12,6,67,111,119,98,111, >> >> 121,49,18,48,16,6,3,85,4,3,12,9,108,111,99,97,108, >> >> 104,111,115,116,48,129,159,48,13,6,9,42,134,72,134, >> >> 247,13,1,1,1,5,0,3,129,141,0,48,129,137,2,129,129,0, >> >> 205,181,181,26,49,2,204,117,28,253,100,147,168,184, >> >> 128,26,168,194,53,199,17,230,198,149,75,236,168,207, >> >> 100,143,70,26,104,201,253,63,168,26,215,228,22,52, >> >> 183,57,160,163,58,19,137,23,196,227,0,162,84,63,125, >> >> 9,207,131,174,159,197,51,143,107,224,74,89,118,135, >> >> 8,162,250,107,152,233,175,254,12,36,162,63,121,205, >> >> 160,58,60,163,103,212,231,102,14,157,161,192,155,23, >> >> 217,153,183,146,150,198,81,148,241,140,57,36,113, >> >> 201,160,81,190,4,140,190,234,52,122,187,177,164,45, >> >> 138,245,2,3,1,0,1,163,123,48,121,48,9,6,3,85,29,19, >> >> 4,2,48,0,48,44,6,9,96,134,72,1,134,248,66,1,13,4,31, >> >> 22,29,79,112,101,110,83,83,76,32,71,101,110,101,114, >> >> 97,116,101,100,32,67,101,114,116,105,102,105,99,97, >> >> 116,101,48,29,6,3,85,29,14,4,22,4,20,30,163,76,66, >> >> 22,35,196,245,114,67,145,3,129,158,205,188,152,198, >> >> 214,239,48,31,6,3,85,29,35,4,24,48,22,128,20,74,125, >> >> 159,10,23,104,229,44,16,230,52,190,136,184,75,134, >> >> 99,74,93,111,48,13,6,9,42,134,72,134,247,13,1,1,5,5, >> >> 0,3,129,129,0,35,27,161,84,35,175,31,46,253,249,55, >> >> 130,95,236,71,75,91,3,69,159,252,215,18,216,60,236, >> >> 203,103,51,157,216,21,80,1,184,74,166,254,133,248, >> >> 39,209,218,128,201,66,160,133,26,227,220,144,220,99, >> >> 22,36,176,99,200,146,80,223,63,54,91,239,34,119,246, >> >> 93,122,235,30,89,136,140,225,167,192,128,85,211,239, >> >> 71,20,115,159,14,107,103,6,151,122,202,242,94,237, >> >> 99,85,38,113,78,189,204,97,151,100,27,162,154,0,205, >> >> 45,247,79,152,148,98,217,80,111,31,2,39,49,208,23, >> 254>>, >> undefined,0,<<"?(">>,undefined,undefined,new, >> 63559002936,undefined}, >> 28691,ssl_session_cache, >> {3,0}, >> false,ecdhe_rsa, >> {undefined,undefined}, >> undefined, >> {{1,2,840,113549,1,1,1}, >> {'RSAPublicKey', >> >> 144454330320215406279953568628491651436272064667760200600239478371082943052406671504117055906783067021801616968245536600804524397616119868619607006483647544685500850941126623013107537763694736146580312576904568190966271012889302320531771708303887413277040358538410888392437638452540396352971161638449355524853, >> >> 65537}, >> 'NULL'}, >> undefined,undefined,undefined,undefined,undefined, >> >> undefined,undefined,20497,#Ref<0.0.0.977>,undefined,<<>>, >> {false,first}, >> {<0.33.0>,#Ref<0.0.0.968>}, >> undefined, >> {[],[]}, >> false,true,false,undefined,undefined} >> ** Reason for termination = >> ** {bad_return_value,{alert,2,51,{"ssl_connection.erl",420}}} >> ** exception exit: >> {{bad_return_value,{alert,2,51,{"ssl_connection.erl",420}}}, >> {gen_fsm,sync_send_all_state_event, >> [<0.74.0>,{start,infinity},infinity]}} >> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, >> line 240) >> in call from ssl_connection:sync_send_all_state_event/2 >> (ssl_connection.erl, line 1630) >> in call from ssl_connection:handshake/2 (ssl_connection.erl, line 96) >> in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) >> in call from ssl_connection:connect/8 (ssl_connection.erl, line 67) >> 6> sslv3bug_2:server(). >> <0.78.0> >> 7> sslv3bug_2:client(). >> ** exception exit: {{{case_clause,{4}}, >> >> [{ssl_v3,mac_hash,3,[{file,"ssl_v3.erl"},{line,163}]}, >> {tls_record,encode_plain_text,4, >> [{file,"tls_record.erl"},{line,134}]}, >> {tls_connection,encode_handshake,4, >> [{file,"tls_connection.erl"}, >> {line,362}]}, >> {tls_connection,send_handshake,2, >> [{file,"tls_connection.erl"}, >> {line,108}]}, >> {ssl_connection,client_certify_and_key_exchange,2, >> [{file,"ssl_connection.erl"}, >> {line,1038}]}, >> {tls_connection,next_state,4, >> [{file,"tls_connection.erl"}, >> {line,458}]}, >> >> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,239}]}]}, >> {gen_fsm,sync_send_all_state_event, >> [<0.81.0>,{start,infinity},infinity]}} >> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, >> line 240) >> in call from ssl_connection:sync_send_all_state_event/2 >> (ssl_connection.erl, line 1630) >> in call from ssl_connection:handshake/2 (ssl_connection.erl, line 96) >> in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) >> in call from ssl_connection:connect/8 (ssl_connection.erl, line 67) >> 8> >> =ERROR REPORT==== 7-Feb-2014::14:35:59 === >> ** State machine <0.81.0> terminating >> ** Last message in was {tcp,#Port<0.2911>, >> >> <<255,201,15,218,162,33,104,194,52,196,198,98,139, >> >> 128,220,28,209,41,2,78,8,138,103,204,116,2,11, >> >> 190,166,59,19,155,34,81,74,8,121,142,52,4,221, >> >> 239,149,25,179,205,58,67,27,48,43,10,109,242,95, >> >> 20,55,79,225,53,109,109,81,194,69,228,133,181, >> >> 118,98,94,126,198,244,76,66,233,166,55,237,107, >> >> 11,255,92,182,244,6,183,237,238,56,107,251,90, >> >> 137,159,165,174,159,36,17,124,75,31,230,73,40, >> >> 102,81,236,230,83,129,255,255,255,255,255,255, >> >> 255,255,0,1,2,0,128,216,166,31,174,121,159,156, >> >> 152,74,250,106,59,107,235,224,100,58,223,33,83, >> >> 118,28,193,65,121,227,4,83,159,162,248,251,156, >> >> 228,77,141,104,34,249,116,173,104,186,118,133, >> >> 43,79,55,213,103,22,79,162,165,3,251,2,252,106, >> >> 104,78,101,255,40,203,145,80,207,182,133,98,55, >> >> 49,1,80,68,54,12,31,138,6,235,74,72,16,106,4,17, >> >> 92,123,162,154,192,198,115,233,224,185,226,144, >> >> 225,241,68,141,237,16,159,212,2,60,232,186,100, >> >> 159,38,105,250,242,33,153,95,246,14,177,170,244, >> >> 86,41,0,47,48,45,2,20,78,183,247,114,172,238, >> >> 108,236,172,199,38,160,32,215,236,141,241,69, >> >> 232,195,2,21,0,206,237,39,58,180,66,46,147,245, >> >> 175,250,151,208,4,205,60,242,87,255,177,22,3,0, >> 0,4,14,0,0,0>>} >> ** When State == certify >> ** Data == {state,client, >> {#Ref<0.0.0.1012>,<0.76.0>}, >> gen_tcp,tls_connection,tcp,tcp_closed,tcp_error, >> "localhost",44443,#Port<0.2911>, >> {ssl_options,undefined, >> [{3,3},{3,2},{3,1},{3,0}], >> verify_none, >> {#Fun,[]}, >> false,false,undefined,1,<<>>,undefined,<<>>, >> undefined,undefined,undefined,<<>>,undefined, >> undefined,undefined,undefined,undefined, >> [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, >> <<0,107>>, >> <<0,106>>, >> <<0,61>>, >> <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, >> <<0,103>>, >> <<0,64>>, >> <<0,60>>, >> <<"?\n">>, >> <<192,20>>, >> <<0,57>>, >> <<0,56>>, >> <<192,5>>, >> <<192,15>>, >> <<0,53>>, >> <<"?\b">>, >> <<192,18>>, >> <<0,22>>, >> <<0,19>>, >> <<192,3>>, >> <<"?\r">>, >> <<0,10>>, >> <<"?\t">>, >> <<192,19>>, >> <<0,51>>, >> <<0,50>>, >> <<192,4>>, >> <<192,14>>, >> <<0,47>>, >> <<192,7>>, >> <<192,17>>, >> <<0,5>>, >> <<0,4>>, >> <<0,21>>, >> <<192,2>>, >> <<"?\f">>, >> <<0,9>>], >> >> #Fun,true,268435456,false,undefined, >> >> undefined,false,undefined,undefined,true,undefined, >> false}, >> {socket_options,list,0,0,0,true}, >> {connection_states, >> {connection_state, >> {security_parameters, >> <<0,0>>, >> >> 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, >> undefined,undefined}, >> >> undefined,undefined,undefined,undefined,2,true, >> undefined,undefined}, >> {connection_state, >> {security_parameters, >> <<0,106>>, >> 1,7,1,16,256,32,unknown,4,4711,32,0, >> undefined, >> >> <<82,244,225,63,101,215,80,75,202,30,236,75, >> >> 214,92,173,239,61,137,174,226,135,182,38, >> 168,60,36,24,219,50,94,16,198>>, >> >> <<82,244,225,63,188,177,3,238,107,25,107,72, >> >> 243,243,32,133,171,156,145,181,53,121,188, >> 56,69,37,1,65,127,169,225,11>>, >> undefined}, >> undefined,undefined,undefined,undefined, >> undefined,true,undefined,undefined}, >> {connection_state, >> {security_parameters, >> <<0,0>>, >> >> 1,0,0,0,0,0,0,0,0,0,0,undefined,undefined, >> undefined,undefined}, >> >> undefined,undefined,undefined,undefined,1,true, >> undefined,undefined}, >> {connection_state, >> {security_parameters, >> <<0,106>>, >> 1,7,1,16,256,32,unknown,4,4711,32,0, >> undefined, >> >> <<82,244,225,63,101,215,80,75,202,30,236,75, >> >> 214,92,173,239,61,137,174,226,135,182,38, >> 168,60,36,24,219,50,94,16,198>>, >> >> <<82,244,225,63,188,177,3,238,107,25,107,72, >> >> 243,243,32,133,171,156,145,181,53,121,188, >> 56,69,37,1,65,127,169,225,11>>, >> undefined}, >> undefined,undefined,undefined,undefined, >> undefined,true,undefined,undefined}}, >> {protocol_buffers,[], >> >> <<22,3,0,1,60,12,0,1,56,0,128,255,255,255,255,255,255, >> 255>>, >> <<>>,[]}, >> >> {[<<11,0,5,153,0,5,150,0,5,147,48,130,5,143,48,130,4,41, >> >> 160,3,2,1,2,2,6,0,168,88,141,229,65,48,130,1,44,6,7, >> >> 42,134,72,206,56,4,3,48,130,1,31,2,129,129,0,232,148, >> >> 166,31,193,7,156,37,221,185,181,134,210,206,133,125, >> >> 228,157,66,197,142,159,163,53,134,75,44,121,95,112, >> >> 171,141,10,111,6,104,28,68,249,89,51,210,135,202,124, >> >> 137,39,248,58,33,142,102,238,53,87,191,54,173,119,76, >> >> 14,129,52,149,215,77,223,78,247,64,247,138,164,116,37, >> >> 226,84,65,234,101,56,68,165,160,128,238,161,159,24, >> >> 216,48,172,183,209,100,143,141,107,100,45,29,108,193, >> >> 215,105,37,171,150,125,122,202,252,36,144,93,68,243, >> >> 192,32,114,86,101,122,253,217,161,54,81,2,21,0,214, >> >> 110,187,124,141,25,20,86,167,217,74,223,208,214,158, >> >> 82,129,45,229,129,2,129,129,0,145,148,122,39,49,43,61, >> >> 30,153,81,106,86,228,252,211,63,233,231,52,125,126, >> >> 210,184,201,77,113,188,219,174,151,155,7,34,93,62,234, >> >> 185,143,184,96,42,159,6,159,4,210,162,131,209,153,105, >> >> 125,172,202,235,169,97,78,193,237,51,92,122,0,44,226, >> >> 15,154,4,66,171,170,119,180,104,229,6,197,143,62,152, >> >> 192,216,215,209,189,218,27,42,199,48,112,73,125,55, >> >> 156,44,47,95,167,75,90,70,97,42,109,255,161,229,57, >> >> 246,0,172,207,230,62,211,188,197,8,250,139,25,71,57, >> >> 132,252,175,48,123,49,32,48,30,6,9,42,134,72,134,247, >> >> 13,1,9,1,22,17,82,111,111,116,67,65,64,101,114,108,97, >> >> 110,103,46,111,114,103,49,15,48,13,6,3,85,4,3,19,6,82, >> >> 111,111,116,67,65,49,18,48,16,6,3,85,4,7,19,9,83,116, >> >> 111,99,107,104,111,108,109,49,11,48,9,6,3,85,4,6,19,2, >> >> 83,69,49,15,48,13,6,3,85,4,10,19,6,101,114,108,97,110, >> >> 103,49,20,48,18,6,3,85,4,11,19,11,116,101,115,116,105, >> >> 110,103,32,100,101,112,48,34,24,15,50,48,49,52,48,50, >> >> 48,54,48,48,48,48,48,48,90,24,15,50,48,49,52,48,50,49, >> >> 52,48,48,48,48,48,48,90,48,121,49,31,48,29,6,9,42,134, >> >> 72,134,247,13,1,9,1,22,16,101,115,115,101,110,64,101, >> >> 114,108,97,110,103,46,111,114,103,49,14,48,12,6,3,85, >> >> 4,3,19,5,101,115,115,101,110,49,18,48,16,6,3,85,4,7, >> >> 19,9,83,116,111,99,107,104,111,108,109,49,11,48,9,6,3, >> >> 85,4,6,19,2,83,69,49,15,48,13,6,3,85,4,10,19,6,101, >> >> 114,108,97,110,103,49,20,48,18,6,3,85,4,11,19,11,116, >> >> 101,115,116,105,110,103,32,100,101,112,48,130,1,183, >> >> 48,130,1,43,6,7,42,134,72,206,56,4,1,48,130,1,30,2, >> >> 129,129,0,172,20,101,160,1,130,221,238,24,42,170,3,17, >> >> 62,230,231,15,182,23,122,127,202,54,148,36,32,27,64, >> >> 221,180,126,41,187,207,133,60,140,0,116,50,56,250,210, >> >> 130,36,42,1,0,254,74,15,125,231,23,199,145,185,91,88, >> >> 223,179,52,215,22,36,165,226,0,4,236,135,79,246,221, >> >> 81,124,230,72,58,212,233,186,42,201,32,47,115,113,22, >> >> 251,228,179,170,88,91,55,151,16,150,103,0,88,136,40, >> >> 89,52,202,162,205,187,89,154,57,76,34,101,146,109,244, >> >> 232,72,134,127,42,102,7,189,43,2,21,0,213,146,169,239, >> >> 217,145,225,127,111,174,189,211,177,222,47,248,104,29, >> >> 27,237,2,129,128,16,109,41,186,123,49,80,129,242,62, >> >> 70,145,216,15,131,72,58,194,148,147,221,175,54,65,123, >> >> 227,5,114,111,40,176,249,196,244,205,13,12,7,135,99, >> >> 54,234,160,44,233,6,117,17,196,162,142,213,141,109, >> >> 141,148,108,149,217,138,200,100,108,254,98,41,241,147, >> >> 214,217,252,186,131,40,26,118,255,17,241,219,101,166, >> >> 161,62,43,20,24,120,204,242,70,63,190,208,134,173,160, >> >> 196,206,225,255,223,8,180,115,245,128,7,193,136,7,151, >> >> 36,154,246,240,187,218,72,139,23,18,21,7,129,20,230, >> >> 72,3,129,133,0,2,129,129,0,152,168,223,43,127,77,1, >> >> 215,72,34,80,184,125,73,66,28,78,154,60,68,31,82,235, >> >> 252,250,73,183,249,83,189,159,48,60,60,11,88,52,57,55, >> >> 84,243,40,204,232,50,91,126,196,126,2,122,90,71,151, >> >> 148,135,145,192,163,23,244,154,184,151,79,14,206,64, >> >> 64,35,67,18,185,8,91,8,83,21,25,76,69,76,247,134,107, >> >> 112,103,204,60,192,28,158,224,106,64,18,14,43,24,212, >> >> 137,199,141,103,252,93,241,32,110,212,33,89,251,137, >> >> 28,144,197,212,76,219,135,208,21,252,243,184,104,67, >> >> 163,19,48,17,48,15,6,3,85,29,19,1,1,255,4,5,48,3,1,1, >> >> 255,48,130,1,44,6,7,42,134,72,206,56,4,3,48,130,1,31, >> >> 2,129,129,0,232,148,166,31,193,7,156,37,221,185,181, >> >> 134,210,206,133,125,228,157,66,197,142,159,163,53,134, >> >> 75,44,121,95,112,171,141,10,111,6,104,28,68,249,89,51, >> >> 210,135,202,124,137,39,248,58,33,142,102,238,53,87, >> >> 191,54,173,119,76,14,129,52,149,215,77,223,78,247,64, >> >> 247,138,164,116,37,226,84,65,234,101,56,68,165,160, >> >> 128,238,161,159,24,216,48,172,183,209,100,143,141,107, >> >> 100,45,29,108,193,215,105,37,171,150,125,122,202,252, >> >> 36,144,93,68,243,192,32,114,86,101,122,253,217,161,54, >> >> 81,2,21,0,214,110,187,124,141,25,20,86,167,217,74,223, >> >> 208,214,158,82,129,45,229,129,2,129,129,0,145,148,122, >> >> 39,49,43,61,30,153,81,106,86,228,252,211,63,233,231, >> >> 52,125,126,210,184,201,77,113,188,219,174,151,155,7, >> >> 34,93,62,234,185,143,184,96,42,159,6,159,4,210,162, >> >> 131,209,153,105,125,172,202,235,169,97,78,193,237,51, >> >> 92,122,0,44,226,15,154,4,66,171,170,119,180,104,229,6, >> >> 197,143,62,152,192,216,215,209,189,218,27,42,199,48, >> >> 112,73,125,55,156,44,47,95,167,75,90,70,97,42,109,255, >> >> 161,229,57,246,0,172,207,230,62,211,188,197,8,250,139, >> >> 25,71,57,132,252,175,3,48,0,48,45,2,21,0,182,82,58, >> >> 106,122,13,155,122,152,41,77,231,69,191,61,48,195,179, >> >> 189,65,2,20,18,41,247,30,218,157,162,131,0,182,220, >> 145,199,117,186,83,112,21,220,12>>, >> >> <<2,0,0,83,3,0,82,244,225,63,188,177,3,238,107,25,107, >> >> 72,243,243,32,133,171,156,145,181,53,121,188,56,69,37, >> >> 1,65,127,169,225,11,32,190,94,115,98,18,255,115,139, >> >> 99,87,33,75,186,233,22,47,165,75,129,175,177,99,152, >> >> 60,150,43,93,150,146,202,73,169,0,106,0,0,11,0,11,0,2, >> 1,0,255,1,0,1,0>>, >> [1, >> <<0,0,245>>, >> >> <<3,3,82,244,225,63,101,215,80,75,202,30,236,75,214, >> >> 92,173,239,61,137,174,226,135,182,38,168,60,36,24, >> >> 219,50,94,16,198,0,0,88,0,255,192,36,192,40,192,38, >> >> 192,42,0,107,0,106,0,61,192,35,192,39,192,37,192, >> >> 41,0,103,0,64,0,60,192,10,192,20,0,57,0,56,192,5, >> >> 192,15,0,53,192,8,192,18,0,22,0,19,192,3,192,13,0, >> >> 10,192,9,192,19,0,51,0,50,192,4,192,14,0,47,192,7, >> >> 192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0,0,116,0,0, >> >> 0,14,0,12,0,0,9,108,111,99,97,108,104,111,115,116, >> >> 0,10,0,58,0,56,0,14,0,13,0,25,0,28,0,11,0,12,0,27, >> >> 0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6,0,7,0,20,0,21, >> >> 0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15,0,16,0,17,0,11, >> >> 0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3,5,1,4,3,4,1,3,3, >> 3,1,2,3,2,1,2,2,1,1>>]], >> >> [<<2,0,0,83,3,0,82,244,225,63,188,177,3,238,107,25,107, >> >> 72,243,243,32,133,171,156,145,181,53,121,188,56,69,37, >> >> 1,65,127,169,225,11,32,190,94,115,98,18,255,115,139, >> >> 99,87,33,75,186,233,22,47,165,75,129,175,177,99,152, >> >> 60,150,43,93,150,146,202,73,169,0,106,0,0,11,0,11,0,2, >> 1,0,255,1,0,1,0>>, >> [1, >> <<0,0,245>>, >> >> <<3,3,82,244,225,63,101,215,80,75,202,30,236,75,214, >> >> 92,173,239,61,137,174,226,135,182,38,168,60,36,24, >> 219,50,94,16,198,0,0,88,0,255,192,36,192,40,192, >> 38,192,42,0,107,0,106,0,61,192,35,192,39,192,37, >> 192,41,0,103,0,64,0,60,192,10,192,20,0,57,0,56, >> 192,5,192,15,0,53,192,8,192,18,0,22,0,19,192,3, >> >> 192,13,0,10,192,9,192,19,0,51,0,50,192,4,192,14,0, >> >> 47,192,7,192,17,0,5,0,4,0,21,192,2,192,12,0,9,1,0, >> 0,116,0,0,0,14,0,12,0,0,9,108,111,99,97,108,104, >> >> 111,115,116,0,10,0,58,0,56,0,14,0,13,0,25,0,28,0, >> >> 11,0,12,0,27,0,24,0,9,0,10,0,26,0,22,0,23,0,8,0,6, >> >> 0,7,0,20,0,21,0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15, >> >> 0,16,0,17,0,11,0,2,1,0,0,13,0,26,0,24,6,3,6,1,5,3, >> 5,1,4,3,4,1,3,3,3,1,2,3,2,1,2,2,1,1>>]]}, >> 16400, >> {session, >> >> <<190,94,115,98,18,255,115,139,99,87,33,75,186,233,22, >> >> 47,165,75,129,175,177,99,152,60,150,43,93,150,146, >> 202,73,169>>, >> >> <<48,130,5,143,48,130,4,41,160,3,2,1,2,2,6,0,168,88, >> >> 141,229,65,48,130,1,44,6,7,42,134,72,206,56,4,3,48, >> >> 130,1,31,2,129,129,0,232,148,166,31,193,7,156,37, >> >> 221,185,181,134,210,206,133,125,228,157,66,197,142, >> >> 159,163,53,134,75,44,121,95,112,171,141,10,111,6, >> >> 104,28,68,249,89,51,210,135,202,124,137,39,248,58, >> >> 33,142,102,238,53,87,191,54,173,119,76,14,129,52, >> >> 149,215,77,223,78,247,64,247,138,164,116,37,226,84, >> >> 65,234,101,56,68,165,160,128,238,161,159,24,216,48, >> >> 172,183,209,100,143,141,107,100,45,29,108,193,215, >> >> 105,37,171,150,125,122,202,252,36,144,93,68,243,192, >> >> 32,114,86,101,122,253,217,161,54,81,2,21,0,214,110, >> >> 187,124,141,25,20,86,167,217,74,223,208,214,158,82, >> >> 129,45,229,129,2,129,129,0,145,148,122,39,49,43,61, >> >> 30,153,81,106,86,228,252,211,63,233,231,52,125,126, >> >> 210,184,201,77,113,188,219,174,151,155,7,34,93,62, >> >> 234,185,143,184,96,42,159,6,159,4,210,162,131,209, >> >> 153,105,125,172,202,235,169,97,78,193,237,51,92,122, >> >> 0,44,226,15,154,4,66,171,170,119,180,104,229,6,197, >> >> 143,62,152,192,216,215,209,189,218,27,42,199,48,112, >> >> 73,125,55,156,44,47,95,167,75,90,70,97,42,109,255, >> >> 161,229,57,246,0,172,207,230,62,211,188,197,8,250, >> >> 139,25,71,57,132,252,175,48,123,49,32,48,30,6,9,42, >> >> 134,72,134,247,13,1,9,1,22,17,82,111,111,116,67,65, >> >> 64,101,114,108,97,110,103,46,111,114,103,49,15,48, >> >> 13,6,3,85,4,3,19,6,82,111,111,116,67,65,49,18,48,16, >> >> 6,3,85,4,7,19,9,83,116,111,99,107,104,111,108,109, >> >> 49,11,48,9,6,3,85,4,6,19,2,83,69,49,15,48,13,6,3,85, >> >> 4,10,19,6,101,114,108,97,110,103,49,20,48,18,6,3,85, >> >> 4,11,19,11,116,101,115,116,105,110,103,32,100,101, >> >> 112,48,34,24,15,50,48,49,52,48,50,48,54,48,48,48,48, >> >> 48,48,90,24,15,50,48,49,52,48,50,49,52,48,48,48,48, >> >> 48,48,90,48,121,49,31,48,29,6,9,42,134,72,134,247, >> >> 13,1,9,1,22,16,101,115,115,101,110,64,101,114,108, >> >> 97,110,103,46,111,114,103,49,14,48,12,6,3,85,4,3,19, >> >> 5,101,115,115,101,110,49,18,48,16,6,3,85,4,7,19,9, >> >> 83,116,111,99,107,104,111,108,109,49,11,48,9,6,3,85, >> >> 4,6,19,2,83,69,49,15,48,13,6,3,85,4,10,19,6,101,114, >> >> 108,97,110,103,49,20,48,18,6,3,85,4,11,19,11,116, >> >> 101,115,116,105,110,103,32,100,101,112,48,130,1,183, >> >> 48,130,1,43,6,7,42,134,72,206,56,4,1,48,130,1,30,2, >> >> 129,129,0,172,20,101,160,1,130,221,238,24,42,170,3, >> >> 17,62,230,231,15,182,23,122,127,202,54,148,36,32,27, >> >> 64,221,180,126,41,187,207,133,60,140,0,116,50,56, >> >> 250,210,130,36,42,1,0,254,74,15,125,231,23,199,145, >> >> 185,91,88,223,179,52,215,22,36,165,226,0,4,236,135, >> >> 79,246,221,81,124,230,72,58,212,233,186,42,201,32, >> >> 47,115,113,22,251,228,179,170,88,91,55,151,16,150, >> >> 103,0,88,136,40,89,52,202,162,205,187,89,154,57,76, >> >> 34,101,146,109,244,232,72,134,127,42,102,7,189,43,2, >> >> 21,0,213,146,169,239,217,145,225,127,111,174,189, >> >> 211,177,222,47,248,104,29,27,237,2,129,128,16,109, >> >> 41,186,123,49,80,129,242,62,70,145,216,15,131,72,58, >> >> 194,148,147,221,175,54,65,123,227,5,114,111,40,176, >> >> 249,196,244,205,13,12,7,135,99,54,234,160,44,233,6, >> >> 117,17,196,162,142,213,141,109,141,148,108,149,217, >> >> 138,200,100,108,254,98,41,241,147,214,217,252,186, >> >> 131,40,26,118,255,17,241,219,101,166,161,62,43,20, >> >> 24,120,204,242,70,63,190,208,134,173,160,196,206, >> >> 225,255,223,8,180,115,245,128,7,193,136,7,151,36, >> >> 154,246,240,187,218,72,139,23,18,21,7,129,20,230,72, >> >> 3,129,133,0,2,129,129,0,152,168,223,43,127,77,1,215, >> >> 72,34,80,184,125,73,66,28,78,154,60,68,31,82,235, >> >> 252,250,73,183,249,83,189,159,48,60,60,11,88,52,57, >> >> 55,84,243,40,204,232,50,91,126,196,126,2,122,90,71, >> >> 151,148,135,145,192,163,23,244,154,184,151,79,14, >> >> 206,64,64,35,67,18,185,8,91,8,83,21,25,76,69,76,247, >> >> 134,107,112,103,204,60,192,28,158,224,106,64,18,14, >> >> 43,24,212,137,199,141,103,252,93,241,32,110,212,33, >> >> 89,251,137,28,144,197,212,76,219,135,208,21,252,243, >> >> 184,104,67,163,19,48,17,48,15,6,3,85,29,19,1,1,255, >> >> 4,5,48,3,1,1,255,48,130,1,44,6,7,42,134,72,206,56,4, >> >> 3,48,130,1,31,2,129,129,0,232,148,166,31,193,7,156, >> >> 37,221,185,181,134,210,206,133,125,228,157,66,197, >> >> 142,159,163,53,134,75,44,121,95,112,171,141,10,111, >> >> 6,104,28,68,249,89,51,210,135,202,124,137,39,248,58, >> >> 33,142,102,238,53,87,191,54,173,119,76,14,129,52, >> >> 149,215,77,223,78,247,64,247,138,164,116,37,226,84, >> >> 65,234,101,56,68,165,160,128,238,161,159,24,216,48, >> >> 172,183,209,100,143,141,107,100,45,29,108,193,215, >> >> 105,37,171,150,125,122,202,252,36,144,93,68,243,192, >> >> 32,114,86,101,122,253,217,161,54,81,2,21,0,214,110, >> >> 187,124,141,25,20,86,167,217,74,223,208,214,158,82, >> >> 129,45,229,129,2,129,129,0,145,148,122,39,49,43,61, >> >> 30,153,81,106,86,228,252,211,63,233,231,52,125,126, >> >> 210,184,201,77,113,188,219,174,151,155,7,34,93,62, >> >> 234,185,143,184,96,42,159,6,159,4,210,162,131,209, >> >> 153,105,125,172,202,235,169,97,78,193,237,51,92,122, >> >> 0,44,226,15,154,4,66,171,170,119,180,104,229,6,197, >> >> 143,62,152,192,216,215,209,189,218,27,42,199,48,112, >> >> 73,125,55,156,44,47,95,167,75,90,70,97,42,109,255, >> >> 161,229,57,246,0,172,207,230,62,211,188,197,8,250, >> >> 139,25,71,57,132,252,175,3,48,0,48,45,2,21,0,182,82, >> >> 58,106,122,13,155,122,152,41,77,231,69,191,61,48, >> >> 195,179,189,65,2,20,18,41,247,30,218,157,162,131,0, >> 182,220,145,199,117,186,83,112,21,220,12>>, >> undefined,0, >> <<0,106>>, >> undefined,undefined,new,63559002959,undefined}, >> 28691,ssl_session_cache, >> {3,0}, >> false,dhe_dss, >> {undefined,undefined}, >> undefined, >> {{1,2,840,10040,4,1}, >> >> 107201255589035901224095606533558326562411652347289232035103542030345159420839486230268504779574656171583558015264296286449883604707549621612623958146832751634671347771456676561935478712661717567833349731571068193127995126983390616249150208033231204136081889066713700820639352472736328354631788188647982393411, >> >> {'Dss-Parms', >> >> 120838457660118919847784105390049937477281231873987813527469753170393689289232527428167218258880467891327129458677867506421714970972002253380733557408691307378960985768079995491587653331614446765301506047915886847153350641972403963007845318607852639159131694882003981406543445440571784899938168852566501735723, >> >> >> 1219285746577471382994815749003130182104667462637, >> >> 11535022978489302833643653962713113424104775336555003172828907456342498068622451037206915043471103346423380726835531941532378578411298596088596278301950468270328767064787145526948017146253629314732272784540599889965624014006517245965850597974665875953436492876504607797788574892832624787243340450198197691976}}, >> >> undefined,undefined,undefined,undefined,undefined, >> undefined,undefined,20497,#Ref<0.0.0.1014>,undefined, >> <<>>, >> {false,first}, >> {<0.76.0>,#Ref<0.0.0.1008>}, >> undefined, >> {[],[]}, >> false,true,false,undefined,undefined} >> ** Reason for termination = >> ** {{case_clause,{4}}, >> [{ssl_v3,mac_hash,3,[{file,"ssl_v3.erl"},{line,163}]}, >> >> {tls_record,encode_plain_text,4,[{file,"tls_record.erl"},{line,134}]}, >> {tls_connection,encode_handshake,4, >> [{file,"tls_connection.erl"},{line,362}]}, >> {tls_connection,send_handshake,2, >> [{file,"tls_connection.erl"},{line,108}]}, >> {ssl_connection,client_certify_and_key_exchange,2, >> [{file,"ssl_connection.erl"},{line,1038}]}, >> >> {tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,458}]}, >> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, >> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} >> >> >> On 02/07/2014 11:10 AM, Ingela Anderton Andin wrote: >>> Hi! >>> >>> If you can provide a failing test case that is a good place to start. I >>> will not have time to look at it until Monday as I am looking after my >>> sick daughter today, and just quickly answering some mails. >>> >>> Regards Ingela Erlang/OTP team >>> >>> On 02/07/2014 11:01 AM, Lo?c Hoguin wrote: >>>> On 02/06/2014 09:29 PM, Ingela Anderton Andin wrote: >>>>> Hi! >>>>> >>>>> On 02/06/2014 05:59 PM, Lo?c Hoguin wrote: >>>>>> Just [{cert, Cert}, {key, Key}, {port, 0}, {versions, [sslv3]}] does >>>>>> it. >>>>> >>>>> You mean that you get it when you input certs as binaries? Could it be >>>>> related to https://github.com/erlang/otp/pull/163 >>>>> We want to include this pull request but it solves two problems and >>>>> only one persists and we are waiting for the pull >>>>> request to be updated. >>>> >>>> I don't have any idea what that pull request is about. I am not too well >>>> versed in SSL-fu. >>>> >>>> I narrowed it down a little. >>>> >>>> The previously mentioned issue only happens with a test certificate >>>> generated by erl_make_certs.erl. >>>> >>>> A different report happens with a certificate generated by OpenSSL >>>> (again, setting versions to [sslv3]). >>>> >>>> =ERROR REPORT==== 7-Feb-2014::10:55:57 === >>>> SSL: certify: tls_connection.erl:2286:Fatal error: decrypt error >>>> >>>> =ERROR REPORT==== 7-Feb-2014::10:55:57 === >>>> SSL: certify: tls_connection.erl:2055:Fatal error: decrypt error >>>> {error,{tls_alert,"decrypt error"}} >>>> >>>> The client in all cases is always: >>>> >>>> ssl:connect("localhost", 44443, []). >>>> >>>> I can provide a test case for either or both of them if you want. >>>> >>> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From Ingela.Anderton.Andin@REDACTED Thu Feb 13 12:40:12 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 13 Feb 2014 12:40:12 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <1E80C311-AD62-456E-834C-5756B6687068@gmail.com> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> <52F4B109.3060602@ericsson.com> <52F4E1FD.30600@ninenines.eu> <52FCAB34.4060104@ericsson.com> <1E80C311-AD62-456E-834C-5756B6687068@gmail.com> Message-ID: <52FCAF1C.5020906@ericsson.com> Hi! It is because it is suppose to be a check that the input is correct. We want to here return the value that the user inputed, if no value is inputed the empty list should be returned. The call produces the list of the highest supported TLS versions ciphers so it can make a newer chipher suite be picked later although it should not be supported in the negotiated version. Regards Ingela On 02/13/2014 12:32 PM, Anthony Ramine wrote: > Hello Ingela, > > Out of curiosity, given that this clause is called from > > 629: ciphers = handle_option(ciphers, Opts, []), > > where the default list of ciphers is empty, and given this clause > > 939: cipher_suites(Version, []) -> > 940: ssl_cipher:suites(Version); > > which calls ssl_cipher:suites/1 > > suites({3, 0}) -> > ssl_v3:suites(); > > why would the ciphers list not be the empty list as in this patch? Or does your patch mean that ssl_v3 is actually really called, but that its return value should be ignored and the empty list be used instead? > > Given that ssl:cipher_suites/2 is only called from there, why does it even return something if the return value isn?t used? > From n.oxyde@REDACTED Thu Feb 13 12:41:49 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 12:41:49 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52FCAF1C.5020906@ericsson.com> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> <52F4B109.3060602@ericsson.com> <52F4E1FD.30600@ninenines.eu> <52FCAB34.4060104@ericsson.com> <1E80C311-AD62-456E-834C-5756B6687068@gmail.com> <52FCAF1C.5020906@ericsson.com> Message-ID: <3B230ED2-56A8-4F1D-9AB0-70D847EC3D78@gmail.com> Shouldn?t the function be rewritten to be more explicit about the fact that it is just a check? That code is quite hard to follow. -- Anthony Ramine Le 13 f?vr. 2014 ? 12:40, Ingela Anderton Andin a ?crit : > Hi! > > It is because it is suppose to be a check that the input is correct. We want to here return the value that the user inputed, if no value is inputed the empty list should be returned. The call produces the list of the highest supported TLS versions ciphers so it can make a newer chipher suite be picked later although it should not be supported in the negotiated version. > > Regards Ingela > > > On 02/13/2014 12:32 PM, Anthony Ramine wrote: >> Hello Ingela, >> >> Out of curiosity, given that this clause is called from >> >> 629: ciphers = handle_option(ciphers, Opts, []), >> >> where the default list of ciphers is empty, and given this clause >> >> 939: cipher_suites(Version, []) -> >> 940: ssl_cipher:suites(Version); >> >> which calls ssl_cipher:suites/1 >> >> suites({3, 0}) -> >> ssl_v3:suites(); >> >> why would the ciphers list not be the empty list as in this patch? Or does your patch mean that ssl_v3 is actually really called, but that its return value should be ignored and the empty list be used instead? >> >> Given that ssl:cipher_suites/2 is only called from there, why does it even return something if the return value isn?t used? >> > From Ingela.Anderton.Andin@REDACTED Thu Feb 13 14:10:25 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 13 Feb 2014 14:10:25 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <3B230ED2-56A8-4F1D-9AB0-70D847EC3D78@gmail.com> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> <52F4B109.3060602@ericsson.com> <52F4E1FD.30600@ninenines.eu> <52FCAB34.4060104@ericsson.com> <1E80C311-AD62-456E-834C-5756B6687068@gmail.com> <52FCAF1C.5020906@ericsson.com> <3B230ED2-56A8-4F1D-9AB0-70D847EC3D78@gmail.com> Message-ID: <52FCC441.2020205@ericsson.com> Hi! On 02/13/2014 12:41 PM, Anthony Ramine wrote: > Shouldn?t the function be rewritten to be more explicit about the fact that it is just a check? That code is quite hard to follow. The function is called validate_option, but I do agree that the check is quite subtle and other clauses may reformat the option so I will add some kind of clarification. Regards Ingela Erlang/OTP team - Ericsson AB From n.oxyde@REDACTED Thu Feb 13 14:14:40 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 14:14:40 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <52FCC441.2020205@ericsson.com> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> <52F4B109.3060602@ericsson.com> <52F4E1FD.30600@ninenines.eu> <52FCAB34.4060104@ericsson.com> <1E80C311-AD62-456E-834C-5756B6687068@gmail.com> <52FCAF1C.5020906@ericsson.com> <3B230ED2-56A8-4F1D-9AB0-70D847EC3D78@gmail.com> <52FCC441.2020205@ericsson.com> Message-ID: <84B50145-0214-45BC-A76D-5E6EC004340A@gmail.com> I mean ? ssl:cipher_suites/2 ?, of which the return value is never used. -- Anthony Ramine Le 13 f?vr. 2014 ? 14:10, Ingela Anderton Andin a ?crit : > Hi! > > On 02/13/2014 12:41 PM, Anthony Ramine wrote: >> Shouldn?t the function be rewritten to be more explicit about the fact that it is just a check? That code is quite hard to follow. > > The function is called validate_option, but I do agree that the check is quite subtle and other clauses may reformat the option so I will add some kind of clarification. > > Regards Ingela Erlang/OTP team - Ericsson AB From ingela.anderton.andin@REDACTED Thu Feb 13 15:24:00 2014 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Thu, 13 Feb 2014 15:24:00 +0100 Subject: [erlang-bugs] SSL fails at sending a short message while receiving a big one In-Reply-To: <52F67C80.7070205@ninenines.eu> References: <52F67C80.7070205@ninenines.eu> Message-ID: <52FCD580.3060904@erix.ericsson.se> Hi! If you make your client use a passive socket instead of a active one your first test case, it will work better! I also rewrote your second version into: (which works fine for me) -module(big2). -compile(export_all). server() -> ssl:start(), CaInfo = erl_make_certs:make_cert([{key, dsa}]), {Cert, {Asn1Type, Der, _}} = erl_make_certs:make_cert([{key, dsa}, {issuer, CaInfo}]), Key = {Asn1Type, Der}, spawn(fun() -> {ok, L} = ssl:listen(44444, [ {cert, Cert}, {key, Key}, {active, false}, binary ]), {ok, S} = ssl:transport_accept(L), ssl:ssl_accept(S), ok = recv(S, 27), ok = recv(S, size(<< 0:800000000 >>)), ok = ssl:send(S, <<"it works!">>), ssl:shutdown(S, write), ok = recv(S, 2) end). client() -> {ok, S} = ssl:connect("localhost", 44444, [{active, false}, binary]), ssl:send(S, "some data before a big body"), ssl:send(S, << 0:800000000 >> ), recv(S, 9), ssl:send(S, "ok"), ok. recv(_S, 0) -> ok; recv(S, N) -> {ok, Bin} = ssl:recv(S, 0, 5000), recv(S, N - size(Bin)). Regards Ingela Erlang/OTP team - Ericsson AB On 02/08/2014 07:50 PM, Lo?c Hoguin wrote: > Hello, > > While investigating a solution for TCP linger issues with Cowboy, I > was surprised when I saw that the solution that worked perfectly well > for TCP didn't for SSL. > > It *may* be related to what fails in my other "SSL socket gets closed > abruptly" thread, as both cases send large data. However that other > thread is a little more crazy (as sending any non-200 response does > work there, while in this case I never got any response). > > Please see a test case attached. It's a simpler simulation of what may > actually happen with HTTP. First a few small packets (often one) are > sent for the headers, and then a potentially huge body. The server may > not want to receive the body, but it always needs to send a response. > Problem is, if we don't read the body, that response is never sent > with SSL. > > It's interesting to note that incorrect behavior occurs regardless of > the shutdown call being there. That call is used for the lingering > solution mentioned above so I tried with and without. In both cases > the response isn't received by the client. If the shutdown call is > there, the recv call will eventually say {error, closed} (it may or > may not take a while, I had both). If the shutdown call isn't there, > recv will just timeout. > > You need erl_make_certs from the SSL test suite for this test case too. > > Below output is for R16B02 but the issue also occurs with master > updated sometimes this week too. > > % erl > Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:4:4] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10.3 (abort with ^G) > 1> c(erl_make_certs). > {ok,erl_make_certs} > 2> c(sslbig). > {ok,sslbig} > 3> "With shutdown write". > "With shutdown write" > 4> sslbig:server(). > <0.69.0> > 5> sslbig:client(). > ** exception error: no match of right hand side value {error,closed} > in function sslbig:client/0 (sslbig.erl, line 29) > 6> c(sslbig). > {ok,sslbig} > 7> "Without shutdown write". > "Without shutdown write" > 8> sslbig:server(). > <0.84.0> > 9> sslbig:client(). > ** exception error: no match of right hand side value {error,timeout} > in function sslbig:client/0 (sslbig.erl, line 29) > 10> > > Enjoy! > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Feb 13 15:30:55 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 15:30:55 +0100 Subject: [erlang-bugs] SSL fails at sending a short message while receiving a big one In-Reply-To: <52FCD580.3060904@erix.ericsson.se> References: <52F67C80.7070205@ninenines.eu> <52FCD580.3060904@erix.ericsson.se> Message-ID: <52FCD71F.9020105@ninenines.eu> Okay the test case I sent was obviously incorrect, good catch. I *do* still have an issue though, as the client is in passive mode in the Cowboy test suite, and yet the test still fails in the manner I described. I will investigate further, but have you tried to run the Cowboy suite? There should be 2 cases failing for you, and I have 2 others that I need to push, all only with SSL. On 02/13/2014 03:24 PM, Ingela Anderton Andin wrote: > Hi! > > If you make your client use a passive socket instead of a active one > your first test case, it will work better! > > I also rewrote your second version into: (which works fine for me) > > -module(big2). > -compile(export_all). > > server() -> > ssl:start(), > CaInfo = erl_make_certs:make_cert([{key, dsa}]), > {Cert, {Asn1Type, Der, _}} = erl_make_certs:make_cert([{key, dsa}, > {issuer, CaInfo}]), > Key = {Asn1Type, Der}, > spawn(fun() -> > {ok, L} = ssl:listen(44444, [ > {cert, Cert}, > {key, Key}, > {active, false}, > binary > ]), > {ok, S} = ssl:transport_accept(L), > ssl:ssl_accept(S), > ok = recv(S, 27), > ok = recv(S, size(<< 0:800000000 >>)), > ok = ssl:send(S, <<"it works!">>), > ssl:shutdown(S, write), > ok = recv(S, 2) > end). > > client() -> > {ok, S} = ssl:connect("localhost", 44444, [{active, false}, binary]), > ssl:send(S, "some data before a big body"), > ssl:send(S, << 0:800000000 >> ), > recv(S, 9), > ssl:send(S, "ok"), > ok. > > recv(_S, 0) -> > ok; > recv(S, N) -> > {ok, Bin} = ssl:recv(S, 0, 5000), > recv(S, N - size(Bin)). > > > Regards Ingela Erlang/OTP team - Ericsson AB > > On 02/08/2014 07:50 PM, Lo?c Hoguin wrote: >> Hello, >> >> While investigating a solution for TCP linger issues with Cowboy, I >> was surprised when I saw that the solution that worked perfectly well >> for TCP didn't for SSL. >> >> It *may* be related to what fails in my other "SSL socket gets closed >> abruptly" thread, as both cases send large data. However that other >> thread is a little more crazy (as sending any non-200 response does >> work there, while in this case I never got any response). >> >> Please see a test case attached. It's a simpler simulation of what may >> actually happen with HTTP. First a few small packets (often one) are >> sent for the headers, and then a potentially huge body. The server may >> not want to receive the body, but it always needs to send a response. >> Problem is, if we don't read the body, that response is never sent >> with SSL. >> >> It's interesting to note that incorrect behavior occurs regardless of >> the shutdown call being there. That call is used for the lingering >> solution mentioned above so I tried with and without. In both cases >> the response isn't received by the client. If the shutdown call is >> there, the recv call will eventually say {error, closed} (it may or >> may not take a while, I had both). If the shutdown call isn't there, >> recv will just timeout. >> >> You need erl_make_certs from the SSL test suite for this test case too. >> >> Below output is for R16B02 but the issue also occurs with master >> updated sometimes this week too. >> >> % erl >> Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:4:4] >> [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V5.10.3 (abort with ^G) >> 1> c(erl_make_certs). >> {ok,erl_make_certs} >> 2> c(sslbig). >> {ok,sslbig} >> 3> "With shutdown write". >> "With shutdown write" >> 4> sslbig:server(). >> <0.69.0> >> 5> sslbig:client(). >> ** exception error: no match of right hand side value {error,closed} >> in function sslbig:client/0 (sslbig.erl, line 29) >> 6> c(sslbig). >> {ok,sslbig} >> 7> "Without shutdown write". >> "Without shutdown write" >> 8> sslbig:server(). >> <0.84.0> >> 9> sslbig:client(). >> ** exception error: no match of right hand side value {error,timeout} >> in function sslbig:client/0 (sslbig.erl, line 29) >> 10> >> >> Enjoy! >> >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > -- Lo?c Hoguin http://ninenines.eu From Ingela.Anderton.Andin@REDACTED Thu Feb 13 15:36:23 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 13 Feb 2014 15:36:23 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <84B50145-0214-45BC-A76D-5E6EC004340A@gmail.com> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> <52F4B109.3060602@ericsson.com> <52F4E1FD.30600@ninenines.eu> <52FCAB34.4060104@ericsson.com> <1E80C311-AD62-456E-834C-5756B6687068@gmail.com> <52FCAF1C.5020906@ericsson.com> <3B230ED2-56A8-4F1D-9AB0-70D847EC3D78@gmail.com> <52FCC441.2020205@ericsson.com> <84B50145-0214-45BC-A76D-5E6EC004340A@gmail.com> Message-ID: <52FCD867.6060908@ericsson.com> On 02/13/2014 02:14 PM, Anthony Ramine wrote: > I mean ? ssl:cipher_suites/2 ?, of which the return value is never used. Point taken, I will clearify it for the release! Regards Ingela Erlang/OTP team From Ingela.Anderton.Andin@REDACTED Fri Feb 14 17:29:42 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Fri, 14 Feb 2014 17:29:42 +0100 Subject: [erlang-bugs] SSL sslv3 not working as expected? In-Reply-To: <3B230ED2-56A8-4F1D-9AB0-70D847EC3D78@gmail.com> References: <52F3B38E.8050603@ninenines.eu> <52F3BC58.2060009@erix.ericsson.se> <52F3BF76.2070507@ninenines.eu> <52F3F0BE.9090409@erix.ericsson.se> <52F4AEFD.4090802@ninenines.eu> <52F4B109.3060602@ericsson.com> <52F4E1FD.30600@ninenines.eu> <52FCAB34.4060104@ericsson.com> <1E80C311-AD62-456E-834C-5756B6687068@gmail.com> <52FCAF1C.5020906@ericsson.com> <3B230ED2-56A8-4F1D-9AB0-70D847EC3D78@gmail.com> Message-ID: <52FE4476.70907@ericsson.com> Hi again! On 02/13/2014 12:41 PM, Anthony Ramine wrote: > Shouldn?t the function be rewritten to be more explicit about the fact that it is just a check? That code is quite hard to follow. Comming back to this, the code was a little to smart for its own good so to speak ;) And I actually fooled myself due to how the bug manifested it self. Fortunately I have quite a few test cases now that prevented me from merging my suggested patch. Here is a better and hopefully clear patch :) Regards Ingela Erlang/OTP team Ericsson AB diff --git a/lib/ssl/src/ssl.erl b/lib/ssl/src/ssl.erl index 7edc655..c3bdeb1 100644 --- a/lib/ssl/src/ssl.erl +++ b/lib/ssl/src/ssl.erl @@ -626,7 +626,7 @@ handle_options(Opts0, _Role) -> user_lookup_fun = handle_option(user_lookup_fun, Opts, undefined), psk_identity = handle_option(psk_identity, Opts, undefined), srp_identity = handle_option(srp_identity, Opts, undefined), - ciphers = handle_option(ciphers, Opts, []), + ciphers = handle_cipher_option(proplists:get_value(ciphers, Opts, []), hd(Versions)), %% Server side option reuse_session = handle_option(reuse_session, Opts, ReuseSessionFun), reuse_sessions = handle_option(reuse_sessions, Opts, true), @@ -769,15 +769,6 @@ validate_option(srp_identity, {Username, Password}) {unicode:characters_to_binary(Username), unicode:characters_to_binary(Password)}; -validate_option(ciphers, Value) when is_list(Value) -> - Version = tls_record:highest_protocol_version([]), - try cipher_suites(Version, Value) - catch - exit:_ -> - throw({error, {options, {ciphers, Value}}}); - error:_-> - throw({error, {options, {ciphers, Value}}}) - end; validate_option(reuse_session, Value) when is_function(Value) -> Value; validate_option(reuse_sessions, Value) when is_boolean(Value) -> @@ -937,16 +928,26 @@ emulated_options([Opt|Opts], Inet, Emulated) -> emulated_options([], Inet,Emulated) -> {Inet, Emulated}. -cipher_suites(Version, []) -> +handle_cipher_option(Value, Version) when is_list(Value) -> + try binary_cipher_suites(Version, Value) of + Suites -> + Suites + catch + exit:_ -> + throw({error, {options, {ciphers, Value}}}); + error:_-> + throw({error, {options, {ciphers, Value}}}) + end. +binary_cipher_suites(Version, []) -> %% Defaults to all supported suits ssl_cipher:suites(Version); -cipher_suites(Version, [{_,_,_,_}| _] = Ciphers0) -> %% Backwards compatibility +binary_cipher_suites(Version, [{_,_,_,_}| _] = Ciphers0) -> %% Backwards compatibility Ciphers = [{KeyExchange, Cipher, Hash} || {KeyExchange, Cipher, Hash, _} <- Ciphers0], - cipher_suites(Version, Ciphers); -cipher_suites(Version, [{_,_,_}| _] = Ciphers0) -> + binary_cipher_suites(Version, Ciphers); +binary_cipher_suites(Version, [{_,_,_}| _] = Ciphers0) -> Ciphers = [ssl_cipher:suite(C) || C <- Ciphers0], - cipher_suites(Version, Ciphers); + binary_cipher_suites(Version, Ciphers); -cipher_suites(Version, [Cipher0 | _] = Ciphers0) when is_binary(Cipher0) -> +binary_cipher_suites(Version, [Cipher0 | _] = Ciphers0) when is_binary(Cipher0) -> Supported0 = ssl_cipher:suites(Version) ++ ssl_cipher:anonymous_suites() ++ ssl_cipher:psk_suites(Version) @@ -954,18 +955,18 @@ cipher_suites(Version, [Cipher0 | _] = Ciphers0) when is_binary(Cipher0) -> Supported = ssl_cipher:filter_suites(Supported0), case [Cipher || Cipher <- Ciphers0, lists:member(Cipher, Supported)] of [] -> - Supported; + Supported; %% Defaults to all supported suits Ciphers -> Ciphers end; -cipher_suites(Version, [Head | _] = Ciphers0) when is_list(Head) -> +binary_cipher_suites(Version, [Head | _] = Ciphers0) when is_list(Head) -> %% Format: ["RC4-SHA","RC4-MD5"] Ciphers = [ssl_cipher:openssl_suite(C) || C <- Ciphers0], - cipher_suites(Version, Ciphers); -cipher_suites(Version, Ciphers0) -> + binary_cipher_suites(Version, Ciphers); +binary_cipher_suites(Version, Ciphers0) -> %% Format: "RC4-SHA:RC4-MD5" Ciphers = [ssl_cipher:openssl_suite(C) || C <- string:tokens(Ciphers0, ":")], - cipher_suites(Version, Ciphers). + binary_cipher_suites(Version, Ciphers). unexpected_format(Error) -> lists:flatten(io_lib:format("Unexpected error: ~p", [Error])). From anders.nygren@REDACTED Fri Feb 14 19:16:05 2014 From: anders.nygren@REDACTED (Anders Nygren) Date: Fri, 14 Feb 2014 12:16:05 -0600 Subject: [erlang-bugs] inet:getifaddrs always returns running Message-ID: I am not sure if this is a bug, or if I misunderstand something. On at least R15B01 and R16B03-1 on Linux, inet:getifaddrs always returns RUNNING in the flags even if the network cable is disconnected, and ifconfig does not show RUNNING. Is there any other way of getting the operational state of an interface? /Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-bugs@REDACTED Mon Feb 17 12:48:17 2014 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 17 Feb 2014 12:48:17 +0100 Subject: [erlang-bugs] inet:getifaddrs always returns running In-Reply-To: References: Message-ID: <20140217114817.GA16106@erix.ericsson.se> On Fri, Feb 14, 2014 at 12:16:05PM -0600, Anders Nygren wrote: > I am not sure if this is a bug, or if I misunderstand something. > > On at least R15B01 and R16B03-1 on Linux, inet:getifaddrs always returns > RUNNING in the flags even if the network cable is disconnected, and > ifconfig does not show RUNNING. This seems to be an old (pre-R13) workaround of unknown origin that emulates RUNNING when UP, so the real IFF_RUNNING flag is ignored. I consider it a bug, and if IFF_RUNNING is not working or not present on some platform, that should be worked around instead of working around a working normal case. It is now on our interna ToDo list but without priority yet. > > Is there any other way of getting the operational state of an interface? > > /Anders > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From magnus.mueller@REDACTED Tue Feb 18 11:24:32 2014 From: magnus.mueller@REDACTED (Magnus Mueller) Date: Tue, 18 Feb 2014 10:24:32 +0000 Subject: [erlang-bugs] httpc_handler crash on malformed content-length Message-ID: <6022ca9327e84f9ba925808f83390807@AMSPR03MB051.eurprd03.prod.outlook.com> Hello List. httpc_handler crashes hard when the supplied content-length is not parseable with list_to_integer. == Steps to reproduce == 1) Use netcat to listen at a specific port (nc -l 30100) 2) Open an Erlang shell, start inets and perform a httpc request 3) After httpc sent its request, write the following into stdin of netcat (followed by two newlines): HTTP/1.1 200 OK content-length: die! === httpc in repl === (repl_1@REDACTED)1> inets:start(). ok (repl_1@REDACTED)2> httpc:request("http://localhost:30100"). {error, {badarg, [{erlang,list_to_integer,["die!"],[]}, {httpc_handler,handle_http_body,2, [{file,"httpc_handler.erl"},{line,1143}]}, {httpc_handler,handle_info,2, [{file,"httpc_handler.erl"},{line,462}]}, {gen_server,handle_msg,5, [{file,"gen_server.erl"},{line,604}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]}} (repl_1@REDACTED)3> =ERROR REPORT==== 18-Feb-2014::11:16:52 === ** Generic server <0.55.0> terminating ** Last message in was {tcp,#Port<0.3049>,<<"\n">>} ** When Server state == {state, {request,#Ref<0.0.0.90>,<0.41.0>,0,http, {"localhost",30100}, "/",[],get, {http_request_h,undefined,"keep-alive", undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined,"localhost:30100", undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,[],undefined,undefined, undefined,undefined,"0",undefined, undefined,undefined,undefined,undefined, undefined,[]}, {[],[]}, {http_options,"HTTP/1.1",infinity,true, {essl,[]}, undefined,false,infinity,false}, "http://localhost:30100",[],none,[], 1392718605743,undefined,undefined,false}, {session, {{"localhost",30100},<0.55.0>}, false,http,#Port<0.3049>,ip_comm,1,keep_alive, false}, undefined,undefined,undefined, {httpc_response,parse_headers, [<<"\r\n">>,"!eid :htgnel-tnetnoc",[],nolimit, ["OK",200,"HTTP/1.1"], false]}, {[],[]}, {[],[]}, new,[],nolimit,nolimit, {options, {undefined,[]}, {undefined,[]}, 0,2,5,120000,2,disabled,false,inet,default, default,[]}, {timers,[],undefined}, httpc_manager,inactive} ** Reason for termination == ** {badarg,[{erlang,list_to_integer,["die!"],[]}, {httpc_handler,handle_http_body,2, [{file,"httpc_handler.erl"},{line,1143}]}, {httpc_handler,handle_info,2, [{file,"httpc_handler.erl"},{line,462}]}, {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,604}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} From Ingela.Anderton.Andin@REDACTED Tue Feb 18 12:23:18 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 18 Feb 2014 12:23:18 +0100 Subject: [erlang-bugs] httpc_handler crash on malformed content-length In-Reply-To: <6022ca9327e84f9ba925808f83390807@AMSPR03MB051.eurprd03.prod.outlook.com> References: <6022ca9327e84f9ba925808f83390807@AMSPR03MB051.eurprd03.prod.outlook.com> Message-ID: <530342A6.2000900@ericsson.com> Hi! Thank you for reporting this, I have created a ticket for fixing this. Regards Ingela Erlang/OTP team Ericsson AB On 02/18/2014 11:24 AM, Magnus Mueller wrote: > Hello List. > > httpc_handler crashes hard when the supplied content-length is not parseable with list_to_integer. > > == Steps to reproduce == > > 1) Use netcat to listen at a specific port (nc -l 30100) > 2) Open an Erlang shell, start inets and perform a httpc request > 3) After httpc sent its request, write the following into stdin of netcat (followed by two newlines): > > HTTP/1.1 200 OK > content-length: die! > > === httpc in repl === > > (repl_1@REDACTED)1> inets:start(). > ok > (repl_1@REDACTED)2> httpc:request("http://localhost:30100"). > {error, > {badarg, > [{erlang,list_to_integer,["die!"],[]}, > {httpc_handler,handle_http_body,2, > [{file,"httpc_handler.erl"},{line,1143}]}, > {httpc_handler,handle_info,2, > [{file,"httpc_handler.erl"},{line,462}]}, > {gen_server,handle_msg,5, > [{file,"gen_server.erl"},{line,604}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]}} > (repl_1@REDACTED)3> > =ERROR REPORT==== 18-Feb-2014::11:16:52 === > ** Generic server <0.55.0> terminating > ** Last message in was {tcp,#Port<0.3049>,<<"\n">>} > ** When Server state == {state, > {request,#Ref<0.0.0.90>,<0.41.0>,0,http, > {"localhost",30100}, > "/",[],get, > {http_request_h,undefined,"keep-alive", > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,"localhost:30100", > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,[],undefined,undefined, > undefined,undefined,"0",undefined, > undefined,undefined,undefined,undefined, > undefined,[]}, > {[],[]}, > {http_options,"HTTP/1.1",infinity,true, > {essl,[]}, > undefined,false,infinity,false}, > "http://localhost:30100",[],none,[], > 1392718605743,undefined,undefined,false}, > {session, > {{"localhost",30100},<0.55.0>}, > false,http,#Port<0.3049>,ip_comm,1,keep_alive, > false}, > undefined,undefined,undefined, > {httpc_response,parse_headers, > [<<"\r\n">>,"!eid :htgnel-tnetnoc",[],nolimit, > ["OK",200,"HTTP/1.1"], > false]}, > {[],[]}, > {[],[]}, > new,[],nolimit,nolimit, > {options, > {undefined,[]}, > {undefined,[]}, > 0,2,5,120000,2,disabled,false,inet,default, > default,[]}, > {timers,[],undefined}, > httpc_manager,inactive} > ** Reason for termination == > ** {badarg,[{erlang,list_to_integer,["die!"],[]}, > {httpc_handler,handle_http_body,2, > [{file,"httpc_handler.erl"},{line,1143}]}, > {httpc_handler,handle_info,2, > [{file,"httpc_handler.erl"},{line,462}]}, > {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,604}]}, > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From magnus.mueller@REDACTED Tue Feb 18 12:49:57 2014 From: magnus.mueller@REDACTED (Magnus Mueller) Date: Tue, 18 Feb 2014 11:49:57 +0000 Subject: [erlang-bugs] httpc_handler crash on malformed content-length In-Reply-To: References: <6022ca9327e84f9ba925808f83390807@AMSPR03MB051.eurprd03.prod.outlook.com> Message-ID: Hey Dmitry, there are two issues which bother us with the current behaviour: a) Our logfiles contain error messages which can be safely ignored, but which add to the noise. b) The returned error does not give proper diagnostics to tell us with what httpc struggled exactly. A better message would say something in the line of "failed on parsing content-length". Magnus -----Urspr?ngliche Nachricht----- Von: Dmitry Kolesnikov [mailto:dmitry@REDACTED] Gesendet: Dienstag, 18. Februar 2014 12:21 An: Magnus Mueller Cc: erlang-bugs@REDACTED Betreff: Re: [erlang-bugs] httpc_handler crash on malformed content-length Hello, httpc returned an error to you and crash looks normal to my eye. it is better to crash in this case then try to recover. what is an issue here? - Dmitry On 18 Feb 2014, at 12:24, Magnus Mueller wrote: > Hello List. > > httpc_handler crashes hard when the supplied content-length is not parseable with list_to_integer. > > == Steps to reproduce == > > 1) Use netcat to listen at a specific port (nc -l 30100) > 2) Open an Erlang shell, start inets and perform a httpc request > 3) After httpc sent its request, write the following into stdin of netcat (followed by two newlines): > > HTTP/1.1 200 OK > content-length: die! > > === httpc in repl === > > (repl_1@REDACTED)1> inets:start(). > ok > (repl_1@REDACTED)2> httpc:request("http://localhost:30100"). > {error, > {badarg, > [{erlang,list_to_integer,["die!"],[]}, > {httpc_handler,handle_http_body,2, > [{file,"httpc_handler.erl"},{line,1143}]}, > {httpc_handler,handle_info,2, > [{file,"httpc_handler.erl"},{line,462}]}, > {gen_server,handle_msg,5, > [{file,"gen_server.erl"},{line,604}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]}} > (repl_1@REDACTED)3> > =ERROR REPORT==== 18-Feb-2014::11:16:52 === > ** Generic server <0.55.0> terminating > ** Last message in was {tcp,#Port<0.3049>,<<"\n">>} > ** When Server state == {state, > {request,#Ref<0.0.0.90>,<0.41.0>,0,http, > {"localhost",30100}, > "/",[],get, > {http_request_h,undefined,"keep-alive", > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,"localhost:30100", > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,[],undefined,undefined, > undefined,undefined,"0",undefined, > undefined,undefined,undefined,undefined, > undefined,[]}, > {[],[]}, > {http_options,"HTTP/1.1",infinity,true, > {essl,[]}, > undefined,false,infinity,false}, > "http://localhost:30100",[],none,[], > 1392718605743,undefined,undefined,false}, > {session, > {{"localhost",30100},<0.55.0>}, > false,http,#Port<0.3049>,ip_comm,1,keep_alive, > false}, > undefined,undefined,undefined, > {httpc_response,parse_headers, > [<<"\r\n">>,"!eid :htgnel-tnetnoc",[],nolimit, > ["OK",200,"HTTP/1.1"], > false]}, > {[],[]}, > {[],[]}, > new,[],nolimit,nolimit, > {options, > {undefined,[]}, > {undefined,[]}, > 0,2,5,120000,2,disabled,false,inet,default, > default,[]}, > {timers,[],undefined}, > httpc_manager,inactive} > ** Reason for termination == > ** {badarg,[{erlang,list_to_integer,["die!"],[]}, > {httpc_handler,handle_http_body,2, > [{file,"httpc_handler.erl"},{line,1143}]}, > {httpc_handler,handle_info,2, > [{file,"httpc_handler.erl"},{line,462}]}, > {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,604}]}, > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From tuncer.ayaz@REDACTED Tue Feb 18 13:40:04 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 13:40:04 +0100 Subject: [erlang-bugs] (unconditional) rebuild caused by gen_git_version Message-ID: Since R16 it's not possible anymore to quickly run make in a previously built and otherwise unmodified tree. $ make # everything built # run make again $ make ... GEN x86_64-unknown-linux-gnu/gen_git_version.mk CC obj/x86_64-unknown-linux-gnu/opt/plain/erl_bif_info.o .. LD /tmp/otp/master/bin/x86_64-unknown-linux-gnu/beam This doesn't take long, but recreating an object file and relinking the vm every time doesn't seem right to me. AFAICT, it was introduced to include the git revision of the tree the vm was built from. I don't have time to look into this right now, so no patch from me. From tuncer.ayaz@REDACTED Tue Feb 18 18:53:30 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 18:53:30 +0100 Subject: [erlang-bugs] (unconditional) rebuild caused by gen_git_version In-Reply-To: References: Message-ID: On Tue, Feb 18, 2014 at 1:40 PM, Tuncer Ayaz wrote: > Since R16 it's not possible anymore to quickly run make in a > previously built and otherwise unmodified tree. > > $ make > # everything built > # run make again > $ make > ... > GEN x86_64-unknown-linux-gnu/gen_git_version.mk > CC obj/x86_64-unknown-linux-gnu/opt/plain/erl_bif_info.o > .. > LD /tmp/otp/master/bin/x86_64-unknown-linux-gnu/beam > > This doesn't take long, but recreating an object file and relinking > the vm every time doesn't seem right to me. AFAICT, it was introduced > to include the git revision of the tree the vm was built from. > > I don't have time to look into this right now, so no patch from me. If anyone wants to submit a fix, presumably adding a check that compares the previous build's git revision for inequality should fix the bug. I assume it's probably already cached in a file. From lukas@REDACTED Wed Feb 19 11:55:19 2014 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 19 Feb 2014 11:55:19 +0100 Subject: [erlang-bugs] (unconditional) rebuild caused by gen_git_version In-Reply-To: References: Message-ID: <53048D97.6000301@erlang.org> Hello, When implementing this I noticed it as well and tried to do something about it. Alas it proved quite difficult and I had to settle on a compromise where it does a rebuild once. i.e. commit change make LD make LD make make make make At least that is the way it works for me on Ubuntu Linux. If someone else feels like having a go at making it work they are most welcome. Lukas On 18/02/14 18:53, Tuncer Ayaz wrote: > On Tue, Feb 18, 2014 at 1:40 PM, Tuncer Ayaz wrote: >> Since R16 it's not possible anymore to quickly run make in a >> previously built and otherwise unmodified tree. >> >> $ make >> # everything built >> # run make again >> $ make >> ... >> GEN x86_64-unknown-linux-gnu/gen_git_version.mk >> CC obj/x86_64-unknown-linux-gnu/opt/plain/erl_bif_info.o >> .. >> LD /tmp/otp/master/bin/x86_64-unknown-linux-gnu/beam >> >> This doesn't take long, but recreating an object file and relinking >> the vm every time doesn't seem right to me. AFAICT, it was introduced >> to include the git revision of the tree the vm was built from. >> >> I don't have time to look into this right now, so no patch from me. > If anyone wants to submit a fix, presumably adding a check that > compares the previous build's git revision for inequality should fix > the bug. I assume it's probably already cached in a file. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From bjorn@REDACTED Thu Feb 20 12:29:20 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 20 Feb 2014 12:29:20 +0100 Subject: [erlang-bugs] ASN1 parsing bug In-Reply-To: References: Message-ID: On Fri, Jan 31, 2014 at 3:29 PM, Bj?rn Gustavsson wrote: > On Fri, Jan 31, 2014 at 9:58 AM, Morten Nygaard ?snes > wrote: >> >> Any chance of this getting fixed? > > > Yes, we hope to fix it before the final release of OTP 17. > It will probably be included in the next release candidate. > The correction has been merged to master, and will be included in the next release candidate. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From dgud@REDACTED Thu Feb 20 12:37:22 2014 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 20 Feb 2014 12:37:22 +0100 Subject: [erlang-bugs] Strange application shutdown deadlock In-Reply-To: References: <20130524144546.GB14817@ferdair.local> <7E9616D5-BD4E-4F87-9EDA-A3AF2262FE05@gmail.com> Message-ID: I have merged a fix now, will be available whenever master is pushed to github and in 17.0-RC2 /Dan On Tue, Jan 28, 2014 at 1:32 PM, Tim Watson wrote: > Hi Siri. > > Ok thanks for confirming that. Do you reckon it'll make a bugfix/patch > release or are we looking at R17 now? > > Thanks, > Tim > > On 28 Jan 2014, at 10:00, Siri Hansen wrote: > > Hi Tim, I'm sorry, but this has not made it into the latest release. The > reason is that there has been too many other tasks with higher priority. > Regards > /siri > > > 2014/1/27 Tim Watson > >> Hi Siri, >> >> Did this bug make it into the latest release? I didn't see anything in >> the release notes. >> >> Cheers, >> Tim >> >> >> >> On 19 June 2013 10:47, Siri Hansen wrote: >> >>> Hi Tim - I'm so sorry for the long delay here. I agree that this is a >>> bug in the application master and I have written a ticket for it so it will >>> be prioritized into out backlog. >>> Thanks for the report! >>> Regards >>> /siri >>> >>> >>> 2013/5/29 Tim Watson >>> >>>> Any word from the OTP folks on this one? >>>> >>>> On 24 May 2013, at 18:41, Tim Watson wrote: >>>> >>>> > Gah, sorry folks - this has nothing to do with release handling, that >>>> was a red herring. Someone just pointed out that the call to get_child >>>> originates in a status check in our code. >>>> > >>>> > This still looks like a bug to me though, since if you're going to >>>> handle "other" messages in terminate_loop you ought to ensure they can't >>>> deadlock the vm's shutdown sequence. >>>> > >>>> > Cheers, >>>> > Tim >>>> > >>>> > On 24 May 2013, at 15:45, Fred Hebert wrote: >>>> > >>>> >> Quick question: are you running a release? >>>> >> >>>> >> If so, last time I've seen deadlocks like that was solved by making >>>> sure >>>> >> *all* my applications did depend on stdlib and kernel in their app >>>> file. >>>> >> When I skipped them, sometimes I'd find that things would lock up. >>>> >> >>>> >> My guess was that dependencies from stdlib or kernel got unloaded >>>> before >>>> >> my app and broke something, but I'm not sure -- In my case, I wasn't >>>> >> able to inspect the node as it appeared to be 100% blocked. >>>> >> >>>> >> Adding the apps ended up fixing the problem on the next shutdown. I'm >>>> >> not sure if it might be a good fix for you, but it's a stab in the >>>> dark, >>>> >> >>>> >> Regards, >>>> >> Fred. >>>> >> >>>> >> On 05/24, Tim Watson wrote: >>>> >>> We came across this at a customer's site, where one of the nodes >>>> was apparently in the process of stopping and had been in that state for at >>>> least 24 hours. The short version is that an application_master appears to >>>> be stuck waiting for a child pid (is that the X process, or the root >>>> supervisor?) which is *not* linked to it... >>>> >>> >>>> >>> The application controller is in the process of stopping an >>>> application, during which process a `get_child' message appears to have >>>> come in to that application's application_master from somewhere - we are >>>> *not* running appmon, so I'm really confused how this can happen, as the >>>> only other place where I see (indirect) calls are via the sasl >>>> release_handler!? At the bottom of this email is a dump for the >>>> application_controller and the application_master for the app it is trying >>>> to shut down. I can verify that the pid which the application_master is >>>> waiting on is definitely not linked to it - i.e., process_info(links, >>>> AppMasterPid) doesn't contain the process <0.256.0> that the master appears >>>> to be waiting on. >>>> >>> >>>> >>> My reading of the code is that the application_master cannot end up >>>> in get_child_i unless a get_child request was made which arrives whilst it >>>> is in its terminate loop. As I said, we're not using appmon, therefore I >>>> assume this originated in the sasl application's release_handler_1, though >>>> I'm not sure quite which route would take us there. The relevant bit of >>>> code in application_master appears to be: >>>> >>> >>>> >>> get_child_i(Child) -> >>>> >>> Child ! {self(), get_child}, >>>> >>> receive >>>> >>> {Child, GrandChild, Mod} -> {GrandChild, Mod} >>>> >>> end. >>>> >>> >>>> >>> This in turn originates, I'd guess, in the third receive clause of >>>> terminate_loop/2. Anyway, should that code not be dealing with a >>>> potentially dead pid for Child, either by handling links effectively - >>>> perhaps there is an EXIT signal in the mailbox already which is being >>>> ignored here in get_child_i/1 - or by some other means? >>>> >>> >>>> >>> What follows below is the trace/dump output. Feel free to poke me >>>> for more info as needed. >>>> >>> >>>> >>> Cheers, >>>> >>> Tim >>>> >>> >>>> >>> [TRACE/DUMP] >>>> >>> >>>> >>> pid: <6676.7.0> >>>> >>> registered name: application_controller >>>> >>> stacktrace: [{application_master,call,2, >>>> >>> >>>> [{file,"application_master.erl"},{line,75}]}, >>>> >>> {application_controller,stop_appl,3, >>>> >>> >>>> [{file,"application_controller.erl"}, >>>> >>> {line,1393}]}, >>>> >>> {application_controller,handle_call,3, >>>> >>> >>>> [{file,"application_controller.erl"}, >>>> >>> {line,810}]}, >>>> >>> >>>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}] >>>> >>> ------------------------- >>>> >>> Program counter: 0x00007f9bf9a53720 (application_master:call/2 + >>>> 288) >>>> >>> CP: 0x0000000000000000 (invalid) >>>> >>> arity = 0 >>>> >>> >>>> >>> 0x00007f9bd7948360 Return addr 0x00007f9bfb97de40 >>>> (application_controller:stop_appl/3 + 176) >>>> >>> y(0) #Ref<0.0.20562.258360> >>>> >>> y(1) #Ref<0.0.20562.258361> >>>> >>> y(2) [] >>>> >>> >>>> >>> 0x00007f9bd7948380 Return addr 0x00007f9bfb973c68 >>>> (application_controller:handle_call/3 + 1392) >>>> >>> y(0) temporary >>>> >>> y(1) rabbitmq_web_dispatch >>>> >>> >>>> >>> 0x00007f9bd7948398 Return addr 0x00007f9bf9a600c8 >>>> (gen_server:handle_msg/5 + 272) >>>> >>> y(0) >>>> {state,[],[],[],[{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}],[],[{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}],[],[{rabbit,[{ssl_listeners,[5671]},{ssl_options,[{cacertfile,"/etc/rabbitmq/server.cacrt"},{certfile,"/etc/rabbitmq/server.crt"},{keyfile,"/etc/rabbitmq/server.key"},{verify,verify_none},{fail_if_no_peer_cert,false}]},{default_user,<<2 >>>> bytes>>},{default_pass,<<8 >>>> bytes>>},{vm_memory_high_watermark,5.000000e-01}]},{rabbitmq_management,[{listener,[{port,15672},{ssl,true}]}]}]} >>>> >>> y(1) rabbitmq_web_dispatch >>>> >>> y(2) >>>> [{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}] >>>> >>> y(3) >>>> [{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}] >>>> >>> >>>> >>> 0x00007f9bd79483c0 Return addr 0x00000000008827d8 (>>> process normally>) >>>> >>> y(0) application_controller >>>> >>> y(1) >>>> {state,[],[],[],[{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}],[],[{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}],[],[{rabbit,[{ssl_listeners,[5671]},{ssl_options,[{cacertfile,"/etc/rabbitmq/server.cacrt"},{certfile,"/etc/rabbitmq/server.crt"},{keyfile,"/etc/rabbitmq/server.key"},{verify,verify_none},{fail_if_no_peer_cert,false}]},{default_user,<<2 >>>> bytes>>},{default_pass,<<8 >>>> bytes>>},{vm_memory_high_watermark,5.000000e-01}]},{rabbitmq_management,[{listener,[{port,15672},{ssl,true}]}]}]} >>>> >>> y(2) application_controller >>>> >>> y(3) <0.2.0> >>>> >>> y(4) {stop_application,rabbitmq_web_dispatch} >>>> >>> y(5) {<0.5864.275>,#Ref<0.0.20562.258345>} >>>> >>> y(6) Catch 0x00007f9bf9a600c8 (gen_server:handle_msg/5 + 272) >>>> >>> ------------------------- >>>> >>> >>>> >>> pid: <6676.255.0> >>>> >>> registered name: none >>>> >>> stacktrace: [{application_master,get_child_i,1, >>>> >>> >>>> [{file,"application_master.erl"},{line,392}]}, >>>> >>> {application_master,handle_msg,2, >>>> >>> >>>> [{file,"application_master.erl"},{line,216}]}, >>>> >>> {application_master,terminate_loop,2, >>>> >>> >>>> [{file,"application_master.erl"},{line,206}]}, >>>> >>> {application_master,terminate,2, >>>> >>> >>>> [{file,"application_master.erl"},{line,227}]}, >>>> >>> {application_master,handle_msg,2, >>>> >>> >>>> [{file,"application_master.erl"},{line,219}]}, >>>> >>> {application_master,main_loop,2, >>>> >>> >>>> [{file,"application_master.erl"},{line,194}]}, >>>> >>> >>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] >>>> >>> ------------------------- >>>> >>> Program counter: 0x00007f9bf9a570e0 >>>> (application_master:get_child_i/1 + 120) >>>> >>> CP: 0x0000000000000000 (invalid) >>>> >>> arity = 0 >>>> >>> >>>> >>> 0x00007f9c1adc3dc8 Return addr 0x00007f9bf9a54eb0 >>>> (application_master:handle_msg/2 + 280) >>>> >>> y(0) <0.256.0> >>>> >>> >>>> >>> 0x00007f9c1adc3dd8 Return addr 0x00007f9bf9a54d20 >>>> (application_master:terminate_loop/2 + 520) >>>> >>> y(0) #Ref<0.0.20562.258362> >>>> >>> y(1) <0.9596.275> >>>> >>> y(2) >>>> {state,<0.256.0>,{appl_data,rabbitmq_web_dispatch,[],undefined,{rabbit_web_dispatch_app,[]},[rabbit_web_dispatch,rabbit_web_dispatch_app,rabbit_web_dispatch_registry,rabbit_web_dispatch_sup,rabbit_web_dispatch_util,rabbit_webmachine],[],infinity,infinity},[],0,<0.29.0>} >>>> >>> >>>> >>> 0x00007f9c1adc3df8 Return addr 0x00007f9bf9a55108 >>>> (application_master:terminate/2 + 192) >>>> >>> y(0) <0.256.0> >>>> >>> >>>> >>> 0x00007f9c1adc3e08 Return addr 0x00007f9bf9a54f70 >>>> (application_master:handle_msg/2 + 472) >>>> >>> y(0) [] >>>> >>> y(1) normal >>>> >>> >>>> >>> 0x00007f9c1adc3e20 Return addr 0x00007f9bf9a54a60 >>>> (application_master:main_loop/2 + 1600) >>>> >>> y(0) <0.7.0> >>>> >>> y(1) #Ref<0.0.20562.258360> >>>> >>> y(2) Catch 0x00007f9bf9a54f70 (application_master:handle_msg/2 >>>> + 472) >>>> >>> >>>> >>> 0x00007f9c1adc3e40 Return addr 0x00007f9bfb969420 >>>> (proc_lib:init_p_do_apply/3 + 56) >>>> >>> y(0) <0.7.0> >>>> >>> >>>> >>> 0x00007f9c1adc3e50 Return addr 0x00000000008827d8 (>>> process normally>) >>>> >>> y(0) Catch 0x00007f9bfb969440 (proc_lib:init_p_do_apply/3 + 88) >>>> >>> ------------------------- >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >>> _______________________________________________ >>>> >>> 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 >>>> >>> >>> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.bolinder@REDACTED Thu Feb 20 13:49:33 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 20 Feb 2014 12:49:33 +0000 Subject: [erlang-bugs] [erlang-questions] Crash during compilation In-Reply-To: <525E605F.5010104@gmail.com> References: <759CF9F8-E280-4DB9-888F-EC66A66BA45B@gmail.com> <9EBA66D6-7EB2-4AD7-B393-C1C419EB2762@gmail.com> <3B6E17BB-DDD0-4C10-B0E1-265A002555F4@gmail.com>, <525E605F.5010104@gmail.com> Message-ID: <56466BD70414EA48969B4064696CF28C037AF0FB@ESESSMB207.ericsson.se> [Richard Carlsson:] > Confirmed. Seems like the function leave_file/2 in epp.erl propagates > the macro definitions from the include file, but not the 'uses' field of > the preprocessor state when it leaves the header file. Thanks! The bug will be fixed in Erlang/OTP 17.0. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From hans.bolinder@REDACTED Thu Feb 20 13:52:27 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 20 Feb 2014 12:52:27 +0000 Subject: [erlang-bugs] inet:ntoa/1 incorrect typespec In-Reply-To: References: Message-ID: <56466BD70414EA48969B4064696CF28C037AF117@ESESSMB207.ericsson.se> [Max Treskin:] > inet:ntoa/1 has following typespec: > > -spec ntoa(IpAddress) -> > {ok, Address} | {error, einval} when > Address :: string(), > IpAddress :: ip_address(). > ntoa(Addr) -> > inet_parse:ntoa(Addr). > > but inet_parse:ntoa/1 returns only: > > string() | {error, einval} > > there is no tagged tuple {ok, string()} Thanks! The bug will be fixed in Erlang/OTP 17.0. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From elinsn@REDACTED Fri Feb 21 08:20:31 2014 From: elinsn@REDACTED (Sergey Yelin) Date: Fri, 21 Feb 2014 11:20:31 +0400 Subject: [erlang-bugs] Strange lists:foreach/2 declaration Message-ID: <2B070BE7-1053-46CD-8A3E-DA19825232A8@gmail.com> Hello, just found confusing behaviour for lists:foreach/2: 1> lists:foreach(xxx,[1,2,3]). ** exception error: bad function xxx in function lists:foreach/2 (lists.erl, line 1323) 2> lists:foreach(xxx,[]). ** exception error: no function clause matching lists:foreach(xxx,[]) (lists.erl, line 1322) so it returns two different errors for wrong function and it depends on whether list is empty or not. Here is the snippet from lists.erl: -spec foreach(Fun, List) -> ok when Fun :: fun((Elem :: T) -> term()), List :: [T], T :: term(). foreach(F, [Hd|Tail]) -> F(Hd), foreach(F, Tail); foreach(F, []) when is_function(F, 1) -> ok. So my question is it known bug (or feature)? Why there is no check for function when list is not empty? May be following is better: foreach(F, [Hd|Tail]) when is_function(F, 1) -> F(Hd), foreach(F, Tail); foreach(F, []) -> ok. because actually F will be never call when list is empty? --- Best regards, Sergey Yelin. From joearms@REDACTED Fri Feb 21 14:07:39 2014 From: joearms@REDACTED (Joe Armstrong) Date: Fri, 21 Feb 2014 14:07:39 +0100 Subject: [erlang-bugs] Bug in Erlang/OTP 17 [RELEASE CANDIDATE 1] Message-ID: I can't compile files with UFT characters in R17 With R17 [RELEASE CANDIDATE 1] $ erlc bug.erl bug.erl:8: cannot parse file, giving up bug.erl:8: no module definition bug.erl:8: cannot translate from UTF-8 With R16B joe:paradis-master joe$ ~/nobackup/otp_src_R16B/bin/erlc bug.erl Cheers /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.erl Type: application/octet-stream Size: 586 bytes Desc: not available URL: From vladdu55@REDACTED Fri Feb 21 16:29:22 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 21 Feb 2014 16:29:22 +0100 Subject: [erlang-bugs] Bug in Erlang/OTP 17 [RELEASE CANDIDATE 1] In-Reply-To: References: Message-ID: Hi Joe, Are you sure it's encoded in utf-8 originally? The file I downloaded isn't but it might be any of the systems it went through that messed it up. regards, Vlad On Fri, Feb 21, 2014 at 2:07 PM, Joe Armstrong wrote: > I can't compile files with UFT characters in R17 > > With R17 [RELEASE CANDIDATE 1] > > $ erlc bug.erl > bug.erl:8: cannot parse file, giving up > bug.erl:8: no module definition > bug.erl:8: cannot translate from UTF-8 > > With R16B > > joe:paradis-master joe$ ~/nobackup/otp_src_R16B/bin/erlc bug.erl > > Cheers > > /Joe > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Fri Feb 21 16:38:15 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 21 Feb 2014 10:38:15 -0500 Subject: [erlang-bugs] Bug in Erlang/OTP 17 [RELEASE CANDIDATE 1] In-Reply-To: References: Message-ID: Agreed. On OS X: $ file -I bug.erl bug.erl: text/plain; charset=iso-8859-1 Adding %% -*- coding: utf-8 -*- to the top of the file causes the file to be saved as UTF-8: $ file -I bug.erl bug.erl: text/plain; charset=utf-8 and after that, the compiler -- or more specifically, the file_io_server -- is happy again. --steve On Fri, Feb 21, 2014 at 10:29 AM, Vlad Dumitrescu wrote: > Hi Joe, > > Are you sure it's encoded in utf-8 originally? The file I downloaded isn't > but it might be any of the systems it went through that messed it up. > > regards, > Vlad > > > > On Fri, Feb 21, 2014 at 2:07 PM, Joe Armstrong wrote: > >> I can't compile files with UFT characters in R17 >> >> With R17 [RELEASE CANDIDATE 1] >> >> $ erlc bug.erl >> bug.erl:8: cannot parse file, giving up >> bug.erl:8: no module definition >> bug.erl:8: cannot translate from UTF-8 >> >> With R16B >> >> joe:paradis-master joe$ ~/nobackup/otp_src_R16B/bin/erlc bug.erl >> >> Cheers >> >> /Joe >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas@REDACTED Fri Feb 21 17:25:41 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Fri, 21 Feb 2014 17:25:41 +0100 Subject: [erlang-bugs] FW: Bug in Erlang/OTP 17 [RELEASE CANDIDATE 1] In-Reply-To: <58912684E2630B45963406CF7D8C52581C35DD0B@ESESSMB103.ericsson.se> References: <58912684E2630B45963406CF7D8C52581C35DD0B@ESESSMB103.ericsson.se> Message-ID: <53077E05.7030009@erlang.org> As Steve pointed out, bug.erl was encoded as ISO-8559-1/Latin-1 and not as UTF-8. As a special case, if you only use non-ASCII characters in comments, another alternative is to convert the file to UTF-8; for example, by instructing your editor to do so or by using iconv: $ iconv -f ISO-8859-1 -t UTF-8 bug.erl -o bug.erl Andreas > *From:*erlang-bugs-bounces@REDACTED > [mailto:erlang-bugs-bounces@REDACTED] *On Behalf Of *Steve Vinoski > *Sent:* den 21 februari 2014 16:38 > *To:* Vlad Dumitrescu > *Cc:* erlang-bugs > *Subject:* Re: [erlang-bugs] Bug in Erlang/OTP 17 [RELEASE CANDIDATE 1] > > Agreed. On OS X: > > $ file -I bug.erl > > bug.erl: text/plain; charset=iso-8859-1 > > Adding %% -*- coding: utf-8 -*- to the top of the file causes the file > to be saved as UTF-8: > > $ file -I bug.erl > > bug.erl: text/plain; charset=utf-8 > > and after that, the compiler -- or more specifically, the > file_io_server -- is happy again. > > --steve > > On Fri, Feb 21, 2014 at 10:29 AM, Vlad Dumitrescu > wrote: > > Hi Joe, > > Are you sure it's encoded in utf-8 originally? The file I downloaded > isn't but it might be any of the systems it went through that messed > it up. > > regards, > > Vlad > > On Fri, Feb 21, 2014 at 2:07 PM, Joe Armstrong > wrote: > > I can't compile files with UFT characters in R17 > > With R17 [RELEASE CANDIDATE 1] > > $ erlc bug.erl > > bug.erl:8: cannot parse file, giving up > > bug.erl:8: no module definition > > bug.erl:8: cannot translate from UTF-8 > > With R16B > > joe:paradis-master joe$ ~/nobackup/otp_src_R16B/bin/erlc bug.erl > > Cheers > > /Joe > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joearms@REDACTED Fri Feb 21 18:22:07 2014 From: joearms@REDACTED (Joe Armstrong) Date: Fri, 21 Feb 2014 18:22:07 +0100 Subject: [erlang-bugs] FW: Bug in Erlang/OTP 17 [RELEASE CANDIDATE 1] In-Reply-To: <53077E05.7030009@erlang.org> References: <58912684E2630B45963406CF7D8C52581C35DD0B@ESESSMB103.ericsson.se> <53077E05.7030009@erlang.org> Message-ID: On Fri, Feb 21, 2014 at 5:25 PM, Andreas Schumacher wrote: > As Steve pointed out, bug.erl was encoded as ISO-8559-1/Latin-1 and not > as UTF-8. > > As a special case, if you only use non-ASCII characters in comments, > another alternative is to convert the file to UTF-8; for example, by > instructing your editor to do so or by using iconv: > > $ iconv -f ISO-8859-1 -t UTF-8 bug.erl -o bug.erl > Thanks - The source came from erlide_scan.erl that I had somewhere. I recently downloaded erlguten from git hub and ran into this problem. I think this is going to hit a lot of legacy code. Would it possible to recompile with the old compiler /scanner if this error is seen. It's not nice to find you can't recompile ten year old code ... Thanks anyway /Joe > > Andreas > > > > > > *From:* erlang-bugs-bounces@REDACTED [ > mailto:erlang-bugs-bounces@REDACTED ] *On > Behalf Of *Steve Vinoski > *Sent:* den 21 februari 2014 16:38 > *To:* Vlad Dumitrescu > *Cc:* erlang-bugs > *Subject:* Re: [erlang-bugs] Bug in Erlang/OTP 17 [RELEASE CANDIDATE 1] > > > > Agreed. On OS X: > > > > $ file -I bug.erl > > bug.erl: text/plain; charset=iso-8859-1 > > > > Adding %% -*- coding: utf-8 -*- to the top of the file causes the file to > be saved as UTF-8: > > > > $ file -I bug.erl > > bug.erl: text/plain; charset=utf-8 > > > > and after that, the compiler -- or more specifically, the file_io_server > -- is happy again. > > > > --steve > > > > > > On Fri, Feb 21, 2014 at 10:29 AM, Vlad Dumitrescu > wrote: > > Hi Joe, > > > > Are you sure it's encoded in utf-8 originally? The file I downloaded isn't > but it might be any of the systems it went through that messed it up. > > > > regards, > > Vlad > > > > > > On Fri, Feb 21, 2014 at 2:07 PM, Joe Armstrong wrote: > > I can't compile files with UFT characters in R17 > > > > With R17 [RELEASE CANDIDATE 1] > > > > $ erlc bug.erl > > bug.erl:8: cannot parse file, giving up > > bug.erl:8: no module definition > > bug.erl:8: cannot translate from UTF-8 > > > > With R16B > > > > joe:paradis-master joe$ ~/nobackup/otp_src_R16B/bin/erlc bug.erl > > > > Cheers > > > > /Joe > > > > _______________________________________________ > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Fri Feb 21 18:35:08 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 21 Feb 2014 18:35:08 +0100 Subject: [erlang-bugs] FW: Bug in Erlang/OTP 17 [RELEASE CANDIDATE 1] In-Reply-To: References: <58912684E2630B45963406CF7D8C52581C35DD0B@ESESSMB103.ericsson.se> <53077E05.7030009@erlang.org> Message-ID: <53078E4C.1090202@cs.ntua.gr> On 02/21/2014 06:22 PM, Joe Armstrong wrote: > It's not nice to find you can't recompile ten year old code ... I disagree. I think it's a very nice sign! If nothing else, it goes to show you that (unlike your code) language development has not stalled... Cheers, Kostis From essen@REDACTED Fri Feb 21 21:05:59 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 21 Feb 2014 21:05:59 +0100 Subject: [erlang-bugs] ssl:negotiated_next_protocol/1 client bug? In-Reply-To: <52176F75.7060004@ericsson.com> References: <5215C8CC.4010200@ninenines.eu> <52176F75.7060004@ericsson.com> Message-ID: <5307B1A7.6080501@ninenines.eu> Hello, Do you have any update on this? Twitter doesn't work at all anymore with the SPDY client because it seems that it just picks the first protocol in its list of available protocols and for Twitter that's an HTTP/2.0 draft... Any chance NPN can be fixed for R17? (Or did I miss something perhaps?) Thanks. On 08/23/2013 04:19 PM, Ingela Anderton Andin wrote: > Hi Loic! > > > Lo?c Hoguin wrote: >> Hello, >> >> I can't get ssl:negotiated_next_protocol/1 to work from the client >> side. As a result I can't really know what protocol to use once the >> connection is established. >> >> Example: >> >> 1> ssl:start(). >> ok >> 2> {ok, S} = ssl:connect("twitter.com", 443, [binary, {active, false}, >> {client_preferred_next_protocols, client, [<<"spdy/3">>, >> <<"http/1.1">>], <<"http/1.1">>}]). >> {ok,{sslsocket,{gen_tcp,#Port<0.1088>},<0.52.0>}} >> 3> ssl:negotiated_next_protocol(S). >> {error,next_protocol_not_negotiated} >> >> It says that the protocol hasn't been negotiated. But it actually has >> been as can be demonstrated below. >> >> 4> ssl:send(S, [<<128,3,0,1,1,0,0,81,0,0,0,1,0,0,0,0,0,0>>, >> 4> >> [<<120,187,227,198,167,194,2,101,37,80,122,180,66,164,90,119,215,16,176,72, >> >> 4> >> 49,176,236,203,5,23,144,25,37,37,5,160,244,203,106,5,45,54,184,75,202,51, >> 4> >> 75,128,113,163,151,12,46,77,88,173,10,18,193,229,24,163,62,40,65,91,97, >> 4> 73,220,0,0,0,0,255,255>>]]). >> ok >> 5> ssl:recv(S, 0). >> {ok,<<128,3,0,4,0,0,0,12,0,0,0,1,0,0,0,4,0,0,0,100>>} >> >> This is SPDY working just fine. >> >> The same can be done against an Erlang server that uses >> ssl:negotiated_next_protocol/1 where it works, it only fails on the >> client side. >> >> Bug? >> > > Sounds like it, but I have not had time to check yet. I will as soon as > possible but I am a little busy at the moment. > > > Ingela Erlang OTP/Team - Ericsson AB > -- Lo?c Hoguin http://ninenines.eu From jugg@REDACTED Sat Feb 22 06:28:34 2014 From: jugg@REDACTED (chris) Date: Fri, 21 Feb 2014 21:28:34 -0800 Subject: [erlang-bugs] Revert commit 6189bc07 In-Reply-To: <52FDDDBE.10601@ericsson.com> References: , <52FDDDBE.10601@ericsson.com> Message-ID: > Date: Fri, 14 Feb 2014 10:11:26 +0100 > From: Ingela.Anderton.Andin@REDACTED > Subject: Re: [erlang-bugs] Revert commit 6189bc07 > > Hi! > > We will look into that, the commit was an attempt to improve the > utilization factor of pipelining. Here is the feedback from an open > source user that led us to to do this: > > "The design of httpc_manager/_handler, wherein sessions are (a) > committed to the DB asynchronously, and (b) not committed until a > request is complete, results in max_sessions being grossly violated when > many requests are made in rapid succession. This makes max_sessions, > and pipelining in general, nearly worthless -- rapid requests are > exactly the situation you want pipelining for!" It is not possible to know whether pipelining or keep-alive connections are supported by the server until the first response from the server is received.? To be optimistic about this (since one can assume a client may know that the server actually does support such beforehand) then I could understand an option to force reusing an existing handler before the first response is received, but generally application code just deals with this by making a single request successfully before pipelining subsequent requests.? The original httpc code supported that methodology. I also expect some tweaking of options to have helped with the issue from the above feedback - increasing the value of max pipeline length option would have been a start for them.? But I also think that providing a max_connections option for preventing httpc from opening further non-persistent connections when max_sessions is hit would also be another approach. > The thought was that the retry mechanism could allow us to have a more > optimistic approach to improve utilization maybe it was a bad > assumption. We will see what we can do about it. Ok.? There may be something to address for looking up a session for subsequent pipeline requests after the initial one has been processed and set up, but that is not what this commit is doing. In any case, if the commit won't be reverted (though it really should be), here are a couple of bugs that need fixed that it introduced: The handler state session field is left uninitialized, resulting in crashes on subsequent requests before the first request response is handled and the state session field becomes initialized.? The Session created in the manager needs to be passed to the newly created handler as part of the init call, so it is part of the initial state. In the manager, since sessions are inserted for every request now (ugh) keep-alive requests certainly should not try to use a session that is not actually persistent.? But assuming we are being optimistic for non-retry pipeline requests only, then this needs fixed for keep-alive types in the manager's select_session - ie the Pattern should force persistent = true for keep-alive as well. Regards, Chris > Regards Ingela Erlang/OTP Team - Ericsson AB > > > On 02/07/2014 06:47 PM, chris wrote: >> Hello, >> >> The commit 6189bc07 "inets: httpc improve pipelining" needs to be reverted. >> >> It introduces a crashing bug into the http client by inserting a session prior to a connection even being established, which will cause subsequent requests to crash that attempt to reuse that session. >> >> In httpc_manager:start_handler/2, the session must not be inserted at that point, as there may not yet, nor ever be, a valid connection. >> >> In the httpc_handler:handle_response(#state{status = new} = State) call chain from where the original call to insert_session was removed from httpc_handler:try_to_enable_pipeline_or_keep_alive, is actually where the session should be inserted. >> >> From the test case modification in that commit, it looks like the motivation was to get rid of a sleep(4000). But out of the entire commit, what actually caused the ability to remove the sleep from the test, was simply that every session was now marked as 'available' (renamed 'persistent' in that commit) as soon as the request received a response, if the request established a persistent connection. >> >> In other words, a one line code change to the original httpc_handler:try_to_enable_pipeline_or_keep_alive (renamed to httpc_handler:check_persistent and broken) could have had the same result - by always setting the 'available' session field to true for persistent connections. Which would end up being for all stored sessions, as only persistent connections should have stored sessions anyway. So given that, I question whether the result of such a modifictation is actually the proper thing to do, or whether the original code had its reasons for not making all persistent connections available until later in their life cycle. >> >> In general the entire commit was ill-conceived, and introduces other subtle bugs as well. >> >> Please revert the commit, as previously functional production code running for years against R16B02 and earlier releases is now crashing under R16B03(-1). >> >> Regards, >> >> Chris From rabbe.fogelholm@REDACTED Mon Feb 24 11:50:03 2014 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Mon, 24 Feb 2014 11:50:03 +0100 Subject: [erlang-bugs] Missing hyperlink for timer(3)? In-Reply-To: References: , <52FDDDBE.10601@ericsson.com> Message-ID: <530B23DB.6000408@ericsson.com> In the OTP documentation, on the page http://www.erlang.org/doc/man/kernel_app.html , there is the following text, Starts the timer_server if the parameter is true (see timer(3)). On the same page, a little further down, there is a "See also" with many hyperlinks. Perhaps there should be one for timer(3)? BR, Rabbe Fogelholm http://gp.internal.ericsson.com/?x500uid=ERARAFO From daniel.goertzen@REDACTED Mon Feb 24 23:57:21 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 24 Feb 2014 16:57:21 -0600 Subject: [erlang-bugs] snmp agent inform w/AES privacy not working Message-ID: I am struggling to get SNMP informs with AES privacy working. I have no problems with DES privacy on informs. In snmpa_usm.erl I see that the *local engine* boots and time is passed to snmp_usm:aes_encrypt() which forms part of the IV.... However RFC 3826 states that the *authoritative* engine boots and time should be used, and in the case of informs the authoritative engine is the inform target engine, not the local engine.... [from RFC 3826] 3.1.2.1. AES Encryption Key and IV The first 128 bits of the localized key Kul are used as the AES encryption key. The 128-bit IV is obtained as the concatenation of the authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP engine's 32-bit snmpEngineTime, and a local 64-bit integer. The 64- bit integer is initialized to a pseudo-random value at boot time. Could this be why AES privacy is not working for informs? Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.norell@REDACTED Tue Feb 25 08:30:17 2014 From: ulf.norell@REDACTED (Ulf Norell) Date: Tue, 25 Feb 2014 08:30:17 +0100 Subject: [erlang-bugs] Internal error in beam_except Message-ID: The following module causes an internal error in beam_except when trying to compile it: -module(compiler_bug). f(X) -> a = {X + 1}. Both R15 and R16 exhibits the problem. Here's the error: compiler_bug.erl: internal error in beam_except; crash reason: {{case_clause, {'EXIT', {{badmatch, [{set,[],[], {line,[{location,"compiler_bug.erl",3}]}}, {set, [{x,0}], [{x,0},{integer,1}], {alloc,1,{gc_bif,'+',{f,0}}}}, {set,[],[],{alloc,1,{nozero,nostack,5,[]}}}, {set,[{x,1}],[],{put_tuple,1}}, {set,[],[{x,0}],put}]}, [{beam_except,fix_block,2, [{file,"beam_except.erl"},{line,135}]}, {beam_except,translate_exception,4, [{file,"beam_except.erl"},{line,125}]}, {beam_except,dig_out,2, [{file,"beam_except.erl"},{line,95}]}, {beam_except,translate_1,5, [{file,"beam_except.erl"},{line,75}]}, {beam_except,function,1, [{file,"beam_except.erl"},{line,41}]}, {beam_except,'-module/2-lc$^0/1-0-',1, [{file,"beam_except.erl"},{line,36}]}, {beam_except,module,2, [{file,"beam_except.erl"},{line,36}]}, {compile,'-select_passes/2-anonymous-2-',2, [{file,"compile.erl"},{line,477}]}]}}}, [{compile,'-select_passes/2-anonymous-2-',2, [{file,"compile.erl"},{line,477}]}, {compile,'-internal_comp/4-anonymous-1-',2, [{file,"compile.erl"},{line,277}]}, {compile,fold_comp,3,[{file,"compile.erl"},{line,295}]}, {compile,internal_comp,4,[{file,"compile.erl"},{line,279}]}, {compile,'-do_compile/2-anonymous-0-',2, [{file,"compile.erl"},{line,153}]}]} / Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Tue Feb 25 18:56:32 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Tue, 25 Feb 2014 11:56:32 -0600 Subject: [erlang-bugs] snmp agent inform w/AES privacy not working In-Reply-To: References: Message-ID: The SNMP agent AES initialization vector calculation is definitely wrong. The IV is composed from the authoritative engine boots, engine time, and a random locally generated number. The agent is currently always using the *local* engine to get engine boots and engine time, which happens to be correct for GET, SET, and TRAP, but is wrong for INFORM. The attached patch fixes it. When composing a packet for transmission, the existing code collects the correct engine parameters, so this patch just uses those for the AES IV instead of going off and getting the wrong local engine params. The patch looks bigger than it really is because the order of packet composition had to be changed slightly. With this patch applied, I am able to send AES encrypted informs. AES encrypted traps also continued to work. Cheers, Dan. On Mon, Feb 24, 2014 at 4:57 PM, Daniel Goertzen wrote: > I am struggling to get SNMP informs with AES privacy working. I have no > problems with DES privacy on informs. > > In snmpa_usm.erl I see that the *local engine* boots and time is passed to > snmp_usm:aes_encrypt() which forms part of the IV.... > > > > However RFC 3826 states that the *authoritative* engine boots and time > should be used, and in the case of informs the authoritative engine is the > inform target engine, not the local engine.... > > [from RFC 3826] > > 3.1.2.1. AES Encryption Key and IV > > The first 128 bits of the localized key Kul are used as the AES > encryption key. The 128-bit IV is obtained as the concatenation of > the authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP > engine's 32-bit snmpEngineTime, and a local 64-bit integer. The 64- > bit integer is initialized to a pseudo-random value at boot time. > > > > Could this be why AES privacy is not working for informs? > > Dan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snmp_agent_aes_bootstime_fix.patch Type: text/x-patch Size: 5007 bytes Desc: not available URL: From tuncer.ayaz@REDACTED Tue Feb 25 20:38:17 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 25 Feb 2014 20:38:17 +0100 Subject: [erlang-bugs] utils/make_compiler_flags error Message-ID: Does anybody else see the following error when building a fresh otp.git master (98776a4) tree? can't open x86_64-unknown-linux-gnu/opt/plain/erl_compile_flags.h for writing at utils/make_compiler_flags line 65. From vinoski@REDACTED Tue Feb 25 21:06:00 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 25 Feb 2014 15:06:00 -0500 Subject: [erlang-bugs] utils/make_compiler_flags error In-Reply-To: References: Message-ID: On Tue, Feb 25, 2014 at 2:38 PM, Tuncer Ayaz wrote: > Does anybody else see the following error when building a fresh > otp.git master (98776a4) tree? > > can't open x86_64-unknown-linux-gnu/opt/plain/erl_compile_flags.h for > writing at utils/make_compiler_flags line 65. > Yes. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Wed Feb 26 10:56:34 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 26 Feb 2014 10:56:34 +0100 Subject: [erlang-bugs] Internal error in beam_except In-Reply-To: References: Message-ID: On Tue, Feb 25, 2014 at 8:30 AM, Ulf Norell wrote: > The following module causes an internal error in beam_except when trying to > compile it: > > > -module(compiler_bug). > > f(X) -> a = {X + 1}. > > > Both R15 and R16 exhibits the problem. Here's the error: Thanks! The bug has already been fixed in master, and in OTP 17.0-rc1. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bjorn@REDACTED Wed Feb 26 12:36:54 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 26 Feb 2014 12:36:54 +0100 Subject: [erlang-bugs] utils/make_compiler_flags error In-Reply-To: References: Message-ID: On Tue, Feb 25, 2014 at 8:38 PM, Tuncer Ayaz wrote: > Does anybody else see the following error when building a fresh > otp.git master (98776a4) tree? > > can't open x86_64-unknown-linux-gnu/opt/plain/erl_compile_flags.h for > writing at utils/make_compiler_flags line 65. Thanks for noticing this! As far as I can tell, this annoying error message is harmless. The script is executed everytime the Makefile is run, and the first time the directories have not been created yet, so it fails. The second time the Makefile is run (when doing the actual build), the script will succeed silently. It is too late for the rc2 release, but we will try to fix for the final 17.0 release. If anyone wants to fix it, patches are welcome. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Wed Feb 26 13:26:12 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 26 Feb 2014 13:26:12 +0100 Subject: [erlang-bugs] utils/make_compiler_flags error In-Reply-To: References: Message-ID: <2FE8322F-CADD-4589-B6F2-826D50279048@gmail.com> That bug was already reported and Lukas Larsson had written a fix: https://github.com/garazdawi/otp/tree/lukas/erts/make_deps_fixes Regards, -- Anthony Ramine Le 26 f?vr. 2014 ? 12:36, Bj?rn Gustavsson a ?crit : > On Tue, Feb 25, 2014 at 8:38 PM, Tuncer Ayaz wrote: >> Does anybody else see the following error when building a fresh >> otp.git master (98776a4) tree? >> >> can't open x86_64-unknown-linux-gnu/opt/plain/erl_compile_flags.h for >> writing at utils/make_compiler_flags line 65. > > Thanks for noticing this! > > As far as I can tell, this annoying error message is harmless. > The script is executed everytime the Makefile is run, and the first > time the directories have not been created yet, so it fails. The second > time the Makefile is run (when doing the actual build), the script will > succeed silently. > > It is too late for the rc2 release, but we will try to fix for the > final 17.0 release. > > If anyone wants to fix it, patches are welcome. > > /Bjorn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From tuncer.ayaz@REDACTED Wed Feb 26 19:31:35 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 26 Feb 2014 19:31:35 +0100 Subject: [erlang-bugs] (unconditional) rebuild caused by gen_git_version In-Reply-To: <53048D97.6000301@erlang.org> References: <53048D97.6000301@erlang.org> Message-ID: On Wed, Feb 19, 2014 at 11:55 AM, Lukas Larsson wrote: > Hello, > > When implementing this I noticed it as well and tried to do something about > it. Alas it proved quite difficult and I had to settle on a compromise where > it does a rebuild once. i.e. > > commit change > make > LD > make > LD > make > make > make > make With GNU Make 4.0, gcc 4.8.2, and binutils 2.24: # unmodified tree since last build make LD make LD make LD make LD make LD make LD > At least that is the way it works for me on Ubuntu Linux. > > If someone else feels like having a go at making it work they are most > welcome. > > Lukas > > > On 18/02/14 18:53, Tuncer Ayaz wrote: >> >> On Tue, Feb 18, 2014 at 1:40 PM, Tuncer Ayaz wrote: >>> >>> Since R16 it's not possible anymore to quickly run make in a >>> previously built and otherwise unmodified tree. >>> >>> $ make >>> # everything built >>> # run make again >>> $ make >>> ... >>> GEN x86_64-unknown-linux-gnu/gen_git_version.mk >>> CC obj/x86_64-unknown-linux-gnu/opt/plain/erl_bif_info.o >>> .. >>> LD /tmp/otp/master/bin/x86_64-unknown-linux-gnu/beam >>> >>> This doesn't take long, but recreating an object file and relinking >>> the vm every time doesn't seem right to me. AFAICT, it was introduced >>> to include the git revision of the tree the vm was built from. >>> >>> I don't have time to look into this right now, so no patch from me. >> >> If anyone wants to submit a fix, presumably adding a check that >> compares the previous build's git revision for inequality should fix >> the bug. I assume it's probably already cached in a file. >> _______________________________________________ >> 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 sbobroff@REDACTED Fri Feb 28 04:14:55 2014 From: sbobroff@REDACTED (Sam Bobroff) Date: Fri, 28 Feb 2014 03:14:55 +0000 Subject: [erlang-bugs] qlc incorrect results from simple query Message-ID: <3D949925692E3A429DEFDEECDA1DDB91A10BB58F@SVLITMX02.shoretel.com> Hey all, It appears that QLC is returning incorrect results for a fairly simple usage of ?and? and ?or?, as shown below: $ cat bug.erl -module(bug). -export([start/0]). -include_lib("stdlib/include/qlc.hrl"). -record(r, { k, v }). start() -> T = ets:new(r, [{keypos, 2}]), L = [#r{k=1, v=a}, #r{k=2, v=b}, #r{k=3, v=c}], ets:insert(T, L), io:fwrite("QLC ~p\n", [ qlc:e(qlc:q([R || R <- ets:table(T), (R#r.k =:= 1) or ((R#r.k =:= 2) and (R#r.v =:= a))])) ]), io:fwrite("List ~p\n", [ [R || R <- L, (R#r.k =:= 1) or ((R#r.k =:= 2) and (R#r.v =:= a))] ]). $ erlc bug.erl $ erl -noshell -run bug -run init stop QLC [{r,1,a},{r,2,b}] List [{r,1,a}] $ This seems to occur on at least R16B01, R16B03 and 17.0-rc1. Cheers, Sam. ? templateclass C{Ca;Cb;};Cc; ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. From kenji@REDACTED Fri Feb 28 06:14:25 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Fri, 28 Feb 2014 14:14:25 +0900 Subject: [erlang-bugs] Unstated limits of random:uniform/1 In-Reply-To: <52FA4196.8010808@gmail.com> References: <52FA37FD.4000300@cs.ntua.gr> <52FA4196.8010808@gmail.com> Message-ID: <20140228051425.GA39493@k2r.org> random:uniform/1 is defined as (in lib/stdlib/src/random.erl) uniform(N) when is_integer(N), N >= 1 -> trunc(uniform() * N) + 1. random:uniform/0 is within [0, 1), and is an IEEE 754 double precision float, which only has 53 significand bits. So giving anything larger than 2^53 to N will give no additional meaningful resolution other than the 53 MSBs of the result. And as in ++> Michael Truog [2014-02-11 07:28:22 -0800]: > 27817185604309 == 30269 * 30307 * 30323 is the highest N should ever be, otherwise the result is garbage. the output resolution is slightly less than 2^45 (27817185604309 = ~ 2^(44.66)). I wonder, however, how many of the bits in random:uniform/0 really has the meaningful randomness, since it is a simple multiplying congruential generator. Should N be allowed as high as 2^44? I don't think so. Reference: B. A. Wichmann and I. D. Hill, Algorithm AS 183: An Efficient and Portable Pseudo-Random Number Generator, Journal of the Royal Statistical Society. Series C (Applied Statistics), Vol. 31, No. 2 (1982), pp. 188-190. Kenji Rikitake > On 02/11/2014 06:47 AM, Kostis Sagonas wrote: > > The documentation of random:uniform/1 reads: > > > > uniform(N) -> integer() >= 1 > > > > Types: > > > > N = integer() >= 1 > > > > Given an integer N >= 1, uniform/1 returns a random integer uniformly distributed between 1 and N, updating the state in the process dictionary. > > > > and from it a (naive?) Erlang programmer would assume that it works for Erlang integers. However, apparently there is an (unstated) upper limit. > > > > ======================================================================== > > Eshell V6.0 (abort with ^G) > > 1> random:uniform(1 bsl 42). > > 1950905779137 > > 2> random:uniform(1 bsl 1023). > > 64990220693815292632299777453770053245701880982584490305757715776780176648584151835529728245903303858071465265235635364507930685677056366431569479144084789774752709050314473717035731429737215919311815680621634352115003928201262448305879457258028874562676857884269587024825648343920396535221283000212783104001 > > 3> random:uniform(1 bsl 1024). > > ** exception error: an error occurred when evaluating an arithmetic expression > > in function random:uniform/1 > > in call from erl_eval:do_apply/6 > > in call from shell:exprs/7 > > in call from shell:eval_exprs/7 > > in call from shell:eval_loop/3 > > in call from prim_file:set_cwd/2 > > ======================================================================== > > > > Minimally, the published documentation (and the types of all functions of this module) has to be updated to explicitly mention this limit. > > > > Ideally, the implementation has to change to avoid use of floats when manipulating Erlang integers. IMO, it does not really have to do this and result in crashes like that. > > > > Kostis From mjtruog@REDACTED Fri Feb 28 07:25:10 2014 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 27 Feb 2014 22:25:10 -0800 Subject: [erlang-bugs] Unstated limits of random:uniform/1 In-Reply-To: <20140228051425.GA39493@k2r.org> References: <52FA37FD.4000300@cs.ntua.gr> <52FA4196.8010808@gmail.com> <20140228051425.GA39493@k2r.org> Message-ID: <53102BC6.6070501@gmail.com> Python code comments claim to have 27814431486575 as the max value to be expected from the Wichmann-Hill 1982 generator (http://svn.python.org/projects/python/trunk/Lib/random.py). They also make the same mistake with floating point numbers and they do not enforce the max random number, so they have the same problem. However, based on the algorithm and anywhere else its limitation is mentioned, the max value is 27817185604309 as mentioned previously in the email thread. The random numbers are low-quality (repeats every 2.78e13). However, they are using less than 27 bits for some of the operations, so they are at least using real integers underneath for some of the operations in the random module Erlang code. So, for quick Erlang random numbers where a 2.78e13 period is sufficient, using the random module is best (avoiding the crypto port driver), assuming you only need 44 bits or less. When I last dug into crypto its period is different based on how OpenSSL is configured, and it is difficult to determine based on the source code. So, my numbers are probably wrong, but what I have is: "crypto:strong_rand_bytes/1 repeats in the same way as RAND_bytes within OpenSSL. crypto:rand_bytes/1 repeats in the same way as RAND_pseudo_bytes within OpenSSL. if OpenSSL is configured to use the MD PRNG (default) with SHA1 (in openssl/crypto/rand/md_rand.c), the collisions are between 2^80 and 2^51 (http://eprint.iacr.org/2008/469.pdf). So, that means "weak" would repeat ideally every 1.21e24 and at worst every 2.25e15. if OpenSSL was compiled in FIPS mode, it uses ANSI X9.31 RNG and would have collisions based on 3DES.". OpenSSL should have more generation options now (I looked into this in July of 2012). The worst (period) performance of SHA1 made me learn to like the random module for things that don't deserve the use of crypto/OpenSSL, due to the port driver usage (2.78e13 is relatively close to 2.25e15). I would love it if someone could find a reference for how dependable the OpenSSL random numbers really are, since there should be many. I wish we could have a guard enforce the limit in the random module to avoid its abuse. However, other programming languages have made this mistake with the 1982 generator (at least Python). We also seem to need crypto to give us a floating point number, with code similar to what is below: strong_float() -> % 53 bits maximum for double precision floating point representation Bytes = 7, % erlang:round(53.0 / 8), % bytes for random number MaxRand = 72057594037927940, % math:pow(2, 7 * 8) - 1, % max random number binary:decode_unsigned(crypto:strong_rand_bytes(Bytes)) / MaxRand. part of the reason I created https://github.com/okeuday/quickrand is to avoid these problems On 02/27/2014 09:14 PM, Kenji Rikitake wrote: > random:uniform/1 is defined as (in lib/stdlib/src/random.erl) > > uniform(N) when is_integer(N), N >= 1 -> trunc(uniform() * N) + 1. > > random:uniform/0 is within [0, 1), and is an IEEE 754 double precision > float, which only has 53 significand bits. So giving anything larger > than 2^53 to N will give no additional meaningful resolution other > than the 53 MSBs of the result. > > And as in > > ++> Michael Truog [2014-02-11 07:28:22 -0800]: >> 27817185604309 == 30269 * 30307 * 30323 is the highest N should ever be, otherwise the result is garbage. > the output resolution is slightly less than 2^45 (27817185604309 = ~ > 2^(44.66)). > > I wonder, however, how many of the bits in random:uniform/0 really has > the meaningful randomness, since it is a simple multiplying > congruential generator. Should N be allowed as high as 2^44? I don't > think so. > > Reference: > > B. A. Wichmann and I. D. Hill, > Algorithm AS 183: An Efficient and Portable Pseudo-Random Number > Generator, > Journal of the Royal Statistical Society. Series C (Applied > Statistics), Vol. 31, No. 2 (1982), pp. 188-190. > > Kenji Rikitake > >> On 02/11/2014 06:47 AM, Kostis Sagonas wrote: >>> The documentation of random:uniform/1 reads: >>> >>> uniform(N) -> integer() >= 1 >>> >>> Types: >>> >>> N = integer() >= 1 >>> >>> Given an integer N >= 1, uniform/1 returns a random integer uniformly distributed between 1 and N, updating the state in the process dictionary. >>> >>> and from it a (naive?) Erlang programmer would assume that it works for Erlang integers. However, apparently there is an (unstated) upper limit. >>> >>> ======================================================================== >>> Eshell V6.0 (abort with ^G) >>> 1> random:uniform(1 bsl 42). >>> 1950905779137 >>> 2> random:uniform(1 bsl 1023). >>> 64990220693815292632299777453770053245701880982584490305757715776780176648584151835529728245903303858071465265235635364507930685677056366431569479144084789774752709050314473717035731429737215919311815680621634352115003928201262448305879457258028874562676857884269587024825648343920396535221283000212783104001 >>> 3> random:uniform(1 bsl 1024). >>> ** exception error: an error occurred when evaluating an arithmetic expression >>> in function random:uniform/1 >>> in call from erl_eval:do_apply/6 >>> in call from shell:exprs/7 >>> in call from shell:eval_exprs/7 >>> in call from shell:eval_loop/3 >>> in call from prim_file:set_cwd/2 >>> ======================================================================== >>> >>> Minimally, the published documentation (and the types of all functions of this module) has to be updated to explicitly mention this limit. >>> >>> Ideally, the implementation has to change to avoid use of floats when manipulating Erlang integers. IMO, it does not really have to do this and result in crashes like that. >>> >>> Kostis From lukas@REDACTED Fri Feb 28 12:16:31 2014 From: lukas@REDACTED (Lukas Larsson) Date: Fri, 28 Feb 2014 12:16:31 +0100 Subject: [erlang-bugs] utils/make_compiler_flags error In-Reply-To: <2FE8322F-CADD-4589-B6F2-826D50279048@gmail.com> References: <2FE8322F-CADD-4589-B6F2-826D50279048@gmail.com> Message-ID: <5310700F.4000306@erlang.org> On 26/02/14 13:26, Anthony Ramine wrote: > That bug was already reported and Lukas Larsson had written a fix: > > https://github.com/garazdawi/otp/tree/lukas/erts/make_deps_fixes > > Regards, > Hmm, seems like I forgot to merge that... will fix for 17.0 release. Lukas From egil@REDACTED Fri Feb 28 12:19:19 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 28 Feb 2014 12:19:19 +0100 Subject: [erlang-bugs] utils/make_compiler_flags error In-Reply-To: <5310700F.4000306@erlang.org> References: <2FE8322F-CADD-4589-B6F2-826D50279048@gmail.com> <5310700F.4000306@erlang.org> Message-ID: <531070B7.70300@erlang.org> On 2014-02-28 12:16, Lukas Larsson wrote: > On 26/02/14 13:26, Anthony Ramine wrote: >> That bug was already reported and Lukas Larsson had written a fix: >> >> https://github.com/garazdawi/otp/tree/lukas/erts/make_deps_fixes >> >> Regards, >> > > Hmm, seems like I forgot to merge that... will fix for 17.0 release. ^^ I see my point from our retrospective is shining brightly. =) > > Lukas > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From hans.bolinder@REDACTED Fri Feb 28 12:31:25 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Fri, 28 Feb 2014 11:31:25 +0000 Subject: [erlang-bugs] qlc incorrect results from simple query In-Reply-To: <3D949925692E3A429DEFDEECDA1DDB91A10BB58F@SVLITMX02.shoretel.com> References: <3D949925692E3A429DEFDEECDA1DDB91A10BB58F@SVLITMX02.shoretel.com> Message-ID: <56466BD70414EA48969B4064696CF28C037B21A0@ESESSMB207.ericsson.se> Hi, [Sam Bobroff:] > It appears that QLC is returning incorrect results for a fairly simple usage of ?and? and ?or?, > as shown below: Thanks for the bug report. There will be a fix in Erlang/OTP 17.0. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From ulf.norell@REDACTED Fri Feb 28 14:05:33 2014 From: ulf.norell@REDACTED (Ulf Norell) Date: Fri, 28 Feb 2014 14:05:33 +0100 Subject: [erlang-bugs] More compiler errors Message-ID: I ran some more quickcheck tests and found a few more bugs. These are all tested on R17-rc1: -module(bug1). f() when erlang:'andalso'(true, true) -> ok. -module(bug2). f(X) when erlang:'and'(bad, X) -> ok. -module(bug3). f(Rec, Tag) -> erlang:is_record(Rec, Tag, 1) orelse error. -module(bug4). f(_) -> (fun f/1)(). Output: $ erl Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> c(bug1). Function: f/0 bug1.erl: internal error in v3_codegen; crash reason: {case_clause,{'EXIT',{{badmatch,{remote,{atom,erlang},{atom,'andalso'}}}, [{v3_codegen,call_cg,7, [{file,"v3_codegen.erl"},{line,1105}]}, {v3_codegen,guard_cg,5, [{file,"v3_codegen.erl"},{line,1002}]}, {v3_codegen,'-guard_cg_list/6-anonymous-0-',4, [{file,"v3_codegen.erl"},{line,1045}]}, {v3_codegen,flatmapfoldl,3, [{file,"v3_codegen.erl"},{line,2222}]}, {v3_codegen,guard_cg_list,6, [{file,"v3_codegen.erl"},{line,1043}]}, {v3_codegen,protected_cg,7, [{file,"v3_codegen.erl"},{line,1015}]}, {v3_codegen,guard_clause_cg,4, [{file,"v3_codegen.erl"},{line,982}]}, {v3_codegen,match_cg,5, [{file,"v3_codegen.erl"},{line,282}]}]}}} in function compile:'-select_passes/2-anonymous-2-'/2 (compile.erl, line 494) in call from compile:'-internal_comp/4-anonymous-1-'/2 (compile.erl, line 290) in call from compile:fold_comp/3 (compile.erl, line 308) in call from compile:internal_comp/4 (compile.erl, line 292) in call from compile:'-do_compile/2-anonymous-0-'/2 (compile.erl, line 153) bug1.erl:2: Warning: function f/0 is unused error 2> c(bug2). Function: f/1 bug2.erl: internal error in beam_bool; crash reason: {case_clause, {'EXIT', {function_clause, [{beam_bool,bopt_cg, [{atom,bad}, 5, [{0,{x,0}}], [], {st,100000000, {3, {2, [{block, [{set, [{x,1}], [{atom,bad},{x,0}], {bif,'and',{f,5}}}]}, {test,is_eq_exact,{f,5},[{x,1},{atom,true}]}, {block,[{set,[{x,0}],[{atom,ok}],move}]}, return, {label,5}, {jump,{f,1}}, return], {1, [{line,[{location,"bug2.erl",3}]}, {func_info,{atom,bug2},{atom,f},1}, {label,2}, {block, [{set, [{x,1}], [{atom,bad},{x,0}], {bif,'and',{f,5}}}]}, {test,is_eq_exact,{f,5},[{x,1},{atom,true}]}, {block,[{set,[{x,0}],[{atom,ok}],move}]}, return, {label,5}, {jump,{f,1}}, return], nil,nil}, {5,[{jump,{f,1}},return],nil,nil}}}}], [{file,"beam_bool.erl"},{line,505}]}, {beam_bool,bopt_cg_and,5,[{file,"beam_bool.erl"},{line,552}]}, {beam_bool,bopt_block,5,[{file,"beam_bool.erl"},{line,115}]}, {beam_bool,bopt,3,[{file,"beam_bool.erl"},{line,76}]}, {beam_bool,function,2,[{file,"beam_bool.erl"},{line,57}]}, {lists,mapfoldl,3,[{file,"lists.erl"},{line,1339}]}, {beam_bool,module,2,[{file,"beam_bool.erl"},{line,36}]}, {compile,'-select_passes/2-anonymous-2-',2, [{file,"compile.erl"},{line,494}]}]}}} in function io_lib_pretty:cind_tag_tuple/7 (io_lib_pretty.erl, line 636) in call from io_lib_pretty:cind_element/7 (io_lib_pretty.erl, line 725) in call from io_lib_pretty:cind_list/7 (io_lib_pretty.erl, line 695) in call from io_lib_pretty:cind_element/7 (io_lib_pretty.erl, line 725) in call from io_lib_pretty:cind_list/7 (io_lib_pretty.erl, line 695) in call from io_lib_pretty:cind_element/7 (io_lib_pretty.erl, line 725) in call from io_lib_pretty:cind_list/7 (io_lib_pretty.erl, line 695) in call from io_lib_pretty:cind_element/7 (io_lib_pretty.erl, line 725) bug2.erl:3: Warning: function f/1 is unused error 3> c(bug3). Function: f/2 bug3.erl: internal error in v3_codegen; crash reason: {case_clause,{'EXIT',{{badmatch,{remote,{atom,erlang},{atom,is_record}}}, [{v3_codegen,call_cg,7, [{file,"v3_codegen.erl"},{line,1105}]}, {v3_codegen,guard_cg,5, [{file,"v3_codegen.erl"},{line,1002}]}, {v3_codegen,'-guard_cg_list/6-anonymous-0-',4, [{file,"v3_codegen.erl"},{line,1045}]}, {v3_codegen,flatmapfoldl,3, [{file,"v3_codegen.erl"},{line,2222}]}, {v3_codegen,guard_cg_list,6, [{file,"v3_codegen.erl"},{line,1043}]}, {v3_codegen,protected_cg,7, [{file,"v3_codegen.erl"},{line,1015}]}, {v3_codegen,guard_clause_cg,4, [{file,"v3_codegen.erl"},{line,982}]}, {v3_codegen,match_cg,5, [{file,"v3_codegen.erl"},{line,282}]}]}}} in function compile:'-select_passes/2-anonymous-2-'/2 (compile.erl, line 494) in call from compile:'-internal_comp/4-anonymous-1-'/2 (compile.erl, line 290) in call from compile:fold_comp/3 (compile.erl, line 308) in call from compile:internal_comp/4 (compile.erl, line 292) in call from compile:'-do_compile/2-anonymous-0-'/2 (compile.erl, line 153) bug3.erl:2: Warning: function f/2 is unused error 4> c(bug4). Function f/1 refers to undefined label 5 bug4.erl: internal error in beam_dead; crash reason: {case_clause,{'EXIT',{undefined_label,5}}} in function compile:'-select_passes/2-anonymous-2-'/2 (compile.erl, line 494) in call from compile:'-internal_comp/4-anonymous-1-'/2 (compile.erl, line 290) in call from compile:fold_comp/3 (compile.erl, line 308) in call from compile:internal_comp/4 (compile.erl, line 292) in call from compile:'-do_compile/2-anonymous-0-'/2 (compile.erl, line 153) bug4.erl:2: Warning: function f/1 is unused error / Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Fri Feb 28 23:36:28 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 28 Feb 2014 23:36:28 +0100 Subject: [erlang-bugs] More compiler errors In-Reply-To: References: Message-ID: <53110F6C.1010202@cs.ntua.gr> On 02/28/2014 02:05 PM, Ulf Norell wrote: > I ran some more quickcheck tests and found a few more bugs. These are > all tested on R17-rc1: I am obviously only speaking for myself here, but I think there is a fine line on what is "reasonable" to expect from a compiler (and thus what can be classified as a bug) and what is not. IMO, the Erlang compiler has every right to refuse to compile code that is arguably weird, to say the least. For example, the first two programs I would not expect any sensible programmer to write, and IMO these Erlang programs should be burned in hell. (No sensible programmer would write erlang:'andalso' and I would definitely do not want to have to read code that looks like that.) If you simply change the calls from being remote calls to being operators (e.g. write "true andalso true" for the first one -- similarly for the second, although this one actually has a type error and should perhaps not be compiled anyway), the BEAM compiler happily accepts them. > -module(bug1). > f() when erlang:'andalso'(true, true) -> > ok. > > -module(bug2). > f(X) when erlang:'and'(bad, X) -> > ok. The third program is the only one that I would classify as a bug here. > -module(bug3). > f(Rec, Tag) -> > erlang:is_record(Rec, Tag, 1) orelse error. The problem exists even without the erlang: part. This should be fixed. As to this last program, IMO it's non-sensical: > -module(bug4). > f(_) -> > (fun f/1)(). The compiler has every right to throw up upon seeing code like this. Why wouldn't it? ;) Kostis