From hsvhome@REDACTED Fri Jun 3 11:33:10 2011 From: hsvhome@REDACTED (Sergey Shilov) Date: Fri, 3 Jun 2011 12:33:10 +0300 Subject: [erlang-bugs] ssl_connection crash on client connect w/o certificte Message-ID: <201106031233.10286.hsvhome@mail.ru> Hi all ! If clean Client (b.e. Cromium w/o any certificate ) requested a connection to a SSl server ( "Yaws" frontend in my case), the ssl_connection crashed with report: =CRASH REPORT==== 3-Jun-2011::00:04:10 === crasher: initial call: ssl_connection:init/1 pid: <0.127.0> registered_name: [] exception exit: {function_clause, [{ssl_connection,handle_alert, [{alert,1,41,{"./ssl_connection.erl",1632}}, certify, {state,server, {#Ref<0.0.0.265>,<0.126.0>}, ... ... ... The SSL alerts with number 41 (no certificate) is not defined in ssl_alert.hrl and not handled by any of the ssl_connection:handle_alert implementations. Maybe this is a Bug? -- V.B.R Sergey Shilov. From xazar.studio@REDACTED Mon Jun 6 08:05:35 2011 From: xazar.studio@REDACTED (][azar) Date: Mon, 6 Jun 2011 10:05:35 +0400 Subject: [erlang-bugs] Parameterized module and utf8 pattern compile error Message-ID: Hello. There is an error when i try to compile parameterized module with utf8. Example: -module(test,[Graph]). -export([test/1]). test(Input) -> <> = Input. Error: ./test.erl:none: internal error in expand_module; crash reason: {function_clause, [{sys_expand_pmod,bit_types, [[{unit,undefined},unsigned,big]]}, {sys_expand_pmod,bit_types,1}, {sys_expand_pmod,pattern_grp,2}, {sys_expand_pmod,pattern,2}, {sys_expand_pmod,expr,2}, {sys_expand_pmod,exprs,2}, {sys_expand_pmod,clause,2}, {sys_expand_pmod,clauses,2}]} -------------- next part -------------- An HTML attachment was scrubbed... URL: From igorrs@REDACTED Tue Jun 7 08:19:36 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Tue, 7 Jun 2011 03:19:36 -0300 Subject: [erlang-bugs] All keys in the same slot (Mnesia/dets) Message-ID: Hello. I was running a pool with Erlang/OTP R13B04 until the beginning of the last week, when we upgraded to R14B02. The reason we upgraded is that everyday we were experiencing a lot of corruption in Mnesia's fragments (disc_only_copies). We had Erlang processes checking the fragments periodically and, in case of problems, we would delete the fragment (mnesia:del_table_copy) and clone it again from its replica. Given that Erlang/OTP R14B01 fixed a lot of concurrency issues with dets, I believe those bugs were affecting us because we perform a lot of dirty reads, what must cause more concurrent operations in dets tables. Anyway, since the upgrade to R14B02, no corrupted fragment has been detected. :-) But then I observed that, after the upgrade, most of the servers are performing much better (spending less time in I/O operations), while some of them almost didn't change in that respect. Taking a look at Mnesia's directory in each server, I noticed that the fragment files in one table (uc) are smaller in the servers that are performing better. Example of a fragment in a "slower" server: 59M uc_frag1004.DAT Example of a fragment in a "faster" server: 34M uc_frag598.DAT Since uc is a bag, I thought it could be because uc_frag598, for example, has less records than uc_frag1004. But I copied both to my box and saw I was wrong: 1> {ok, F1004} = dets:open_file("uc_frag1004.DAT"). {ok,#Ref<0.0.0.33>} 2> {ok, F598} = dets:open_file("uc_frag598.DAT"). {ok,#Ref<0.0.0.41>} 3> dets:info(F1004, no_objects). 280105 4> dets:info(F598, no_objects). 303074 5> dets:info(F1004, no_keys). 1404 6> dets:info(F598, no_keys). 1476 The only (very) relevant difference I found between them was in the slots: 7> dets:info(F1004, no_slots). {256,1536,2097152} 8> dets:info(F598, no_slots). {524288,524288,33554432} The weirdest difference being that all records in uc_frag1004 are in the same slot! 9> length([S || S <- lists:seq(0, element(2, dets:info(F1004, no_slots)) - 1), length(dets:slot(F1004, S)) > 0]). 1 10> length([S || S <- lists:seq(0, element(2, dets:info(F598, no_slots)) - 1), length(dets:slot(F598, S)) > 0]). 489 So... what may have happened and what can I do to fix it? Thank you. Igor. -- "The secret of joy in work is contained in one word - excellence. To know how to do something well is to enjoy it." - Pearl S. Buck. From igorrs@REDACTED Tue Jun 7 09:46:14 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Tue, 7 Jun 2011 04:46:14 -0300 Subject: [erlang-bugs] All keys in the same slot (Mnesia/dets) In-Reply-To: References: Message-ID: Hum... mnesia_frag_hash and dets both use phash2, so it makes sense that the keys are poorly distributed among the slots of each dets table that is a disc_only_copies fragment. :-( I guess we'll have to deal with that somehow. However, I still don't understand why one fragment has 1536 slots and the other has 524288, in the example below. Thank you. Igor. On Tue, Jun 7, 2011 at 3:19 AM, Igor Ribeiro Sucupira wrote: > Hello. > > I was running a pool with Erlang/OTP R13B04 until the beginning of the > last week, when we upgraded to R14B02. > > The reason we upgraded is that everyday we were experiencing a lot of > corruption in Mnesia's fragments (disc_only_copies). We had Erlang > processes checking the fragments periodically and, in case of > problems, we would delete the fragment (mnesia:del_table_copy) and > clone it again from its replica. > Given that Erlang/OTP R14B01 fixed a lot of concurrency issues with > dets, I believe those bugs were affecting us because we perform a lot > of dirty reads, what must cause more concurrent operations in dets > tables. > > Anyway, since the upgrade to R14B02, no corrupted fragment has been > detected. ?:-) > > But then I observed that, after the upgrade, most of the servers are > performing much better (spending less time in I/O operations), while > some of them almost didn't change in that respect. > > Taking a look at Mnesia's directory in each server, I noticed that the > fragment files in one table (uc) are smaller in the servers that are > performing better. > > Example of a fragment in a "slower" server: > 59M ? ? uc_frag1004.DAT > > Example of a fragment in a "faster" server: > 34M ? ? uc_frag598.DAT > > Since uc is a bag, I thought it could be because uc_frag598, for > example, has less records than uc_frag1004. But I copied both to my > box and saw I was wrong: > > 1> {ok, F1004} = dets:open_file("uc_frag1004.DAT"). > {ok,#Ref<0.0.0.33>} > 2> {ok, F598} = dets:open_file("uc_frag598.DAT"). > {ok,#Ref<0.0.0.41>} > 3> dets:info(F1004, no_objects). > 280105 > 4> dets:info(F598, no_objects). > 303074 > 5> dets:info(F1004, no_keys). > 1404 > 6> dets:info(F598, no_keys). > 1476 > > The only (very) relevant difference I found between them was in the slots: > > 7> dets:info(F1004, no_slots). > {256,1536,2097152} > 8> dets:info(F598, no_slots). > {524288,524288,33554432} > > The weirdest difference being that all records in uc_frag1004 are in > the same slot! > > 9> length([S || S <- lists:seq(0, element(2, dets:info(F1004, > no_slots)) - 1), length(dets:slot(F1004, S)) > 0]). > 1 > 10> length([S || S <- lists:seq(0, element(2, dets:info(F598, > no_slots)) - 1), length(dets:slot(F598, S)) > 0]). > 489 > > > So... what may have happened and what can I do to fix it? > > Thank you. > Igor. > > -- > "The secret of joy in work is contained in one word - excellence. To > know how to do something well is to enjoy it." - Pearl S. Buck. From mjtruog@REDACTED Tue Jun 7 10:01:11 2011 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 07 Jun 2011 01:01:11 -0700 Subject: [erlang-bugs] All keys in the same slot (Mnesia/dets) In-Reply-To: References: Message-ID: <4DEDDAC7.4040304@gmail.com> Normally hash tables use prime numbers for the number of slots to avoid collisions. Could this be part of the problem here? On 06/07/2011 12:46 AM, Igor Ribeiro Sucupira wrote: > Hum... mnesia_frag_hash and dets both use phash2, so it makes sense > that the keys are poorly distributed among the slots of each dets > table that is a disc_only_copies fragment. :-( > I guess we'll have to deal with that somehow. > > However, I still don't understand why one fragment has 1536 slots and > the other has 524288, in the example below. > > Thank you. > Igor. > > On Tue, Jun 7, 2011 at 3:19 AM, Igor Ribeiro Sucupira wrote: >> Hello. >> >> I was running a pool with Erlang/OTP R13B04 until the beginning of the >> last week, when we upgraded to R14B02. >> >> The reason we upgraded is that everyday we were experiencing a lot of >> corruption in Mnesia's fragments (disc_only_copies). We had Erlang >> processes checking the fragments periodically and, in case of >> problems, we would delete the fragment (mnesia:del_table_copy) and >> clone it again from its replica. >> Given that Erlang/OTP R14B01 fixed a lot of concurrency issues with >> dets, I believe those bugs were affecting us because we perform a lot >> of dirty reads, what must cause more concurrent operations in dets >> tables. >> >> Anyway, since the upgrade to R14B02, no corrupted fragment has been >> detected. :-) >> >> But then I observed that, after the upgrade, most of the servers are >> performing much better (spending less time in I/O operations), while >> some of them almost didn't change in that respect. >> >> Taking a look at Mnesia's directory in each server, I noticed that the >> fragment files in one table (uc) are smaller in the servers that are >> performing better. >> >> Example of a fragment in a "slower" server: >> 59M uc_frag1004.DAT >> >> Example of a fragment in a "faster" server: >> 34M uc_frag598.DAT >> >> Since uc is a bag, I thought it could be because uc_frag598, for >> example, has less records than uc_frag1004. But I copied both to my >> box and saw I was wrong: >> >> 1> {ok, F1004} = dets:open_file("uc_frag1004.DAT"). >> {ok,#Ref<0.0.0.33>} >> 2> {ok, F598} = dets:open_file("uc_frag598.DAT"). >> {ok,#Ref<0.0.0.41>} >> 3> dets:info(F1004, no_objects). >> 280105 >> 4> dets:info(F598, no_objects). >> 303074 >> 5> dets:info(F1004, no_keys). >> 1404 >> 6> dets:info(F598, no_keys). >> 1476 >> >> The only (very) relevant difference I found between them was in the slots: >> >> 7> dets:info(F1004, no_slots). >> {256,1536,2097152} >> 8> dets:info(F598, no_slots). >> {524288,524288,33554432} >> >> The weirdest difference being that all records in uc_frag1004 are in >> the same slot! >> >> 9> length([S || S <- lists:seq(0, element(2, dets:info(F1004, >> no_slots)) - 1), length(dets:slot(F1004, S)) > 0]). >> 1 >> 10> length([S || S <- lists:seq(0, element(2, dets:info(F598, >> no_slots)) - 1), length(dets:slot(F598, S)) > 0]). >> 489 >> >> >> So... what may have happened and what can I do to fix it? >> >> Thank you. >> Igor. >> >> -- >> "The secret of joy in work is contained in one word - excellence. To >> know how to do something well is to enjoy it." - Pearl S. Buck. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From ess@REDACTED Tue Jun 7 10:00:52 2011 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Tue, 7 Jun 2011 10:00:52 +0200 Subject: [erlang-bugs] All keys in the same slot (Mnesia/dets) In-Reply-To: References: Message-ID: <4DEDDAB4.60604@trifork.com> Igor Ribeiro Sucupira wrote: > Hum... mnesia_frag_hash and dets both use phash2, so it makes sense > that the keys are poorly distributed among the slots of each dets > table that is a disc_only_copies fragment. :-( > I guess we'll have to deal with that somehow. > I needed two independent hash functions at some point, and noticed that phash2(X) and phash2({X}) appear to be independent. Is that a good way to achieve independent hash functions? And is it applicable in this situation? Ergards, Erik S?e S?rensen From igorrs@REDACTED Tue Jun 7 17:57:43 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Tue, 7 Jun 2011 12:57:43 -0300 Subject: [erlang-bugs] All keys in the same slot (Mnesia/dets) Message-ID: Both mnesia_frag_hash and dets use linear hashing, so I don't believe there would be any improvement in this case. Thanks. Igor. Em 07/06/2011 05:01, "Michael Truog" escreveu: -------------- next part -------------- An HTML attachment was scrubbed... URL: From igorrs@REDACTED Tue Jun 7 18:12:17 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Tue, 7 Jun 2011 13:12:17 -0300 Subject: [erlang-bugs] All keys in the same slot (Mnesia/dets) Message-ID: I know I can use another module instead of mnesia_frag_hash (and we have tables that don't use it). But it's too late now. I don't see a way to do that without much pain. The cheapest approach I can think of is to create other tables, change the code to use both versions of each table and then migrate the data. It will take a month. :-( Changing dets would be less painful, but I don't know if it's "doable". Is this pitfall with table fragmentation documented anywhere? Thanks. Igor. Em 07/06/2011 05:01, "Erik S?e S?rensen" escreveu: -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.peticolas@REDACTED Wed Jun 8 05:00:52 2011 From: dave.peticolas@REDACTED (Dave Peticolas) Date: Tue, 7 Jun 2011 20:00:52 -0700 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 Message-ID: Hello, I recently tried to build both R14B02 and 03 on my Dell Inspiron Mini (Intel Atom) running Ubuntu 8.04. I already had R14B01 running fine. I found that re:split no longer worked. I built all the versions from source. Here is an example of 01 output: Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.2 (abort with ^G) 1> re:split("abc", "b"). [<<"a">>,<<"c">>] 2> q(). ok And here is what I get on 02 (same as 03 except for the version numbers): Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> re:split("abc", "b"). ** exception error: no case clause matching {match,["b"]} in function re:run/3 called as re:run(<<"abc">>, {re_pattern,0,0, <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, [global]) in call from re:split/3 2> In case the existing build was somehow getting tangled with the new one, I tried removing the 01 build completely and rebuilding 02 and got the same results. thanks, dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From baggett.patrick@REDACTED Wed Jun 8 05:07:15 2011 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Tue, 7 Jun 2011 22:07:15 -0500 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 In-Reply-To: References: Message-ID: Not seeing it here (Win32 platform) Erlang R14B03 (erts-5.8.4) [smp:4:4] [rq:4] [async-threads:0] Eshell V5.8.4 (abort with ^G) 1> re:split("abc","b"). [<<"a">>,<<"c">>] 2> On Tue, Jun 7, 2011 at 10:00 PM, Dave Peticolas wrote: > Hello, I recently tried to build both R14B02 and 03 on my Dell Inspiron > Mini (Intel Atom) > running Ubuntu 8.04. I already had R14B01 running fine. I found that > re:split no longer > worked. I built all the versions from source. Here is an example of 01 > output: > > Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.8.2 (abort with ^G) > 1> re:split("abc", "b"). > [<<"a">>,<<"c">>] > 2> q(). > ok > > > And here is what I get on 02 (same as 03 except for the version numbers): > > Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> re:split("abc", "b"). > ** exception error: no case clause matching {match,["b"]} > in function re:run/3 > called as re:run(<<"abc">>, > {re_pattern,0,0, > > <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, > [global]) > in call from re:split/3 > 2> > > In case the existing build was somehow getting tangled with the new one, > I tried removing the 01 build completely and rebuilding 02 and got the same > results. > > thanks, > dave > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.peticolas@REDACTED Wed Jun 8 05:17:00 2011 From: dave.peticolas@REDACTED (Dave Peticolas) Date: Tue, 7 Jun 2011 20:17:00 -0700 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 In-Reply-To: References: Message-ID: I should mention it works fine on my Linux desktop as well. I'd say something was wrong with my netbook, except 01 works just fine. 2011/6/7 Patrick Baggett > Not seeing it here (Win32 platform) > > Erlang R14B03 (erts-5.8.4) [smp:4:4] [rq:4] [async-threads:0] > > Eshell V5.8.4 (abort with ^G) > 1> re:split("abc","b"). > [<<"a">>,<<"c">>] > 2> > > > > On Tue, Jun 7, 2011 at 10:00 PM, Dave Peticolas wrote: > >> Hello, I recently tried to build both R14B02 and 03 on my Dell Inspiron >> Mini (Intel Atom) >> running Ubuntu 8.04. I already had R14B01 running fine. I found that >> re:split no longer >> worked. I built all the versions from source. Here is an example of 01 >> output: >> >> Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] >> [hipe] [kernel-poll:false] >> >> Eshell V5.8.2 (abort with ^G) >> 1> re:split("abc", "b"). >> [<<"a">>,<<"c">>] >> 2> q(). >> ok >> >> >> And here is what I get on 02 (same as 03 except for the version numbers): >> >> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] >> [hipe] [kernel-poll:false] >> >> Eshell V5.8.3 (abort with ^G) >> 1> re:split("abc", "b"). >> ** exception error: no case clause matching {match,["b"]} >> in function re:run/3 >> called as re:run(<<"abc">>, >> {re_pattern,0,0, >> >> <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, >> [global]) >> in call from re:split/3 >> 2> >> >> In case the existing build was somehow getting tangled with the new one, >> I tried removing the 01 build completely and rebuilding 02 and got the >> same >> results. >> >> thanks, >> dave >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baggett.patrick@REDACTED Wed Jun 8 05:26:12 2011 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Tue, 7 Jun 2011 22:26:12 -0500 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 In-Reply-To: References: Message-ID: Maybe it is compiler options / optimizations producing wrong code? I'd make 100% sure all *.o files are gone and then retry with a debug build. Other than that, I don't know what to tell you. :\ On Tue, Jun 7, 2011 at 10:17 PM, Dave Peticolas wrote: > I should mention it works fine on my Linux desktop as well. > I'd say something was wrong with my netbook, except 01 > works just fine. > > > 2011/6/7 Patrick Baggett > >> Not seeing it here (Win32 platform) >> >> Erlang R14B03 (erts-5.8.4) [smp:4:4] [rq:4] [async-threads:0] >> >> Eshell V5.8.4 (abort with ^G) >> 1> re:split("abc","b"). >> [<<"a">>,<<"c">>] >> 2> >> >> >> >> On Tue, Jun 7, 2011 at 10:00 PM, Dave Peticolas > > wrote: >> >>> Hello, I recently tried to build both R14B02 and 03 on my Dell Inspiron >>> Mini (Intel Atom) >>> running Ubuntu 8.04. I already had R14B01 running fine. I found that >>> re:split no longer >>> worked. I built all the versions from source. Here is an example of 01 >>> output: >>> >>> Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] >>> [hipe] [kernel-poll:false] >>> >>> Eshell V5.8.2 (abort with ^G) >>> 1> re:split("abc", "b"). >>> [<<"a">>,<<"c">>] >>> 2> q(). >>> ok >>> >>> >>> And here is what I get on 02 (same as 03 except for the version numbers): >>> >>> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] >>> [hipe] [kernel-poll:false] >>> >>> Eshell V5.8.3 (abort with ^G) >>> 1> re:split("abc", "b"). >>> ** exception error: no case clause matching {match,["b"]} >>> in function re:run/3 >>> called as re:run(<<"abc">>, >>> {re_pattern,0,0, >>> >>> <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, >>> [global]) >>> in call from re:split/3 >>> 2> >>> >>> In case the existing build was somehow getting tangled with the new one, >>> I tried removing the 01 build completely and rebuilding 02 and got the >>> same >>> results. >>> >>> thanks, >>> dave >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.peticolas@REDACTED Wed Jun 8 06:30:09 2011 From: dave.peticolas@REDACTED (Dave Peticolas) Date: Tue, 7 Jun 2011 21:30:09 -0700 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 In-Reply-To: References: Message-ID: Thanks, I will give that a try. 2011/6/7 Patrick Baggett > Maybe it is compiler options / optimizations producing wrong code? I'd make > 100% sure all *.o files are gone and then retry with a debug build. Other > than that, I don't know what to tell you. :\ > > > On Tue, Jun 7, 2011 at 10:17 PM, Dave Peticolas wrote: > >> I should mention it works fine on my Linux desktop as well. >> I'd say something was wrong with my netbook, except 01 >> works just fine. >> >> >> 2011/6/7 Patrick Baggett >> >>> Not seeing it here (Win32 platform) >>> >>> Erlang R14B03 (erts-5.8.4) [smp:4:4] [rq:4] [async-threads:0] >>> >>> Eshell V5.8.4 (abort with ^G) >>> 1> re:split("abc","b"). >>> [<<"a">>,<<"c">>] >>> 2> >>> >>> >>> >>> On Tue, Jun 7, 2011 at 10:00 PM, Dave Peticolas < >>> dave.peticolas@REDACTED> wrote: >>> >>>> Hello, I recently tried to build both R14B02 and 03 on my Dell Inspiron >>>> Mini (Intel Atom) >>>> running Ubuntu 8.04. I already had R14B01 running fine. I found that >>>> re:split no longer >>>> worked. I built all the versions from source. Here is an example of 01 >>>> output: >>>> >>>> Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] >>>> [hipe] [kernel-poll:false] >>>> >>>> Eshell V5.8.2 (abort with ^G) >>>> 1> re:split("abc", "b"). >>>> [<<"a">>,<<"c">>] >>>> 2> q(). >>>> ok >>>> >>>> >>>> And here is what I get on 02 (same as 03 except for the version >>>> numbers): >>>> >>>> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] >>>> [hipe] [kernel-poll:false] >>>> >>>> Eshell V5.8.3 (abort with ^G) >>>> 1> re:split("abc", "b"). >>>> ** exception error: no case clause matching {match,["b"]} >>>> in function re:run/3 >>>> called as re:run(<<"abc">>, >>>> {re_pattern,0,0, >>>> >>>> <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, >>>> [global]) >>>> in call from re:split/3 >>>> 2> >>>> >>>> In case the existing build was somehow getting tangled with the new one, >>>> I tried removing the 01 build completely and rebuilding 02 and got the >>>> same >>>> results. >>>> >>>> thanks, >>>> dave >>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igorrs@REDACTED Wed Jun 8 21:48:01 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Wed, 8 Jun 2011 16:48:01 -0300 Subject: [erlang-bugs] All keys in the same slot (Mnesia/dets) In-Reply-To: References: Message-ID: Copying erlang-questions. BTW, I'm still trying to understand why some fragments ended up with many more slots after the upgrade I described in the original post. Is there a way to manually raise the number of slots in a dets table? I guess I'll have to do that now. Thanks. Igor. On Tue, Jun 7, 2011 at 1:12 PM, Igor Ribeiro Sucupira wrote: > > I know I can use another module instead of mnesia_frag_hash (and we have > tables that don't use it). > > But it's too late now. I don't see a way to do that without much pain. The > cheapest approach I can think of is to create other tables, change the code > to use both versions of each table and then migrate the data. It will take a > month. :-( > > Changing dets would be less painful, but I don't know if it's "doable". > > Is this pitfall with table fragmentation documented anywhere? > > Thanks. > Igor. > > Em 07/06/2011 05:01, "Erik S?e S?rensen" escreveu: > > Igor Ribeiro Sucupira wrote: > Hum... mnesia_frag_hash and dets both use phash2, so it makes sense > that the keys are poorly distributed among the slots of each dets > table that is a disc_only_copies fragment. :-( > I guess we'll have to deal with that somehow. > > > I needed two independent hash functions at some point, and noticed that phash2(X) and phash2({X}) appear to be independent. > Is that a good way to achieve independent hash functions? > And is it applicable in this situation? > > Ergards, > Erik S?e S?rensen From hans.bolinder@REDACTED Thu Jun 9 13:59:14 2011 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 9 Jun 2011 13:59:14 +0200 Subject: [erlang-bugs] All keys in the same slot (Mnesia/dets) In-Reply-To: References: Message-ID: <19952.46482.187947.878787@ornendil.otp.ericsson.se> Hi, [Igor Ribeiro Sucupira:] > The weirdest difference being that all records in uc_frag1004 are in > the same slot! > > 9> length([S || S <- lists:seq(0, element(2, dets:info(F1004, > no_slots)) - 1), length(dets:slot(F1004, S)) > 0]). > 1 If you still have the file available: How many objects are there in the slot? How many objects does a traversal of the file return? Try length(dets:match_object(F1004,'_')). If the numbers differ then the file is corrupt. > Is there a way to manually raise the number of slots in a dets table? You can try closing the file, and then force a repair: dets:open_file(T, [{min_no_slots,N},{repair,force}]). where N is some suitable integer. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From igorrs@REDACTED Thu Jun 9 20:55:47 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Thu, 9 Jun 2011 15:55:47 -0300 Subject: [erlang-bugs] All keys in the same slot (Mnesia/dets) In-Reply-To: <19952.46482.187947.878787@ornendil.otp.ericsson.se> References: <19952.46482.187947.878787@ornendil.otp.ericsson.se> Message-ID: Hello. Thank you very much (I mean it) for teaching me I can use min_no_slots together with repair. I always thought I could only use min_no_slots "when the table is created", as the docs say. Most mortals won't think that repair is such a case. :-) However, I also had to specify other non-default properties of the table ({type, bag}, for example). Otherwise, it would fail with type_mismatch. As for the other issues (I'm taking the liberty of copying Mr. Gudmundsson, who knows a lot about the internals of Mnesia)... These dets files with all keys in the same slot are not corrupt. They are just a consequence of the awful combination of table fragmentation with disc_only_copies (mnesia_frag_hash with dets, to be more precise). If a table is split in N fragments, at most 1/N of the slots in each dets fragment will be used. I have verified that this is the case for all disc_only_copies tables I have deployed. The only exception is the table that does not use mnesia_frag_hash (another module was specified as hash_module at table creation). What happened to my "uc" table (which is a bag) during the upgrade from R13B04 to R14B02 seems to have been unintended behavior from Mnesia, which ended up benefiting me. Each of the 1024 fragments in the uc table has about 300,000 objects, but only about 1,500 keys. Before the upgrade, I think (not sure) each fragment had around 1,500 slots, with all keys in the same slot (as expected). During the upgrade, for some reason, the fragments in most servers (and in their replicas) seem to have been recreated with around 500,000 slots each. This fact caused a performance improvement, since 1/1024 of the 500k slots in each fragment are being used now. I believe it was unintended, because (I think) Mnesia used the number of objects (instead of the the number of keys) as estimated_no_objects when it recreated the dets tables. I don't suppose it has bags in mind for this step. If I now pick one of the fragments that were left with around 1,500 slots and perform mnesia:change_table_copy_type to disc_copies and then back to disc_only_copies, the number of slots is increased to around 500k (Mnesia's source code gave me this tip). But I still don't understand how it happened during the restarts/repairs for the upgrade. Calling del_table_copy and add_table_copy does not increase the number of slots in the dets table (I think it's just copied from the replica "as is", the same way it happens during the restarts with all nodes in R14B02). Thanks! Igor. On Thu, Jun 9, 2011 at 8:59 AM, Hans Bolinder wrote: > Hi, > > [Igor Ribeiro Sucupira:] >> The weirdest difference being that all records in uc_frag1004 are in >> the same slot! >> >> 9> length([S || S <- lists:seq(0, element(2, dets:info(F1004, >> ? ?no_slots)) - 1), length(dets:slot(F1004, S)) > 0]). >> 1 > > If you still have the file available: How many objects are there in > the slot? How many objects does a traversal of the file return? Try > > ?length(dets:match_object(F1004,'_')). > > If the numbers differ then the file is corrupt. > >> Is there a way to manually raise the number of slots in a dets table? > > You can try closing the file, and then force a repair: > > ?dets:open_file(T, [{min_no_slots,N},{repair,force}]). > > where N is some suitable integer. > > Best regards, > > Hans Bolinder, Erlang/OTP team, Ericsson > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From dave.peticolas@REDACTED Fri Jun 10 05:19:07 2011 From: dave.peticolas@REDACTED (Dave Peticolas) Date: Thu, 9 Jun 2011 20:19:07 -0700 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 In-Reply-To: References: Message-ID: I built a debug emulator, but I'm not sure what I should do with it, other than re-run that test which produces the same failing result. 2011/6/7 Dave Peticolas > Thanks, I will give that a try. > > > 2011/6/7 Patrick Baggett > >> Maybe it is compiler options / optimizations producing wrong code? I'd >> make 100% sure all *.o files are gone and then retry with a debug build. >> Other than that, I don't know what to tell you. :\ >> >> >> On Tue, Jun 7, 2011 at 10:17 PM, Dave Peticolas > > wrote: >> >>> I should mention it works fine on my Linux desktop as well. >>> I'd say something was wrong with my netbook, except 01 >>> works just fine. >>> >>> >>> 2011/6/7 Patrick Baggett >>> >>>> Not seeing it here (Win32 platform) >>>> >>>> Erlang R14B03 (erts-5.8.4) [smp:4:4] [rq:4] [async-threads:0] >>>> >>>> Eshell V5.8.4 (abort with ^G) >>>> 1> re:split("abc","b"). >>>> [<<"a">>,<<"c">>] >>>> 2> >>>> >>>> >>>> >>>> On Tue, Jun 7, 2011 at 10:00 PM, Dave Peticolas < >>>> dave.peticolas@REDACTED> wrote: >>>> >>>>> Hello, I recently tried to build both R14B02 and 03 on my Dell Inspiron >>>>> Mini (Intel Atom) >>>>> running Ubuntu 8.04. I already had R14B01 running fine. I found that >>>>> re:split no longer >>>>> worked. I built all the versions from source. Here is an example of 01 >>>>> output: >>>>> >>>>> Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] >>>>> [hipe] [kernel-poll:false] >>>>> >>>>> Eshell V5.8.2 (abort with ^G) >>>>> 1> re:split("abc", "b"). >>>>> [<<"a">>,<<"c">>] >>>>> 2> q(). >>>>> ok >>>>> >>>>> >>>>> And here is what I get on 02 (same as 03 except for the version >>>>> numbers): >>>>> >>>>> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] >>>>> [hipe] [kernel-poll:false] >>>>> >>>>> Eshell V5.8.3 (abort with ^G) >>>>> 1> re:split("abc", "b"). >>>>> ** exception error: no case clause matching {match,["b"]} >>>>> in function re:run/3 >>>>> called as re:run(<<"abc">>, >>>>> {re_pattern,0,0, >>>>> >>>>> <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, >>>>> [global]) >>>>> in call from re:split/3 >>>>> 2> >>>>> >>>>> In case the existing build was somehow getting tangled with the new >>>>> one, >>>>> I tried removing the 01 build completely and rebuilding 02 and got the >>>>> same >>>>> results. >>>>> >>>>> thanks, >>>>> dave >>>>> >>>>> _______________________________________________ >>>>> erlang-bugs mailing list >>>>> erlang-bugs@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baggett.patrick@REDACTED Fri Jun 10 05:37:46 2011 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Thu, 9 Jun 2011 22:37:46 -0500 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 In-Reply-To: References: Message-ID: Well the point was to check if there might be a reason like compiler optimization that was causing it. Usually debug builds don't have extremely heavy optimization enabled and if that was the cause, it would automagically disappear. Since it isn't the problem, I don't really have good ideas other than debugging Erlang itself. Patrick On Thu, Jun 9, 2011 at 10:19 PM, Dave Peticolas wrote: > I built a debug emulator, but I'm not sure what I should do with it, > other than re-run that test which produces the same failing result. > > > 2011/6/7 Dave Peticolas > >> Thanks, I will give that a try. >> >> >> 2011/6/7 Patrick Baggett >> >>> Maybe it is compiler options / optimizations producing wrong code? I'd >>> make 100% sure all *.o files are gone and then retry with a debug build. >>> Other than that, I don't know what to tell you. :\ >>> >>> >>> On Tue, Jun 7, 2011 at 10:17 PM, Dave Peticolas < >>> dave.peticolas@REDACTED> wrote: >>> >>>> I should mention it works fine on my Linux desktop as well. >>>> I'd say something was wrong with my netbook, except 01 >>>> works just fine. >>>> >>>> >>>> 2011/6/7 Patrick Baggett >>>> >>>>> Not seeing it here (Win32 platform) >>>>> >>>>> Erlang R14B03 (erts-5.8.4) [smp:4:4] [rq:4] [async-threads:0] >>>>> >>>>> Eshell V5.8.4 (abort with ^G) >>>>> 1> re:split("abc","b"). >>>>> [<<"a">>,<<"c">>] >>>>> 2> >>>>> >>>>> >>>>> >>>>> On Tue, Jun 7, 2011 at 10:00 PM, Dave Peticolas < >>>>> dave.peticolas@REDACTED> wrote: >>>>> >>>>>> Hello, I recently tried to build both R14B02 and 03 on my Dell >>>>>> Inspiron Mini (Intel Atom) >>>>>> running Ubuntu 8.04. I already had R14B01 running fine. I found that >>>>>> re:split no longer >>>>>> worked. I built all the versions from source. Here is an example of 01 >>>>>> output: >>>>>> >>>>>> Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] >>>>>> [hipe] [kernel-poll:false] >>>>>> >>>>>> Eshell V5.8.2 (abort with ^G) >>>>>> 1> re:split("abc", "b"). >>>>>> [<<"a">>,<<"c">>] >>>>>> 2> q(). >>>>>> ok >>>>>> >>>>>> >>>>>> And here is what I get on 02 (same as 03 except for the version >>>>>> numbers): >>>>>> >>>>>> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] >>>>>> [hipe] [kernel-poll:false] >>>>>> >>>>>> Eshell V5.8.3 (abort with ^G) >>>>>> 1> re:split("abc", "b"). >>>>>> ** exception error: no case clause matching {match,["b"]} >>>>>> in function re:run/3 >>>>>> called as re:run(<<"abc">>, >>>>>> {re_pattern,0,0, >>>>>> >>>>>> <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, >>>>>> [global]) >>>>>> in call from re:split/3 >>>>>> 2> >>>>>> >>>>>> In case the existing build was somehow getting tangled with the new >>>>>> one, >>>>>> I tried removing the 01 build completely and rebuilding 02 and got the >>>>>> same >>>>>> results. >>>>>> >>>>>> thanks, >>>>>> dave >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-bugs mailing list >>>>>> erlang-bugs@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.peticolas@REDACTED Fri Jun 10 06:08:22 2011 From: dave.peticolas@REDACTED (Dave Peticolas) Date: Thu, 9 Jun 2011 21:08:22 -0700 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 In-Reply-To: References: Message-ID: Fair enough. To the debugger! 2011/6/9 Patrick Baggett > Well the point was to check if there might be a reason like compiler > optimization that was causing it. Usually debug builds don't have extremely > heavy optimization enabled and if that was the cause, it would automagically > disappear. Since it isn't the problem, I don't really have good ideas other > than debugging Erlang itself. > > Patrick > > > On Thu, Jun 9, 2011 at 10:19 PM, Dave Peticolas wrote: > >> I built a debug emulator, but I'm not sure what I should do with it, >> other than re-run that test which produces the same failing result. >> >> >> 2011/6/7 Dave Peticolas >> >>> Thanks, I will give that a try. >>> >>> >>> 2011/6/7 Patrick Baggett >>> >>>> Maybe it is compiler options / optimizations producing wrong code? I'd >>>> make 100% sure all *.o files are gone and then retry with a debug build. >>>> Other than that, I don't know what to tell you. :\ >>>> >>>> >>>> On Tue, Jun 7, 2011 at 10:17 PM, Dave Peticolas < >>>> dave.peticolas@REDACTED> wrote: >>>> >>>>> I should mention it works fine on my Linux desktop as well. >>>>> I'd say something was wrong with my netbook, except 01 >>>>> works just fine. >>>>> >>>>> >>>>> 2011/6/7 Patrick Baggett >>>>> >>>>>> Not seeing it here (Win32 platform) >>>>>> >>>>>> Erlang R14B03 (erts-5.8.4) [smp:4:4] [rq:4] [async-threads:0] >>>>>> >>>>>> Eshell V5.8.4 (abort with ^G) >>>>>> 1> re:split("abc","b"). >>>>>> [<<"a">>,<<"c">>] >>>>>> 2> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 7, 2011 at 10:00 PM, Dave Peticolas < >>>>>> dave.peticolas@REDACTED> wrote: >>>>>> >>>>>>> Hello, I recently tried to build both R14B02 and 03 on my Dell >>>>>>> Inspiron Mini (Intel Atom) >>>>>>> running Ubuntu 8.04. I already had R14B01 running fine. I found that >>>>>>> re:split no longer >>>>>>> worked. I built all the versions from source. Here is an example of >>>>>>> 01 output: >>>>>>> >>>>>>> Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] >>>>>>> [async-threads:0] [hipe] [kernel-poll:false] >>>>>>> >>>>>>> Eshell V5.8.2 (abort with ^G) >>>>>>> 1> re:split("abc", "b"). >>>>>>> [<<"a">>,<<"c">>] >>>>>>> 2> q(). >>>>>>> ok >>>>>>> >>>>>>> >>>>>>> And here is what I get on 02 (same as 03 except for the version >>>>>>> numbers): >>>>>>> >>>>>>> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] >>>>>>> [async-threads:0] [hipe] [kernel-poll:false] >>>>>>> >>>>>>> Eshell V5.8.3 (abort with ^G) >>>>>>> 1> re:split("abc", "b"). >>>>>>> ** exception error: no case clause matching {match,["b"]} >>>>>>> in function re:run/3 >>>>>>> called as re:run(<<"abc">>, >>>>>>> {re_pattern,0,0, >>>>>>> >>>>>>> <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, >>>>>>> [global]) >>>>>>> in call from re:split/3 >>>>>>> 2> >>>>>>> >>>>>>> In case the existing build was somehow getting tangled with the new >>>>>>> one, >>>>>>> I tried removing the 01 build completely and rebuilding 02 and got >>>>>>> the same >>>>>>> results. >>>>>>> >>>>>>> thanks, >>>>>>> dave >>>>>>> >>>>>>> _______________________________________________ >>>>>>> erlang-bugs mailing list >>>>>>> erlang-bugs@REDACTED >>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.peticolas@REDACTED Sat Jun 11 21:18:49 2011 From: dave.peticolas@REDACTED (Dave Peticolas) Date: Sat, 11 Jun 2011 12:18:49 -0700 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 In-Reply-To: References: Message-ID: For the record, it looks like a compiler bug. I found that on line 551 in erl_bif_re.c, the 'else if' branch is not taken, even though the 'ri' variable is initialized to the address of the local 'defri' structure and the boolean condition should be true. Moving 'defri' to a static module variable fixes the problem. I'm going to try rebuilding with a newer gcc (currently using the 4.2.3 that comes with the distro). dave 2011/6/9 Dave Peticolas > Fair enough. To the debugger! > > > 2011/6/9 Patrick Baggett > >> Well the point was to check if there might be a reason like compiler >> optimization that was causing it. Usually debug builds don't have extremely >> heavy optimization enabled and if that was the cause, it would automagically >> disappear. Since it isn't the problem, I don't really have good ideas other >> than debugging Erlang itself. >> >> Patrick >> >> >> On Thu, Jun 9, 2011 at 10:19 PM, Dave Peticolas > > wrote: >> >>> I built a debug emulator, but I'm not sure what I should do with it, >>> other than re-run that test which produces the same failing result. >>> >>> >>> 2011/6/7 Dave Peticolas >>> >>>> Thanks, I will give that a try. >>>> >>>> >>>> 2011/6/7 Patrick Baggett >>>> >>>>> Maybe it is compiler options / optimizations producing wrong code? I'd >>>>> make 100% sure all *.o files are gone and then retry with a debug build. >>>>> Other than that, I don't know what to tell you. :\ >>>>> >>>>> >>>>> On Tue, Jun 7, 2011 at 10:17 PM, Dave Peticolas < >>>>> dave.peticolas@REDACTED> wrote: >>>>> >>>>>> I should mention it works fine on my Linux desktop as well. >>>>>> I'd say something was wrong with my netbook, except 01 >>>>>> works just fine. >>>>>> >>>>>> >>>>>> 2011/6/7 Patrick Baggett >>>>>> >>>>>>> Not seeing it here (Win32 platform) >>>>>>> >>>>>>> Erlang R14B03 (erts-5.8.4) [smp:4:4] [rq:4] [async-threads:0] >>>>>>> >>>>>>> Eshell V5.8.4 (abort with ^G) >>>>>>> 1> re:split("abc","b"). >>>>>>> [<<"a">>,<<"c">>] >>>>>>> 2> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 7, 2011 at 10:00 PM, Dave Peticolas < >>>>>>> dave.peticolas@REDACTED> wrote: >>>>>>> >>>>>>>> Hello, I recently tried to build both R14B02 and 03 on my Dell >>>>>>>> Inspiron Mini (Intel Atom) >>>>>>>> running Ubuntu 8.04. I already had R14B01 running fine. I found that >>>>>>>> re:split no longer >>>>>>>> worked. I built all the versions from source. Here is an example of >>>>>>>> 01 output: >>>>>>>> >>>>>>>> Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] >>>>>>>> [async-threads:0] [hipe] [kernel-poll:false] >>>>>>>> >>>>>>>> Eshell V5.8.2 (abort with ^G) >>>>>>>> 1> re:split("abc", "b"). >>>>>>>> [<<"a">>,<<"c">>] >>>>>>>> 2> q(). >>>>>>>> ok >>>>>>>> >>>>>>>> >>>>>>>> And here is what I get on 02 (same as 03 except for the version >>>>>>>> numbers): >>>>>>>> >>>>>>>> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] >>>>>>>> [async-threads:0] [hipe] [kernel-poll:false] >>>>>>>> >>>>>>>> Eshell V5.8.3 (abort with ^G) >>>>>>>> 1> re:split("abc", "b"). >>>>>>>> ** exception error: no case clause matching {match,["b"]} >>>>>>>> in function re:run/3 >>>>>>>> called as re:run(<<"abc">>, >>>>>>>> {re_pattern,0,0, >>>>>>>> >>>>>>>> <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, >>>>>>>> [global]) >>>>>>>> in call from re:split/3 >>>>>>>> 2> >>>>>>>> >>>>>>>> In case the existing build was somehow getting tangled with the new >>>>>>>> one, >>>>>>>> I tried removing the 01 build completely and rebuilding 02 and got >>>>>>>> the same >>>>>>>> results. >>>>>>>> >>>>>>>> thanks, >>>>>>>> dave >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> erlang-bugs mailing list >>>>>>>> erlang-bugs@REDACTED >>>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igorrs@REDACTED Tue Jun 14 07:55:52 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Tue, 14 Jun 2011 02:55:52 -0300 Subject: [erlang-bugs] "Killed" Mnesia transaction left locks behind Message-ID: An Erlang process in node N was killed while executing a transaction (our system does that automatically for some kinds of operations, when they take too long to finish). However, some locks were left behind in the 4 nodes that have the tables (this should be a bug, according to what Dan Gudmundsson once told me in this list). Anyway, I'd like to know if there's a way of releasing the locks without restarting the nodes. I tried mnesia_locker:release_tid(27211023009), but the locks still appear when I call mnesia:system_info(held_locks): - In nodes N1 and N2: [{{si_build_hq_frag31,7}, write, {tid,27211023009,<8057.12454.8>}}] - In nodes N3 and N4: [{{si_build_hq_frag191,{7,1}}, write, {tid,27211023009,<8057.12454.8>}}] - Also in node N3: [{{si_build_hq_frag191,{7,1}}, read, {tid,27211023009,<8057.12454.8>}}, I'm sure the process is no longer running in node N. Thank you. Igor. -- "The secret of joy in work is contained in one word - excellence. To know how to do something well is to enjoy it." - Pearl S. Buck. From adam@REDACTED Tue Jun 14 09:51:33 2011 From: adam@REDACTED (Adam Lindberg) Date: Tue, 14 Jun 2011 09:51:33 +0200 Subject: [erlang-bugs] Code server does not correctly handle case sensitivity Message-ID: <4DF71305.8050503@erlang-solutions.com> Hi, I was playing around with PropEr, testing meck, when discovering that loading a lower case module using it's name in upper case will cause the code server to crash: 1> l('DBG'). {error,badfile} =ERROR REPORT==== 14-Jun-2011::09:45:15 === Loading of /Users/alind/Applications/erlang/r13b04/lib/erlang/lib/runtime_tools-1.8.3/ebin/DBG.beam failed: badfile =ERROR REPORT==== 14-Jun-2011::09:45:15 === beam/beam_load.c(1036): Error loading module 'DBG': module name in object code is dbg 2> l(dbg). {module,dbg} Loading a module which has an upper case name already works just fine: 3> l('TEST'). {module,'TEST'} Cheers, Adam From dangud@REDACTED Tue Jun 14 12:26:21 2011 From: dangud@REDACTED (Dan Gudmundsson) Date: Tue, 14 Jun 2011 12:26:21 +0200 Subject: [erlang-bugs] "Killed" Mnesia transaction left locks behind In-Reply-To: References: Message-ID: mnesia_locker:release_tid/1 takes a #tid{} as argument. But I'm concerned about it not being released, the transaction process is linked to mnesia_tm which should handle exit message and handle it accordingly, if not it is a bug. /Dan On Tue, Jun 14, 2011 at 7:55 AM, Igor Ribeiro Sucupira wrote: > An Erlang process in node N was killed while executing a transaction > (our system does that automatically for some kinds of operations, when > they take too long to finish). > However, some locks were left behind in the 4 nodes that have the > tables (this should be a bug, according to what Dan Gudmundsson once > told me in this list). > > Anyway, I'd like to know if there's a way of releasing the locks > without restarting the nodes. > I tried mnesia_locker:release_tid(27211023009), but the locks still > appear when I call mnesia:system_info(held_locks): > - In nodes N1 and N2: > [{{si_build_hq_frag31,7}, > write, > {tid,27211023009,<8057.12454.8>}}] > - In nodes N3 and N4: > [{{si_build_hq_frag191,{7,1}}, > write, > {tid,27211023009,<8057.12454.8>}}] > - Also in node N3: > [{{si_build_hq_frag191,{7,1}}, > read, > {tid,27211023009,<8057.12454.8>}}, > > > I'm sure the process is no longer running in node N. > > Thank you. > Igor. > > -- > "The secret of joy in work is contained in one word - excellence. To > know how to do something well is to enjoy it." - Pearl S. Buck. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam@REDACTED Tue Jun 14 13:59:15 2011 From: adam@REDACTED (Adam Lindberg) Date: Tue, 14 Jun 2011 13:59:15 +0200 Subject: [erlang-bugs] Code server does not correctly handle case sensitivity In-Reply-To: <4DF71305.8050503@erlang-solutions.com> References: <4DF71305.8050503@erlang-solutions.com> Message-ID: <4DF74D13.8030509@erlang-solutions.com> Hmm, might be true: $ touch test $ rm TEST $ ls test ls: test: No such file or directory Still, bug in Erlang or not? Cheers, Adam Tuncer Ayaz wrote: > Hey Adam, > > you're not using Darwin with a case insensitive HFS+ filesystem, which > happens to be a default setting, do you? > > That might explain the problem. From zichen@REDACTED Thu Jun 16 19:43:26 2011 From: zichen@REDACTED (Zichen Cao) Date: Thu, 16 Jun 2011 17:43:26 +0000 Subject: [erlang-bugs] dets:match_object/1 cannot pass '$end_of_table' as the parameter. In-Reply-To: <7D338DA710E25D4AADFA5F0892D86EC6050407DA@CH1PRD0102MB113.prod.exchangelabs.com> References: <7D338DA710E25D4AADFA5F0892D86EC6050407DA@CH1PRD0102MB113.prod.exchangelabs.com> Message-ID: <7D338DA710E25D4AADFA5F0892D86EC605040C1F@CH1PRD0102MB113.prod.exchangelabs.com> Hi, I was testing ets and dets, and I found that they behave differently on the functions ets:match_object/1 and dets:match_object/1. 1> ets:match_object('$end_of_table'). '$end_of_table' 2> dets:match_object('$end_of_table'). ** exception error: bad argument in function dets:match_object/1 called as dets:match_object('$end_of_table') When passing '$end_of_table' as the parameter, the shell threw an exception. This maybe not what we want. Zichen From zichen@REDACTED Thu Jun 16 19:44:33 2011 From: zichen@REDACTED (Zichen Cao) Date: Thu, 16 Jun 2011 17:44:33 +0000 Subject: [erlang-bugs] Strange behavior of dets:match_object/1. In-Reply-To: <7D338DA710E25D4AADFA5F0892D86EC605040BF4@CH1PRD0102MB113.prod.exchangelabs.com> References: <7D338DA710E25D4AADFA5F0892D86EC605040BF4@CH1PRD0102MB113.prod.exchangelabs.com> Message-ID: <7D338DA710E25D4AADFA5F0892D86EC605040C28@CH1PRD0102MB113.prod.exchangelabs.com> Hi, I was testing the functions in dets, and I found the behavior of dets:match_object/1 is strange. I am not sure if it's a bug. f() -> file:delete(test), {ok, Tab} = dets:open_file(test, [{type, bag}]), dets:safe_fixtable(Tab, true), dets:insert(Tab, [{a},{b},{c,0},{d,0}]), {M1, C} = dets:match_object(Tab, {'_'}, 3), dets:insert(Tab, {b,0}), _ = dets:match_object(Tab, '_', 1), {M2, _} = dets:match_object(C), dets:close(Tab), {M1, M2}. This function returns {[{b}],[{a},{b}]}. It shows that dets:match_object/1 returned a tuple which had already been returned by dets:match_object/3. This is minimal test case, and only happen with using dets:safe_fixtable/2. The call _ = dets:match_object(Tab, '_', 1) is also necessary to provoke the problem. Zichen Cao From zichen@REDACTED Thu Jun 16 19:45:38 2011 From: zichen@REDACTED (Zichen Cao) Date: Thu, 16 Jun 2011 17:45:38 +0000 Subject: [erlang-bugs] Strange behaviors in supervisor module. In-Reply-To: <7D338DA710E25D4AADFA5F0892D86EC605040C04@CH1PRD0102MB113.prod.exchangelabs.com> References: <7D338DA710E25D4AADFA5F0892D86EC605040C04@CH1PRD0102MB113.prod.exchangelabs.com> Message-ID: <7D338DA710E25D4AADFA5F0892D86EC605040C39@CH1PRD0102MB113.prod.exchangelabs.com> Hi, I was testing supervisor module, and I found three strange behaviors in it. start() -> Pid = spawn_link(fun child/0), {ok, Pid}. child() -> receive exit -> exit(normal) end. init(_) -> {ok, {{one_for_one, 30000, 10000},[]}}. f_sup1()-> {ok, Sup} = supervisor:start_link(?MODULE, []), {ok, Child} = supervisor:start_child(Sup, {child, {supervisor,start_link, [?MODULE,[]]}, temporary,infinity,supervisor,[?MODULE]}), exit(Child, kill), supervisor:delete_child(Sup, child). f_sup2()-> {ok, Sup} = supervisor:start_link(?MODULE, []), {ok, Child1} = supervisor:start_child(Sup, {child1, {?MODULE,start,[]}, temporary,1,worker, [?MODULE]}), {ok, Child2} = supervisor:start_child(Sup, {child2, {?MODULE,start,[]}, transient,1,worker, [?MODULE]}), Child1 ! exit, Child2 ! exit, timer:sleep(100), {supervisor:restart_child(Sup, child1), supervisor:restart_child(Sup, child2)}. f_sup3()-> {ok, Sup} = supervisor:start_link(?MODULE, []), {ok, Child} = supervisor:start_child(Sup, {child, {?MODULE,start,[]}, transient,10000,worker, [?MODULE]}), exit(Child, shutdown), timer:sleep(100), {Child, supervisor:which_children(Sup)}. In f_sup1, after killing the child process, I try to delete it by calling supervisor:delete_child, it returns {error,running}. In f_sup2, if a child processes exits with reason normal, a temporary child process cannot be restarted, but transient process can. So f_sup2 returns{{error,not_found},{ok,<0.364.0>}}. This seems inconsistent because a transient process that exits with reason normal is not supposed to be restarted. In f_sup3, if a transient child process exits with the reason shutdown, it won't be restarted. It seems strange, since, a transient child process should be restarted unless it is terminated with the reason normal. Zichen Cao From dave.peticolas@REDACTED Fri Jun 17 03:55:56 2011 From: dave.peticolas@REDACTED (Dave Peticolas) Date: Thu, 16 Jun 2011 18:55:56 -0700 Subject: [erlang-bugs] error in re:split on R14B02 and R14B03 In-Reply-To: References: Message-ID: And for the final record, rebuilding R14B03 with gcc 4.5.3 fixes the problem. 2011/6/11 Dave Peticolas > For the record, it looks like a compiler bug. I found that on line 551 in > erl_bif_re.c, the > 'else if' branch is not taken, even though the 'ri' variable is initialized > to the address of > the local 'defri' structure and the boolean condition should be true. > Moving 'defri' to a static > module variable fixes the problem. I'm going to try rebuilding with a newer > gcc (currently > using the 4.2.3 that comes with the distro). > > dave > > 2011/6/9 Dave Peticolas > >> Fair enough. To the debugger! >> >> >> 2011/6/9 Patrick Baggett >> >>> Well the point was to check if there might be a reason like compiler >>> optimization that was causing it. Usually debug builds don't have extremely >>> heavy optimization enabled and if that was the cause, it would automagically >>> disappear. Since it isn't the problem, I don't really have good ideas other >>> than debugging Erlang itself. >>> >>> Patrick >>> >>> >>> On Thu, Jun 9, 2011 at 10:19 PM, Dave Peticolas < >>> dave.peticolas@REDACTED> wrote: >>> >>>> I built a debug emulator, but I'm not sure what I should do with it, >>>> other than re-run that test which produces the same failing result. >>>> >>>> >>>> 2011/6/7 Dave Peticolas >>>> >>>>> Thanks, I will give that a try. >>>>> >>>>> >>>>> 2011/6/7 Patrick Baggett >>>>> >>>>>> Maybe it is compiler options / optimizations producing wrong code? I'd >>>>>> make 100% sure all *.o files are gone and then retry with a debug build. >>>>>> Other than that, I don't know what to tell you. :\ >>>>>> >>>>>> >>>>>> On Tue, Jun 7, 2011 at 10:17 PM, Dave Peticolas < >>>>>> dave.peticolas@REDACTED> wrote: >>>>>> >>>>>>> I should mention it works fine on my Linux desktop as well. >>>>>>> I'd say something was wrong with my netbook, except 01 >>>>>>> works just fine. >>>>>>> >>>>>>> >>>>>>> 2011/6/7 Patrick Baggett >>>>>>> >>>>>>>> Not seeing it here (Win32 platform) >>>>>>>> >>>>>>>> Erlang R14B03 (erts-5.8.4) [smp:4:4] [rq:4] [async-threads:0] >>>>>>>> >>>>>>>> Eshell V5.8.4 (abort with ^G) >>>>>>>> 1> re:split("abc","b"). >>>>>>>> [<<"a">>,<<"c">>] >>>>>>>> 2> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jun 7, 2011 at 10:00 PM, Dave Peticolas < >>>>>>>> dave.peticolas@REDACTED> wrote: >>>>>>>> >>>>>>>>> Hello, I recently tried to build both R14B02 and 03 on my Dell >>>>>>>>> Inspiron Mini (Intel Atom) >>>>>>>>> running Ubuntu 8.04. I already had R14B01 running fine. I found >>>>>>>>> that re:split no longer >>>>>>>>> worked. I built all the versions from source. Here is an example of >>>>>>>>> 01 output: >>>>>>>>> >>>>>>>>> Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] >>>>>>>>> [async-threads:0] [hipe] [kernel-poll:false] >>>>>>>>> >>>>>>>>> Eshell V5.8.2 (abort with ^G) >>>>>>>>> 1> re:split("abc", "b"). >>>>>>>>> [<<"a">>,<<"c">>] >>>>>>>>> 2> q(). >>>>>>>>> ok >>>>>>>>> >>>>>>>>> >>>>>>>>> And here is what I get on 02 (same as 03 except for the version >>>>>>>>> numbers): >>>>>>>>> >>>>>>>>> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] >>>>>>>>> [async-threads:0] [hipe] [kernel-poll:false] >>>>>>>>> >>>>>>>>> Eshell V5.8.3 (abort with ^G) >>>>>>>>> 1> re:split("abc", "b"). >>>>>>>>> ** exception error: no case clause matching {match,["b"]} >>>>>>>>> in function re:run/3 >>>>>>>>> called as re:run(<<"abc">>, >>>>>>>>> {re_pattern,0,0, >>>>>>>>> >>>>>>>>> <<69,82,67,80,49,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,98,0,0,...>>}, >>>>>>>>> [global]) >>>>>>>>> in call from re:split/3 >>>>>>>>> 2> >>>>>>>>> >>>>>>>>> In case the existing build was somehow getting tangled with the new >>>>>>>>> one, >>>>>>>>> I tried removing the 01 build completely and rebuilding 02 and got >>>>>>>>> the same >>>>>>>>> results. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> dave >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> erlang-bugs mailing list >>>>>>>>> erlang-bugs@REDACTED >>>>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Fri Jun 17 12:28:26 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 17 Jun 2011 12:28:26 +0200 Subject: [erlang-bugs] Strange behaviors in supervisor module. In-Reply-To: <7D338DA710E25D4AADFA5F0892D86EC605040C39@CH1PRD0102MB113.prod.exchangelabs.com> References: <7D338DA710E25D4AADFA5F0892D86EC605040C04@CH1PRD0102MB113.prod.exchangelabs.com> <7D338DA710E25D4AADFA5F0892D86EC605040C39@CH1PRD0102MB113.prod.exchangelabs.com> Message-ID: Hi! The strange behaviors that you have discovered are really the expected behaviors. However, I do agree that the documentation is a bit incomplete on these issues. In f_sup1, after killing the child process, I try to delete it by calling > supervisor:delete_child, it returns {error,running}. > This is a timing issue - since exit/1 is asynchronous, delete_child/2 will be called before the process is actually terminated. However, if you add an appropriate timer:sleep(...) between the two calls, you will get {error,not_found} instead. This is because a temporary child is automatically deleted when it terminates, since such processes can never be restarted anyway. In f_sup2, if a child processes exits with reason normal, a temporary child > process cannot be restarted, but transient process can. So f_sup2 > returns{{error,not_found},{ok,<0.364.0>}}. This seems inconsistent because a > transient process that exits with reason normal is not supposed to be > restarted. > It is correct that a transient process which terminates with reason normal is not automatically restarted by the supervisor. However, it is still possible to explicitly restart it by calling supervisor:restart_child as long as you have not deleted the child spec by calling supervisor:delete_child. Only temporary processes can not be restarted this way. > In f_sup3, if a transient child process exits with the reason shutdown, it > won't be restarted. It seems strange, since, a transient child process > should be restarted unless it is terminated with the reason normal. > The exit reason 'shutdown' has a special meaning in OTP - it is the exit reason used by a supervisor when terminating its children. Obviously, the child shall not be automatically restarted after such termination. I will have a look at the documentation and try to make it more clear. Regards /siri@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam@REDACTED Fri Jun 17 13:22:32 2011 From: adam@REDACTED (Adam Lindberg) Date: Fri, 17 Jun 2011 13:22:32 +0200 Subject: [erlang-bugs] Code server does not correctly handle case sensitivity In-Reply-To: <4DF74D13.8030509@erlang-solutions.com> References: <4DF71305.8050503@erlang-solutions.com> <4DF74D13.8030509@erlang-solutions.com> Message-ID: <4DFB38F8.9080406@erlang-solutions.com> So, bug in Erlang or just how it's supposed to "work" when the file system is case insensitive? Cheers, Adam Adam Lindberg wrote: > Hmm, might be true: > > $ touch test > $ rm TEST > $ ls test > ls: test: No such file or directory > > > Still, bug in Erlang or not? > > Cheers, > Adam > > Tuncer Ayaz wrote: > > Hey Adam, > > > > you're not using Darwin with a case insensitive HFS+ filesystem, which > > happens to be a default setting, do you? > > > > That might explain the problem. From rj@REDACTED Fri Jun 17 23:59:25 2011 From: rj@REDACTED (Richard Jones) Date: Fri, 17 Jun 2011 22:59:25 +0100 Subject: [erlang-bugs] SSL socket not sending ssl_closed/ssl_error after a crash Message-ID: After making an SSL connection to a remote server, and setting the socket {active, true}, I'm able to crash the gen_fsm that is part of the ssl socket, without receiving ssl_closed, ssl_error or an EXIT signal in the controlling process. This will cause the crash: ssl:getopts(Sock, some_invalid_atom_here). Presumably this should be impossible? I want to rely on receiving ssl_closed or ssl_error so my controlling process can shut down when the socket closes or crashes. I've had a process leak due to this problem - ssl sockets closing, and my code not noticing, leaving idle processes lingering. I'm not triggering it in production using getopts/2 as below, but something similar is happening somehow. I've included some example code below, and a rather hefty error report it generates. Am I doing something daft, or is this a bug? Regards, RJ Code, or with highlighting at http://ideone.com/T2ys0 ===== -module(ssltest). -compile(export_all). start() -> application:start(sasl), application:start(crypto), application:start(public_key), application:start(ssl), %% Just using github as a publicly available ssl port to for a demo: Opts = [list, {packet, line}, {active, false}], {ok, Sock} = ssl:connect("github.com", 443, Opts), Pid = spawn(fun client/0), ok = ssl:controlling_process(Sock, Pid), Pid ! {give, Sock}, timer:sleep(1000), crash_weirdly(Sock), timer:sleep(1000), %% By now the client process should have received a ssl_closed/error msg %% but it doesnt get one, and is thus still running. case process_info(Pid) of undefined -> io:format("OK\n",[]), exit(normal); Props -> io:format("FAIL - no message received, process_info(~p):\n~p\n", [Pid, Props]), exit(fail) end. %% This appears to crash the gen_fsm of the ssl socket %% but doesn't trigger a {ssl_closed, Sock} msg, or 'EXIT' %% There are probably other ways it can crash like this too. crash_weirdly(Sock) -> io:format("Crashing SSL socket\n", []), catch ssl:getopts(Sock, some_invalid_atom_here). %% This process becomes the owner of the socket, and needs to terminate when %% the socket is closed. client() -> process_flag(trap_exit, true), %% Wait for controlling_process to be set: receive {give, Sock} -> ssl:setopts(Sock, [{active, true}]), io:format("Pid: ~p Sock: ~p made {active,true}\n", [self(),Sock]), recv_loop() end. recv_loop() -> receive {ssl_closed, _} -> io:format("GOT SSL_CLOSED\n", []), ok; {ssl_error, _, Reason} -> io:format("GOT SSL_ERROR ~p\n", [Reason]), ok; X -> io:format("GOT: ~p\n", [X]), recv_loop() end. =ERROR REPORT==== 17-Jun-2011::22:44:33 === ** State machine <0.142.0> terminating ** Last message in was {'$gen_sync_all_state_event', {<0.135.0>,#Ref<0.0.0.666>}, {get_opts,some_invalid_atom_here}} ** When State == connection ** Data == {state,client, {#Ref<0.0.0.662>,<0.143.0>}, gen_tcp,tcp,tcp_closed,tcp_error,"github.com",443, #Port<0.2884>, {ssl_options,[],verify_none,#Fun,false, false,undefined,1,[],[],undefined,undefined,[], undefined, [<<0,57>>, <<0,56>>, <<0,53>>, <<0,22>>, <<0,19>>, <<0,10>>, <<0,51>>, <<0,50>>, <<0,47>>, <<0,5>>, <<0,4>>, <<0,21>>, <<0,9>>], #Fun,true,18446744073709551900,false, []}, {socket_options,list,line,0,0,true}, {connection_states, {connection_state, {security_parameters, <<0,53>>, 1,7,1,16,256,32,unknown,2,20,0, <<254,226,8,153,158,133,167,137,122,65,223,95, 199,62,150,14,245,185,34,18,222,22,80,53, 144,55,219,45,219,144,154,61,115,146,69,154, 169,92,12,70,174,132,26,179,172,211,57,46>>, <<77,251,202,192,105,255,244,98,162,152,147, 244,74,171,108,19,241,117,195,42,111,43,65, 254,226,214,61,144,22,62,205,97>>, <<77,251,202,192,60,117,73,65,49,38,238,91,11, 208,144,28,154,0,211,16,126,128,35,92,106, 253,30,96,72,8,185,60>>, undefined}, undefined, {cipher_state, <<107,193,209,70,14,51,191,243,6,30,235,102, 177,66,108,91>>, <<82,122,121,50,67,146,95,105,141,89,204,41, 100,220,66,0,155,39,193,179,77,82,117,3,82, 50,239,196,223,45,153,192>>, undefined}, <<138,74,111,39,183,247,74,90,128,251,163,51,162, 134,187,95,239,150,95,60>>, 1,true, <<199,217,7,37,129,205,108,88,226,52,211,51>>, <<112,230,216,51,212,101,251,25,135,84,199,203>>}, {connection_state, {security_parameters,undefined,1,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined, <<77,251,202,192,89,182,0,44,93,225,217,162, 14,42,169,222,17,209,142,212,247,18,33,182, 63,47,102,161,116,187,144,170>>, undefined,undefined}, undefined,undefined,undefined,undefined,true, undefined,undefined}, {connection_state, {security_parameters, <<0,53>>, 1,7,1,16,256,32,unknown,2,20,0, <<254,226,8,153,158,133,167,137,122,65,223,95, 199,62,150,14,245,185,34,18,222,22,80,53, 144,55,219,45,219,144,154,61,115,146,69,154, 169,92,12,70,174,132,26,179,172,211,57,46>>, <<77,251,202,192,105,255,244,98,162,152,147, 244,74,171,108,19,241,117,195,42,111,43,65, 254,226,214,61,144,22,62,205,97>>, <<77,251,202,192,60,117,73,65,49,38,238,91,11, 208,144,28,154,0,211,16,126,128,35,92,106, 253,30,96,72,8,185,60>>, undefined}, undefined, {cipher_state, <<67,15,24,23,53,236,18,90,72,41,97,211,175, 56,148,242>>, <<88,144,90,102,28,113,30,48,224,50,164,48,94, 43,35,54,0,203,91,66,113,135,169,4,52,9,154, 82,90,15,250,71>>, undefined}, <<97,53,165,232,130,210,58,150,35,107,110,217,252, 26,77,201,16,112,28,231>>, 1,true, <<199,217,7,37,129,205,108,88,226,52,211,51>>, <<112,230,216,51,212,101,251,25,135,84,199,203>>}, {connection_state, {security_parameters,undefined,1,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined, <<77,251,202,192,28,184,76,68,123,76,60,142, 106,240,173,4,49,192,225,191,249,104,4,239, 222,69,131,35,191,245,19,1>>, undefined,undefined}, undefined,undefined,undefined,undefined,true, undefined,undefined}}, [],<<>>,<<>>, {{<<127,40,71,77,128,20,238,48,237,90,195,130,105,141,116, 224,32,128,0,0,0,0,0,0,135,84,199,203,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,0, 0,0>>, <<241,223,170,74,130,30,208,157,176,34,157,47,22,53, 101,223,229,36,29,122,32,128,0,0,0,0,0,0,135,84,199, 203,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,4,0,0,0>>}, {<<28,22,93,1,181,148,104,2,201,120,127,203,130,141,153, 239,160,127,0,0,0,0,0,0,52,27,250,73,248,152,87,65, 188,19,124,110,164,44,199,195,178,69,135,100,166,29, 53,1,4,61,203,149,153,73,127,74,49,89,99,113,20,0,0, 12,199,217,7,37,129,205,108,88,226,52,211,51,0,0,0,0, 0,0,0,0,0,0,0,0,52,0,0,0>>, <<28,51,142,246,15,126,227,240,185,11,6,135,7,54,173, 1,97,186,89,238,160,127,0,0,0,0,0,0,52,27,250,73, 248,152,87,65,188,19,124,110,164,44,199,195,178,69, 135,100,166,29,53,1,4,61,203,149,153,73,127,74,49, 89,99,113,20,0,0,12,199,217,7,37,129,205,108,88,226, 52,211,51,0,0,0,0,0,0,0,0,0,0,0,0,52,0,0,0>>}}, [],undefined, {session, <<93,85,39,160,113,79,61,119,168,42,21,212,128,173,57, 245,196,81,177,34,215,105,207,104,143,170,179,33, 205,107,59,108>>, <<48,130,7,42,48,130,6,18,160,3,2,1,2,2,16,14,119,118, 138,93,7,240,229,121,89,202,42,157,80,130,181,48,13, 6,9,42,134,72,134,247,13,1,1,5,5,0,48,105,49,11,48, 9,6,3,85,4,6,19,2,85,83,49,21,48,19,6,3,85,4,10,19, 12,68,105,103,105,67,101,114,116,32,73,110,99,49,25, 48,23,6,3,85,4,11,19,16,119,119,119,46,100,105,103, 105,99,101,114,116,46,99,111,109,49,40,48,38,6,3,85, 4,3,19,31,68,105,103,105,67,101,114,116,32,72,105, 103,104,32,65,115,115,117,114,97,110,99,101,32,69, 86,32,67,65,45,49,48,30,23,13,49,49,48,53,50,55,48, 48,48,48,48,48,90,23,13,49,51,48,55,50,57,49,50,48, 48,48,48,90,48,129,202,49,29,48,27,6,3,85,4,15,12, 20,80,114,105,118,97,116,101,32,79,114,103,97,110, 105,122,97,116,105,111,110,49,19,48,17,6,11,43,6,1, 4,1,130,55,60,2,1,3,19,2,85,83,49,27,48,25,6,11,43, 6,1,4,1,130,55,60,2,1,2,19,10,67,97,108,105,102,111, 114,110,105,97,49,17,48,15,6,3,85,4,5,19,8,67,51,50, 54,56,49,48,50,49,11,48,9,6,3,85,4,6,19,2,85,83,49, 19,48,17,6,3,85,4,8,19,10,67,97,108,105,102,111,114, 110,105,97,49,22,48,20,6,3,85,4,7,19,13,83,97,110, 32,70,114,97,110,99,105,115,99,111,49,21,48,19,6,3, 85,4,10,19,12,71,105,116,72,117,98,44,32,73,110,99, 46,49,19,48,17,6,3,85,4,3,19,10,103,105,116,104,117, 98,46,99,111,109,48,130,1,34,48,13,6,9,42,134,72, 134,247,13,1,1,1,5,0,3,130,1,15,0,48,130,1,10,2,130, 1,1,0,237,211,137,195,93,112,114,9,243,51,79,26,114, 116,217,182,90,149,80,187,104,97,159,247,251,31,25, 225,218,4,49,175,21,124,26,127,249,115,175,29,229, 67,43,86,9,0,69,105,74,232,196,91,223,194,119,82,81, 25,91,209,43,217,57,101,54,160,50,25,28,65,115,251, 50,178,61,159,152,236,130,91,11,55,100,57,44,183,16, 131,114,205,240,234,36,75,250,217,148,46,195,133,21, 57,169,58,246,136,218,244,39,137,166,149,79,132,162, 55,78,124,37,120,58,201,131,109,2,23,149,120,125,71, 168,85,131,238,19,200,25,26,179,60,241,95,254,59,2, 225,133,251,17,102,171,9,93,159,76,67,240,199,36,94, 41,114,40,206,212,117,104,79,36,114,41,174,57,40, 252,223,141,79,77,131,115,116,12,111,17,155,167,221, 98,222,255,226,235,23,230,255,12,191,192,45,49,59, 214,89,162,242,221,135,74,72,123,109,51,17,20,77,52, 159,50,56,246,200,25,157,241,182,61,197,70,239,81, 11,138,198,51,237,72,97,196,29,23,27,189,124,182, 103,233,57,207,165,82,128,10,244,234,205,2,3,1,0,1, 163,130,3,106,48,130,3,102,48,31,6,3,85,29,35,4,24, 48,22,128,20,76,88,203,37,240,65,79,82,244,40,200, 129,67,155,166,168,160,230,146,229,48,29,6,3,85,29, 14,4,22,4,20,135,209,143,25,110,228,135,111,83,140, 119,145,7,80,223,163,191,85,71,32,48,37,6,3,85,29, 17,4,30,48,28,130,10,103,105,116,104,117,98,46,99, 111,109,130,14,119,119,119,46,103,105,116,104,117, 98,46,99,111,109,48,129,129,6,8,43,6,1,5,5,7,1,1,4, 117,48,115,48,36,6,8,43,6,1,5,5,7,48,1,134,24,104, 116,116,112,58,47,47,111,99,115,112,46,100,105,103, 105,99,101,114,116,46,99,111,109,48,75,6,8,43,6,1,5, 5,7,48,2,134,63,104,116,116,112,58,47,47,119,119, 119,46,100,105,103,105,99,101,114,116,46,99,111,109, 47,67,65,67,101,114,116,115,47,68,105,103,105,67, 101,114,116,72,105,103,104,65,115,115,117,114,97, 110,99,101,69,86,67,65,45,49,46,99,114,116,48,12,6, 3,85,29,19,1,1,255,4,2,48,0,48,97,6,3,85,29,31,4,90, 48,88,48,42,160,40,160,38,134,36,104,116,116,112,58, 47,47,99,114,108,51,46,100,105,103,105,99,101,114, 116,46,99,111,109,47,101,118,50,48,48,57,97,46,99, 114,108,48,42,160,40,160,38,134,36,104,116,116,112, 58,47,47,99,114,108,52,46,100,105,103,105,99,101, 114,116,46,99,111,109,47,101,118,50,48,48,57,97,46, 99,114,108,48,130,1,196,6,3,85,29,32,4,130,1,187,48, 130,1,183,48,130,1,179,6,9,96,134,72,1,134,253,108, 2,1,48,130,1,164,48,58,6,8,43,6,1,5,5,7,2,1,22,46, 104,116,116,112,58,47,47,119,119,119,46,100,105,103, 105,99,101,114,116,46,99,111,109,47,115,115,108,45, 99,112,115,45,114,101,112,111,115,105,116,111,114, 121,46,104,116,109,48,130,1,100,6,8,43,6,1,5,5,7,2, 2,48,130,1,86,30,130,1,82,0,65,0,110,0,121,0,32,0, 117,0,115,0,101,0,32,0,111,0,102,0,32,0,116,0,104,0, 105,0,115,0,32,0,67,0,101,0,114,0,116,0,105,0,102,0, 105,0,99,0,97,0,116,0,101,0,32,0,99,0,111,0,110,0, 115,0,116,0,105,0,116,0,117,0,116,0,101,0,115,0,32, 0,97,0,99,0,99,0,101,0,112,0,116,0,97,0,110,0,99,0, 101,0,32,0,111,0,102,0,32,0,116,0,104,0,101,0,32,0, 68,0,105,0,103,0,105,0,67,0,101,0,114,0,116,0,32,0, 67,0,80,0,47,0,67,0,80,0,83,0,32,0,97,0,110,0,100,0, 32,0,116,0,104,0,101,0,32,0,82,0,101,0,108,0,121,0, 105,0,110,0,103,0,32,0,80,0,97,0,114,0,116,0,121,0, 32,0,65,0,103,0,114,0,101,0,101,0,109,0,101,0,110,0, 116,0,32,0,119,0,104,0,105,0,99,0,104,0,32,0,108,0, 105,0,109,0,105,0,116,0,32,0,108,0,105,0,97,0,98,0, 105,0,108,0,105,0,116,0,121,0,32,0,97,0,110,0,100,0, 32,0,97,0,114,0,101,0,32,0,105,0,110,0,99,0,111,0, 114,0,112,0,111,0,114,0,97,0,116,0,101,0,100,0,32,0, 104,0,101,0,114,0,101,0,105,0,110,0,32,0,98,0,121,0, 32,0,114,0,101,0,102,0,101,0,114,0,101,0,110,0,99,0, 101,0,46,48,29,6,3,85,29,37,4,22,48,20,6,8,43,6,1,5, 5,7,3,1,6,8,43,6,1,5,5,7,3,2,48,17,6,9,96,134,72,1, 134,248,66,1,1,4,4,3,2,6,192,48,14,6,3,85,29,15,1,1, 255,4,4,3,2,5,160,48,13,6,9,42,134,72,134,247,13,1, 1,5,5,0,3,130,1,1,0,20,82,113,31,134,157,109,53,62, 134,187,102,26,139,133,152,185,0,76,203,66,181,70, 252,6,231,68,57,200,232,82,216,17,20,35,179,114,150, 233,20,148,158,47,0,40,247,213,4,69,64,0,198,244,87, 66,66,222,9,137,151,17,13,20,92,107,189,11,247,24, 163,95,103,2,243,9,56,99,191,193,18,157,48,186,142, 165,84,116,89,83,103,161,27,80,91,38,218,253,19,126, 89,23,191,73,239,148,126,69,164,253,58,73,50,240, 106,255,137,141,169,97,169,170,155,150,70,200,28, 224,24,28,230,251,130,244,10,171,82,166,202,232,84, 34,217,219,42,61,90,34,123,128,234,7,5,212,249,199, 240,83,89,95,187,119,126,222,147,112,65,78,35,203, 120,121,121,196,46,234,215,102,42,24,247,209,197, 124,226,18,120,130,141,29,236,130,158,1,162,229,2, 190,120,161,185,89,88,197,76,111,79,165,49,180,73, 91,94,152,30,46,56,246,25,196,57,162,74,251,121,5, 184,242,89,229,38,18,112,173,192,232,117,35,31,24, 209,11,224,159,101,228,195,215,73,135,91,114,108, 177,47,172,111>>, 0, <<0,53>>, <<254,226,8,153,158,133,167,137,122,65,223,95,199,62, 150,14,245,185,34,18,222,22,80,53,144,55,219,45,219, 144,154,61,115,146,69,154,169,92,12,70,174,132,26, 179,172,211,57,46>>, true,undefined}, 20499,ssl_session_cache, {3,1}, undefined,false,rsa, {{1,2,840,113549,1,1,1}, {'RSAPublicKey', 30022791620261825757993662585953092115593876007790889075857977169380755026843488295590920332822959949671733783772267273663127572234689557556838440961311958034872446138607383478249154120700224788846090518954426547213891114527577249466052578760409101386764739954597264062457764350325580813575208479828785125746659984354118047108089208903185979168757084287242652658664280506839310200006418365390463140656501936394629471169620807647477079812243508155549460290614662952471527791986452768187753921075252815690139573016552982548499689965311352938938970566167612062244558031493494815274290207588576741886915392581117360270029, 65537}, 'NULL'}, undefined,undefined,undefined, <<3,1,206,145,41,17,221,72,203,148,200,153,94,83,137,250, 208,132,136,231,216,156,242,214,230,137,138,173,184,97, 148,200,195,6,175,5,154,136,35,172,78,163,255,27,208,67, 35,188>>, #Ref<0.0.0.656>, {<0.135.0>,#Ref<0.0.0.659>}, 0,<<>>,true,undefined,false, {[],[]}} ** Reason for termination = ** {function_clause,[{ssl_connection,get_socket_opts, [#Port<0.2884>,some_invalid_atom_here, {socket_options,list,line,0,0,true}, []]}, {ssl_connection,handle_sync_event,4}, {gen_fsm,handle_msg,7}, {proc_lib,init_p_do_apply,3}]} =CRASH REPORT==== 17-Jun-2011::22:44:33 === crasher: initial call: ssl_connection:init/1 pid: <0.142.0> registered_name: [] exception exit: {function_clause, [{ssl_connection,get_socket_opts, [#Port<0.2884>,some_invalid_atom_here, {socket_options,list,line,0,0,true}, []]}, {ssl_connection,handle_sync_event,4}, {gen_fsm,handle_msg,7}, {proc_lib,init_p_do_apply,3}]} in function gen_fsm:terminate/7 ancestors: [ssl_connection_sup,ssl_sup,<0.59.0>] messages: [] links: [<0.63.0>] dictionary: [] trap_exit: false status: running heap_size: 1597 stack_size: 24 reductions: 9050 neighbours: =SUPERVISOR REPORT==== 17-Jun-2011::22:44:33 === Supervisor: {local,ssl_connection_sup} Context: child_terminated Reason: {function_clause, [{ssl_connection,get_socket_opts, [#Port<0.2884>,some_invalid_atom_here, {socket_options,list,line,0,0,true}, []]}, {ssl_connection,handle_sync_event,4}, {gen_fsm,handle_msg,7}, {proc_lib,init_p_do_apply,3}]} Offender: [{pid,<0.142.0>}, {name,undefined}, {mfargs, {ssl_connection,start_link, [client,"github.com",443,#Port<0.2884>, {{ssl_options,[],verify_none, #Fun,false,false,undefined,1, [],[],undefined,[],[],undefined, [<<0,57>>, <<0,56>>, <<0,53>>, <<0,22>>, <<0,19>>, <<0,10>>, <<0,51>>, <<0,50>>, <<0,47>>, <<0,5>>, <<0,4>>, <<0,21>>, <<0,9>>], #Fun,true, 18446744073709551900,false,[]}, {socket_options,list,line,0,0,false}}, <0.135.0>, {gen_tcp,tcp,tcp_closed,tcp_error}]}}, {restart_type,temporary}, {shutdown,4000}, {child_type,worker}] From ess@REDACTED Sun Jun 19 03:40:43 2011 From: ess@REDACTED (=?iso-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Sun, 19 Jun 2011 03:40:43 +0200 Subject: [erlang-bugs] beam_validator does not validate receive state Message-ID: The following function passes beam_validator verification, but crashes the emulator with a segfault if called: {function, recv, 0, 2}. {label,1}. {func_info,{atom,broken_recv},{atom,recv},0}. {label,2}. {loop_rec_end,{f,3}}. {label,3}. return. This is using R14B, compiler version 4.7.2. Regards, Erik S?e S?rensen From ali.yakout@REDACTED Sun Jun 19 09:33:53 2011 From: ali.yakout@REDACTED (Ali Yakout) Date: Sun, 19 Jun 2011 09:33:53 +0200 Subject: [erlang-bugs] ssh_sftp:stop_channel/1 tampers trap_exit flag Message-ID: <591FA96352AC9946A403D860A601665216CF04A629@ESESSCMS0357.eemea.ericsson.se> Hi, I was facing a problem with ssh_sftp:stop_channel/1, while checking the code I noticed that it changes the trap_exit to be always true! > stop_channel(Pid) -> > case process_info(Pid, [trap_exit]) of > [{trap_exit, Bool}] -> > ... > process_flag(trap_exit, Bool), I think 'Pid' should have been self() instead. > stop_channel(Pid) -> > case process_info(self(), [trap_exit]) of Beside this issue, I'm getting a 'gen_server' noproc crash when trying to close the sftp channel... The server complains with a strange message "Received oclose for nonexistent channel 0." Any idea? /Ali Crash report below: =================== 14> {ok,Pid,Conn}=ssh_sftp:start_channel("myhost",22,[{user,"myuser"},{password,"mypass"}]). {ok,<0.76.0>,<0.73.0>} 15> ssh_sftp:stop_channel(Pid). ok 16> =ERROR REPORT==== 18-Jun-2011::22:37:04 === ** Generic server <0.73.0> terminating ** Last message in was {ssh_msg,<0.74.0>, {ssh_msg_disconnect,2, "Received oclose for nonexistent channel 0.", []}} ** When Server state == {state,client,<0.32.0>,undefined,<0.74.0>, {connection,[],32784,[],[],1,undefined,undefined, undefined,undefined,undefined,undefined}, 0, [{address,"myhost"}, {port,22}, {role,client}, {channel_pid,<0.32.0>}, {socket_opts,[inet6]}, {ssh_opts, [{host,"myhost"}, {password,"mypass"}, {user,"myuser"}]}], undefined,true} ** Reason for termination == ** {noproc,{gen_server,call,[undefined,which_children,infinity]}} =ERROR REPORT==== 18-Jun-2011::22:37:04 === ** Generic server <0.72.0> terminating ** Last message in was {'EXIT',<0.73.0>, {noproc, {gen_server,call, [undefined,which_children,infinity]}}} ** When Server state == {state,client,<0.73.0>,<0.74.0>,undefined} ** Reason for termination == ** {noproc,{gen_server,call,[undefined,which_children,infinity]}} From nick@REDACTED Mon Jun 20 10:02:06 2011 From: nick@REDACTED (Niclas Eklund) Date: Mon, 20 Jun 2011 10:02:06 +0200 Subject: [erlang-bugs] ssh_sftp:stop_channel/1 tampers trap_exit flag In-Reply-To: <591FA96352AC9946A403D860A601665216CF04A629@ESESSCMS0357.eemea.ericsson.se> References: <591FA96352AC9946A403D860A601665216CF04A629@ESESSCMS0357.eemea.ericsson.se> Message-ID: Hello! The crash report should be related to a bug that was fixed some time ago. Are you sure that you're running the latest SSH version (2.0.7)?! Best regards, Niclas @ Erlang/OTP On Sun, 19 Jun 2011, Ali Yakout wrote: > Hi, > > I was facing a problem with ssh_sftp:stop_channel/1, while checking the code I noticed that it changes the trap_exit to be always true! > >> stop_channel(Pid) -> >> case process_info(Pid, [trap_exit]) of >> [{trap_exit, Bool}] -> >> ... >> process_flag(trap_exit, Bool), > > > I think 'Pid' should have been self() instead. > >> stop_channel(Pid) -> >> case process_info(self(), [trap_exit]) of > > > > Beside this issue, I'm getting a 'gen_server' noproc crash when trying to close the sftp channel... > The server complains with a strange message "Received oclose for nonexistent channel 0." > > > Any idea? > > /Ali > > > Crash report below: > =================== > > 14> {ok,Pid,Conn}=ssh_sftp:start_channel("myhost",22,[{user,"myuser"},{password,"mypass"}]). > {ok,<0.76.0>,<0.73.0>} > 15> ssh_sftp:stop_channel(Pid). > ok > 16> > =ERROR REPORT==== 18-Jun-2011::22:37:04 === > ** Generic server <0.73.0> terminating > ** Last message in was {ssh_msg,<0.74.0>, > {ssh_msg_disconnect,2, > "Received oclose for nonexistent channel 0.", > []}} > ** When Server state == {state,client,<0.32.0>,undefined,<0.74.0>, > {connection,[],32784,[],[],1,undefined,undefined, > undefined,undefined,undefined,undefined}, > 0, > [{address,"myhost"}, > {port,22}, > {role,client}, > {channel_pid,<0.32.0>}, > {socket_opts,[inet6]}, > {ssh_opts, > [{host,"myhost"}, > {password,"mypass"}, > {user,"myuser"}]}], > undefined,true} > ** Reason for termination == > ** {noproc,{gen_server,call,[undefined,which_children,infinity]}} > > =ERROR REPORT==== 18-Jun-2011::22:37:04 === > ** Generic server <0.72.0> terminating > ** Last message in was {'EXIT',<0.73.0>, > {noproc, > {gen_server,call, > [undefined,which_children,infinity]}}} > ** When Server state == {state,client,<0.73.0>,<0.74.0>,undefined} > ** Reason for termination == > ** {noproc,{gen_server,call,[undefined,which_children,infinity]}} > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From ingela@REDACTED Mon Jun 20 10:52:01 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 20 Jun 2011 10:52:01 +0200 Subject: [erlang-bugs] SSL socket not sending ssl_closed/ssl_error after a crash In-Reply-To: References: Message-ID: <4DFF0A31.1050107@erix.ericsson.se> Hi! Well inet:getopts had a somwhat unexpexted behaviour (although documented when I looked a little closer) "An error tuple is only returned when getting options for the socket is impossible (i.e. the socket is closed or the buffer size in a raw request is too large). This behavior is kept for backward compatibility reasons." So we will add catch for inet:getopts in ssl. Regards Ingela Erlang/OTP team - Ericsson AB Richard Jones wrote: > After making an SSL connection to a remote server, and setting the > socket {active, true}, I'm able to crash the gen_fsm that is part of > the ssl socket, without receiving ssl_closed, ssl_error or an EXIT > signal in the controlling process. This will cause the crash: > ssl:getopts(Sock, some_invalid_atom_here). > > Presumably this should be impossible? I want to rely on receiving > ssl_closed or ssl_error so my controlling process can shut down when > the socket closes or crashes. > > I've had a process leak due to this problem - ssl sockets closing, and > my code not noticing, leaving idle processes lingering. I'm not > triggering it in production using getopts/2 as below, but something > similar is happening somehow. > > I've included some example code below, and a rather hefty error report > it generates. > > Am I doing something daft, or is this a bug? > > Regards, > RJ > > > Code, or with highlighting at http://ideone.com/T2ys0 > ===== > > > -module(ssltest). > > -compile(export_all). > > start() -> > application:start(sasl), > application:start(crypto), > application:start(public_key), > application:start(ssl), > %% Just using github as a publicly available ssl port to for a demo: > Opts = [list, {packet, line}, {active, false}], > {ok, Sock} = ssl:connect("github.com", 443, Opts), > Pid = spawn(fun client/0), > ok = ssl:controlling_process(Sock, Pid), > Pid ! {give, Sock}, > timer:sleep(1000), > crash_weirdly(Sock), > timer:sleep(1000), > %% By now the client process should have received a ssl_closed/error msg > %% but it doesnt get one, and is thus still running. > case process_info(Pid) of > undefined -> > io:format("OK\n",[]), > exit(normal); > Props -> > io:format("FAIL - no message received, process_info(~p):\n~p\n", > [Pid, Props]), > exit(fail) > end. > > %% This appears to crash the gen_fsm of the ssl socket > %% but doesn't trigger a {ssl_closed, Sock} msg, or 'EXIT' > %% There are probably other ways it can crash like this too. > crash_weirdly(Sock) -> > io:format("Crashing SSL socket\n", []), > catch ssl:getopts(Sock, some_invalid_atom_here). > > > %% This process becomes the owner of the socket, and needs to terminate when > %% the socket is closed. > client() -> > process_flag(trap_exit, true), > %% Wait for controlling_process to be set: > receive > {give, Sock} -> > ssl:setopts(Sock, [{active, true}]), > io:format("Pid: ~p Sock: ~p made {active,true}\n", [self(),Sock]), > recv_loop() > end. > > > recv_loop() -> > receive > {ssl_closed, _} -> > io:format("GOT SSL_CLOSED\n", []), > ok; > > {ssl_error, _, Reason} -> > io:format("GOT SSL_ERROR ~p\n", [Reason]), > ok; > > X -> > io:format("GOT: ~p\n", [X]), > recv_loop() > end. > > > > > =ERROR REPORT==== 17-Jun-2011::22:44:33 === > ** State machine <0.142.0> terminating > ** Last message in was {'$gen_sync_all_state_event', > {<0.135.0>,#Ref<0.0.0.666>}, > {get_opts,some_invalid_atom_here}} > ** When State == connection > ** Data == {state,client, > {#Ref<0.0.0.662>,<0.143.0>}, > gen_tcp,tcp,tcp_closed,tcp_error,"github.com",443, > #Port<0.2884>, > {ssl_options,[],verify_none,#Fun,false, > false,undefined,1,[],[],undefined,undefined,[], > undefined, > [<<0,57>>, > <<0,56>>, > <<0,53>>, > <<0,22>>, > <<0,19>>, > <<0,10>>, > <<0,51>>, > <<0,50>>, > <<0,47>>, > <<0,5>>, > <<0,4>>, > <<0,21>>, > <<0,9>>], > #Fun,true,18446744073709551900,false, > []}, > {socket_options,list,line,0,0,true}, > {connection_states, > {connection_state, > {security_parameters, > <<0,53>>, > 1,7,1,16,256,32,unknown,2,20,0, > <<254,226,8,153,158,133,167,137,122,65,223,95, > 199,62,150,14,245,185,34,18,222,22,80,53, > 144,55,219,45,219,144,154,61,115,146,69,154, > 169,92,12,70,174,132,26,179,172,211,57,46>>, > <<77,251,202,192,105,255,244,98,162,152,147, > 244,74,171,108,19,241,117,195,42,111,43,65, > 254,226,214,61,144,22,62,205,97>>, > <<77,251,202,192,60,117,73,65,49,38,238,91,11, > 208,144,28,154,0,211,16,126,128,35,92,106, > 253,30,96,72,8,185,60>>, > undefined}, > undefined, > {cipher_state, > <<107,193,209,70,14,51,191,243,6,30,235,102, > 177,66,108,91>>, > <<82,122,121,50,67,146,95,105,141,89,204,41, > 100,220,66,0,155,39,193,179,77,82,117,3,82, > 50,239,196,223,45,153,192>>, > undefined}, > <<138,74,111,39,183,247,74,90,128,251,163,51,162, > 134,187,95,239,150,95,60>>, > 1,true, > <<199,217,7,37,129,205,108,88,226,52,211,51>>, > <<112,230,216,51,212,101,251,25,135,84,199,203>>}, > {connection_state, > {security_parameters,undefined,1,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined, > <<77,251,202,192,89,182,0,44,93,225,217,162, > 14,42,169,222,17,209,142,212,247,18,33,182, > 63,47,102,161,116,187,144,170>>, > undefined,undefined}, > undefined,undefined,undefined,undefined,true, > undefined,undefined}, > {connection_state, > {security_parameters, > <<0,53>>, > 1,7,1,16,256,32,unknown,2,20,0, > <<254,226,8,153,158,133,167,137,122,65,223,95, > 199,62,150,14,245,185,34,18,222,22,80,53, > 144,55,219,45,219,144,154,61,115,146,69,154, > 169,92,12,70,174,132,26,179,172,211,57,46>>, > <<77,251,202,192,105,255,244,98,162,152,147, > 244,74,171,108,19,241,117,195,42,111,43,65, > 254,226,214,61,144,22,62,205,97>>, > <<77,251,202,192,60,117,73,65,49,38,238,91,11, > 208,144,28,154,0,211,16,126,128,35,92,106, > 253,30,96,72,8,185,60>>, > undefined}, > undefined, > {cipher_state, > <<67,15,24,23,53,236,18,90,72,41,97,211,175, > 56,148,242>>, > <<88,144,90,102,28,113,30,48,224,50,164,48,94, > 43,35,54,0,203,91,66,113,135,169,4,52,9,154, > 82,90,15,250,71>>, > undefined}, > <<97,53,165,232,130,210,58,150,35,107,110,217,252, > 26,77,201,16,112,28,231>>, > 1,true, > <<199,217,7,37,129,205,108,88,226,52,211,51>>, > <<112,230,216,51,212,101,251,25,135,84,199,203>>}, > {connection_state, > {security_parameters,undefined,1,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined, > <<77,251,202,192,28,184,76,68,123,76,60,142, > 106,240,173,4,49,192,225,191,249,104,4,239, > 222,69,131,35,191,245,19,1>>, > undefined,undefined}, > undefined,undefined,undefined,undefined,true, > undefined,undefined}}, > [],<<>>,<<>>, > {{<<127,40,71,77,128,20,238,48,237,90,195,130,105,141,116, > 224,32,128,0,0,0,0,0,0,135,84,199,203,0,0,0,0,0,0,0,0, > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,0, > 0,0>>, > <<241,223,170,74,130,30,208,157,176,34,157,47,22,53, > 101,223,229,36,29,122,32,128,0,0,0,0,0,0,135,84,199, > 203,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, > 0,0,0,0,0,0,0,0,0,0,4,0,0,0>>}, > {<<28,22,93,1,181,148,104,2,201,120,127,203,130,141,153, > 239,160,127,0,0,0,0,0,0,52,27,250,73,248,152,87,65, > 188,19,124,110,164,44,199,195,178,69,135,100,166,29, > 53,1,4,61,203,149,153,73,127,74,49,89,99,113,20,0,0, > 12,199,217,7,37,129,205,108,88,226,52,211,51,0,0,0,0, > 0,0,0,0,0,0,0,0,52,0,0,0>>, > <<28,51,142,246,15,126,227,240,185,11,6,135,7,54,173, > 1,97,186,89,238,160,127,0,0,0,0,0,0,52,27,250,73, > 248,152,87,65,188,19,124,110,164,44,199,195,178,69, > 135,100,166,29,53,1,4,61,203,149,153,73,127,74,49, > 89,99,113,20,0,0,12,199,217,7,37,129,205,108,88,226, > 52,211,51,0,0,0,0,0,0,0,0,0,0,0,0,52,0,0,0>>}}, > [],undefined, > {session, > <<93,85,39,160,113,79,61,119,168,42,21,212,128,173,57, > 245,196,81,177,34,215,105,207,104,143,170,179,33, > 205,107,59,108>>, > <<48,130,7,42,48,130,6,18,160,3,2,1,2,2,16,14,119,118, > 138,93,7,240,229,121,89,202,42,157,80,130,181,48,13, > 6,9,42,134,72,134,247,13,1,1,5,5,0,48,105,49,11,48, > 9,6,3,85,4,6,19,2,85,83,49,21,48,19,6,3,85,4,10,19, > 12,68,105,103,105,67,101,114,116,32,73,110,99,49,25, > 48,23,6,3,85,4,11,19,16,119,119,119,46,100,105,103, > 105,99,101,114,116,46,99,111,109,49,40,48,38,6,3,85, > 4,3,19,31,68,105,103,105,67,101,114,116,32,72,105, > 103,104,32,65,115,115,117,114,97,110,99,101,32,69, > 86,32,67,65,45,49,48,30,23,13,49,49,48,53,50,55,48, > 48,48,48,48,48,90,23,13,49,51,48,55,50,57,49,50,48, > 48,48,48,90,48,129,202,49,29,48,27,6,3,85,4,15,12, > 20,80,114,105,118,97,116,101,32,79,114,103,97,110, > 105,122,97,116,105,111,110,49,19,48,17,6,11,43,6,1, > 4,1,130,55,60,2,1,3,19,2,85,83,49,27,48,25,6,11,43, > 6,1,4,1,130,55,60,2,1,2,19,10,67,97,108,105,102,111, > 114,110,105,97,49,17,48,15,6,3,85,4,5,19,8,67,51,50, > 54,56,49,48,50,49,11,48,9,6,3,85,4,6,19,2,85,83,49, > 19,48,17,6,3,85,4,8,19,10,67,97,108,105,102,111,114, > 110,105,97,49,22,48,20,6,3,85,4,7,19,13,83,97,110, > 32,70,114,97,110,99,105,115,99,111,49,21,48,19,6,3, > 85,4,10,19,12,71,105,116,72,117,98,44,32,73,110,99, > 46,49,19,48,17,6,3,85,4,3,19,10,103,105,116,104,117, > 98,46,99,111,109,48,130,1,34,48,13,6,9,42,134,72, > 134,247,13,1,1,1,5,0,3,130,1,15,0,48,130,1,10,2,130, > 1,1,0,237,211,137,195,93,112,114,9,243,51,79,26,114, > 116,217,182,90,149,80,187,104,97,159,247,251,31,25, > 225,218,4,49,175,21,124,26,127,249,115,175,29,229, > 67,43,86,9,0,69,105,74,232,196,91,223,194,119,82,81, > 25,91,209,43,217,57,101,54,160,50,25,28,65,115,251, > 50,178,61,159,152,236,130,91,11,55,100,57,44,183,16, > 131,114,205,240,234,36,75,250,217,148,46,195,133,21, > 57,169,58,246,136,218,244,39,137,166,149,79,132,162, > 55,78,124,37,120,58,201,131,109,2,23,149,120,125,71, > 168,85,131,238,19,200,25,26,179,60,241,95,254,59,2, > 225,133,251,17,102,171,9,93,159,76,67,240,199,36,94, > 41,114,40,206,212,117,104,79,36,114,41,174,57,40, > 252,223,141,79,77,131,115,116,12,111,17,155,167,221, > 98,222,255,226,235,23,230,255,12,191,192,45,49,59, > 214,89,162,242,221,135,74,72,123,109,51,17,20,77,52, > 159,50,56,246,200,25,157,241,182,61,197,70,239,81, > 11,138,198,51,237,72,97,196,29,23,27,189,124,182, > 103,233,57,207,165,82,128,10,244,234,205,2,3,1,0,1, > 163,130,3,106,48,130,3,102,48,31,6,3,85,29,35,4,24, > 48,22,128,20,76,88,203,37,240,65,79,82,244,40,200, > 129,67,155,166,168,160,230,146,229,48,29,6,3,85,29, > 14,4,22,4,20,135,209,143,25,110,228,135,111,83,140, > 119,145,7,80,223,163,191,85,71,32,48,37,6,3,85,29, > 17,4,30,48,28,130,10,103,105,116,104,117,98,46,99, > 111,109,130,14,119,119,119,46,103,105,116,104,117, > 98,46,99,111,109,48,129,129,6,8,43,6,1,5,5,7,1,1,4, > 117,48,115,48,36,6,8,43,6,1,5,5,7,48,1,134,24,104, > 116,116,112,58,47,47,111,99,115,112,46,100,105,103, > 105,99,101,114,116,46,99,111,109,48,75,6,8,43,6,1,5, > 5,7,48,2,134,63,104,116,116,112,58,47,47,119,119, > 119,46,100,105,103,105,99,101,114,116,46,99,111,109, > 47,67,65,67,101,114,116,115,47,68,105,103,105,67, > 101,114,116,72,105,103,104,65,115,115,117,114,97, > 110,99,101,69,86,67,65,45,49,46,99,114,116,48,12,6, > 3,85,29,19,1,1,255,4,2,48,0,48,97,6,3,85,29,31,4,90, > 48,88,48,42,160,40,160,38,134,36,104,116,116,112,58, > 47,47,99,114,108,51,46,100,105,103,105,99,101,114, > 116,46,99,111,109,47,101,118,50,48,48,57,97,46,99, > 114,108,48,42,160,40,160,38,134,36,104,116,116,112, > 58,47,47,99,114,108,52,46,100,105,103,105,99,101, > 114,116,46,99,111,109,47,101,118,50,48,48,57,97,46, > 99,114,108,48,130,1,196,6,3,85,29,32,4,130,1,187,48, > 130,1,183,48,130,1,179,6,9,96,134,72,1,134,253,108, > 2,1,48,130,1,164,48,58,6,8,43,6,1,5,5,7,2,1,22,46, > 104,116,116,112,58,47,47,119,119,119,46,100,105,103, > 105,99,101,114,116,46,99,111,109,47,115,115,108,45, > 99,112,115,45,114,101,112,111,115,105,116,111,114, > 121,46,104,116,109,48,130,1,100,6,8,43,6,1,5,5,7,2, > 2,48,130,1,86,30,130,1,82,0,65,0,110,0,121,0,32,0, > 117,0,115,0,101,0,32,0,111,0,102,0,32,0,116,0,104,0, > 105,0,115,0,32,0,67,0,101,0,114,0,116,0,105,0,102,0, > 105,0,99,0,97,0,116,0,101,0,32,0,99,0,111,0,110,0, > 115,0,116,0,105,0,116,0,117,0,116,0,101,0,115,0,32, > 0,97,0,99,0,99,0,101,0,112,0,116,0,97,0,110,0,99,0, > 101,0,32,0,111,0,102,0,32,0,116,0,104,0,101,0,32,0, > 68,0,105,0,103,0,105,0,67,0,101,0,114,0,116,0,32,0, > 67,0,80,0,47,0,67,0,80,0,83,0,32,0,97,0,110,0,100,0, > 32,0,116,0,104,0,101,0,32,0,82,0,101,0,108,0,121,0, > 105,0,110,0,103,0,32,0,80,0,97,0,114,0,116,0,121,0, > 32,0,65,0,103,0,114,0,101,0,101,0,109,0,101,0,110,0, > 116,0,32,0,119,0,104,0,105,0,99,0,104,0,32,0,108,0, > 105,0,109,0,105,0,116,0,32,0,108,0,105,0,97,0,98,0, > 105,0,108,0,105,0,116,0,121,0,32,0,97,0,110,0,100,0, > 32,0,97,0,114,0,101,0,32,0,105,0,110,0,99,0,111,0, > 114,0,112,0,111,0,114,0,97,0,116,0,101,0,100,0,32,0, > 104,0,101,0,114,0,101,0,105,0,110,0,32,0,98,0,121,0, > 32,0,114,0,101,0,102,0,101,0,114,0,101,0,110,0,99,0, > 101,0,46,48,29,6,3,85,29,37,4,22,48,20,6,8,43,6,1,5, > 5,7,3,1,6,8,43,6,1,5,5,7,3,2,48,17,6,9,96,134,72,1, > 134,248,66,1,1,4,4,3,2,6,192,48,14,6,3,85,29,15,1,1, > 255,4,4,3,2,5,160,48,13,6,9,42,134,72,134,247,13,1, > 1,5,5,0,3,130,1,1,0,20,82,113,31,134,157,109,53,62, > 134,187,102,26,139,133,152,185,0,76,203,66,181,70, > 252,6,231,68,57,200,232,82,216,17,20,35,179,114,150, > 233,20,148,158,47,0,40,247,213,4,69,64,0,198,244,87, > 66,66,222,9,137,151,17,13,20,92,107,189,11,247,24, > 163,95,103,2,243,9,56,99,191,193,18,157,48,186,142, > 165,84,116,89,83,103,161,27,80,91,38,218,253,19,126, > 89,23,191,73,239,148,126,69,164,253,58,73,50,240, > 106,255,137,141,169,97,169,170,155,150,70,200,28, > 224,24,28,230,251,130,244,10,171,82,166,202,232,84, > 34,217,219,42,61,90,34,123,128,234,7,5,212,249,199, > 240,83,89,95,187,119,126,222,147,112,65,78,35,203, > 120,121,121,196,46,234,215,102,42,24,247,209,197, > 124,226,18,120,130,141,29,236,130,158,1,162,229,2, > 190,120,161,185,89,88,197,76,111,79,165,49,180,73, > 91,94,152,30,46,56,246,25,196,57,162,74,251,121,5, > 184,242,89,229,38,18,112,173,192,232,117,35,31,24, > 209,11,224,159,101,228,195,215,73,135,91,114,108, > 177,47,172,111>>, > 0, > <<0,53>>, > <<254,226,8,153,158,133,167,137,122,65,223,95,199,62, > 150,14,245,185,34,18,222,22,80,53,144,55,219,45,219, > 144,154,61,115,146,69,154,169,92,12,70,174,132,26, > 179,172,211,57,46>>, > true,undefined}, > 20499,ssl_session_cache, > {3,1}, > undefined,false,rsa, > {{1,2,840,113549,1,1,1}, > {'RSAPublicKey', > > 30022791620261825757993662585953092115593876007790889075857977169380755026843488295590920332822959949671733783772267273663127572234689557556838440961311958034872446138607383478249154120700224788846090518954426547213891114527577249466052578760409101386764739954597264062457764350325580813575208479828785125746659984354118047108089208903185979168757084287242652658664280506839310200006418365390463140656501936394629471169620807647477079812243508155549460290614662952471527791986452768187753921075252815690139573016552982548499689965311352938938970566167612062244558031493494815274290207588576741886915392581117360270029, > 65537}, > 'NULL'}, > undefined,undefined,undefined, > <<3,1,206,145,41,17,221,72,203,148,200,153,94,83,137,250, > 208,132,136,231,216,156,242,214,230,137,138,173,184,97, > 148,200,195,6,175,5,154,136,35,172,78,163,255,27,208,67, > 35,188>>, > #Ref<0.0.0.656>, > {<0.135.0>,#Ref<0.0.0.659>}, > 0,<<>>,true,undefined,false, > {[],[]}} > ** Reason for termination = > ** {function_clause,[{ssl_connection,get_socket_opts, > [#Port<0.2884>,some_invalid_atom_here, > {socket_options,list,line,0,0,true}, > []]}, > {ssl_connection,handle_sync_event,4}, > {gen_fsm,handle_msg,7}, > {proc_lib,init_p_do_apply,3}]} > > =CRASH REPORT==== 17-Jun-2011::22:44:33 === > crasher: > initial call: ssl_connection:init/1 > pid: <0.142.0> > registered_name: [] > exception exit: {function_clause, > [{ssl_connection,get_socket_opts, > [#Port<0.2884>,some_invalid_atom_here, > {socket_options,list,line,0,0,true}, > []]}, > {ssl_connection,handle_sync_event,4}, > {gen_fsm,handle_msg,7}, > {proc_lib,init_p_do_apply,3}]} > in function gen_fsm:terminate/7 > ancestors: [ssl_connection_sup,ssl_sup,<0.59.0>] > messages: [] > links: [<0.63.0>] > dictionary: [] > trap_exit: false > status: running > heap_size: 1597 > stack_size: 24 > reductions: 9050 > neighbours: > > =SUPERVISOR REPORT==== 17-Jun-2011::22:44:33 === > Supervisor: {local,ssl_connection_sup} > Context: child_terminated > Reason: {function_clause, > [{ssl_connection,get_socket_opts, > [#Port<0.2884>,some_invalid_atom_here, > {socket_options,list,line,0,0,true}, > []]}, > {ssl_connection,handle_sync_event,4}, > {gen_fsm,handle_msg,7}, > {proc_lib,init_p_do_apply,3}]} > Offender: [{pid,<0.142.0>}, > {name,undefined}, > {mfargs, > {ssl_connection,start_link, > [client,"github.com",443,#Port<0.2884>, > {{ssl_options,[],verify_none, > #Fun,false,false,undefined,1, > [],[],undefined,[],[],undefined, > [<<0,57>>, > <<0,56>>, > <<0,53>>, > <<0,22>>, > <<0,19>>, > <<0,10>>, > <<0,51>>, > <<0,50>>, > <<0,47>>, > <<0,5>>, > <<0,4>>, > <<0,21>>, > <<0,9>>], > #Fun,true, > 18446744073709551900,false,[]}, > {socket_options,list,line,0,0,false}}, > <0.135.0>, > {gen_tcp,tcp,tcp_closed,tcp_error}]}}, > {restart_type,temporary}, > {shutdown,4000}, > {child_type,worker}] > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From gopienko@REDACTED Mon Jun 20 14:19:53 2011 From: gopienko@REDACTED (Andrew Gopienko) Date: Mon, 20 Jun 2011 19:19:53 +0700 Subject: [erlang-bugs] Code path of application Message-ID: Hi, Code path of application can specify to old location after release upgrade. It's possible if we change only vsn of application, no erlang code of modules is changed. (In my case under priv directory I have JavaScript code). Generated relup doesnt contains instructions for reload application... no 'load_object_code,{OurApp,NewVsn,Mods}'. After release upgraded we have: application:loaded_applications() .... {OurApp,Description,NewVsn} .... but code:priv_dir(OurApp) points to old location. If relup contains {OurApp,NewVsn,[]} then location of application is correctly updated. Andrew Gopienko ThreeLine LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Mon Jun 20 14:57:52 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Mon, 20 Jun 2011 14:57:52 +0200 Subject: [erlang-bugs] Code path of application In-Reply-To: References: Message-ID: Hi Andrew - thanks for reporting this. I will have a look at it. Regards siri@REDACTED 2011/6/20 Andrew Gopienko > Hi, > > Code path of application can specify to old location after release upgrade. > > It's possible if we change only vsn of application, no erlang code of > modules is changed. (In my case under priv directory I have JavaScript > code). > > Generated relup doesnt contains instructions for reload application... > no 'load_object_code,{OurApp,NewVsn,Mods}'. > > After release upgraded we have: > application:loaded_applications() > .... > {OurApp,Description,NewVsn} > .... > > but > > code:priv_dir(OurApp) points to old location. > > If relup contains {OurApp,NewVsn,[]} then location of application is correctly > updated. > > > Andrew Gopienko > ThreeLine LLC > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Mon Jun 20 15:37:33 2011 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 20 Jun 2011 15:37:33 +0200 Subject: [erlang-bugs] Code server does not correctly handle case sensitivity In-Reply-To: <4DFB38F8.9080406@erlang-solutions.com> References: <4DF71305.8050503@erlang-solutions.com> <4DF74D13.8030509@erlang-solutions.com> <4DFB38F8.9080406@erlang-solutions.com> Message-ID: On Fri, Jun 17, 2011 at 1:22 PM, Adam Lindberg wrote: > So, bug in Erlang or just how it's supposed to "work" when the file system > is case insensitive? This is how it's supposed to "work" and as erlc fails on name mismatch the code server correctly expects beam_filename=:=module_name. From adam@REDACTED Tue Jun 21 10:41:31 2011 From: adam@REDACTED (Adam Lindberg) Date: Tue, 21 Jun 2011 10:41:31 +0200 Subject: [erlang-bugs] Code server does not correctly handle case sensitivity In-Reply-To: References: <4DF71305.8050503@erlang-solutions.com> <4DF74D13.8030509@erlang-solutions.com> <4DFB38F8.9080406@erlang-solutions.com> Message-ID: <4E00593B.2040801@erlang-solutions.com> Yes, since the file system is case insensitive there's no way for Erlang to know that an upper case file was requested. I guess {error, badfile} is acceptable in that case. Cheers, Adam Tuncer Ayaz wrote: > On Fri, Jun 17, 2011 at 1:22 PM, Adam Lindberg wrote: >> So, bug in Erlang or just how it's supposed to "work" when the file system >> is case insensitive? > > This is how it's supposed to "work" and as erlc fails on name mismatch > the code server correctly expects beam_filename=:=module_name. From hpjcon@REDACTED Tue Jun 21 20:06:43 2011 From: hpjcon@REDACTED (Jan Jacobs) Date: Tue, 21 Jun 2011 20:06:43 +0200 Subject: [erlang-bugs] SSL cache delete bug. Message-ID: <4E00DDB3.6070702@mweb.co.za> Hi, I am getting a lot of the following errors in the log files: =ERROR REPORT==== 20-Jun-2011::05:27:31 === Error in process <0.1702.0> on node 'maxman@REDACTED' with exit value: {undef,[{ssl_session_cache,delete,[{8088,<<32 bytes>>}]}]} I managed to track it down to: In the ssl_manager.erl, lines 273 and 280 it sets up timer to clean the cache. (see below) Line 273: timer:apply_after(?CLEAN_SESSION_DB, CacheCb, delete, [{{Host, Port}, ID}]), Line 280: timer:apply_after(?CLEAN_SESSION_DB, CacheCb, delete, [{Port, ID}]), CacheCB is equal to ssl_session_cache.erl. ssl_session_cache.erl only has a two parameter delete (delete(Cache, Key)). The Cache is not been passed as the first parameter. Cheers Jan From robert.virding@REDACTED Wed Jun 22 04:17:37 2011 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 22 Jun 2011 02:17:37 +0000 (GMT) Subject: [erlang-bugs] QLC bug In-Reply-To: <321477349.323561308706123905.JavaMail.root@zimbra> Message-ID: <1377766900.323581308709057663.JavaMail.root@zimbra> If you generate the expansion from the example in documentation: qlc:q([{A,X,Z,W} || A <- [a,b,c], {X,Z} <- [{a,1},{b,4},{c,6}], {W,Y} <- [{2,a},{3,b},{4,c}], X =:= Y]). and then from the equivalent canonical form: qlc:q([{A,X,Z,W} || A <- [a,b,c], {X,Z} <- [{a,1},{b,4},{c,6}], {W,Y} <- [{2,a},{3,b},{4,c}], erlang:'=:='(X, Y)]). you find that they are VERY different. The first one is much larger with more cases in it. I don't know if they are equivalent. Note that this is *exactly the same code* with just a different way of writing the equality test. If they are not equivalent then it is definitely a bug as both forms are equivalent, X =:= Y is just the operator syntax for the canonical form erlang:'=:='(X, Y). Even if they are equivalent then it is probably also as bug as there is no reason for the expansions to be different as again the code is the same. A quick idea as to why it is like this is that the special handling of operators is done before it is converted into the canonical form. Robert -- Robert Virding, Erlang Solutions Ltd. From ali.yakout@REDACTED Wed Jun 22 07:12:39 2011 From: ali.yakout@REDACTED (Ali Yakout) Date: Wed, 22 Jun 2011 07:12:39 +0200 Subject: [erlang-bugs] ssh_sftp:stop_channel/1 tampers trap_exit flag In-Reply-To: References: <591FA96352AC9946A403D860A601665216CF04A629@ESESSCMS0357.eemea.ericsson.se> Message-ID: <591FA96352AC9946A403D860A601665216CF09B0F2@ESESSCMS0357.eemea.ericsson.se> Hi Niclas, You are right, this seems to be a problem with the version I'm using SSH-2.0.1/R14B. The stop_channel/1 is running fine with the latest SSH-2.0.7 Thanks for the feedback. Regards, Ali -----Original Message----- From: Niclas Eklund [mailto:nick@REDACTED] Sent: Monday, June 20, 2011 1:32 PM To: Ali Yakout Cc: erlang-bugs@REDACTED Subject: Re: [erlang-bugs] ssh_sftp:stop_channel/1 tampers trap_exit flag Hello! The crash report should be related to a bug that was fixed some time ago. Are you sure that you're running the latest SSH version (2.0.7)?! Best regards, Niclas @ Erlang/OTP On Sun, 19 Jun 2011, Ali Yakout wrote: > Hi, > > I was facing a problem with ssh_sftp:stop_channel/1, while checking the code I noticed that it changes the trap_exit to be always true! > >> stop_channel(Pid) -> >> case process_info(Pid, [trap_exit]) of >> [{trap_exit, Bool}] -> >> ... >> process_flag(trap_exit, Bool), > > > I think 'Pid' should have been self() instead. > >> stop_channel(Pid) -> >> case process_info(self(), [trap_exit]) of > > > > Beside this issue, I'm getting a 'gen_server' noproc crash when trying to close the sftp channel... > The server complains with a strange message "Received oclose for nonexistent channel 0." > > > Any idea? > > /Ali > > > Crash report below: > =================== > > 14> {ok,Pid,Conn}=ssh_sftp:start_channel("myhost",22,[{user,"myuser"},{password,"mypass"}]). > {ok,<0.76.0>,<0.73.0>} > 15> ssh_sftp:stop_channel(Pid). > ok > 16> > =ERROR REPORT==== 18-Jun-2011::22:37:04 === > ** Generic server <0.73.0> terminating > ** Last message in was {ssh_msg,<0.74.0>, > {ssh_msg_disconnect,2, > "Received oclose for nonexistent channel 0.", > []}} > ** When Server state == {state,client,<0.32.0>,undefined,<0.74.0>, > {connection,[],32784,[],[],1,undefined,undefined, > undefined,undefined,undefined,undefined}, > 0, > [{address,"myhost"}, > {port,22}, > {role,client}, > {channel_pid,<0.32.0>}, > {socket_opts,[inet6]}, > {ssh_opts, > [{host,"myhost"}, > {password,"mypass"}, > {user,"myuser"}]}], > undefined,true} > ** Reason for termination == > ** {noproc,{gen_server,call,[undefined,which_children,infinity]}} > > =ERROR REPORT==== 18-Jun-2011::22:37:04 === > ** Generic server <0.72.0> terminating > ** Last message in was {'EXIT',<0.73.0>, > {noproc, > {gen_server,call, > > [undefined,which_children,infinity]}}} > ** When Server state == {state,client,<0.73.0>,<0.74.0>,undefined} > ** Reason for termination == > ** {noproc,{gen_server,call,[undefined,which_children,infinity]}} > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From ingela@REDACTED Wed Jun 22 09:26:56 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 22 Jun 2011 09:26:56 +0200 Subject: [erlang-bugs] SSL cache delete bug. In-Reply-To: <4E00DDB3.6070702@mweb.co.za> References: <4E00DDB3.6070702@mweb.co.za> Message-ID: <4E019940.5090801@erix.ericsson.se> Hi! Yes this is a known bug. It has been fixed and pushed to github. ( Merge of branch ia/ssl/session-table-clean-up/OTP-9346) The bug should not affect your connections but the memory consumption on a long time perspective will go up. Regards Ingela Erlang/OTP - Ericsson AB Jan Jacobs wrote: > Hi, > > I am getting a lot of the following errors in the log files: > =ERROR REPORT==== 20-Jun-2011::05:27:31 === > Error in process <0.1702.0> on node 'maxman@REDACTED' with exit value: > {undef,[{ssl_session_cache,delete,[{8088,<<32 bytes>>}]}]} > > I managed to track it down to: > > In the ssl_manager.erl, lines 273 and 280 it sets up timer to clean > the cache. (see below) > Line 273: timer:apply_after(?CLEAN_SESSION_DB, CacheCb, delete, > [{{Host, Port}, ID}]), > Line 280: timer:apply_after(?CLEAN_SESSION_DB, CacheCb, delete, > [{Port, ID}]), > > CacheCB is equal to ssl_session_cache.erl. > ssl_session_cache.erl only has a two parameter delete (delete(Cache, > Key)). > The Cache is not been passed as the first parameter. > > Cheers > Jan > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From hpjcon@REDACTED Wed Jun 22 21:32:03 2011 From: hpjcon@REDACTED (Jan Jacobs) Date: Wed, 22 Jun 2011 21:32:03 +0200 Subject: [erlang-bugs] SSL cache delete bug. In-Reply-To: <4E019940.5090801@erix.ericsson.se> References: <4E00DDB3.6070702@mweb.co.za> <4E019940.5090801@erix.ericsson.se> Message-ID: <4E024333.4070203@mweb.co.za> An HTML attachment was scrubbed... URL: From vlm@REDACTED Sun Jun 26 01:31:15 2011 From: vlm@REDACTED (Lev Walkin) Date: Sat, 25 Jun 2011 16:31:15 -0700 Subject: [erlang-bugs] Erlang ASN.1 REAL value 0.0 decoding bug Message-ID: <4121C539-EA98-43F4-9B4D-621D3F2A7DF2@lionet.info> Hello, I discovered that the asn1ct code mishandles the REAL values. Here's a simple test case demonstrating inconsistency and mishandling of 0.0 floating point value. Consider the following ASN.1 module: RealTest DEFINITIONS ::= BEGIN Real ::= REAL RealWrapper ::= SEQUENCE { real REAL } END Running it through the asn1c to decode the 0.0 value encoded as NR3 and as X.690(07/2002)#8.5.2 (If the real value is the value zero, there shall be no contents octets in the encoding.) 1> asn1ct:compile('RealTest', []). ok 2> asn1ct:decode('RealTest', 'Real', [9,6,3,48,46,69,43,48]). {ok,"0.E+0"} 3> asn1ct:decode('RealTest', 'Real', [9,0]). {ok,0} % Until now everything is more or less OK. 4> asn1ct:decode('RealTest', 'RealWrapper', [48,8, 9,6,3,48,46,69,43,48]). {ok,{'RealWrapper',"0.E+0"}} % Here comes the trouble: 6> asn1ct:decode('RealTest', 'RealWrapper', [48,2, 9,0]). {error,{asn1,{{badmatch,{0,<<>>}}, [{'RealTest',dec_RealWrapper,3}, {'RealTest',decode,2}, {asn1rt,decode,3}, {erl_eval,do_apply,5}, {shell,exprs,7}, {shell,eval_exprs,7}, {shell,eval_loop,3}]}}} This example shows that the same encoding of the REAL value carrying value zero (0.0) results in a proper decoding when attempting to decode it through a typereference Real, yet generates an error when encoded as a field of a container (SEQUENCE, SET, etc). What should one expect? The consistent result is that line 6 should return {ok, {'RealWrapper', 0}}, which it doesn't. Please advise. -- Lev Walkin lionet.info/asn1c From ess@REDACTED Mon Jun 27 11:00:48 2011 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 27 Jun 2011 11:00:48 +0200 Subject: [erlang-bugs] beam_validator does not validate against circularity in constructed values In-Reply-To: References: Message-ID: <4E0846C0.1070705@trifork.com> The following function passes beam_validator verification, but constructs a recursive data structure: {module, beamtoying4}. %% version = 0 {exports, [{module_info,0},{module_info,1},{recdata,1}]}. {labels, 2}. {function, recdata, 1, 2}. {label,1}. {func_info,{atom,beamtoying4},{atom,recdata},1}. {label,2}. {test_heap,3,1}. {put_tuple,2,{x,1}}. {put,{x,0}}. {put,{x,1}}. {move,{x,1},{x,0}}. return. Demo: erik@REDACTED:q$ erlc beamtoying4.S erik@REDACTED:q$ erl Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:0] [kernel-poll:false] Eshell V5.8.1 (abort with ^G) 1> beamtoying4:recdata(x). {x, {x,{x,{x,{x,{x,{x,{x,{x,{x,{x,{x,{x,{x,{x,...}}}}}}}}}}}}}}} (The REPL is then stuck.) Regards, Erik S?e S?rensen From ess@REDACTED Mon Jun 27 11:15:28 2011 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 27 Jun 2011 11:15:28 +0200 Subject: [erlang-bugs] beam_validator does not validate against circularity in constructed values In-Reply-To: <4E0846C0.1070705@trifork.com> References: <4E0846C0.1070705@trifork.com> Message-ID: <4E084A30.707@trifork.com> The following function passes beam_validator verification, but calls a gc_bif while a tuple is not completely constructed. (I take it that that could wreak havoc in the interpreter and is thus illegal and technically a validator bug; I'm not completely certain of this though. Apologies if this is not a bug after all.) {module, beamtoying5}. %% version = 0 {exports, [{gc_in_cons,1},{gc_in_cons2,1}]}. {attributes, []}. {labels, 4}. {function, gc_in_cons, 1, 2}. {label,1}. {func_info,{atom,beamtoying5},{atom,gc_in_cons},1}. {label,2}. {test_heap,3,1}. {put_tuple,2,{x,1}}. {put,{atom,dummy}}. {gc_bif,'bnot',{f,0},1,[{x,0}],{x,0}}. {put,{x,0}}. {move,{x,1},{x,0}}. return. Another thing: If the "put dummy" instruction is moved down beside the "put x0" instruction, then we get a function which also passes beam_validator validation, yet results in the following error message when the module is loaded: =ERROR REPORT==== 27-Jun-2011::11:14:10 === Loading of /home/erik/kode/q/beamtoying5.beam failed: badfile {error,badfile} =ERROR REPORT==== 27-Jun-2011::11:14:10 === beam/beam_load.c(1771): Error loading function beamtoying5:gc_in_cons2/1: op put_tuple u x: no specific operation found because the instruction rewriter expects a "put" directly after a "put_tuple". Regards, Erik S?e S?rensen From ess@REDACTED Mon Jun 27 11:19:56 2011 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 27 Jun 2011 11:19:56 +0200 Subject: [erlang-bugs] beam_validator does not validate against GC during tuple construction (Was: something else) In-Reply-To: <4E084A30.707@trifork.com> References: <4E0846C0.1070705@trifork.com> <4E084A30.707@trifork.com> Message-ID: <4E084B3C.3080108@trifork.com> Sorry about the wrong subject originally -- I guess my laziness shows :-( This obviously not concerns circularity, but GC triggered at inoppportune times. Erik S?e S?rensen wrote: > The following function passes beam_validator verification, but calls a > gc_bif while a tuple is not completely constructed. > (I take it that that could wreak havoc in the interpreter and is thus > illegal and technically a validator bug; I'm not completely certain of > this though. Apologies if this is not a bug after all.) > > {module, beamtoying5}. %% version = 0 > {exports, [{gc_in_cons,1},{gc_in_cons2,1}]}. > {attributes, []}. > {labels, 4}. > > {function, gc_in_cons, 1, 2}. > {label,1}. > {func_info,{atom,beamtoying5},{atom,gc_in_cons},1}. > {label,2}. > {test_heap,3,1}. > {put_tuple,2,{x,1}}. > {put,{atom,dummy}}. > {gc_bif,'bnot',{f,0},1,[{x,0}],{x,0}}. > {put,{x,0}}. > {move,{x,1},{x,0}}. > return. > > Another thing: If the "put dummy" instruction is moved down beside the > "put x0" instruction, then we get a function which also passes > beam_validator validation, yet results in the following error message > when the module is loaded: > > =ERROR REPORT==== 27-Jun-2011::11:14:10 === > Loading of /home/erik/kode/q/beamtoying5.beam failed: badfile > {error,badfile} > > =ERROR REPORT==== 27-Jun-2011::11:14:10 === > beam/beam_load.c(1771): Error loading function > beamtoying5:gc_in_cons2/1: op put_tuple u x: > no specific operation found > > because the instruction rewriter expects a "put" directly after a > "put_tuple". > > > Regards, > Erik S?e S?rensen > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From dcoppa@REDACTED Mon Jun 27 11:37:32 2011 From: dcoppa@REDACTED (David Coppa) Date: Mon, 27 Jun 2011 11:37:32 +0200 Subject: [erlang-bugs] Unaligned memory access on sparc64 Message-ID: <20110627093732.GA5560@latitude.dacolab.dom> Hi all, There's an unaligned memory access into lib/erl_interface/src/connect/ei_resolve.c that causes a SIGBUS crash on sparc64. The following backtrace is from R13B04, but the code has not changed, so this bug is still present. $ gdb erl_call /usr/ports/pobj/rabbitmq-2.5.0/rabbitmq-server-2.5.0/erl_call.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-unknown-openbsd4.9"... Core was generated by `erl_call'. Program terminated with signal 10, Bus error. Reading symbols from /usr/lib/libpthread.so.13.1...done. Loaded symbols for /usr/lib/libpthread.so.13.1 Reading symbols from /usr/lib/libc.so.58.3...done. Loaded symbols for /usr/lib/libc.so.58.3 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x000000000010d32c in copy_hostent (dest=0xfffffffffffce780, src=0x20fc2d8c0, buffer=0xfffffffffffce9ac "", buflen=996) at connect/ei_resolve.c:224 224 *pptr = src_aliases; (gdb) bt #0 0x000000000010d32c in copy_hostent (dest=0xfffffffffffce780, src=0x20fc2d8c0, buffer=0xfffffffffffce9ac "", buflen=996) at connect/ei_resolve.c:224 #1 0x000000000010d790 in my_gethostbyname_r (name=0xfffffffffffcfa1f "vulcan", hostp=0xfffffffffffce950, buffer=0xfffffffffffce990 "vulcan.*****.*******.***", buflen=1024, h_errnop=0xfffffffffffce98c) at connect/ei_resolve.c:319 #2 0x000000000010db18 in ei_gethostbyname_r (name=0xfffffffffffcfa1f "vulcan", hostp=0xfffffffffffce950, buffer=0xfffffffffffce990 "vulcan.*****.*******.***", buflen=1024, h_errnop=0xfffffffffffce98c) at connect/ei_resolve.c:629 #3 0x0000000000108580 in ei_connect_tmo (ec=0xfffffffffffcf4fc, nodename=0xfffffffffffcfa10 "rabbitmq-check@REDACTED", ms=0) at connect/ei_connect.c:604 #4 0x00000000001087e8 in ei_connect (ec=0xfffffffffffcf4fc, nodename=0xfffffffffffcfa10 "rabbitmq-check@REDACTED") at connect/ei_connect.c:659 #5 0x00000000001046e8 in main (argc=5, argv=0xfffffffffffcfc88) at prog/erl_call.c:384 (gdb) thread apply all bt full Thread 1 (process 26785): #0 0x000000000010d32c in copy_hostent (dest=0xfffffffffffce780, src=0x20fc2d8c0, buffer=0xfffffffffffce9ac "", buflen=996) at connect/ei_resolve.c:224 pptr = (char **) 0xfffffffffffce9ac len = 24 src_aliases = (char **) 0x20fc2d8e0 src_addr_list = (char **) 0x0 #1 0x000000000010d790 in my_gethostbyname_r (name=0xfffffffffffcfa1f "vulcan", hostp=0xfffffffffffce950, buffer=0xfffffffffffce990 "vulcan.*****.*******.***", buflen=1024, h_errnop=0xfffffffffffce98c) at connect/ei_resolve.c:319 dest = {h_name = 0xfffffffffffce990 "vulcan.*****.*******.***", h_aliases = 0xfffffffffffce9ac, h_addrtype = 2, h_length = 4, h_addr_list = 0x21fb20} src = (struct hostent *) 0x20fc2d8c0 rval = (struct hostent *) 0x0 #2 0x000000000010db18 in ei_gethostbyname_r (name=0xfffffffffffcfa1f "vulcan", hostp=0xfffffffffffce950, buffer=0xfffffffffffce990 "vulcan.*****.*******.***", buflen=1024, h_errnop=0xfffffffffffce98c) at connect/ei_resolve.c:629 No locals. #3 0x0000000000108580 in ei_connect_tmo (ec=0xfffffffffffcf4fc, nodename=0xfffffffffffcfa10 "rabbitmq-check@REDACTED", ms=0) at connect/ei_connect.c:604 hostname = 0xfffffffffffcfa1f "vulcan" alivename = "rabbitmq-check\000\000?????????\r\027?\205?qqeck/.erlang.cookie", '\0' , "\200\000\005???????!?\r\027?\207\003\035?\000\000\000\002\rq\001@", '\0' , "r7\210\000\000\000\000\000\000\001E\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\001\000\000\000\000\000\000*?\000\000\000\000\000\000??\000\000\000\002\017?E\000\000\000\000\002\017?\024?\000\000\000\002\017q!\020\000\000\000\002\017??????????x", '\0' , "\002\017????????"... hp = (struct hostent *) 0x20f550000 host = {h_name = 0x20dfe3408 "", h_aliases = 0x200000000, h_addrtype = 2, h_length = 257275424, h_addr_list = 0x20f550000} buffer = "vulcan.*****.*******.***\000\000\000\000\000=*?\000\000\000\001\000\000\002=???????@\000\000\000\000N\003zm", '\0' , "N\003zm\000\000\000\000\000\001?\017", '\0' , "\002\017U\000\000\000\000\000\000\000\020/\200", '\0' , "\004?\000\000\000\002\rP?", '\0' , "\002\017?E", '\0' , "\002\017?\026P\000\000\000\000\000\000\002\000\000\000\000\002\017?\026P\000\000\000\002\rP?\000\000\000\000\000\000\"\0050???????1?\r\027?\205?i????"... ei_h_errno = -202726 #4 0x00000000001087e8 in ei_connect (ec=0xfffffffffffcf4fc, nodename=0xfffffffffffcfa10 "rabbitmq-check@REDACTED") at connect/ei_connect.c:659 No locals. #5 0x00000000001046e8 in main (argc=5, argv=0xfffffffffffcfc88) at prog/erl_call.c:384 i = 17 fd = 80 creation = 1 hp = (struct hostent *) 0x20fc2d8c0 host_name = "vulcan\000\030\000\000\000\000\0002 \000???????A?\r\027?\212??5\000\000\000\a\000\000\000\f???????8\000\000\000\002\rP\000\000\000\000\000\000\000\000\000\000" nodename = "rabbitmq-check@REDACTED\000??\000\000\000\000\000\000\000\000???????\201?\r\027?\212??\005???????\201?\r\027?\212??\005", '\0' , "/??", '\0' , "\002\r???\000\000\000\002\r???\000\000\000\000\000\"`\000\000\000\000\000\000\000 \000" p = 0x0 ct = 0x20fc2da0d ".*****.*******.***" modsize = 0 host = 0xfffffffffffcfae0 "vulcan" module = 0x0 modname = 0x0 flags = {startp = 0, cookiep = 0, modp = 0, evalp = 1, randomp = 0, use_long_name = 0, debugp = 0, verbosep = 0, haltp = 1, cookie = 0x0, node = 0x20d7107c0 "rabbitmq-check", hidden = 0x20d710f70 "c17", apply = 0x0, script = 0x0} progname = 0xfffffffffffcfe78 "erl_call" ec = { thishostname = "vulcan\000\000\000\000\000\000\000\000\000\002\r??\000\000\000\000\000\000/??\000\000\000\000\0001?\200\000\000\000\000\000\000\000\214\000\000\000\000\000\000\a\020\000\000\000\002\016_?8\000\000\000\002\016", thisnodename = "c17@REDACTED\000?\r\027?\207??U???????\221?\r\027?\207\002?\005\000\000\000\000\000\000\000\034??????? ???????\f", '\0' , "\002\rP\026", '\0' , "\002\rP0\000\000\000\000\000\rP0\000\000\000\000\002\rP0\000\000\000\000\000\rP0", '\0' , "\002\016\037", thisalivename = "c17\000\000\002\rP?\000\000\000\000\002\016\037?\030\000\000\000\000\000\000\002\000\000\000\000\002\016O? ", '\0' , "\002\000\000\000\002\r?u@\000\000\000\000\000", ei_connect_cookie = "OZMRLUAHORQAALOCKXDN\000????Q?\r\027?\207\002?i\000\000\000\a\000/??\000\000\000\000\0001??\000\000\000\000\000\000\000\004\000\000\000\000\000\000 ", '\0' , "\a?\000\000\b\000\000\000\000\002\016\037?\034\000\000\000\002\016\037? \000\000\000\002\016`5?\000\000\000\000\000\000\001?\000\000\000\002\016`5?", '\0' , "\002\016O? \000\000\000\000\000r5\200\000\000\000\002\016\037? \000\000\000\002\016`5?\000\000\000\000\000\000\001?\000\000\000\002\016`5?", '\0' , "\002\017?E\000\000\000\000\002\017\201?@", '\0' ..., creation = 1, self = { node = "c17@REDACTED\000?\000\000\000\000\000/??\000\000\000\000\000\000\001?\000\000\000\002\017UP?\000\000\000\002\017U\000\000\000\000\000\002\017WA0\000\000\000\002\017U\000\000????????\000\000\000\002\017V0J\000\000\000\000\000\000\000\003\000\000\000\002\r??\000\000\000\000\000\000/?P\000\000\000\000\000, "????????\000\000\000\002\r???", '\0' , "????????"..., num = 0, serial = 0, creation = 1}} Cheers! David Coppa From egil@REDACTED Mon Jun 27 11:52:35 2011 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 27 Jun 2011 11:52:35 +0200 Subject: [erlang-bugs] Unaligned memory access on sparc64 In-Reply-To: <20110627093732.GA5560@latitude.dacolab.dom> References: <20110627093732.GA5560@latitude.dacolab.dom> Message-ID: <4E0852E3.7040402@erix.ericsson.se> Filed a ticket, will have a look at it. Regards, Bj?rn-Egil Erlang/OTP On 2011-06-27 11:37, David Coppa wrote: > Hi all, > > There's an unaligned memory access into lib/erl_interface/src/connect/ei_resolve.c that causes a SIGBUS > crash on sparc64. > > The following backtrace is from R13B04, but the code has not changed, so this bug is still present. > > $ gdb erl_call /usr/ports/pobj/rabbitmq-2.5.0/rabbitmq-server-2.5.0/erl_call.core > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc64-unknown-openbsd4.9"... > Core was generated by `erl_call'. > Program terminated with signal 10, Bus error. > Reading symbols from /usr/lib/libpthread.so.13.1...done. > Loaded symbols for /usr/lib/libpthread.so.13.1 > Reading symbols from /usr/lib/libc.so.58.3...done. > Loaded symbols for /usr/lib/libc.so.58.3 > Reading symbols from /usr/libexec/ld.so...done. > Loaded symbols for /usr/libexec/ld.so > #0 0x000000000010d32c in copy_hostent (dest=0xfffffffffffce780, src=0x20fc2d8c0, buffer=0xfffffffffffce9ac "", buflen=996) at connect/ei_resolve.c:224 > 224 *pptr = src_aliases; > (gdb) bt > #0 0x000000000010d32c in copy_hostent (dest=0xfffffffffffce780, src=0x20fc2d8c0, buffer=0xfffffffffffce9ac "", buflen=996) at connect/ei_resolve.c:224 > #1 0x000000000010d790 in my_gethostbyname_r (name=0xfffffffffffcfa1f "vulcan", hostp=0xfffffffffffce950, buffer=0xfffffffffffce990 "vulcan.*****.*******.***", buflen=1024, h_errnop=0xfffffffffffce98c) at connect/ei_resolve.c:319 > #2 0x000000000010db18 in ei_gethostbyname_r (name=0xfffffffffffcfa1f "vulcan", hostp=0xfffffffffffce950, buffer=0xfffffffffffce990 "vulcan.*****.*******.***", buflen=1024, h_errnop=0xfffffffffffce98c) at connect/ei_resolve.c:629 > #3 0x0000000000108580 in ei_connect_tmo (ec=0xfffffffffffcf4fc, nodename=0xfffffffffffcfa10 "rabbitmq-check@REDACTED", ms=0) at connect/ei_connect.c:604 > #4 0x00000000001087e8 in ei_connect (ec=0xfffffffffffcf4fc, nodename=0xfffffffffffcfa10 "rabbitmq-check@REDACTED") at connect/ei_connect.c:659 > #5 0x00000000001046e8 in main (argc=5, argv=0xfffffffffffcfc88) at prog/erl_call.c:384 > (gdb) thread apply all bt full > > Thread 1 (process 26785): > #0 0x000000000010d32c in copy_hostent (dest=0xfffffffffffce780, src=0x20fc2d8c0, buffer=0xfffffffffffce9ac "", buflen=996) at connect/ei_resolve.c:224 > pptr = (char **) 0xfffffffffffce9ac > len = 24 > src_aliases = (char **) 0x20fc2d8e0 > src_addr_list = (char **) 0x0 > #1 0x000000000010d790 in my_gethostbyname_r (name=0xfffffffffffcfa1f "vulcan", hostp=0xfffffffffffce950, buffer=0xfffffffffffce990 "vulcan.*****.*******.***", buflen=1024, h_errnop=0xfffffffffffce98c) at connect/ei_resolve.c:319 > dest = {h_name = 0xfffffffffffce990 "vulcan.*****.*******.***", h_aliases = 0xfffffffffffce9ac, h_addrtype = 2, h_length = 4, h_addr_list = 0x21fb20} > src = (struct hostent *) 0x20fc2d8c0 > rval = (struct hostent *) 0x0 > #2 0x000000000010db18 in ei_gethostbyname_r (name=0xfffffffffffcfa1f "vulcan", hostp=0xfffffffffffce950, buffer=0xfffffffffffce990 "vulcan.*****.*******.***", buflen=1024, h_errnop=0xfffffffffffce98c) at connect/ei_resolve.c:629 > No locals. > #3 0x0000000000108580 in ei_connect_tmo (ec=0xfffffffffffcf4fc, nodename=0xfffffffffffcfa10 "rabbitmq-check@REDACTED", ms=0) at connect/ei_connect.c:604 > hostname = 0xfffffffffffcfa1f "vulcan" > alivename = "rabbitmq-check\000\000?????????\r\027?\205?qqeck/.erlang.cookie", '\0', "\200\000\005???????!?\r\027?\207\003\035?\000\000\000\002\rq\001@", '\0', "r7\210\000\000\000\000\000\000\001E\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\001\000\000\000\000\000\000*?\000\000\000\000\000\000??\000\000\000\002\017?E\000\000\000\000\002\017?\024?\000\000\000\002\017q!\020\000\000\000\002\017??????????x", '\0', "\002\017????????"... > hp = (struct hostent *) 0x20f550000 > host = {h_name = 0x20dfe3408 "", h_aliases = 0x200000000, h_addrtype = 2, h_length = 257275424, h_addr_list = 0x20f550000} > buffer = "vulcan.*****.*******.***\000\000\000\000\000=*?\000\000\000\001\000\000\002=???????@\000\000\000\000N\003zm", '\0', "N\003zm\000\000\000\000\000\001?\017", '\0', "\002\017U\000\000\000\000\000\000\000\020/\200", '\0', "\004?\000\000\000\002\rP?", '\0', "\002\017?E", '\0', "\002\017?\026P\000\000\000\000\000\000\002\000\000\000\000\002\017?\026P\000\000\000\002\rP?\000\000\000\000\000\000\"\0050???????1?\r\027?\205?i????"... > ei_h_errno = -202726 > #4 0x00000000001087e8 in ei_connect (ec=0xfffffffffffcf4fc, nodename=0xfffffffffffcfa10 "rabbitmq-check@REDACTED") at connect/ei_connect.c:659 > No locals. > #5 0x00000000001046e8 in main (argc=5, argv=0xfffffffffffcfc88) at prog/erl_call.c:384 > i = 17 > fd = 80 > creation = 1 > hp = (struct hostent *) 0x20fc2d8c0 > host_name = "vulcan\000\030\000\000\000\000\0002 \000???????A?\r\027?\212??5\000\000\000\a\000\000\000\f???????8\000\000\000\002\rP\000\000\000\000\000\000\000\000\000\000" > nodename = "rabbitmq-check@REDACTED\000??\000\000\000\000\000\000\000\000???????\201?\r\027?\212??\005???????\201?\r\027?\212??\005", '\0', "/??", '\0', "\002\r???\000\000\000\002\r???\000\000\000\000\000\"`\000\000\000\000\000\000\000 \000" > p = 0x0 > ct = 0x20fc2da0d ".*****.*******.***" > modsize = 0 > host = 0xfffffffffffcfae0 "vulcan" > module = 0x0 > modname = 0x0 > flags = {startp = 0, cookiep = 0, modp = 0, evalp = 1, randomp = 0, use_long_name = 0, debugp = 0, verbosep = 0, haltp = 1, cookie = 0x0, node = 0x20d7107c0 "rabbitmq-check", hidden = 0x20d710f70 "c17", apply = 0x0, script = 0x0} > progname = 0xfffffffffffcfe78 "erl_call" > ec = { > thishostname = "vulcan\000\000\000\000\000\000\000\000\000\002\r??\000\000\000\000\000\000/??\000\000\000\000\0001?\200\000\000\000\000\000\000\000\214\000\000\000\000\000\000\a\020\000\000\000\002\016_?8\000\000\000\002\016", > thisnodename = "c17@REDACTED\000?\r\027?\207??U???????\221?\r\027?\207\002?\005\000\000\000\000\000\000\000\034??????? ???????\f", '\0', "\002\rP\026", '\0', "\002\rP0\000\000\000\000\000\rP0\000\000\000\000\002\rP0\000\000\000\000\000\rP0", '\0', "\002\016\037", > thisalivename = "c17\000\000\002\rP?\000\000\000\000\002\016\037?\030\000\000\000\000\000\000\002\000\000\000\000\002\016O? ", '\0', "\002\000\000\000\002\r?u@\000\000\000\000\000", > ei_connect_cookie = "OZMRLUAHORQAALOCKXDN\000????Q?\r\027?\207\002?i\000\000\000\a\000/??\000\000\000\000\0001??\000\000\000\000\000\000\000\004\000\000\000\000\000\000 ", '\0', "\a?\000\000\b\000\000\000\000\002\016\037?\034\000\000\000\002\016\037? \000\000\000\002\016`5?\000\000\000\000\000\000\001?\000\000\000\002\016`5?", '\0', "\002\016O? \000\000\000\000\000r5\200\000\000\000\002\016\037? \000\000\000\002\016`5?\000\000\000\000\000\000\001?\000\000\000\002\016`5?", '\0', "\002\017?E\000\000\000\000\002\017\201?@", '\0'..., creation = 1, self = { > node = "c17@REDACTED\000?\000\000\000\000\000/??\000\000\000\000\000\000\001?\000\000\000\002\017UP?\000\000\000\002\017U\000\000\000\000\000\002\017WA0\000\000\000\002\017U\000\000????????\000\000\000\002\017V0J\000\000\000\000\000\000\000\003\000\000\000\002\r??\000\000\000\000\000\000/?P\000\000\000\000\000, "????????\000\000\000\002\r???", '\0', "????????"..., num = 0, serial = 0, creation = 1}} > > Cheers! > David Coppa > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From bgustavsson@REDACTED Mon Jun 27 14:32:58 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 27 Jun 2011 14:32:58 +0200 Subject: [erlang-bugs] beam_validator does not validate receive state In-Reply-To: References: Message-ID: On Sun, Jun 19, 2011 at 3:40 AM, Erik S?e S?rensen wrote: > The following function passes beam_validator verification, but crashes the emulator with a segfault if called: > > {function, recv, 0, 2}. > {label,1}. > {func_info,{atom,broken_recv},{atom,recv},0}. > {label,2}. > {loop_rec_end,{f,3}}. > {label,3}. > return. The purpose of the beam_validator is to find subtle compiler bugs that are difficult to find using test suites. An example of such bug is invoking the test_heap instruction with uninitialized x registers. It is very difficult to find that kind of bug by testing because: 1) The test_heap instruction will not invoke the GC at all if there already is sufficient heap space. 2) Even if the GC is invoked, if the uninitialized x register happens to contain an immediate value (such as an atom or small integer), nothing bad will happen. 3) Even if the x register contains a pointer term (e.g. cons or boxed pointer), depending on where the pointer points, there may not happen any actual and/or noticeable harm. It is not a primary focus of the beam_validator to find obvious bugs that will be found by the loader (for example, references to non-existing labels) or found when the emulator is started or a few test suites are run. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Mon Jun 27 15:00:15 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 27 Jun 2011 15:00:15 +0200 Subject: [erlang-bugs] beam_validator does not validate against circularity in constructed values In-Reply-To: <4E084A30.707@trifork.com> References: <4E0846C0.1070705@trifork.com> <4E084A30.707@trifork.com> Message-ID: On Mon, Jun 27, 2011 at 11:15 AM, Erik S?e S?rensen wrote: > The following function passes beam_validator verification, but calls a > gc_bif while a tuple is not completely constructed. > (I take it that that could wreak havoc in the interpreter and is thus > illegal and technically a validator bug; I'm not completely certain of this > though. Apologies if this is not a bug after all.) > > {module, beamtoying5}. %% version = 0 > {exports, [{gc_in_cons,1},{gc_in_cons2,1}]}. > {attributes, []}. > {labels, 4}. > > {function, gc_in_cons, 1, 2}. > {label,1}. > {func_info,{atom,beamtoying5},{atom,gc_in_cons},1}. > {label,2}. > {test_heap,3,1}. > {put_tuple,2,{x,1}}. > {put,{atom,dummy}}. > {gc_bif,'bnot',{f,0},1,[{x,0}],{x,0}}. > {put,{x,0}}. > {move,{x,1},{x,0}}. > return. > The beam_validator WILL complain if you disable optimization: $ erlc +no_postopt beamtoying5.S beamtoying5: function gc_in_cons/1+8: Internal consistency check failed - please report this bug. Instruction: {put,{x,0}} Error: {heap_overflow,{left,0},{wanted,1}}: With optimizations enabled, the code will be rewritten to: {beam_file,beamtoying5, [{gc_in_cons,1,2}], [{vsn,[329530243180151502074282151407467260379]}], [{options,[asm, {cwd,"/home/bjorn/test"}, {outdir,"/home/bjorn/test"}, time]}, {version,"4.7.4"}, {time,{2011,6,27,12,42,27}}, {source,"/home/bjorn/test/beamtoying5.S"}], [{function,gc_in_cons,1,2, [{label,1}, {func_info,{atom,beamtoying5},{atom,gc_in_cons},1}, {label,2}, {test_heap,2,1}, {put_tuple,2,{x,1}}, {put,{atom,dummy}}, {gc_bif,'bnot',{f,0},2,[{x,0}],{x,0}}, {test_heap,1,2}, {put,{x,0}}, {move,{x,1},{x,0}}, return]}]} This code is not safe, in a subtle way, so there really is a bug in the beam_validator. I might fix this bug, but it does not have very high priority for me, because the loader in R14B03 (and in R14B02, I think) will refuse to load the resulting module, so it will not go unnoticed. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From ess@REDACTED Mon Jun 27 15:18:21 2011 From: ess@REDACTED (=?UTF-8?B?RXJpayBTw7hlIFPDuHJlbnNlbg==?=) Date: Mon, 27 Jun 2011 15:18:21 +0200 Subject: [erlang-bugs] beam_validator does not validate against circularity in constructed values In-Reply-To: References: <4E0846C0.1070705@trifork.com> <4E084A30.707@trifork.com> Message-ID: <4E08831D.4070603@trifork.com> Bj?rn Gustavsson wrote: > On Mon, Jun 27, 2011 at 11:15 AM, Erik S?e S?rensen wrote: > >> The following function passes beam_validator verification, but calls a >> gc_bif while a tuple is not completely constructed. >> (I take it that that could wreak havoc in the interpreter and is thus >> illegal and technically a validator bug; I'm not completely certain of this >> though. Apologies if this is not a bug after all.) >> >> {module, beamtoying5}. %% version = 0 >> {exports, [{gc_in_cons,1},{gc_in_cons2,1}]}. >> {attributes, []}. >> {labels, 4}. >> >> {function, gc_in_cons, 1, 2}. >> {label,1}. >> {func_info,{atom,beamtoying5},{atom,gc_in_cons},1}. >> {label,2}. >> {test_heap,3,1}. >> {put_tuple,2,{x,1}}. >> {put,{atom,dummy}}. >> {gc_bif,'bnot',{f,0},1,[{x,0}],{x,0}}. >> {put,{x,0}}. >> {move,{x,1},{x,0}}. >> return. >> >> > > The beam_validator WILL complain if you disable optimization: > > $ erlc +no_postopt beamtoying5.S > beamtoying5: function gc_in_cons/1+8: > Internal consistency check failed - please report this bug. > Instruction: {put,{x,0}} > Error: {heap_overflow,{left,0},{wanted,1}}: > > With optimizations enabled, the code will be rewritten to: > > {beam_file,beamtoying5, > [{gc_in_cons,1,2}], > [{vsn,[329530243180151502074282151407467260379]}], > [{options,[asm, > {cwd,"/home/bjorn/test"}, > {outdir,"/home/bjorn/test"}, > time]}, > {version,"4.7.4"}, > {time,{2011,6,27,12,42,27}}, > {source,"/home/bjorn/test/beamtoying5.S"}], > [{function,gc_in_cons,1,2, > [{label,1}, > {func_info,{atom,beamtoying5},{atom,gc_in_cons},1}, > {label,2}, > {test_heap,2,1}, > {put_tuple,2,{x,1}}, > {put,{atom,dummy}}, > {gc_bif,'bnot',{f,0},2,[{x,0}],{x,0}}, > {test_heap,1,2}, > {put,{x,0}}, > {move,{x,1},{x,0}}, > return]}]} > > This code is not safe, in a subtle way, so there really > is a bug in the beam_validator. > > I might fix this bug, but it does not have very high > priority for me, because the loader in R14B03 (and > in R14B02, I think) will refuse to load the resulting module, > so it will not go unnoticed. > OK, thanks for the reply (and for the pointer to +no_postopt). I forgot that this validator issue is in fact already noted in a comment in beam_validator.erl, so it's not news. (In any case, I understand that this is low priority, and that the validator focusing on the subtle stuff makes sense as long as its task is to validate compiler output.) As for the fix, part of a solution could be to set #st.h=0 on all instruction which might trigger GC. I guess a full fix would introduce a field in #st which contains the number of tuple fields allocated but not populated, to be checked for zeroness at certain instructions. (Certainly "anything that might GC" and "any return"; could be "anything besides put".) Regards, Erik From adam@REDACTED Tue Jun 28 09:32:24 2011 From: adam@REDACTED (Adam Lindberg) Date: Tue, 28 Jun 2011 09:32:24 +0200 Subject: [erlang-bugs] gen_server documentation error Message-ID: <4E098388.4090804@erlang-solutions.com> Hi, In the documentation for Module:handle_call/3 in the gen_server module, it states: > If the function returns {stop,Reason,Reply,NewState}, Reply will be given back to From. If the function returns {stop,Reason,NewState}, any reply to From must be given explicitly using gen_server:reply/2. The gen_server will then call Module:terminate(Reason,NewState) and terminate. This is false. The true behavior exists on line 573: {stop, Reason, Reply, NState} -> {'EXIT', R} = (catch terminate(Reason, Name, Msg, Mod, NState, [])), reply(From, Reply), exit(R); The documentation should probably read: If the function returns {stop,Reason,Reply,NewState}, the gen_server will call Module:terminate(Reason,NewState) and Reply will be given back to From after the call to Module:terminate/2 has completed. If the function returns {stop,Reason,NewState}, any reply to From must be given explicitly using gen_server:reply/2. Cheers, Adam From michal.ptaszek@REDACTED Tue Jun 28 09:42:52 2011 From: michal.ptaszek@REDACTED (Michal Ptaszek) Date: Tue, 28 Jun 2011 09:42:52 +0200 Subject: [erlang-bugs] gen_sctp documentation error Message-ID: <5A856D42-1794-4960-8FD1-6260ABE61710@erlang-solutions.com> Hello, in the examples section of gen_sctp module (sctp_server.erl) it is said: {ok,S} = gen_sctp:open([{ip,IP},{port,Port}],[{recbuf,65536}]), io:format("Listening on ~w:~w. ~w~n", [IP,Port,S]), but gen_sctp API has changed, so the example should probably now look like: {ok,S} = gen_sctp:open(Port, [{recbuf, 65536}, {ip, IP}]), io:format("Listening on ~w:~w. ~w~n", [IP,Port,S]), Best regards, Michal Ptaszek From ess@REDACTED Tue Jun 28 09:53:23 2011 From: ess@REDACTED (=?UTF-8?B?RXJpayBTw7hlIFPDuHJlbnNlbg==?=) Date: Tue, 28 Jun 2011 09:53:23 +0200 Subject: [erlang-bugs] gen_server documentation error In-Reply-To: <4E098388.4090804@erlang-solutions.com> References: <4E098388.4090804@erlang-solutions.com> Message-ID: <4E098873.8070605@trifork.com> I think it would appeal more to intuition if the code is fixed rather than the documentation... i.e. swap the two actions. That would keep all replies before the terminate action. Adam Lindberg wrote: > Hi, > > In the documentation for Module:handle_call/3 in the gen_server module, > it states: > > >> If the function returns {stop,Reason,Reply,NewState}, Reply will be given back to From. If the function returns {stop,Reason,NewState}, any reply to From must be given explicitly using gen_server:reply/2. The gen_server will then call Module:terminate(Reason,NewState) and terminate. >> > > This is false. > > The true behavior exists on line 573: > > {stop, Reason, Reply, NState} -> > {'EXIT', R} = > (catch terminate(Reason, Name, Msg, Mod, NState, [])), > reply(From, Reply), > exit(R); > > The documentation should probably read: > > If the function returns {stop,Reason,Reply,NewState}, the gen_server > will call Module:terminate(Reason,NewState) and Reply will be given back > to From after the call to Module:terminate/2 has completed. If the > function returns {stop,Reason,NewState}, any reply to From must be given > explicitly using gen_server:reply/2. > > Cheers, > Adam > From sverker@REDACTED Tue Jun 28 11:05:07 2011 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 28 Jun 2011 11:05:07 +0200 Subject: [erlang-bugs] gen_sctp documentation error In-Reply-To: <5A856D42-1794-4960-8FD1-6260ABE61710@erlang-solutions.com> References: <5A856D42-1794-4960-8FD1-6260ABE61710@erlang-solutions.com> Message-ID: <4E099943.4090005@erix.ericsson.se> Thank you. I'll correct that. /Sverker, Erlang/OTP Michal Ptaszek wrote: > Hello, > > in the examples section of gen_sctp module (sctp_server.erl) it is said: > > {ok,S} = gen_sctp:open([{ip,IP},{port,Port}],[{recbuf,65536}]), > io:format("Listening on ~w:~w. ~w~n", [IP,Port,S]), > > but gen_sctp API has changed, so the example should probably now > look like: > > {ok,S} = gen_sctp:open(Port, [{recbuf, 65536}, {ip, IP}]), > io:format("Listening on ~w:~w. ~w~n", [IP,Port,S]), > > Best regards, > Michal Ptaszek > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From adam@REDACTED Tue Jun 28 11:07:07 2011 From: adam@REDACTED (Adam Lindberg) Date: Tue, 28 Jun 2011 11:07:07 +0200 Subject: [erlang-bugs] gen_server documentation error In-Reply-To: <4E098873.8070605@trifork.com> References: <4E098388.4090804@erlang-solutions.com> <4E098873.8070605@trifork.com> Message-ID: <4E0999BB.5060205@erlang-solutions.com> There might be code which relies on the current behavior (such as cleaning up state in terminate, and expecting that that state is cleaned up after the call returns). Cheers, Adam Erik S?e S?rensen wrote: > I think it would appeal more to intuition if the code is fixed rather > than the documentation... i.e. swap the two actions. > That would keep all replies before the terminate action. > > Adam Lindberg wrote: >> Hi, >> >> In the documentation for Module:handle_call/3 in the gen_server >> module, it states: >> >>> If the function returns {stop,Reason,Reply,NewState}, Reply will be >>> given back to From. If the function returns {stop,Reason,NewState}, >>> any reply to From must be given explicitly using gen_server:reply/2. >>> The gen_server will then call Module:terminate(Reason,NewState) and >>> terminate. >> >> This is false. >> >> The true behavior exists on line 573: >> >> {stop, Reason, Reply, NState} -> >> {'EXIT', R} = >> (catch terminate(Reason, Name, Msg, Mod, NState, [])), >> reply(From, Reply), >> exit(R); >> >> The documentation should probably read: >> >> If the function returns {stop,Reason,Reply,NewState}, the gen_server >> will call Module:terminate(Reason,NewState) and Reply will be given >> back to From after the call to Module:terminate/2 has completed. If >> the function returns {stop,Reason,NewState}, any reply to From must be >> given explicitly using gen_server:reply/2. >> >> Cheers, >> Adam > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From ess@REDACTED Tue Jun 28 17:39:04 2011 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Tue, 28 Jun 2011 17:39:04 +0200 Subject: [erlang-bugs] gen_server documentation error In-Reply-To: <4E0999BB.5060205@erlang-solutions.com> References: <4E098388.4090804@erlang-solutions.com> <4E098873.8070605@trifork.com> <4E0999BB.5060205@erlang-solutions.com> Message-ID: <4E09F598.9060402@trifork.com> Ah, ok - that makes sense for stop messages. You're right; that's also a nice property. Adam Lindberg wrote: > There might be code which relies on the current behavior (such as > cleaning up state in terminate, and expecting that that state is cleaned > up after the call returns). > > Cheers, > Adam > > > > Erik S?e S?rensen wrote: > >> I think it would appeal more to intuition if the code is fixed rather >> than the documentation... i.e. swap the two actions. >> That would keep all replies before the terminate action. >> >> Adam Lindberg wrote: >> >>> Hi, >>> >>> In the documentation for Module:handle_call/3 in the gen_server >>> module, it states: >>> >>> >>>> If the function returns {stop,Reason,Reply,NewState}, Reply will be >>>> given back to From. If the function returns {stop,Reason,NewState}, >>>> any reply to From must be given explicitly using gen_server:reply/2. >>>> The gen_server will then call Module:terminate(Reason,NewState) and >>>> terminate. >>>> >>> This is false. >>> >>> The true behavior exists on line 573: >>> >>> {stop, Reason, Reply, NState} -> >>> {'EXIT', R} = >>> (catch terminate(Reason, Name, Msg, Mod, NState, [])), >>> reply(From, Reply), >>> exit(R); >>> >>> The documentation should probably read: >>> >>> If the function returns {stop,Reason,Reply,NewState}, the gen_server >>> will call Module:terminate(Reason,NewState) and Reply will be given >>> back to From after the call to Module:terminate/2 has completed. If >>> the function returns {stop,Reason,NewState}, any reply to From must be >>> given explicitly using gen_server:reply/2. >>> >>> Cheers, >>> Adam >>> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> From alex.demidenko@REDACTED Wed Jun 29 07:16:33 2011 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Wed, 29 Jun 2011 12:16:33 +0700 Subject: [erlang-bugs] xmerl, xmerl_scan, trouble with validating xml document with attribute containse " Message-ID: Hello, I have a trouble with validating xml document by xsd schema in case of one of the attribute in the xml document containse " in own value. I attached simple sample, where you can see this problem. To run it, compile xml_test and invoke "test" method. You can see the error message: {error,[{value_not_string,["\"",85,110,115,117,112,112,111,114,116,101,100,32,113,117,111,116,32,104,101,114,101,33,"\""]}]}. How can I see, the problem in the xmerl_scan.erl module, scan_att_chars method. In case of using " value in the attribute's value, this metod return nonflatten value of the attribute. Tested by Erlang 13B4, xmerl 1.2.4 and 14B3, xmerl 1.2.9 %% file test.xml %% file test.xsd ? ? ? ? ? ? ? ? ? ? ? %% file test.erl -module(xml_test). -export([ test/0 ? ? ? ? ]). read_xml(FileName) -> ? ? {ok, Schema} = xmerl_xsd:process_schema("test.xsd"), ? ? {ok, BXml} = file:read_file(FileName), ? ? Xml = erlang:binary_to_list(BXml), ? ? {XmerXml, _} = xmerl_scan:string(Xml), ? ? xmerl_xsd:validate(XmerXml, Schema). test() -> ? ? try ? ? ? ? Result = read_xml("test.xml"), io:format("~p~n", [Result]) ? ? catch _: Error -> ? ?io:format("Error: ~p", [Error]) ? ? end. -- --------------------------------------------- With best regards, Alexander.