headers
Sergey Shilov | 3 Jun 2011 11:33
Picon
Gravatar

ssl_connection crash on client connect w/o certificte

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.
_______________________________________________
erlang-bugs mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
][azar | 6 Jun 2011 08:05
Picon

Parameterized module and utf8 pattern compile error

Hello.
There is an error when i try to compile parameterized module with utf8.

Example:

-module(test,[Graph]).

-export([test/1]).

test(Input) ->
    <<C/utf8,Rest/binary>> = 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}]}

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |
headers
Igor Ribeiro Sucupira | 7 Jun 2011 08:19
Picon

All keys in the same slot (Mnesia/dets)

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 <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 8 comments |
headers
Igor Ribeiro Sucupira | 7 Jun 2011 09:46
Picon

Re: All keys in the same slot (Mnesia/dets)

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 <igorrs <at> gmail.com> 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 <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 2 comments |
headers
Michael Truog | 7 Jun 2011 10:01
Picon
Gravatar

Re: All keys in the same slot (Mnesia/dets)

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 <igorrs <at> gmail.com> 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 <at> erlang.org
> http://erlang.org/mailman/listinfo/erlang-bugs
>

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |
headers
Erik Søe Sørensen | 7 Jun 2011 10:00
Favicon

Re: All keys in the same slot (Mnesia/dets)

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

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |
headers
Igor Ribeiro Sucupira | 7 Jun 2011 17:57
Picon

Re: All keys in the same slot (Mnesia/dets)

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" <mjtruog <at> gmail.com> escreveu:
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |
headers
Igor Ribeiro Sucupira | 7 Jun 2011 18:12
Picon

Re: All keys in the same slot (Mnesia/dets)


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" <ess <at> trifork.com> escreveu:
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 3 comments |
headers
Dave Peticolas | 8 Jun 2011 05:00
Picon
Gravatar

error in re:split on R14B02 and R14B03

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 <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 2 comments |
headers
Patrick Baggett | 8 Jun 2011 05:07
Picon

Re: error in re:split on R14B02 and R14B03

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 <at> gmail.com> 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 <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs


_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 1 comment |

Gmane