From pfisher@REDACTED  Mon Aug  3 00:08:16 2009
From: pfisher@REDACTED (Paul Fisher)
Date: Sun, 02 Aug 2009 17:08:16 -0500
Subject: R13B-1 internal error in v3_codegen
Message-ID: <4A760E50.8000800@alertlogic.net>

Is this a known issue, and is there a patch?

Function: handle_call/3
./alrules_srv.erl:none: internal error in v3_codegen;
crash reason: {{case_clause,
                    {'EXIT',
                        {function_clause,
                            [{v3_codegen,longest,[[{ker26},{ker25}],[]]},
                             {v3_codegen,longest,2},
                             {v3_codegen,sr_merge,2},
                             {v3_codegen,match_cg,5},
                             {v3_codegen,guard_match_cg,6},
                             {v3_codegen,'-cg_list/5-anonymous-0-',3},
                             {v3_codegen,flatmapfoldl,3},
                             {v3_codegen,cg_list,5}]}}},
                [{compile,'-select_passes/2-anonymous-2-',2},
                 {compile,'-internal_comp/4-anonymous-1-',2},
                 {compile,fold_comp,3},
                 {compile,internal_comp,4},
                 {compile,internal,3}]}


--
paul


From bgustavsson@REDACTED  Mon Aug  3 15:49:55 2009
From: bgustavsson@REDACTED (Bjorn Gustavsson)
Date: Mon, 3 Aug 2009 15:49:55 +0200
Subject: [erlang-bugs] R13B-1 internal error in v3_codegen
In-Reply-To: <4A760E50.8000800@alertlogic.net>
References: <4A760E50.8000800@alertlogic.net>
Message-ID: <6672d0160908030649q18ea9adftdc8bfe42b9ea2722@mail.gmail.com>

On Mon, Aug 3, 2009 at 12:08 AM, Paul Fisher<pfisher@REDACTED> wrote:
> Is this a known issue, and is there a patch?

Can you post a compilable version of the source code?

/Bjorn

-- 
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB

From hakan@REDACTED  Mon Aug  3 17:26:59 2009
From: hakan@REDACTED (Hakan Mattsson)
Date: Mon, 3 Aug 2009 17:26:59 +0200 (CEST)
Subject: [erlang-bugs] Arguments passed to escript's emulator by %%!
 affect os:cmd/1o
In-Reply-To: <e42595410907211243vaf67ea4qd54c213d3927e430@mail.gmail.com>
References: <e42595410907211243vaf67ea4qd54c213d3927e430@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0908031721210.8538@falco.du.uab.ericsson.se>


Hi!

Thank you for reporting this bug.

It is now fixed and it will be released in R13B02.
Send me a mail if you want to test it earlier.

/H?kan
---
H?kan Mattsson (uabhams)
Erlang/OTP, Ericsson AB

On Tue, 21 Jul 2009, Sergey Samokhin wrote:

> Hello.
> 
> Some weeks ago I sent a bug report describing the problem with passing
> arguments to escript's emulator by using %%! and os:cmd/1. I used R13B
> to test it.
> 
> Today I've tested this with R13B01 - the problem is still here. I
> reproduced it on Archlinux and FreeBSD. So I decided to write this
> letter.
> 
> The easiest way reproduce the problem is by starting this script:
> 
> %-----------------------
> #!/usr/bin/env escript
> %%! -smp disable
> 
> main(_) ->
>     os:cmd("erl -detached -sname test").
> %-----------------------
> 
> Although there is no "-smp disable" within the argument to os:cmd/1,
> the newly started node will have smp disabled too.
> 
> It's impossible to use "%%! <arguments>" syntax (for example to make
> an escript's node hidden) because all arguments I specify are passed
> to a node started by os:cmd/1.
> 
> Here is the original bug-report with all the details on how to
> reproduce the bug:
> http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1296:200905:finpkpaeoenpofkcegce
> 
> -- 
> Sergey Samokhin
> 
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org

From pfisher@REDACTED  Mon Aug  3 17:34:59 2009
From: pfisher@REDACTED (Paul Fisher)
Date: Mon, 03 Aug 2009 10:34:59 -0500
Subject: [erlang-bugs] R13B-1 internal error in v3_codegen
In-Reply-To: <6672d0160908030649q18ea9adftdc8bfe42b9ea2722@mail.gmail.com>
References: <4A760E50.8000800@alertlogic.net> <6672d0160908030649q18ea9adftdc8bfe42b9ea2722@mail.gmail.com>
Message-ID: <4A7703A3.2090700@alertlogic.net>

Bjorn Gustavsson wrote:
> On Mon, Aug 3, 2009 at 12:08 AM, Paul Fisher<pfisher@REDACTED> wrote:
>> Is this a known issue, and is there a patch?
> 
> Can you post a compilable version of the source code?

The original was 3000+ lines, but i've reduced it to this:

-module(codegen).
-compile([export_all, debug_info]).

perform_select( {Type, Keyval} ) ->
     try
         if is_atom(Type) andalso length(Keyval) > 0 -> ok;
            true -> ok
         end
     catch
         _:_ -> fail
     end.


$ erlc codegen.erl
Function: perform_select/1
./codegen.erl:none: internal error in v3_codegen;
crash reason: {{case_clause,
                    {'EXIT',
                        {function_clause,
                            [{v3_codegen,longest,[[{ker2},{ker1}],[]]},
                             {v3_codegen,longest,2},
                             {v3_codegen,sr_merge,2},
                             {v3_codegen,match_cg,5},
                             {v3_codegen,guard_match_cg,6},
                             {v3_codegen,guard_cg,5},
                             {v3_codegen,'-guard_cg_list/6-anonymous-0-',4},
                             {v3_codegen,flatmapfoldl,3}]}}},
                [{compile,'-select_passes/2-anonymous-2-',2},
                 {compile,'-internal_comp/4-anonymous-1-',2},
                 {compile,fold_comp,3},
                 {compile,internal_comp,4},
                 {compile,internal,3}]}


--
paul

From jonas.boberg@REDACTED  Tue Aug  4 16:05:25 2009
From: jonas.boberg@REDACTED (Jonas Boberg)
Date: Tue, 4 Aug 2009 15:05:25 +0100 (BST)
Subject: R13B-1 hanging processes in ssh
In-Reply-To: <23323333.46501249394310702.JavaMail.root@zimbra>
Message-ID: <1599649.46571249394725148.JavaMail.root@zimbra>

Hi,

On Erlang R13B-1 (erts-5.7.2) the ssh application leaves two processes and one socket hanging when opening and closing a connection.

How to reproduce:
------------------------
-module(ssh_test).

-export([test/0]).

test() ->
    application:start(crypto),
    application:start(ssh),
    Host = "127.0.0.1",
    Port = 22,
    User = "username-here",
    Password = "password-here",
    {ok, C} =  ssh:connect(Host, Port, [{user, User},
                                        {password, Password},
                                        {silently_accept_hosts, true}]),
    ssh:close(C).
------------------------

> ssh_test:test()
ok
> {length(erlang:processes()), length(erlang:ports())}.
{47, 22}
> ssh_test:test().
ok
> {length(erlang:processes()), length(erlang:ports())}.
{49,23}

I've also confirmed this by looking at the process tree
with the appmon application.
Two processes under the sshc_sup supervisor are left behind.

In our application, eventually thousands of processes and ports are left open after running for a few hours.

Regards
Jonas

From nik.epifanov@REDACTED  Thu Aug  6 10:23:57 2009
From: nik.epifanov@REDACTED (Nikolay Epifanov)
Date: Thu, 6 Aug 2009 12:23:57 +0400
Subject: ODBC problem with R13B01 in OpenBSD 4.5 amd64
Message-ID: <a992b16b0908060123j53d0a75av6a315ff3cc724e6c@mail.gmail.com>

Hi,

while trying to connect I get:

Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:4:4] [rq:4]
[async-threads:0] [kernel-poll:false]

Eshell V5.7.2  (abort with ^G)
1> odbc:start().
ok
2> {ok, Ref} = odbc:connect("DSN=pc-backend", [{scrollable_cursors,off}]).

=ERROR REPORT==== 6-Aug-2009::11:20:21 ===
** Generic server <0.39.0> terminating
** Last message in was {<0.32.0>,
                        {connect,[1,1,2,2,1,"DSN=pc-backend"],on,off},
                        infinity}
** When Server state == {state,#Port<0.546>,
                               {<0.32.0>,#Ref<0.0.0.35>},

<0.32.0>,undefined,on,undefined,undefined,off,
                               connecting,undefined,0,
                               [#Port<0.544>,#Port<0.545>],
                               undefined,undefined}
** Reason for termination ==
** timeout
** exception error: no match of right hand side value
{error,connection_closed}

Same error for both iodbc and unixODBC.
Actually odbcserver exits in (lib/odbc/c_src/odbcserver.c:1646)  WIN32
version of connect_to_erlang after receiving ECONNREFUSED for "connect(sock,
(struct sockaddr*)&sin, sizeof(sin)". This WIN32 function enforced with
#define USE_IPV4. I switched to UNIX one and at least connects and queries
started working. The patch that made this change is
http://www1.erlang.org/pipermail/erlang-bugs/2007-October/000486.html
Why does the WIN32 function have to be used? Is it ok to use UNIX version?

From mjtruog@REDACTED  Fri Aug  7 01:41:16 2009
From: mjtruog@REDACTED (Michael Truog)
Date: Thu, 06 Aug 2009 16:41:16 -0700
Subject: [erlang-bugs] ODBC problem with R13B01 in OpenBSD 4.5 amd64
In-Reply-To: <a992b16b0908060123j53d0a75av6a315ff3cc724e6c@mail.gmail.com>
References: <a992b16b0908060123j53d0a75av6a315ff3cc724e6c@mail.gmail.com>
Message-ID: <4A7B6A1C.5050201@gmail.com>

When I emailed Alex Popov, the OpenBSD maintainer, he said that Erlang
compiles cleanly but that they use "--disable-jinterface and
--disable-odbc".  I am not sure about all the reasons, but I assume the
"--disable-odbc" is a problem unless you are compiling your own Erlang
installation and making ODBC work on OpenBSD.

Nikolay Epifanov wrote:
> Hi,
>
> while trying to connect I get:
>
> Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:4:4] [rq:4]
> [async-threads:0] [kernel-poll:false]
>
> Eshell V5.7.2  (abort with ^G)
> 1> odbc:start().
> ok
> 2> {ok, Ref} = odbc:connect("DSN=pc-backend", [{scrollable_cursors,off}]).
>
> =ERROR REPORT==== 6-Aug-2009::11:20:21 ===
> ** Generic server <0.39.0> terminating
> ** Last message in was {<0.32.0>,
>                         {connect,[1,1,2,2,1,"DSN=pc-backend"],on,off},
>                         infinity}
> ** When Server state == {state,#Port<0.546>,
>                                {<0.32.0>,#Ref<0.0.0.35>},
>
> <0.32.0>,undefined,on,undefined,undefined,off,
>                                connecting,undefined,0,
>                                [#Port<0.544>,#Port<0.545>],
>                                undefined,undefined}
> ** Reason for termination ==
> ** timeout
> ** exception error: no match of right hand side value
> {error,connection_closed}
>
> Same error for both iodbc and unixODBC.
> Actually odbcserver exits in (lib/odbc/c_src/odbcserver.c:1646)  WIN32
> version of connect_to_erlang after receiving ECONNREFUSED for "connect(sock,
> (struct sockaddr*)&sin, sizeof(sin)". This WIN32 function enforced with
> #define USE_IPV4. I switched to UNIX one and at least connects and queries
> started working. The patch that made this change is
> http://www1.erlang.org/pipermail/erlang-bugs/2007-October/000486.html
> Why does the WIN32 function have to be used? Is it ok to use UNIX version?
>
>   


From nik.epifanov@REDACTED  Fri Aug  7 10:02:21 2009
From: nik.epifanov@REDACTED (Nikolay Epifanov)
Date: Fri, 7 Aug 2009 12:02:21 +0400
Subject: [erlang-bugs] ODBC problem with R13B01 in OpenBSD 4.5 amd64
In-Reply-To: <4A7B6A1C.5050201@gmail.com>
References: <a992b16b0908060123j53d0a75av6a315ff3cc724e6c@mail.gmail.com>
	 <4A7B6A1C.5050201@gmail.com>
Message-ID: <a992b16b0908070102n33c181cfnb271d50baea49f49@mail.gmail.com>

2009/8/7 Michael Truog <mjtruog@REDACTED>

> When I emailed Alex Popov, the OpenBSD maintainer, he said that Erlang
> compiles cleanly but that they use "--disable-jinterface and
> --disable-odbc".  I am not sure about all the reasons, but I assume the
> "--disable-odbc" is a problem unless you are compiling your own Erlang
> installation and making ODBC work on OpenBSD.
>
>
Sorry for not mentioning it in the first place. I compiled erlang with odbc
enabled and tried both iodbc and unixODBC. I get compiled odbcserver and
odbc beams ok, also they are installed correctly.
The only problem is odbcserver fails to connect.

From samb-bulk@REDACTED  Tue Aug 11 08:54:58 2009
From: samb-bulk@REDACTED (Sam Bobroff)
Date: Tue, 11 Aug 2009 16:54:58 +1000
Subject: Duplicate results from qlc on ordered_set mnesia table with secondary
 index
Message-ID: <4A8115C2.9000404@m5networks.com.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Mighty Erlangers,

I've found a situation where a simple qlc query returns multiple records
with the same primary key from an mnesia table with the ordered_set
type. It seems to be triggered by doing the query just after updating a
record using mnesia:write that is within the same transaction as the
query. The duplicate entry does not appear in the results of mnesia:select.

Here's some code that reproduces the issue for me in Erlang R13B01:

- --- begin ---

%% Bug replication code, save to "bug.erl".
%% Compile with: erlc bug.erl
%% Run with: erl -noshell -run bug -run init stop

- -module(bug).
- -export([start/0]).

- -include_lib("stdlib/include/qlc.hrl").

- -record(rec, {key, val}).

start() ->
	ok = mnesia:start(),
	{atomic, ok} = mnesia:create_table(rec, [{attributes,
record_info(fields, rec)}, {type, ordered_set}]),
	[ ok = mnesia:dirty_write(R) || R <- [ {rec,1,1}, {rec,2,1} ] ],
	io:fwrite("Before add_table_index.\n"),
	{atomic, _} = mnesia:transaction(fun do_test/0, []),
	{atomic, ok} = mnesia:add_table_index(rec, val),
	io:fwrite("After add_table_index.\n"),
	{atomic, _} = mnesia:transaction(fun do_test/0, []).

do_test() ->
	Val = 1,
	Key = 1,
	[Rec] = mnesia:read(rec, Key),
	ok = mnesia:write(Rec),
	check(Val).

check(Val) ->
	io:fwrite("select(val ~p) = ~p\n", [
		Val, mnesia:select(rec, [{#rec{val = Val, key = '$1', _ = '_'}, [],
['$1']}])
	]),
	io:fwrite("qlc(val ~p)    = ~p\n", [
		Val, qlc:e(qlc:q([ Rec#rec.key || Rec <- mnesia:table(rec),
Rec#rec.val =:= Val ]))
	]).

- -- end ---

The output I get from running this code is:

$ erl -noshell -run bug -run init stop
Before add_table_index.
select(val 1) = [1,2]
qlc(val 1)    = [1,2]
After add_table_index.
select(val 1) = [1,2]
qlc(val 1)    = [1,2,1]

It seems like two record with the key of 1 must be incorrect for an
ordered_set table. Is this a bug?

Sam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKgRXCm97/UHSa/AQRAmc/AJ9lqXXFYw+qw8Q6eW29JFIUQO+DZQCdFFfq
a9aaH2VmbbAHkRibPYEPWPw=
=30qU
-----END PGP SIGNATURE-----

From bgustavsson@REDACTED  Tue Aug 11 10:54:21 2009
From: bgustavsson@REDACTED (Bjorn Gustavsson)
Date: Tue, 11 Aug 2009 10:54:21 +0200
Subject: [erlang-bugs] R13B01 internal error in v3_codegen
In-Reply-To: <28423d490907210416j7e328a98h6a3f9bba935a856@mail.gmail.com>
References: <28423d490907210416j7e328a98h6a3f9bba935a856@mail.gmail.com>
Message-ID: <6672d0160908110154y39f234dew608cae823daf9d8b@mail.gmail.com>

On Tue, Jul 21, 2009 at 1:16 PM, Martin Engstr?m<whongo@REDACTED> wrote:
> Hi! This small list comprehension works fine in R12B-5, but not in R13B01
>
> -module(alphanum).
> -export([orgno_alphanum/1]).
> orgno_alphanum(OrgNo) ->
>   [C || C <- OrgNo, ((C >= $0) andalso (C =< $9))
>           orelse  ((C >= $a) andalso (C =< $z))
>           orelse  ((C >= $A) andalso (C =< $Z))].
>

Thanks! A correction will be included in R13B02.

/Bjorn

-- 
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB

From bgustavsson@REDACTED  Tue Aug 11 10:55:40 2009
From: bgustavsson@REDACTED (Bjorn Gustavsson)
Date: Tue, 11 Aug 2009 10:55:40 +0200
Subject: [erlang-bugs] R13B-1 internal error in v3_codegen
In-Reply-To: <4A7703A3.2090700@alertlogic.net>
References: <4A760E50.8000800@alertlogic.net>
	 <6672d0160908030649q18ea9adftdc8bfe42b9ea2722@mail.gmail.com>
	 <4A7703A3.2090700@alertlogic.net>
Message-ID: <6672d0160908110155r7a1ce53fk44710b4b9249b0b8@mail.gmail.com>

On Mon, Aug 3, 2009 at 5:34 PM, Paul Fisher<pfisher@REDACTED> wrote:
> Bjorn Gustavsson wrote:
>>
>> On Mon, Aug 3, 2009 at 12:08 AM, Paul Fisher<pfisher@REDACTED>
>> wrote:
>>>
>>> Is this a known issue, and is there a patch?
>>
>> Can you post a compilable version of the source code?
>
> The original was 3000+ lines, but i've reduced it to this:
[...]

Thanks for reporting this bug and for reducing the source code.

A correction will be included in R13B02.

/Bjorn

-- 
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB

From bgustavsson@REDACTED  Tue Aug 11 10:57:15 2009
From: bgustavsson@REDACTED (Bjorn Gustavsson)
Date: Tue, 11 Aug 2009 10:57:15 +0200
Subject: [erlang-questions] compiler crash on very long module paths
In-Reply-To: <781dd98c0906200614t4c417d54v3931726fdcdbe5a1@mail.gmail.com>
References: <781dd98c0906200614t4c417d54v3931726fdcdbe5a1@mail.gmail.com>
Message-ID: <6672d0160908110157t1344298s2d432a4798d608d@mail.gmail.com>

On Sat, Jun 20, 2009 at 3:14 PM, Chris Newcombe<chris.newcombe@REDACTED> wrote:
> Please could the compiler be changed to not call list_to_atom/1 on module paths?

Yes, we will do that in R13B02.

Thanks for reporting this problem.

/Bjorn
-- 
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB

From anton.krasovsky@REDACTED  Tue Aug 11 13:47:07 2009
From: anton.krasovsky@REDACTED (Anton Krasovsky)
Date: Tue, 11 Aug 2009 12:47:07 +0100
Subject: HTTP client error, invalid_version
Message-ID: <46167e6a0908110447l437ea651yf6da2f616bc2bb37@mail.gmail.com>

I'm using inets http client to fetch some twitter profile images
(hosted on amazon s3), observed a crash in http client.

Attaching a trace.

Regards,
Anton
-------------- next part --------------
=ERROR REPORT==== 11-Aug-2009::11:26:23 ===
** Generic server <0.927.0> terminating 
** Last message in was {tcp,#Port<0.3985>,
                            <<82,18,138,6,220,185,201,110,222,213,231,212,119,
                              168,206,218,92,188,169,35,173,191,240,215,132,
                              228,5,173,124,97,109,20,188,130,98,157,200,7,
                              184,35,21,21,223,135,252,51,111,18,64,222,48,
                              138,69,242,246,110,121,31,57,63,133,115,49,51,
                              65,33,48,249,127,103,150,79,152,168,231,119,248,
                              251,213,219,251,175,50,209,164,37,36,116,83,188,
                              130,11,14,220,227,173,71,45,217,182,219,23,245,
                              15,15,232,23,50,198,176,120,227,201,137,48,25,
                              165,153,153,155,177,57,219,216,1,86,174,60,61,
                              161,91,106,214,177,232,158,47,51,93,74,190,82,
                              24,228,119,126,84,146,199,229,234,122,86,77,170,
                              197,61,178,170,71,186,52,83,184,176,251,173,142,
                              149,78,210,246,226,195,89,183,125,61,228,91,165,
                              114,209,202,220,175,211,220,211,229,178,220,92,
                              215,232,81,248,131,160,69,162,91,65,38,110,11,
                              92,146,16,73,242,240,62,241,218,71,174,57,250,
                              215,22,107,178,248,177,172,221,234,23,186,96,
                              212,238,3,79,21,166,31,113,198,24,187,118,250,
                              98,184,89,111,109,163,235,50,146,123,14,107,158,
                              178,114,157,162,143,162,192,212,165,67,14,185,
                              228,151,204,145,234,39,161,46,32,151,253,92,170,
                              73,237,156,26,86,83,130,112,113,81,202,214,232,
                              218,85,97,53,120,187,145,115,154,50,115,74,69,
                              52,131,138,163,158,77,160,221,73,186,154,221,41,
                              188,142,244,210,51,115,102,231,131,52,247,212,
                              252,69,111,106,132,12,238,98,113,156,0,166,189,
                              155,192,195,82,211,180,75,141,9,34,133,227,153,
                              156,178,60,68,140,182,50,217,206,59,15,165,121,
                              199,193,91,89,39,241,36,147,160,255,0,85,17,228,
                              251,244,175,109,187,95,236,237,52,220,54,30,121,
                              142,200,99,199,223,108,118,246,174,44,76,218,
                              151,42,55,195,211,83,124,239,161,157,162,232,
                              158,127,137,44,236,252,214,158,75,56,165,146,87,
                              0,0,3,1,132,253,9,174,123,226,23,129,116,120,45,
                              63,180,238,237,86,36,103,36,178,63,150,127,62,
                              153,175,74,240,22,158,116,235,86,154,230,85,55,
                              19,243,33,61,201,254,149,91,226,197,188,151,158,
                              29,91,61,139,36,67,59,147,104,57,94,57,25,239,
                              92,156,242,140,147,76,238,158,30,46,15,153,30,
                              73,164,120,75,83,112,151,158,31,241,133,220,46,
                              231,10,151,128,145,183,28,97,129,32,215,109,103,
                              226,253,123,74,130,43,79,20,105,69,138,141,159,
                              105,182,229,88,14,248,237,84,252,25,164,193,164,
                              120,82,206,222,207,80,143,237,139,19,27,168,166,
                              132,236,114,88,145,219,176,192,227,156,213,200,
                              53,11,185,45,196,26,166,155,115,14,122,25,23,
                              119,228,123,143,122,236,170,251,234,143,46,132,
                              100,149,210,113,103,83,165,234,16,106,16,27,155,
                              25,12,145,49,229,128,35,30,199,53,113,164,218,
                              252,140,41,239,156,138,229,124,59,11,91,94,0,18,
                              79,179,190,112,160,124,132,215,75,52,136,225,
                              152,55,204,153,62,149,196,210,79,67,178,45,201,
                              106,54,103,113,42,70,135,112,35,114,182,122,14,
                              188,215,55,226,171,107,86,183,96,242,40,222,120,
                              35,158,43,67,78,149,167,212,21,227,109,232,37,
                              11,236,51,129,214,179,53,219,25,174,245,115,18,
                              92,165,173,146,130,242,92,158,145,33,60,12,119,
                              239,93,241,124,144,230,103,149,82,46,165,78,84,
                              113,26,221,149,156,90,108,246,182,202,132,136,
                              247,121,160,252,193,193,237,245,175,54,190,142,
                              91,56,165,118,142,69,150,120,198,192,6,0,4,96,
                              181,125,5,119,225,111,13,37,128,22,122,13,213,
                              217,110,60,251,165,218,204,73,234,55,28,143,202,
                              188,135,198,186,40,176,212,175,237,67,63,150,97,
                              79,36,177,251,136,1,33,127,60,10,215,15,136,83,
                              151,41,24,252,186,120,122,74,165,238,191,35,156,
                              123,168,173,116,141,66,88,64,13,58,136,23,30,
                              152,27,191,90,229,107,107,196,13,28,49,199,99,
                              19,22,84,198,125,241,223,243,205,99,98,186,225,
                              181,207,54,49,178,26,104,165,197,37,104,132,196,
                              164,52,180,134,153,44,41,8,165,162,154,21,134,
                              145,69,56,211,123,208,67,3,72,122,210,209,138,4,
                              52,82,210,82,213,16,130,129,69,20,138,22,138,40,
                              164,48,165,20,148,80,52,58,129,77,165,20,20,45,
                              20,81,69,134,46,104,52,148,82,11,142,162,146,
                              138,10,20,83,133,32,162,164,180,46,104,205,37,
                              40,20,20,40,230,158,162,144,10,122,210,102,145,
                              136,1,78,2,146,130,106,77,150,130,147,138,76,
                              250,83,115,147,79,85,165,176,38,222,199,170,124,
                              35,241,180,246,176,203,166,95,15,50,8,163,47,
                              230,57,24,8,58,131,159,173,118,74,159,100,184,
                              93,71,195,75,28,144,220,48,50,217,249,160,46,
                              122,238,66,120,3,218,188,18,210,59,131,28,194,
                              217,202,254,236,239,25,198,229,238,43,123,193,
                              158,34,189,208,167,71,91,117,188,179,199,205,1,
                              108,180,103,213,15,99,237,88,207,2,234,46,122,
                              123,246,58,41,227,213,10,138,21,118,211,94,196,
                              190,56,188,212,238,60,77,116,117,139,68,142,229,
                              135,1,8,249,84,116,193,250,119,174,123,77,142,
                              41,102,216,102,142,30,14,88,158,185,236,61,107,
                              173,241,246,189,105,226,61,90,41,52,203,89,34,
                              133,34,96,254,108,101,73,39,28,127,58,227,173,
                              80,71,118,64,9,198,75,1,233,232,43,211,194,73,
                              170,49,82,86,125,143,31,23,24,251,121,114,62,
                              101,125,205,95,35,204,133,173,202,186,203,25,56,
                              110,63,60,251,211,151,42,171,242,59,198,203,128,
                              120,224,143,66,59,212,214,18,218,139,200,82,236,
                              6,183,152,5,152,167,222,216,125,61,235,217,236,
                              252,33,225,155,95,13,216,248,135,199,215,150,
                              250,84,75,23,148,182,137,251,181,97,146,80,176,
                              3,37,202,227,229,31,141,116,69,94,23,57,167,43,
                              61,81,228,186,54,251,107,89,174,203,93,52,160,
                              236,70,126,163,35,24,247,235,64,138,123,55,146,
                              75,171,91,134,12,0,97,129,184,159,82,59,3,94,
                              183,97,121,240,91,197,36,233,218,110,169,46,157,
                              124,232,35,139,205,71,139,121,61,2,150,27,115,
                              245,197,121,215,197,29,19,91,240,190,167,45,173,
                              199,239,160,156,230,43,150,201,220,163,129,244,
                              97,199,21,14,205,222,247,33,78,234,214,177,77,
                              244,43,68,144,108,191,142,89,112,178,53,151,150,
                              119,179,55,240,41,60,100,113,214,178,117,24,158,
                              218,231,201,186,89,142>>}
** When Server state == {state,
                            {request,#Ref<0.0.0.6803>,<0.96.0>,0,http,
                                {"s3.amazonaws.com",80},
                                "/twitter_production/profile_images/219314140/obama_4color_omark_normal.jpg",
                                [],get,
                                {http_request_h,undefined,"keep-alive",
                                    undefined,undefined,undefined,undefined,
                                    undefined,undefined,undefined,undefined,
                                    undefined,undefined,undefined,undefined,
                                    undefined,undefined,"s3.amazonaws.com",
                                    undefined,undefined,undefined,undefined,
                                    undefined,undefined,undefined,undefined,
                                    undefined,[],undefined,undefined,
                                    undefined,undefined,"0",undefined,
                                    undefined,undefined,undefined,undefined,
                                    undefined,[]},
                                {[],[]},
                                {http_options,"HTTP/1.1",infinity,true,[],
                                    undefined,false},
                                "http://s3.amazonaws.com/twitter_production/profile_images/219314140/obama_4color_omark_normal.jpg",
                                [],none,[]},
                            {tcp_session,
                                {{"s3.amazonaws.com",80},<0.927.0>},
                                false,http,#Port<0.3985>,1,keep_alive},
                            {"HTTP/1.1",200,"OK"},
                            {http_response_h,"max-age=252460800",undefined,
                                "Tue, 11 Aug 2009 11:26:23 GMT",undefined,
                                undefined,undefined,undefined,undefined,
                                undefined,undefined,undefined,
                                "\"3201981bf67bbdf7a6d72399468f9d2d\"",
                                undefined,undefined,undefined,"AmazonS3",
                                undefined,undefined,undefined,undefined,
                                undefined,"30570",undefined,undefined,
                                undefined,"image/jpeg",
                                "Thu, 09 Mar 2017 16:09:46 GMT",
                                "Mon, 09 Mar 2009 16:09:46 GMT",
                                [{"x-amz-id-2",
                                  "/AvfWrSuGZ2NN5VP6+feFF3w/3kgIrv4OGgzlMMCdhBuxlGjQ2qQgKsHnUJgQ8Nk"},
                                 {"x-amz-request-id","D6251E0A344C740D"}]},
                            undefined,
                            {httpc_response,parse,[nolimit,false]},
                            {[],[]},
                            {[],[]},
                            keep_alive,[],nolimit,nolimit,
                            {options,
                                {undefined,[]},
                                0,2,5,120000,2,disabled,false,inet,default,
                                default},
                            {timers,[],#Ref<0.0.0.6776>},
                            httpc_manager,undefined}
** Reason for termination == 
** {bad_return_value,
       {error,
           {invalid_version,
               [82,18,138,6,220,185,201,110,222,213,231,212,119,168,206,218,
                92,188,169,35,173,191,240,215,132,228,5,173,124,97,109,20,188,
                130,98,157,200,7,184,35,21,21,223,135,252,51,111,18,64,222,48,
                138,69,242,246,110,121,31,57,63,133,115,49,51,65,33,48,249,
                127,103,150,79,152,168,231,119,248,251,213,219,251,175,50,209,
                164,37,36,116,83,188,130,11,14,220,227,173,71,45,217,182,219,
                23,245,15,15,232,23,50,198,176,120,227,201,137,48,25,165,153,
                153,155,177,57,219,216,1,86,174,60,61,161,91,106,214,177,232,
                158,47,51,93,74,190,82,24,228,119,126,84,146,199,229,234,122,
                86,77,170,197,61,178,170,71,186,52,83,184,176,251,173,142,149,
                78,210,246,226,195,89,183,125,61,228,91,165,114,209,202,220,
                175,211,220,211,229,178,220,92,215,232,81,248,131,160,69,162,
                91,65,38,110,11,92,146,16,73,242,240,62,241,218,71,174,57,250,
                215,22,107,178,248,177,172,221,234,23,186,96,212,238,3,79,21,
                166,31,113,198,24,187,118,250,98,184,89,111,109,163,235,50,
                146,123,14,107,158,178,114,157,162,143,162,192,212,165,67,14,
                185,228,151,204,145,234,39,161,46]}}}

=CRASH REPORT==== 11-Aug-2009::11:26:23 ===
  crasher:
    initial call: httpc_handler:init/1
    pid: <0.927.0>
    registered_name: []
    exception exit: {bad_return_value,
                        {error,
                            {invalid_version,
                                [82,18,138,6,220,185,201,110,222,213,231,212,
                                 119,168,206,218,92,188,169,35,173,191,240,
                                 215,132,228,5,173,124,97,109,20,188,130,98,
                                 157,200,7,184,35,21,21,223,135,252,51,111,18,
                                 64,222,48,138,69,242,246,110,121,31,57,63,
                                 133,115,49,51,65,33,48,249,127,103,150,79,
                                 152,168,231,119,248,251,213,219,251,175,50,
                                 209,164,37,36,116,83,188,130,11,14,220,227,
                                 173,71,45,217,182,219,23,245,15,15,232,23,50,
                                 198,176,120,227,201,137,48,25,165,153,153,
                                 155,177,57,219,216,1,86,174,60,61,161,91,106,
                                 214,177,232,158,47,51,93,74,190,82,24,228,
                                 119,126,84,146,199,229,234,122,86,77,170,197,
                                 61,178,170,71,186,52,83,184,176,251,173,142,
                                 149,78,210,246,226,195,89,183,125,61,228,91,
                                 165,114,209,202,220,175,211,220,211,229,178,
                                 220,92,215,232,81,248,131,160,69,162,91,65,
                                 38,110,11,92,146,16,73,242,240,62,241,218,71,
                                 174,57,250,215,22,107,178,248,177,172,221,
                                 234,23,186,96,212,238,3,79,21,166,31,113,198,
                                 24,187,118,250,98,184,89,111,109,163,235,50,
                                 146,123,14,107,158,178,114,157,162,143,162,
                                 192,212,165,67,14,185,228,151,204,145,234,39,
                                 161,46]}}}
      in function  gen_server:terminate/6
    ancestors: [httpc_handler_sup,httpc_sup,inets_sup,<0.63.0>]
    messages: []
    links: [<0.69.0>]
    dictionary: []
    trap_exit: true
    status: running
    heap_size: 4181
    stack_size: 24
    reductions: 7730
  neighbours:

=SUPERVISOR REPORT==== 11-Aug-2009::11:26:23 ===
     Supervisor: {local,httpc_handler_sup}
     Context:    child_terminated
     Reason:     {bad_return_value,
                     {error,
                         {invalid_version,
                             [82,18,138,6,220,185,201,110,222,213,231,212,119,
                              168,206,218,92,188,169,35,173,191,240,215,132,
                              228,5,173,124,97,109,20,188,130,98,157,200,7,
                              184,35,21,21,223,135,252,51,111,18,64,222,48,
                              138,69,242,246,110,121,31,57,63,133,115,49,51,
                              65,33,48,249,127,103,150,79,152,168,231,119,248,
                              251,213,219,251,175,50,209,164,37,36,116,83,188,
                              130,11,14,220,227,173,71,45,217,182,219,23,245,
                              15,15,232,23,50,198,176,120,227,201,137,48,25,
                              165,153,153,155,177,57,219,216,1,86,174,60,61,
                              161,91,106,214,177,232,158,47,51,93,74,190,82,
                              24,228,119,126,84,146,199,229,234,122,86,77,170,
                              197,61,178,170,71,186,52,83,184,176,251,173,142,
                              149,78,210,246,226,195,89,183,125,61,228,91,165,
                              114,209,202,220,175,211,220,211,229,178,220,92,
                              215,232,81,248,131,160,69,162,91,65,38,110,11,
                              92,146,16,73,242,240,62,241,218,71,174,57,250,
                              215,22,107,178,248,177,172,221,234,23,186,96,
                              212,238,3,79,21,166,31,113,198,24,187,118,250,
                              98,184,89,111,109,163,235,50,146,123,14,107,158,
                              178,114,157,162,143,162,192,212,165,67,14,185,
                              228,151,204,145,234,39,161,46]}}}
     Offender:   [{pid,<0.927.0>},
                  {name,undefined},
                  {mfa,
                      {httpc_handler,start_link,
                          [{request,#Ref<0.0.0.6746>,<0.96.0>,0,http,
                               {"s3.amazonaws.com",80},
                               "/twitter_production/profile_images/71412989/Picture_4_normal.png",
                               [],get,
                               {http_request_h,undefined,"keep-alive",
                                   undefined,undefined,undefined,undefined,
                                   undefined,undefined,undefined,undefined,
                                   undefined,undefined,undefined,undefined,
                                   undefined,undefined,"s3.amazonaws.com",
                                   undefined,undefined,undefined,undefined,
                                   undefined,undefined,undefined,undefined,
                                   undefined,[],undefined,undefined,undefined,
                                   undefined,"0",undefined,undefined,
                                   undefined,undefined,undefined,undefined,[]},
                               {[],[]},
                               {http_options,"HTTP/1.1",infinity,true,[],
                                   undefined,false},
                               "http://s3.amazonaws.com/twitter_production/profile_images/71412989/Picture_4_normal.png",
                               [],none,[]},
                           {options,
                               {undefined,[]},
                               0,2,5,120000,2,disabled,false,inet,default,
                               default},
                           httpc_manager]}},
                  {restart_type,temporary},
                  {shutdown,4000},
                  {child_type,worker}]

From baryluk@REDACTED  Tue Aug 11 14:03:11 2009
From: baryluk@REDACTED (Witold Baryluk)
Date: Tue, 11 Aug 2009 14:03:11 +0200
Subject: [erlang-bugs] HTTP client error, invalid_version
In-Reply-To: <46167e6a0908110447l437ea651yf6da2f616bc2bb37@mail.gmail.com>
References: <46167e6a0908110447l437ea651yf6da2f616bc2bb37@mail.gmail.com>
Message-ID: <1249992191.20019.0.camel@sredniczarny>

Dnia 2009-08-11, wto o godzinie 12:47 +0100, Anton Krasovsky pisze:
> I'm using inets http client to fetch some twitter profile images
> (hosted on amazon s3), observed a crash in http client.
> 
> Attaching a trace.

Reported few days ago by me, with the same problem.

Are you doing multiple concurrent requests to the same server
from the same profile?

-- 
Witold Baryluk <baryluk@REDACTED>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: To jest cz??? wiadomo?ci podpisana cyfrowo
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090811/87342349/attachment.bin>

From prikrutil@REDACTED  Tue Aug 11 20:00:18 2009
From: prikrutil@REDACTED (Sergey Samokhin)
Date: Tue, 11 Aug 2009 11:00:18 -0700
Subject: [erlang-bugs] Arguments passed to escript's emulator by %%! 
	affect os:cmd/1o
In-Reply-To: <Pine.LNX.4.64.0908031721210.8538@falco.du.uab.ericsson.se>
References: <e42595410907211243vaf67ea4qd54c213d3927e430@mail.gmail.com> 
	<Pine.LNX.4.64.0908031721210.8538@falco.du.uab.ericsson.se>
Message-ID: <e42595410908111100o28abe83aybce815d5f4f1bb9e@mail.gmail.com>

Hello.

> It is now fixed and it will be released in R13B02.

Thanks for that!

-- 
Sergey Samokhin

From pfisher@REDACTED  Wed Aug 12 14:59:47 2009
From: pfisher@REDACTED (Paul Fisher)
Date: Wed, 12 Aug 2009 07:59:47 -0500
Subject: [erlang-bugs] R13B-1 internal error in v3_codegen
In-Reply-To: <6672d0160908110155r7a1ce53fk44710b4b9249b0b8@mail.gmail.com>
References: <4A760E50.8000800@alertlogic.net>	 <6672d0160908030649q18ea9adftdc8bfe42b9ea2722@mail.gmail.com>	 <4A7703A3.2090700@alertlogic.net> <6672d0160908110155r7a1ce53fk44710b4b9249b0b8@mail.gmail.com>
Message-ID: <4A82BCC3.4020909@alertlogic.net>

Bjorn Gustavsson wrote:
> On Mon, Aug 3, 2009 at 5:34 PM, Paul Fisher<pfisher@REDACTED> wrote:
>> Bjorn Gustavsson wrote:
>>> On Mon, Aug 3, 2009 at 12:08 AM, Paul Fisher<pfisher@REDACTED>
>>> wrote:
>>>> Is this a known issue, and is there a patch?
>>> Can you post a compilable version of the source code?
>> The original was 3000+ lines, but i've reduced it to this:
> [...]
> 
> Thanks for reporting this bug and for reducing the source code.
> 
> A correction will be included in R13B02.

Thank you for fixing this!

Is R13B02 imminent? If not, is it possible to get a patch against R13B01 
which resolves this?


--
paul

From ulf.wiger@REDACTED  Wed Aug 12 15:52:57 2009
From: ulf.wiger@REDACTED (Ulf Wiger)
Date: Wed, 12 Aug 2009 15:52:57 +0200
Subject: [erlang-bugs] R13B-1 internal error in v3_codegen
In-Reply-To: <4A82BCC3.4020909@alertlogic.net>
References: <4A760E50.8000800@alertlogic.net>	 <6672d0160908030649q18ea9adftdc8bfe42b9ea2722@mail.gmail.com>	 <4A7703A3.2090700@alertlogic.net> <6672d0160908110155r7a1ce53fk44710b4b9249b0b8@mail.gmail.com> <4A82BCC3.4020909@alertlogic.net>
Message-ID: <4A82C939.2040709@erlang-consulting.com>


I noticed that there are daily R13B02 snapshots
available since 11 Jun.

If a correction exists as of a certain snapshot, that
might be useful information, esp if it might be possible
for the enterprising user to extract their own patch. :)

http://erlang.org/download/snapshots/otp_html_R13B02_2009-08-11_18.tar.gz

BR,
Ulf W

Paul Fisher wrote:
> Bjorn Gustavsson wrote:
>> On Mon, Aug 3, 2009 at 5:34 PM, Paul Fisher<pfisher@REDACTED> 
>> wrote:
>>> Bjorn Gustavsson wrote:
>>>> On Mon, Aug 3, 2009 at 12:08 AM, Paul Fisher<pfisher@REDACTED>
>>>> wrote:
>>>>> Is this a known issue, and is there a patch?
>>>> Can you post a compilable version of the source code?
>>> The original was 3000+ lines, but i've reduced it to this:
>> [...]
>>
>> Thanks for reporting this bug and for reducing the source code.
>>
>> A correction will be included in R13B02.
> 
> Thank you for fixing this!
> 
> Is R13B02 imminent? If not, is it possible to get a patch against R13B01 
> which resolves this?
> 
> 
> -- 
> paul
> 
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
> 


-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

From pfisher@REDACTED  Wed Aug 12 20:03:52 2009
From: pfisher@REDACTED (Paul Fisher)
Date: Wed, 12 Aug 2009 13:03:52 -0500
Subject: [erlang-bugs] R13B-1 internal error in v3_codegen
In-Reply-To: <4A82C939.2040709@erlang-consulting.com>
References: <4A760E50.8000800@alertlogic.net>	 <6672d0160908030649q18ea9adftdc8bfe42b9ea2722@mail.gmail.com>	 <4A7703A3.2090700@alertlogic.net> <6672d0160908110155r7a1ce53fk44710b4b9249b0b8@mail.gmail.com> <4A82BCC3.4020909@alertlogic.net> <4A82C939.2040709@erlang-consulting.com>
Message-ID: <4A830408.8020803@alertlogic.net>

Ulf Wiger wrote:
> I noticed that there are daily R13B02 snapshots
> available since 11 Jun.
> 
> If a correction exists as of a certain snapshot, that
> might be useful information, esp if it might be possible
> for the enterprising user to extract their own patch. :)
> 
> http://erlang.org/download/snapshots/otp_html_R13B02_2009-08-11_18.tar.gz

I'm sure you meant:

http://erlang.org/download/snapshots/otp_src_R13B02.tar.gz

But even that is not really the same thing, since I don't know what 
modules changed and what other changes are active in the new tree.

Anyway, I will start validating the snapshot independently so that I can 
make sure it will be working when 02 is released.

If a patch is easy, and 02 release will be a while, I would still 
appreciate it.  Nothing life and death about it, so please only if it is 
not much trouble.

thanks!


--
paul

From ulf.wiger@REDACTED  Wed Aug 12 21:27:46 2009
From: ulf.wiger@REDACTED (Ulf Wiger)
Date: Wed, 12 Aug 2009 21:27:46 +0200
Subject: [erlang-bugs] R13B-1 internal error in v3_codegen
In-Reply-To: <4A830408.8020803@alertlogic.net>
References: <4A760E50.8000800@alertlogic.net>	 <6672d0160908030649q18ea9adftdc8bfe42b9ea2722@mail.gmail.com>	 <4A7703A3.2090700@alertlogic.net> <6672d0160908110155r7a1ce53fk44710b4b9249b0b8@mail.gmail.com> <4A82BCC3.4020909@alertlogic.net> <4A82C939.2040709@erlang-consulting.com> <4A830408.8020803@alertlogic.net>
Message-ID: <4A8317B2.6030706@erlang-consulting.com>

Yes, apologies.

I should also clarify that I don't know if the
patch is included in the latest snapshot.
I thought I'd suggest that the OTP team could
include that information (and perhaps also which
files were affected) when available.

BR,
Ulf W


Paul Fisher wrote:
> Ulf Wiger wrote:
>> I noticed that there are daily R13B02 snapshots
>> available since 11 Jun.
>>
>> If a correction exists as of a certain snapshot, that
>> might be useful information, esp if it might be possible
>> for the enterprising user to extract their own patch. :)
>>
>> http://erlang.org/download/snapshots/otp_html_R13B02_2009-08-11_18.tar.gz
> 
> I'm sure you meant:
> 
> http://erlang.org/download/snapshots/otp_src_R13B02.tar.gz
> 
> But even that is not really the same thing, since I don't know what 
> modules changed and what other changes are active in the new tree.
> 
> Anyway, I will start validating the snapshot independently so that I can 
> make sure it will be working when 02 is released.
> 
> If a patch is easy, and 02 release will be a while, I would still 
> appreciate it.  Nothing life and death about it, so please only if it is 
> not much trouble.
> 
> thanks!
> 
> 
> -- 
> paul


-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

From kenji.rikitake@REDACTED  Thu Aug 13 12:09:26 2009
From: kenji.rikitake@REDACTED (Kenji Rikitake)
Date: Thu, 13 Aug 2009 19:09:26 +0900
Subject: Erlang R13B01 ssh and crypto module patch of aes128-cbc support on
	ssh
Message-ID: <20090813100926.GA12085@k2r.org>

The following patch includes a feature enhancement of Erlang R13B01 ssh
and crypto modules to support aes128-cbc mode on SSH.

BUG FOUND: ssh_transport:unpack/3 causes crypto:aes_cbc_ivec/1 to crash,
by passing a null binary (<<>>), which causes erlang:split_binary/2 to
crash by badarg.

By tracing the exchange between a FreeBSD OpenSSH implementation, I
found a case where the internal variable SshLength in
ssh_transport:unpack/3 goes to zero, which leads to passing a null
binary as an argument to ssh_transport:decrypt_blocks/3 and to
aes_cbc_ivec/1.  So I added a case statement to avoid calling the
decrypt_blocks/3 when SshLength = 0.

Patches follow.

Kenji Rikitake

--- lib/ssh/src/ssh_transport.erl.FCS	2009-06-05 21:55:34.000000000 +0900
+++ lib/ssh/src/ssh_transport.erl	2009-08-13 17:42:28.000000000 +0900
@@ -228,8 +228,10 @@
 		  cookie = Random,
 		  kex_algorithms = ["diffie-hellman-group1-sha1"],
 		  server_host_key_algorithms = ["ssh-rsa", "ssh-dss"],
-		  encryption_algorithms_client_to_server = ["3des-cbc"],
-		  encryption_algorithms_server_to_client = ["3des-cbc"],
+		  %% encryption_algorithms_client_to_server = ["3des-cbc"],
+		  %% encryption_algorithms_server_to_client = ["3des-cbc"],
+		  encryption_algorithms_client_to_server = ["aes128-cbc","3des-cbc"],
+		  encryption_algorithms_server_to_client = ["aes128-cbc","3des-cbc"],
 		  mac_algorithms_client_to_server = ["hmac-sha1"],
 		  mac_algorithms_server_to_client = ["hmac-sha1"],
 		  compression_algorithms_client_to_server = Compression,
@@ -243,8 +245,10 @@
 		  cookie = Random,
 		  kex_algorithms = ["diffie-hellman-group1-sha1"],
 		  server_host_key_algorithms = ["ssh-dss"],
-		  encryption_algorithms_client_to_server = ["3des-cbc"],
-		  encryption_algorithms_server_to_client = ["3des-cbc"],
+		  %% encryption_algorithms_client_to_server = ["3des-cbc"],
+		  %% encryption_algorithms_server_to_client = ["3des-cbc"],
+		  encryption_algorithms_client_to_server = ["aes128-cbc","3des-cbc"],
+		  encryption_algorithms_server_to_client = ["aes128-cbc","3des-cbc"],
 		  mac_algorithms_client_to_server = ["hmac-sha1"],
 		  mac_algorithms_server_to_client = ["hmac-sha1"],
 		  compression_algorithms_client_to_server = Compression,
@@ -703,6 +707,9 @@
 
 unpack(EncodedSoFar, ReminingLenght, #ssh{recv_mac_size = MacSize} = Ssh0) ->
     SshLength = ReminingLenght - MacSize,
+    %%?dbg(?DBG_CRYPTO, 
+    %%     "unpack: EncodedsoFar=~p SshLength=~p ReminingLenght=~p MacSize=~p ~n",
+    %%     [EncodedSoFar, SshLength, ReminingLenght, MacSize]),
     {NoMac, Mac, Rest} = case MacSize of
 			     0 ->
 				 <<NoMac0:SshLength/binary, 
@@ -714,8 +721,16 @@
 				  Rest0/binary>> = EncodedSoFar,
 				 {NoMac0, Mac0, Rest0}
 			 end,
-    {Ssh1, DecData, <<>>} = 
-	ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0),
+    %%?dbg(?DBG_CRYPTO, "unpack: NoMac=~p Mac=~p Rest=~p ~n",
+    %%     [NoMac, Mac, Rest]),
+    {Ssh1, DecData, <<>>} = case SshLength of
+			        0 ->
+				    {Ssh0, <<>>, <<>>};
+				_ ->
+				     ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0)
+			    end,
+    %%?dbg(?DBG_CRYPTO, "unpack: Ssh1=~p DecData=~p Rest=~p Mac=~p ~n",
+    %%     [Ssh1, DecData, Rest, Mac]),
     {Ssh1, DecData, Rest, Mac}.
 
 msg_data(PacketData) ->
@@ -800,6 +815,18 @@
     <<K1:8/binary, K2:8/binary, K3:8/binary>> = hash(Ssh, "D", 192),
     {ok, Ssh#ssh{encrypt_keys = {K1,K2,K3},
 		 encrypt_block_size = 8,
+		 encrypt_ctx = IV}};
+encrypt_init(#ssh{encrypt = 'aes128-cbc', role = client} = Ssh) ->
+    IV = hash(Ssh, "A", 128),
+    <<K:16/binary>> = hash(Ssh, "C", 128),
+    {ok, Ssh#ssh{encrypt_keys = K,
+		 encrypt_block_size = 16,
+		 encrypt_ctx = IV}};
+encrypt_init(#ssh{encrypt = 'aes128-cbc', role = server} = Ssh) ->
+    IV = hash(Ssh, "B", 128),
+    <<K:16/binary>> = hash(Ssh, "D", 128),
+    {ok, Ssh#ssh{encrypt_keys = K,
+		 encrypt_block_size = 16,
 		 encrypt_ctx = IV}}.
 
 encrypt_final(Ssh) ->
@@ -815,10 +842,19 @@
 	     encrypt_keys = {K1,K2,K3},
 	     encrypt_ctx = IV0} = Ssh, Data) ->
     %%?dbg(?DBG_CRYPTO, "encrypt: IV=~p K1=~p, K2=~p, K3=~p ~n",
-    %%	 [IV0,K1,K2,K3]),
+    %%         [IV0,K1,K2,K3]),
     Enc = crypto:des3_cbc_encrypt(K1,K2,K3,IV0,Data),
     %%?dbg(?DBG_CRYPTO, "encrypt: ~p -> ~p ~n", [Data, Enc]),
     IV = crypto:des_cbc_ivec(Enc),
+    {Ssh#ssh{encrypt_ctx = IV}, Enc};
+encrypt(#ssh{encrypt = 'aes128-cbc',
+	     encrypt_keys = K,
+	     encrypt_ctx = IV0} = Ssh, Data) ->
+    %%?dbg(?DBG_CRYPTO, "encrypt: IV=~p K=~p ~n",
+    %%     [IV0,K]),
+    Enc = crypto:aes_cbc_128_encrypt(K,IV0,Data),
+    %%?dbg(?DBG_CRYPTO, "encrypt: ~p -> ~p ~n", [Data, Enc]),
+    IV = crypto:aes_cbc_ivec(Enc),
     {Ssh#ssh{encrypt_ctx = IV}, Enc}.
   
 
@@ -840,7 +876,21 @@
 		hash(Ssh, "C", 192)},
     <<K1:8/binary, K2:8/binary, K3:8/binary>> = KD,
     {ok, Ssh#ssh{decrypt_keys = {K1, K2, K3}, decrypt_ctx = IV,
-		 decrypt_block_size = 8}}.
+		 decrypt_block_size = 8}};
+
+decrypt_init(#ssh{decrypt = 'aes128-cbc', role = client} = Ssh) ->
+    {IV, KD} = {hash(Ssh, "B", 128),
+		hash(Ssh, "D", 128)},
+    <<K:16/binary>> = KD,
+    {ok, Ssh#ssh{decrypt_keys = K, decrypt_ctx = IV,
+			 decrypt_block_size = 16}}; 
+
+decrypt_init(#ssh{decrypt = 'aes128-cbc', role = server} = Ssh) ->
+    {IV, KD} = {hash(Ssh, "A", 128),
+		hash(Ssh, "C", 128)},
+    <<K:16/binary>> = KD,
+    {ok, Ssh#ssh{decrypt_keys = K, decrypt_ctx = IV,
+		 decrypt_block_size = 16}}.
   
 decrypt_final(Ssh) ->
     {ok, Ssh#ssh {decrypt = none, 
@@ -858,6 +908,14 @@
     Dec = crypto:des3_cbc_decrypt(K1,K2,K3,IV0,Data),
     %%?dbg(?DBG_CRYPTO, "decrypt: ~p -> ~p ~n", [Data, Dec]),
     IV = crypto:des_cbc_ivec(Data),
+    {Ssh#ssh{decrypt_ctx = IV}, Dec};
+decrypt(#ssh{decrypt = 'aes128-cbc', decrypt_keys = Key,
+	     decrypt_ctx = IV0} = Ssh, Data) ->
+    %%?dbg(?DBG_CRYPTO, "decrypt: IV=~p Key=~p ~n",
+    %%     [IV0,Key]),
+    Dec = crypto:aes_cbc_128_decrypt(Key,IV0,Data),
+    %%?dbg(?DBG_CRYPTO, "decrypt: ~p -> ~p ~n", [Data, Dec]),
+    IV = crypto:aes_cbc_ivec(Data),
     {Ssh#ssh{decrypt_ctx = IV}, Dec}.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- lib/crypto/src/crypto.erl.FCS	2009-03-12 21:28:35.000000000 +0900
+++ lib/crypto/src/crypto.erl	2009-08-13 13:27:09.000000000 +0900
@@ -45,6 +45,7 @@
 %% -export([idea_cbc_encrypt/3, idea_cbc_decrypt/3]).
 -export([aes_cbc_128_encrypt/3, aes_cbc_128_decrypt/3]).
 -export([aes_cbc_256_encrypt/3, aes_cbc_256_decrypt/3]).
+-export([aes_cbc_ivec/1]).
 
 -export([dh_generate_parameters/2, dh_check/1]). %% Testing see below
 
@@ -469,6 +470,19 @@
     control(?AES_CBC_256_DECRYPT, [Key, IVec, Data]).
 
 %%
+%% aes_cbc_ivec(Data) -> binary()
+%%
+%% Returns the IVec to be used in the next iteration of 
+%% aes_cbc_*_[encrypt|decrypt].
+%% IVec size: 16 bytes
+%%
+aes_cbc_ivec(Data) when is_binary(Data) -> 
+    {_, IVec} = split_binary(Data, size(Data) - 16),
+    IVec;
+aes_cbc_ivec(Data) when is_list(Data) ->
+    aes_cbc_ivec(list_to_binary(Data)).
+
+%%
 %% XOR - xor to iolists and return a binary
 %% NB doesn't check that they are the same size, just concatenates
 %% them and sends them to the driver
-------------- next part --------------
--- lib/ssh/src/ssh_transport.erl.FCS	2009-06-05 21:55:34.000000000 +0900
+++ lib/ssh/src/ssh_transport.erl	2009-08-13 17:42:28.000000000 +0900
@@ -228,8 +228,10 @@
 		  cookie = Random,
 		  kex_algorithms = ["diffie-hellman-group1-sha1"],
 		  server_host_key_algorithms = ["ssh-rsa", "ssh-dss"],
-		  encryption_algorithms_client_to_server = ["3des-cbc"],
-		  encryption_algorithms_server_to_client = ["3des-cbc"],
+		  %% encryption_algorithms_client_to_server = ["3des-cbc"],
+		  %% encryption_algorithms_server_to_client = ["3des-cbc"],
+		  encryption_algorithms_client_to_server = ["aes128-cbc","3des-cbc"],
+		  encryption_algorithms_server_to_client = ["aes128-cbc","3des-cbc"],
 		  mac_algorithms_client_to_server = ["hmac-sha1"],
 		  mac_algorithms_server_to_client = ["hmac-sha1"],
 		  compression_algorithms_client_to_server = Compression,
@@ -243,8 +245,10 @@
 		  cookie = Random,
 		  kex_algorithms = ["diffie-hellman-group1-sha1"],
 		  server_host_key_algorithms = ["ssh-dss"],
-		  encryption_algorithms_client_to_server = ["3des-cbc"],
-		  encryption_algorithms_server_to_client = ["3des-cbc"],
+		  %% encryption_algorithms_client_to_server = ["3des-cbc"],
+		  %% encryption_algorithms_server_to_client = ["3des-cbc"],
+		  encryption_algorithms_client_to_server = ["aes128-cbc","3des-cbc"],
+		  encryption_algorithms_server_to_client = ["aes128-cbc","3des-cbc"],
 		  mac_algorithms_client_to_server = ["hmac-sha1"],
 		  mac_algorithms_server_to_client = ["hmac-sha1"],
 		  compression_algorithms_client_to_server = Compression,
@@ -703,6 +707,9 @@
 
 unpack(EncodedSoFar, ReminingLenght, #ssh{recv_mac_size = MacSize} = Ssh0) ->
     SshLength = ReminingLenght - MacSize,
+    %%?dbg(?DBG_CRYPTO, 
+    %%     "unpack: EncodedsoFar=~p SshLength=~p ReminingLenght=~p MacSize=~p ~n",
+    %%     [EncodedSoFar, SshLength, ReminingLenght, MacSize]),
     {NoMac, Mac, Rest} = case MacSize of
 			     0 ->
 				 <<NoMac0:SshLength/binary, 
@@ -714,8 +721,16 @@
 				  Rest0/binary>> = EncodedSoFar,
 				 {NoMac0, Mac0, Rest0}
 			 end,
-    {Ssh1, DecData, <<>>} = 
-	ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0),
+    %%?dbg(?DBG_CRYPTO, "unpack: NoMac=~p Mac=~p Rest=~p ~n",
+    %%     [NoMac, Mac, Rest]),
+    {Ssh1, DecData, <<>>} = case SshLength of
+			        0 ->
+				    {Ssh0, <<>>, <<>>};
+				_ ->
+				     ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0)
+			    end,
+    %%?dbg(?DBG_CRYPTO, "unpack: Ssh1=~p DecData=~p Rest=~p Mac=~p ~n",
+    %%     [Ssh1, DecData, Rest, Mac]),
     {Ssh1, DecData, Rest, Mac}.
 
 msg_data(PacketData) ->
@@ -800,6 +815,18 @@
     <<K1:8/binary, K2:8/binary, K3:8/binary>> = hash(Ssh, "D", 192),
     {ok, Ssh#ssh{encrypt_keys = {K1,K2,K3},
 		 encrypt_block_size = 8,
+		 encrypt_ctx = IV}};
+encrypt_init(#ssh{encrypt = 'aes128-cbc', role = client} = Ssh) ->
+    IV = hash(Ssh, "A", 128),
+    <<K:16/binary>> = hash(Ssh, "C", 128),
+    {ok, Ssh#ssh{encrypt_keys = K,
+		 encrypt_block_size = 16,
+		 encrypt_ctx = IV}};
+encrypt_init(#ssh{encrypt = 'aes128-cbc', role = server} = Ssh) ->
+    IV = hash(Ssh, "B", 128),
+    <<K:16/binary>> = hash(Ssh, "D", 128),
+    {ok, Ssh#ssh{encrypt_keys = K,
+		 encrypt_block_size = 16,
 		 encrypt_ctx = IV}}.
 
 encrypt_final(Ssh) ->
@@ -815,10 +842,19 @@
 	     encrypt_keys = {K1,K2,K3},
 	     encrypt_ctx = IV0} = Ssh, Data) ->
     %%?dbg(?DBG_CRYPTO, "encrypt: IV=~p K1=~p, K2=~p, K3=~p ~n",
-    %%	 [IV0,K1,K2,K3]),
+    %%         [IV0,K1,K2,K3]),
     Enc = crypto:des3_cbc_encrypt(K1,K2,K3,IV0,Data),
     %%?dbg(?DBG_CRYPTO, "encrypt: ~p -> ~p ~n", [Data, Enc]),
     IV = crypto:des_cbc_ivec(Enc),
+    {Ssh#ssh{encrypt_ctx = IV}, Enc};
+encrypt(#ssh{encrypt = 'aes128-cbc',
+	     encrypt_keys = K,
+	     encrypt_ctx = IV0} = Ssh, Data) ->
+    %%?dbg(?DBG_CRYPTO, "encrypt: IV=~p K=~p ~n",
+    %%     [IV0,K]),
+    Enc = crypto:aes_cbc_128_encrypt(K,IV0,Data),
+    %%?dbg(?DBG_CRYPTO, "encrypt: ~p -> ~p ~n", [Data, Enc]),
+    IV = crypto:aes_cbc_ivec(Enc),
     {Ssh#ssh{encrypt_ctx = IV}, Enc}.
   
 
@@ -840,7 +876,21 @@
 		hash(Ssh, "C", 192)},
     <<K1:8/binary, K2:8/binary, K3:8/binary>> = KD,
     {ok, Ssh#ssh{decrypt_keys = {K1, K2, K3}, decrypt_ctx = IV,
-		 decrypt_block_size = 8}}.
+		 decrypt_block_size = 8}};
+
+decrypt_init(#ssh{decrypt = 'aes128-cbc', role = client} = Ssh) ->
+    {IV, KD} = {hash(Ssh, "B", 128),
+		hash(Ssh, "D", 128)},
+    <<K:16/binary>> = KD,
+    {ok, Ssh#ssh{decrypt_keys = K, decrypt_ctx = IV,
+			 decrypt_block_size = 16}}; 
+
+decrypt_init(#ssh{decrypt = 'aes128-cbc', role = server} = Ssh) ->
+    {IV, KD} = {hash(Ssh, "A", 128),
+		hash(Ssh, "C", 128)},
+    <<K:16/binary>> = KD,
+    {ok, Ssh#ssh{decrypt_keys = K, decrypt_ctx = IV,
+		 decrypt_block_size = 16}}.
   
 decrypt_final(Ssh) ->
     {ok, Ssh#ssh {decrypt = none, 
@@ -858,6 +908,14 @@
     Dec = crypto:des3_cbc_decrypt(K1,K2,K3,IV0,Data),
     %%?dbg(?DBG_CRYPTO, "decrypt: ~p -> ~p ~n", [Data, Dec]),
     IV = crypto:des_cbc_ivec(Data),
+    {Ssh#ssh{decrypt_ctx = IV}, Dec};
+decrypt(#ssh{decrypt = 'aes128-cbc', decrypt_keys = Key,
+	     decrypt_ctx = IV0} = Ssh, Data) ->
+    %%?dbg(?DBG_CRYPTO, "decrypt: IV=~p Key=~p ~n",
+    %%     [IV0,Key]),
+    Dec = crypto:aes_cbc_128_decrypt(Key,IV0,Data),
+    %%?dbg(?DBG_CRYPTO, "decrypt: ~p -> ~p ~n", [Data, Dec]),
+    IV = crypto:aes_cbc_ivec(Data),
     {Ssh#ssh{decrypt_ctx = IV}, Dec}.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-------------- next part --------------
--- lib/crypto/src/crypto.erl.FCS	2009-03-12 21:28:35.000000000 +0900
+++ lib/crypto/src/crypto.erl	2009-08-13 13:27:09.000000000 +0900
@@ -45,6 +45,7 @@
 %% -export([idea_cbc_encrypt/3, idea_cbc_decrypt/3]).
 -export([aes_cbc_128_encrypt/3, aes_cbc_128_decrypt/3]).
 -export([aes_cbc_256_encrypt/3, aes_cbc_256_decrypt/3]).
+-export([aes_cbc_ivec/1]).
 
 -export([dh_generate_parameters/2, dh_check/1]). %% Testing see below
 
@@ -469,6 +470,19 @@
     control(?AES_CBC_256_DECRYPT, [Key, IVec, Data]).
 
 %%
+%% aes_cbc_ivec(Data) -> binary()
+%%
+%% Returns the IVec to be used in the next iteration of 
+%% aes_cbc_*_[encrypt|decrypt].
+%% IVec size: 16 bytes
+%%
+aes_cbc_ivec(Data) when is_binary(Data) -> 
+    {_, IVec} = split_binary(Data, size(Data) - 16),
+    IVec;
+aes_cbc_ivec(Data) when is_list(Data) ->
+    aes_cbc_ivec(list_to_binary(Data)).
+
+%%
 %% XOR - xor to iolists and return a binary
 %% NB doesn't check that they are the same size, just concatenates
 %% them and sends them to the driver

From bgustavsson@REDACTED  Thu Aug 13 13:41:08 2009
From: bgustavsson@REDACTED (Bjorn Gustavsson)
Date: Thu, 13 Aug 2009 13:41:08 +0200
Subject: [erlang-bugs] R13B-1 internal error in v3_codegen
In-Reply-To: <4A8317B2.6030706@erlang-consulting.com>
References: <4A760E50.8000800@alertlogic.net>
	 <6672d0160908030649q18ea9adftdc8bfe42b9ea2722@mail.gmail.com>
	 <4A7703A3.2090700@alertlogic.net>
	 <6672d0160908110155r7a1ce53fk44710b4b9249b0b8@mail.gmail.com>
	 <4A82BCC3.4020909@alertlogic.net>
	 <4A82C939.2040709@erlang-consulting.com>
	 <4A830408.8020803@alertlogic.net>
	 <4A8317B2.6030706@erlang-consulting.com>
Message-ID: <6672d0160908130441y193879bbk187900db29e5d83f@mail.gmail.com>

On Wed, Aug 12, 2009 at 9:27 PM, Ulf
Wiger<ulf.wiger@REDACTED> wrote:
> I should also clarify that I don't know if the
> patch is included in the latest snapshot.
> I thought I'd suggest that the OTP team could
> include that information (and perhaps also which
> files were affected) when available.

The patch is included in the last snapshot.

It might be easiest to replace the entire compiler application. If you
want to pick individual files, the following modules have corrections
for the three bugs I have fixed for R13B02:

lib/compiler/src/beam_utils.erl
lib/compiler/src/v3_codegen.erl
lib/compiler/src/v3_core.erl

/Bjorn

-- 
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB

From davidepesa@REDACTED  Sun Aug 16 22:05:35 2009
From: davidepesa@REDACTED (Davide Pesavento)
Date: Sun, 16 Aug 2009 22:05:35 +0200
Subject: [erlang-bugs] Build system ignores LDFLAGS
Message-ID: <2da21fe50908161305n6b3ce3cam3283ed47fadf91e6@mail.gmail.com>

On Mon, Apr 20, 2009 at 14:30, Raimo
Niskanen<raimo+erlang-bugs@REDACTED> wrote:
> On Fri, Apr 17, 2009 at 11:34:49PM +0200, Davide Pesavento wrote:
>> On Sat, Apr 4, 2009 at 13:05, Davide Pesavento <davidepesa@REDACTED> wrote:
>> > On Tue, Mar 31, 2009 at 22:13, Davide Pesavento <davidepesa@REDACTED> wrote:
>> >> Hello,
>> >>
>> >> Erlang's build system seems to ignore custom LDFLAGS. This is the QA
>> >> warning shown by Portage (Gentoo Linux's package manager) after
>> >> building R12B-5 with LDFLAGS="-Wl,-O1 -Wl,--as-needed
>> >> -Wl,--hash-style=gnu"
>> >>
>> >> QA Notice: Files built without respecting LDFLAGS have been detected
>> >> ?Please include the following list of files in your report:
>> >> /usr/lib64/erlang/lib/runtime_tools-1.7.3/priv/lib/trace_file_drv.so
>> >> /usr/lib64/erlang/lib/runtime_tools-1.7.3/priv/lib/trace_ip_drv.so
>> >> /usr/lib64/erlang/lib/megaco-3.9.1.1/priv/lib/megaco_flex_scanner_drv_mt.so
>> >> /usr/lib64/erlang/lib/megaco-3.9.1.1/priv/lib/megaco_flex_scanner_drv.so
>> >> /usr/lib64/erlang/lib/erl_interface-3.5.9/bin/erl_call
>> >> /usr/lib64/erlang/lib/ssl-3.10/priv/bin/ssl_esock
>> >> /usr/lib64/erlang/lib/asn1-1.6.2/priv/lib/asn1_erl_drv.so
>> >> /usr/lib64/erlang/lib/crypto-1.5.3/priv/lib/crypto_drv.so
>> >> /usr/lib64/erlang/lib/common_test-1.3.4/priv/lib/erl_rx_driver.so
>> >> /usr/lib64/erlang/erts-5.6.5/bin/child_setup
>> >>
>> >> Before digging into the Makefiles, I'd like to know if you already
>> >> have some ideas about the root cause of this issue.
>> >>
>> >
>> > This bug is still present in R13A.
>> >
>> > ?* QA Notice: Files built without respecting LDFLAGS have been detected
>> > ?* ?Please include the following list of files in your report:
>> > ?* /usr/lib64/erlang/lib/runtime_tools-1.8/priv/lib/trace_file_drv.so
>> > ?* /usr/lib64/erlang/lib/runtime_tools-1.8/priv/lib/trace_ip_drv.so
>> > ?* /usr/lib64/erlang/lib/erl_interface-3.6/bin/erl_call
>> > ?* /usr/lib64/erlang/lib/crypto-1.6/priv/lib/crypto_drv.so
>> > ?* /usr/lib64/erlang/lib/megaco-3.10.0.1/priv/lib/megaco_flex_scanner_drv_mt.so
>> > ?* /usr/lib64/erlang/lib/megaco-3.10.0.1/priv/lib/megaco_flex_scanner_drv.so
>> > ?* /usr/lib64/erlang/lib/ssl-3.10.1/priv/bin/ssl_esock
>> > ?* /usr/lib64/erlang/lib/asn1-1.6.8/priv/lib/asn1_erl_drv.so
>> > ?* /usr/lib64/erlang/erts-5.7/bin/child_setup
>> >
>> > Best regards,
>> > Davide
>> >
>>
>> The attached patch fixes the problem for me: LDFLAGS are now respected.
>>
>> Regards,
>> Davide
>
> The patch looks great! It is unfortunately a few days late to make
> it into R13B. Now the source tree is labeled, and cut in stone.
> We have applied it, and it will be in the first patch release.
>
> We will also release it as a source code patch immediately
> after the R13B release.
>
> More patches like that! (and earlier)-:
>
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
>

As far as I can see the patch has not been applied, or at least it's
not present in R13B01. Has it been lost?

Regards,
Davide
-------------- next part --------------
A non-text attachment was scrubbed...
Name: erlang-R13B-LDFLAGS.patch
Type: application/octet-stream
Size: 4225 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090816/3907e8c8/attachment.obj>

From tuncer.ayaz@REDACTED  Tue Aug 18 02:27:10 2009
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Tue, 18 Aug 2009 02:27:10 +0200
Subject: R13B01: internal error in the boolean guard optimizer
Message-ID: <4ac8254d0908171727g3fdd4c02gbd880e777f327b13@mail.gmail.com>

Is the following a known problem in R13B01?

The fun is taken from "Erlang Programming".

guard(X,Y) when not(((X>Y) or not(is_atom(X)) ) and (is_atom(Y) or (X==3.4))) ->
  X+Y.

Compiling this with erlc results in an internal compiler error which seems
to happen in the beam assembler's boolean guard optimizer pass.

Function: guard/2
./chapter3.erl:none: internal error in beam_bool;
crash reason: {{case_clause,
                   {'EXIT',
                       {function_clause,
                           [{beam_bool,bopt_cg_not,
                                [{'not',{test,is_atom,fail,[{x,0}]}}]},
                            {beam_bool,'-bopt_cg_not/1-lc$^1/1-0-',1},
                            {beam_bool,'-bopt_cg_not/1-lc$^1/1-0-',1},
                            {beam_bool,bopt_cg_not,1},
                            {beam_bool,'-bopt_cg_not/1-lc$^0/1-1-',1},
                            {beam_bool,bopt_cg_not,1},
                            {beam_bool,bopt_cg,5},
                            {beam_bool,bopt_block,5}]}}},
               [{compile,'-select_passes/2-anonymous-2-',2},
                {compile,'-internal_comp/4-anonymous-1-',2},
                {compile,fold_comp,3},
                {compile,internal_comp,4},
                {compile,internal,3}]}

From hans.bolinder@REDACTED  Wed Aug 19 10:06:52 2009
From: hans.bolinder@REDACTED (Hans Bolinder)
Date: Wed, 19 Aug 2009 10:06:52 +0200
Subject: [erlang-bugs] bug in erl_eval
In-Reply-To: <4A4E2497.5030400@erlang-consulting.com>
References: <4A4E2497.5030400@erlang-consulting.com>
Message-ID: <19083.45724.41783.74403@ornendil.du.uab.ericsson.se>

[Ulf Wiger:]
> 
> The following shell dialogue didn't work out
> as expected:
> 
> 1> E = fun(N) -> if is_integer(N) -> <<N/integer>>; true -> throw(foo) 
> end end.
> #Fun<erl_eval.6.13229925>
> 2> << << (E(V))/binary >> || V <- [1,2,3] >>.
> <<1,2,3>>
> 3> catch << << (E(V))/binary >> || V <- [1,2,3,a] >>.
> {'EXIT',{{case_clause,foo},
>           [{erl_eval,expr,5},
>            {erl_eval,eval_bc1,6},
>            {erl_eval,eval_generate,7},
>            {erl_eval,eval_bc,6},
>            {erl_eval,expr,5},
>            {shell,exprs,6},
>            {shell,eval_exprs,6},
>            {shell,eval_loop,3}]}}

Thanks for the bug report. We'll fix the bug in R13B02.

Best regards,

Hans Bolinder, Erlang/OTP team, Ericsson

From hans.bolinder@REDACTED  Wed Aug 19 11:06:16 2009
From: hans.bolinder@REDACTED (Hans Bolinder)
Date: Wed, 19 Aug 2009 11:06:16 +0200
Subject: [erlang-bugs] Possible documentation error?
In-Reply-To: <8f24f4b10907191741o712eb05eoecc734e173691043@mail.gmail.com>
References: <8f24f4b10907191741o712eb05eoecc734e173691043@mail.gmail.com>
Message-ID: <19083.49288.783861.364116@ornendil.du.uab.ericsson.se>

[John Haugeland:]
> >From the lists module documentation for ukeysort/2:
> 
> "Returns a list containing the sorted elements of the list TupleList1 where
> all but the first tuple of the tuples comparing equal have been deleted."
> 
> Actual behavior is to make unique on key equality, not on tuple equality.
> 
> 243> lists:ukeysort(2, [ {1,1}, {2,1}, {2,2} ]).
> [{1,1},{2,2}]
> 
> Am I missing something obvious?

I don't know, perhaps the wording is unclear. But you left out the
last sentence of the documentation:

"Sorting is performed on the Nth element of the tuples."

which means that two tuples compare equal if the Nth element of the
tuples compare equal.

Best regards,

Hans Bolinder, Erlang/OTP team, Ericsson

From essiene@REDACTED  Wed Aug 19 21:35:19 2009
From: essiene@REDACTED (Essien Essien)
Date: Wed, 19 Aug 2009 20:35:19 +0100
Subject: new_ssl [{verify,verify_peer}, {fail_if_no_peer_cert, true}] bug
Message-ID: <88b82c90908191235l48491308x220928de84f8f5f4@mail.gmail.com>

Hi all,

I'm either missing something very major or there is a bug in the way
the new_ssl implementation in R13B-2 handles a Client's
CertificateMessages after it has indeed issued a CertificateRequest to
the connecting client or rather the _absence_ of the
CerfificateMessage

The rfc requires compliant clients to compulsorily return a
CertificateMessage even if its a zero length on, once the server
issues a CertificateRequest, but the rfc also says that it is up to
the server to decide what to do if the client refuses to send its
cert.

I believe then that the fail_if_no_peer_cert option is designed to
control the server's behaviour when there is no client cert, but on
closer inspection and testing, the erlang stack seems to ONLY properly
fail if the clients sends it a CertificateMessage  of zero length.
Normally this would not be a problem, but Mono 2.4-2 infact does just
this. If Mono does not find a certificate to send back to the server
in response to a CertificateRequest during the handshake, it simply
does not send any CertificateMessage request at all, not even one with
a zero length, hence clearly breaking the rfc.

This behaviour currently throws the erlang new_ssl implementation for
a loop and the gen_fsm used by new_ssl just silently moves to the
'cipher' state, where it expects and processes a ClientKeyExchange
message, effectively allowing the erring client to make it through.


In summary, the only valid change from 'certify' to 'cipher' for a
server should be:

1. role = server, current_state = certify, verify = verify_peer,
fail_if_no_peer_cert = false, message = client_key_exchange:
          next_state = cipher

2. role = server, current_state = certify, verify = verify_peer,
fail_if_no_peer_cert = false, message = certificate
          next_state = cipher


3. role = server, current_state = certify, verify = verify_peer,
fail_if_no_peer_cert = true, message = certificate{length > 0}
          next_state = cipher

while the following states should produce an error:

4. role = server, current_state = certify, verify = verify_peer,
fail_if_no_peer_cert = true, message = client_key_exchange:
          next_state = ERROR

5. role = server, current_state = certify, verify = verify_peer,
fail_if_no_peer_cert = true, message = certificate{length = 0}
          next_state = ERROR


Of all the rules above, only rule 4 is not handled by new_ssl in
R13B-2 and the following patch (which is just a quick and dirty proof
of concept) properly kills the connection if the client in the event
that rule 4 occurs.

<patch>

--- /usr/lib/erlang/lib/ssl-3.10.1/src/ssl_connection.erl	2009-04-27
07:05:47.000000000 +0100
+++ ssl-3.10.1/src/ssl_connection.erl	2009-08-07 13:09:02.142360183 +0100
@@ -477,6 +477,11 @@
 	    {stop, normal, State0}
     end;

+certify(#client_key_exchange{}, State =
+        #state{role = server, ssl_options = #ssl_options{verify = verify_peer,
+                fail_if_no_peer_cert = true}}) ->
+    {stop, normal, State};
+
 certify(#client_key_exchange{exchange_keys
 			     = #encrypted_premaster_secret{premaster_secret
 							   = EncPMS}},


</patch>

From anders.nygren@REDACTED  Wed Aug 19 23:06:38 2009
From: anders.nygren@REDACTED (Anders Nygren)
Date: Wed, 19 Aug 2009 16:06:38 -0500
Subject: sctp chunked messages
Message-ID: <d3520a2f0908191406t5c602b8erd24bde0156dda222@mail.gmail.com>

Hi
I am having a problem with chunked messages. When I try to send a
message that is ~2kByte, it gets split into two chunks. But gen_sctp
does not reassemble the chunks and only delivers the last chunk to
my application.
I have attached a simple test case to demonstrate the problem.

To run
Machine A:
sctp_err:server(IP,Port).

Machine B:
sctp_err:client(IP,Port).

I dont know if this is related but sometimes I also receive a
{sctp_error, enoent} before the the #sctp_sndrcvinfo with the second
chunk.

This is using
OTP R13B01
Between two machines running Ubuntu

uname -a
Linux curso-laptop 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25
00:28:35 UTC 2009 i686 GNU/Linux

 uname -a
Linux glr-desktop 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51
UTC 2009 i686 GNU/Linux

/Anders
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sctp_err.erl
Type: application/octet-stream
Size: 1170 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090819/d4b672c3/attachment.obj>

From pfisher@REDACTED  Thu Aug 20 01:53:28 2009
From: pfisher@REDACTED (Paul Fisher)
Date: Wed, 19 Aug 2009 18:53:28 -0500
Subject: mnesia disc_copies memory size corrupts w/HiPE 64-bit
Message-ID: <4A8C9078.2080700@alertlogic.net>

I have a mnesia table that is defined as disc_copies, which ends up with 
a corrupt memory size value after being updated from concurrent (erlang) 
processes from code compiled with HiPE.  All updates to the table are 
done as mnesia:transaction/1 calls.

If I update the table from only two processes the memory size is correct:

(emacs@REDACTED)2> mnesia:table_info(clu_unassignedq,size).
0
(emacs@REDACTED)3> mnesia:table_info(clu_unassignedq,memory).
90

After updating the table via 11 processes, the table size ends up zero, 
but memory size is completely bogus:

(emacs@REDACTED)10> mnesia:table_info(clu_unassignedq,size).
0
(emacs@REDACTED)11> mnesia:table_info(clu_unassignedq,memory).
2305843009213693459

If the same thing is done with the code calling the mnesia operations is 
*not* compiled with HiPE, all is well and everything appears correct.

This appears to be an artifact of the SMP/ets concurrency improvements 
introduced in R13. Thoughts for further investigation?

Platform is amd64 (intel core 2) on opensolaris.  Erlang R13B02 snapshot 
from 2009/08/12.

pfisher@REDACTED:~/lm/third_party/erlang-R13/install/solaris$ gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure 
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as 
--with-ld=/usr/ccs/bin/ld --without-gnu-ld 
--enable-languages=c,c++,f77,objc --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)


--
paul

From pfisher@REDACTED  Thu Aug 20 02:20:27 2009
From: pfisher@REDACTED (Paul Fisher)
Date: Wed, 19 Aug 2009 19:20:27 -0500
Subject: [erlang-bugs] mnesia disc_copies memory size corrupts w/HiPE
 64-bit
In-Reply-To: <4A8C9078.2080700@alertlogic.net>
References: <4A8C9078.2080700@alertlogic.net>
Message-ID: <4A8C96CB.6010304@alertlogic.net>

Paul Fisher wrote:
> I have a mnesia table that is defined as disc_copies, which ends up with 
> a corrupt memory size value after being updated from concurrent (erlang) 
> processes from code compiled with HiPE.  All updates to the table are 
> done as mnesia:transaction/1 calls.

The part about HiPE is not correct.  I have reproduced this with 
everything compiled without HiPE.  Otherwise the corruption happens just 
as described in the original email.  Sorry for the confusion.


--
paul

From paul-trapexit@REDACTED  Thu Aug 20 06:21:16 2009
From: paul-trapexit@REDACTED (Paul Mineiro)
Date: Wed, 19 Aug 2009 21:21:16 -0700 (PDT)
Subject: tracing while constructing binary segfaults emulator
Message-ID: <Pine.LNX.4.52L2.0908192111440.2434@herbie>

this is r12b5, happens on both my mac os/x and my ubuntu 32 bit hardy.
the exact number of calls to random_binaries before the problem exhibits
is variable.

cheers,

-- p

----------

-module (crash).
-export ([ random_binaries/1 ]).

random_binary () ->
  << <<($a + random:uniform ($z - $a)):8>> || _ <- lists:seq (1, 10) >>.

random_binaries (N) when N > 0 ->
  random_binary (),
  random_binaries (N - 1);
random_binaries (_) ->
  ok.

----------

% erl
Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] [kernel-poll:false]
Eshell V5.6.5  (abort with ^G)
1> c (crash), dbg:tracer (), dbg:p (all, [ call ]), dbg:tpl (crash, dbg:fun2ms (fun (_) -> return_trace () end)), crash:random_binaries (1000).
(<0.31.0>) call crash:random_binaries(1000)
(<0.31.0>) call crash:random_binary()
(<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([1,2,3,4,5,6,7,8,9,10],<<>>
)
(<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([2,3,4,5,6,7,8,9,10],<<"d">
>)

...

(<0.31.0>) returned from crash:random_binary/0 -> <<"hulbjkedwk">>
(<0.31.0>) call crash:random_binaries(938)
(<0.31.0>) call crash:random_binary()
(<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([1,2,3,4,5,6,7,8,9,10],<<>>)
(<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([2,3,4,5,6,7,8,9,10],<<0>>)
(<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([3,4,5,6,7,8,9,10],<<0,0>>)
(<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([4,5,6,7,8,9,10],<<0,0,0>>)
(<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([5,6,7,8,9,10],<<0,0,0,0>>)
zsh: segmentation fault (core dumped)  erl
% gdb /usr/lib/erlang/erts-5.6.5/bin/beam core.20527
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libutil.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libutil.so.1
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/tls/i686/cmov/libm.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/librt.so.1
Reading symbols from /lib/tls/i686/cmov/libc.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libsctp.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libsctp.so.1
(no debugging symbols found)
Core was generated by `/usr/lib/erlang/erts-5.6.5/bin/beam -- -root /usr/lib/erlang -progname erl -- -'.
Program terminated with signal 11, Segmentation fault.
[New process 20527]
[New process 20531]
#0  0x080788e8 in ?? ()
(gdb) bt
#0  0x080788e8 in ?? ()
#1  0x0807230c in ?? ()
#2  0x0807462b in erts_alcu_alloc_ts ()
#3  0x080beb52 in new_binary ()
#4  0x080bed35 in list_to_binary_1 ()
#5  0x080fe13c in process_main ()
#6  0x0807c504 in erl_start ()
#7  0x08067492 in main ()
(gdb) q

--------------


From zerthurd@REDACTED  Thu Aug 20 07:28:49 2009
From: zerthurd@REDACTED (Maxim Treskin)
Date: Thu, 20 Aug 2009 12:28:49 +0700
Subject: [erlang-bugs] tracing while constructing binary segfaults 
	emulator
In-Reply-To: <Pine.LNX.4.52L2.0908192111440.2434@herbie>
References: <Pine.LNX.4.52L2.0908192111440.2434@herbie>
Message-ID: <be8f531d0908192228q4b06ad42t5986504229e0c749@mail.gmail.com>

Crashes on R13B1 also


-- 
Maxim Treskin

From tomas.abrahamsson@REDACTED  Thu Aug 20 07:59:18 2009
From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson)
Date: Thu, 20 Aug 2009 07:59:18 +0200
Subject: [erlang-bugs] inets: HTTP client race condition
In-Reply-To: <1249037307.13468.50.camel@sredniczarny>
References: <1249037307.13468.50.camel@sredniczarny>
Message-ID: <b330698a0908192259g658baea5w10fd634ce0d43d62@mail.gmail.com>

> Today I have encountered strange problem in simple scenario with inets.
> when I'm doing concurrent requests to the same server which responds
> slowly.

Hi, I too have got bitten by this now, so I extended your
test program to not rely on any external web server,
to make it a bit easier to trigger and observe the bug.
Attached is a program that triggers the bug fairly often
in a local environment. Compile it and run it like this:
   erl -s http_client_race_condition go -s erlang halt

Attached is also a patch fixing the problem.
The patch is against R13B01/inets-5.1

It seems the problem is that if one calls http:request and
the httpc_manager selects a session where there's already
a pending request, then the connection handler for that
session effectively resets its parser, readying it for the
response to the second request, but sometimes there are
still some more inbound packets for the response to the
first request, and that's when things get confused.

I did some research: The bug first appeared in
R13A/inets-5.0.13, in which a queue for keep-alive requests
seems to have been introduced. In inets-5.0.12 (R12B-5)
there was only one pipeline queue, but in 5.0.13 there's
also another queue for keep-alive. (I don't know the reason
for there being two queues).

Incidentally, when fixing the problem, the code for handling
the keep-alive queue more and more grew to resemble the
code that handles the pipeline queue. Now it looks much like
two copies of the same code. So someone more knowledgeable
in the art of inets and the pipeline/keep-alive queues might
want to refactor the patched code into something more beautiful.

As you already observed, creating separate profiles works
around the bug. With this patch, it is no longer necessary
to create extra profiles if one wants to send http requests
concurrently.


BRs
Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http_client_race_condition.erl
Type: text/x-erlang
Size: 4811 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090820/93e27385/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpc_handler.erl.patch
Type: text/x-patch
Size: 3443 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090820/93e27385/attachment-0001.bin>

From dgud@REDACTED  Thu Aug 20 10:23:40 2009
From: dgud@REDACTED (Dan Gudmundsson)
Date: Thu, 20 Aug 2009 10:23:40 +0200
Subject: [erlang-bugs] new_ssl [{verify,verify_peer}, {fail_if_no_peer_cert,
 true}] bug
In-Reply-To: <88b82c90908191235l48491308x220928de84f8f5f4@mail.gmail.com>
References: <88b82c90908191235l48491308x220928de84f8f5f4@mail.gmail.com>
Message-ID: <4A8D080C.9010308@erix.ericsson.se>

That sounds correct to me.

I will fix that R13B02.

Thanks.

/Dan

Essien Essien wrote:
> Hi all,
> 
> I'm either missing something very major or there is a bug in the way
> the new_ssl implementation in R13B-2 handles a Client's
> CertificateMessages after it has indeed issued a CertificateRequest to
> the connecting client or rather the _absence_ of the
> CerfificateMessage
> 
> The rfc requires compliant clients to compulsorily return a
> CertificateMessage even if its a zero length on, once the server
> issues a CertificateRequest, but the rfc also says that it is up to
> the server to decide what to do if the client refuses to send its
> cert.
> 
> I believe then that the fail_if_no_peer_cert option is designed to
> control the server's behaviour when there is no client cert, but on
> closer inspection and testing, the erlang stack seems to ONLY properly
> fail if the clients sends it a CertificateMessage  of zero length.
> Normally this would not be a problem, but Mono 2.4-2 infact does just
> this. If Mono does not find a certificate to send back to the server
> in response to a CertificateRequest during the handshake, it simply
> does not send any CertificateMessage request at all, not even one with
> a zero length, hence clearly breaking the rfc.
> 
> This behaviour currently throws the erlang new_ssl implementation for
> a loop and the gen_fsm used by new_ssl just silently moves to the
> 'cipher' state, where it expects and processes a ClientKeyExchange
> message, effectively allowing the erring client to make it through.
> 
> 
> In summary, the only valid change from 'certify' to 'cipher' for a
> server should be:
> 
> 1. role = server, current_state = certify, verify = verify_peer,
> fail_if_no_peer_cert = false, message = client_key_exchange:
>           next_state = cipher
> 
> 2. role = server, current_state = certify, verify = verify_peer,
> fail_if_no_peer_cert = false, message = certificate
>           next_state = cipher
> 
> 
> 3. role = server, current_state = certify, verify = verify_peer,
> fail_if_no_peer_cert = true, message = certificate{length > 0}
>           next_state = cipher
> 
> while the following states should produce an error:
> 
> 4. role = server, current_state = certify, verify = verify_peer,
> fail_if_no_peer_cert = true, message = client_key_exchange:
>           next_state = ERROR
> 
> 5. role = server, current_state = certify, verify = verify_peer,
> fail_if_no_peer_cert = true, message = certificate{length = 0}
>           next_state = ERROR
> 
> 
> Of all the rules above, only rule 4 is not handled by new_ssl in
> R13B-2 and the following patch (which is just a quick and dirty proof
> of concept) properly kills the connection if the client in the event
> that rule 4 occurs.
> 
> <patch>
> 
> --- /usr/lib/erlang/lib/ssl-3.10.1/src/ssl_connection.erl	2009-04-27
> 07:05:47.000000000 +0100
> +++ ssl-3.10.1/src/ssl_connection.erl	2009-08-07 13:09:02.142360183 +0100
> @@ -477,6 +477,11 @@
>  	    {stop, normal, State0}
>      end;
> 
> +certify(#client_key_exchange{}, State =
> +        #state{role = server, ssl_options = #ssl_options{verify = verify_peer,
> +                fail_if_no_peer_cert = true}}) ->
> +    {stop, normal, State};
> +
>  certify(#client_key_exchange{exchange_keys
>  			     = #encrypted_premaster_secret{premaster_secret
>  							   = EncPMS}},
> 
> 
> </patch>
> 
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
> 

From essiene@REDACTED  Thu Aug 20 11:02:02 2009
From: essiene@REDACTED (Essien Essien)
Date: Thu, 20 Aug 2009 10:02:02 +0100
Subject: [erlang-bugs] new_ssl [{verify,verify_peer}, {fail_if_no_peer_cert, 
	true}] bug
In-Reply-To: <4A8D080C.9010308@erix.ericsson.se>
References: <88b82c90908191235l48491308x220928de84f8f5f4@mail.gmail.com> 
	<4A8D080C.9010308@erix.ericsson.se>
Message-ID: <88b82c90908200202v729da07co6d82ac77f74a057c@mail.gmail.com>

You're welcome :)

On Thu, Aug 20, 2009 at 9:23 AM, Dan Gudmundsson<dgud@REDACTED> wrote:
> That sounds correct to me.
>
> I will fix that R13B02.
>
> Thanks.
>
> /Dan
>
> Essien Essien wrote:
>>
>> Hi all,
>>
>> I'm either missing something very major or there is a bug in the way
>> the new_ssl implementation in R13B-2 handles a Client's
>> CertificateMessages after it has indeed issued a CertificateRequest to
>> the connecting client or rather the _absence_ of the
>> CerfificateMessage
>>
>> The rfc requires compliant clients to compulsorily return a
>> CertificateMessage even if its a zero length on, once the server
>> issues a CertificateRequest, but the rfc also says that it is up to
>> the server to decide what to do if the client refuses to send its
>> cert.
>>
>> I believe then that the fail_if_no_peer_cert option is designed to
>> control the server's behaviour when there is no client cert, but on
>> closer inspection and testing, the erlang stack seems to ONLY properly
>> fail if the clients sends it a CertificateMessage ?of zero length.
>> Normally this would not be a problem, but Mono 2.4-2 infact does just
>> this. If Mono does not find a certificate to send back to the server
>> in response to a CertificateRequest during the handshake, it simply
>> does not send any CertificateMessage request at all, not even one with
>> a zero length, hence clearly breaking the rfc.
>>
>> This behaviour currently throws the erlang new_ssl implementation for
>> a loop and the gen_fsm used by new_ssl just silently moves to the
>> 'cipher' state, where it expects and processes a ClientKeyExchange
>> message, effectively allowing the erring client to make it through.
>>
>>
>> In summary, the only valid change from 'certify' to 'cipher' for a
>> server should be:
>>
>> 1. role = server, current_state = certify, verify = verify_peer,
>> fail_if_no_peer_cert = false, message = client_key_exchange:
>> ? ? ? ? ?next_state = cipher
>>
>> 2. role = server, current_state = certify, verify = verify_peer,
>> fail_if_no_peer_cert = false, message = certificate
>> ? ? ? ? ?next_state = cipher
>>
>>
>> 3. role = server, current_state = certify, verify = verify_peer,
>> fail_if_no_peer_cert = true, message = certificate{length > 0}
>> ? ? ? ? ?next_state = cipher
>>
>> while the following states should produce an error:
>>
>> 4. role = server, current_state = certify, verify = verify_peer,
>> fail_if_no_peer_cert = true, message = client_key_exchange:
>> ? ? ? ? ?next_state = ERROR
>>
>> 5. role = server, current_state = certify, verify = verify_peer,
>> fail_if_no_peer_cert = true, message = certificate{length = 0}
>> ? ? ? ? ?next_state = ERROR
>>
>>
>> Of all the rules above, only rule 4 is not handled by new_ssl in
>> R13B-2 and the following patch (which is just a quick and dirty proof
>> of concept) properly kills the connection if the client in the event
>> that rule 4 occurs.
>>
>> <patch>
>>
>> --- /usr/lib/erlang/lib/ssl-3.10.1/src/ssl_connection.erl ? ? ? 2009-04-27
>> 07:05:47.000000000 +0100
>> +++ ssl-3.10.1/src/ssl_connection.erl ? 2009-08-07 13:09:02.142360183
>> +0100
>> @@ -477,6 +477,11 @@
>> ? ? ? ? ? ?{stop, normal, State0}
>> ? ? end;
>>
>> +certify(#client_key_exchange{}, State =
>> + ? ? ? ?#state{role = server, ssl_options = #ssl_options{verify =
>> verify_peer,
>> + ? ? ? ? ? ? ? ?fail_if_no_peer_cert = true}}) ->
>> + ? ?{stop, normal, State};
>> +
>> ?certify(#client_key_exchange{exchange_keys
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? = #encrypted_premaster_secret{premaster_secret
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? = EncPMS}},
>>
>>
>> </patch>
>>
>> ________________________________________________________________
>> erlang-bugs mailing list. See http://www.erlang.org/faq.html
>> erlang-bugs (at) erlang.org
>>
>

From dgud@REDACTED  Thu Aug 20 11:25:09 2009
From: dgud@REDACTED (Dan Gudmundsson)
Date: Thu, 20 Aug 2009 11:25:09 +0200
Subject: [erlang-bugs] mnesia disc_copies memory size corrupts w/HiPE
 64-bit
In-Reply-To: <4A8C9078.2080700@alertlogic.net>
References: <4A8C9078.2080700@alertlogic.net>
Message-ID: <4A8D1675.4070604@erix.ericsson.se>

Hi

Do you have a test case, so we can debug this?

It seems that is an ets bug, could you test with ets directly.

/Dan

Paul Fisher wrote:
> I have a mnesia table that is defined as disc_copies, which ends up with 
> a corrupt memory size value after being updated from concurrent (erlang) 
> processes from code compiled with HiPE.  All updates to the table are 
> done as mnesia:transaction/1 calls.
> 
> If I update the table from only two processes the memory size is correct:
> 
> (emacs@REDACTED)2> mnesia:table_info(clu_unassignedq,size).
> 0
> (emacs@REDACTED)3> mnesia:table_info(clu_unassignedq,memory).
> 90
> 
> After updating the table via 11 processes, the table size ends up zero, 
> but memory size is completely bogus:
> 
> (emacs@REDACTED)10> mnesia:table_info(clu_unassignedq,size).
> 0
> (emacs@REDACTED)11> mnesia:table_info(clu_unassignedq,memory).
> 2305843009213693459
> 
> If the same thing is done with the code calling the mnesia operations is 
> *not* compiled with HiPE, all is well and everything appears correct.
> 
> This appears to be an artifact of the SMP/ets concurrency improvements 
> introduced in R13. Thoughts for further investigation?
> 
> Platform is amd64 (intel core 2) on opensolaris.  Erlang R13B02 snapshot 
> from 2009/08/12.
> 
> pfisher@REDACTED:~/lm/third_party/erlang-R13/install/solaris$ gcc -v
> Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
> Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure 
> --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as 
> --with-ld=/usr/ccs/bin/ld --without-gnu-ld 
> --enable-languages=c,c++,f77,objc --enable-shared
> Thread model: posix
> gcc version 3.4.3 (csl-sol210-3_4-20050802)
> 
> 
> -- 
> paul
> 
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
> 

From bgustavsson@REDACTED  Thu Aug 20 16:37:22 2009
From: bgustavsson@REDACTED (Bjorn Gustavsson)
Date: Thu, 20 Aug 2009 16:37:22 +0200
Subject: [erlang-bugs] R13B01: internal error in the boolean guard 
	optimizer
In-Reply-To: <4ac8254d0908171727g3fdd4c02gbd880e777f327b13@mail.gmail.com>
References: <4ac8254d0908171727g3fdd4c02gbd880e777f327b13@mail.gmail.com>
Message-ID: <6672d0160908200737o3dcf44ffp681cb0cdd6e76b18@mail.gmail.com>

On Tue, Aug 18, 2009 at 2:27 AM, Tuncer Ayaz<tuncer.ayaz@REDACTED> wrote:
> Is the following a known problem in R13B01?

No.

> The fun is taken from "Erlang Programming".
>
> guard(X,Y) when not(((X>Y) or not(is_atom(X)) ) and (is_atom(Y) or (X==3.4))) ->
>  X+Y.
>
> Compiling this with erlc results in an internal compiler error which seems
> to happen in the beam assembler's boolean guard optimizer pass.
>

Thanks for reporting this bug. A correction will be included in R13B02.

/Bjorn
-- 
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compiler.patch
Type: text/x-patch
Size: 844 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090820/47245db0/attachment.bin>

From anders.nygren@REDACTED  Thu Aug 20 22:23:38 2009
From: anders.nygren@REDACTED (Anders Nygren)
Date: Thu, 20 Aug 2009 15:23:38 -0500
Subject: sctp chunked messages
In-Reply-To: <d3520a2f0908191406t5c602b8erd24bde0156dda222@mail.gmail.com>
References: <d3520a2f0908191406t5c602b8erd24bde0156dda222@mail.gmail.com>
Message-ID: <d3520a2f0908201323g37126eem80857c44fdacf776@mail.gmail.com>

After some more testing I have found that
1, the error only happens when it is the client that is receiving chunked
messages.
2, it works correctly on Solaris

/Anders

On Wed, Aug 19, 2009 at 4:06 PM, Anders Nygren<anders.nygren@REDACTED> wrote:
> Hi
> I am having a problem with chunked messages. When I try to send a
> message that is ~2kByte, it gets split into two chunks. But gen_sctp
> does not reassemble the chunks and only delivers the last chunk to
> my application.
> I have attached a simple test case to demonstrate the problem.
>
> To run
> Machine A:
> sctp_err:server(IP,Port).
>
> Machine B:
> sctp_err:client(IP,Port).
>
> I dont know if this is related but sometimes I also receive a
> {sctp_error, enoent} before the the #sctp_sndrcvinfo with the second
> chunk.
>
> This is using
> OTP R13B01
> Between two machines running Ubuntu
>
> uname -a
> Linux curso-laptop 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25
> 00:28:35 UTC 2009 i686 GNU/Linux
>
> ?uname -a
> Linux glr-desktop 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51
> UTC 2009 i686 GNU/Linux
>
> /Anders
>

From tuncer.ayaz@REDACTED  Fri Aug 21 00:19:22 2009
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Fri, 21 Aug 2009 00:19:22 +0200
Subject: [erlang-bugs] R13B01: internal error in the boolean guard 
	optimizer
In-Reply-To: <6672d0160908200737o3dcf44ffp681cb0cdd6e76b18@mail.gmail.com>
References: <4ac8254d0908171727g3fdd4c02gbd880e777f327b13@mail.gmail.com> 
	<6672d0160908200737o3dcf44ffp681cb0cdd6e76b18@mail.gmail.com>
Message-ID: <4ac8254d0908201519h5735a80h4713ddceb15a9339@mail.gmail.com>

On Thu, Aug 20, 2009 at 4:37 PM, Bjorn Gustavsson<bgustavsson@REDACTED> wrote:
> On Tue, Aug 18, 2009 at 2:27 AM, Tuncer Ayaz<tuncer.ayaz@REDACTED> wrote:
>> Is the following a known problem in R13B01?
>
> No.
>
>> The fun is taken from "Erlang Programming".
>>
>> guard(X,Y) when not(((X>Y) or not(is_atom(X)) ) and (is_atom(Y) or (X==3.4))) ->
>> ?X+Y.
>>
>> Compiling this with erlc results in an internal compiler error which seems
>> to happen in the beam assembler's boolean guard optimizer pass.
>>
>
> Thanks for reporting this bug. A correction will be included in R13B02.

Thanks for the patch. It fixes the issue.

From kenji.rikitake@REDACTED  Fri Aug 21 03:47:55 2009
From: kenji.rikitake@REDACTED (Kenji Rikitake)
Date: Fri, 21 Aug 2009 10:47:55 +0900
Subject: Erlang R13B01 ssh_transport possible bug
Message-ID: <20090821014755.GA98897@k2r.org>

This is a simplified version of previous patch at
http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1465:200908:jocpkoflfkoikpmnfcnj

I think this is a bug, so I resubmit the issue and the patch here.

BUG FOUND: ssh_transport:unpack/3 causes crash by passing a null
binary (<<>>) to erlang:split_binary/2, with error code badarg.

By tracing the exchange between a FreeBSD OpenSSH implementation, I
found a case where the internal variable SshLength in
ssh_transport:unpack/3 goes to zero, which leads to passing a null
binary as an argument to ssh_transport:decrypt_blocks/3 and to
aes_cbc_ivec/1.  So I added a case statement to avoid calling the
decrypt_blocks/3 when SshLength = 0.

Patch follow.

Kenji Rikitake

--- lib/ssh/src/ssh_transport.erl.orig
+++ lib/ssh/src/ssh_transport.erl
@@ -714,8 +714,13 @@
 				  Rest0/binary>> = EncodedSoFar,
 				 {NoMac0, Mac0, Rest0}
 			 end,
-    {Ssh1, DecData, <<>>} = 
-	ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0),
+    {Ssh1, DecData, <<>>} = case SshLength of
+                                0 ->
+                                    {Ssh0, <<>>, <<>>};
+                                _ ->
+                                     ssh_transport:decrypt_blocks(NoMac, SshLeng
+th, Ssh0)
+                            end,
     {Ssh1, DecData, Rest, Mac}.
 
 msg_data(PacketData) ->

From kenji.rikitake@REDACTED  Fri Aug 21 03:54:53 2009
From: kenji.rikitake@REDACTED (Kenji Rikitake)
Date: Fri, 21 Aug 2009 10:54:53 +0900
Subject: [erlang-bugs] Erlang R13B01 ssh_transport possible bug
In-Reply-To: <20090821014755.GA98897@k2r.org>
References: <20090821014755.GA98897@k2r.org>
Message-ID: <20090821015453.GA99031@k2r.org>

clarification: "aes_cbc_ivec/1" is irrelevant, in 3des-cbc it is
crypto:des_cbc_ivec/1.  Regards, Kenji Rikitake

In the message <20090821014755.GA98897@REDACTED>
dated Fri, Aug 21, 2009 at 10:47:31AM +0900,
Kenji Rikitake <kenji.rikitake@REDACTED> writes:
> BUG FOUND: ssh_transport:unpack/3 causes crash by passing a null
> binary (<<>>) to erlang:split_binary/2, with error code badarg.
> 
> By tracing the exchange between a FreeBSD OpenSSH implementation, I
> found a case where the internal variable SshLength in
> ssh_transport:unpack/3 goes to zero, which leads to passing a null
> binary as an argument to ssh_transport:decrypt_blocks/3 and to
> aes_cbc_ivec/1.  So I added a case statement to avoid calling the
> decrypt_blocks/3 when SshLength = 0.

From paul-trapexit@REDACTED  Sun Aug 23 22:25:32 2009
From: paul-trapexit@REDACTED (Paul Mineiro)
Date: Sun, 23 Aug 2009 13:25:32 -0700 (PDT)
Subject: http:request doesn't compute content-length of iolist correctly
Message-ID: <Pine.LNX.4.52L2.0908231320140.2434@herbie>

Example:

---------
Shell One:

% nc -l -p 9999
PUT / HTTP/1.1
content-type: text/plain
content-length: 1
te:
host: 127.0.0.1
connection: keep-alive

iodata

---------
Shell Two:
% erl
Erlang (BEAM) emulator version 5.6.5 [source] [smp:2] [async-threads:0] [kernel-poll:false]

Eshell V5.6.5  (abort with ^G)
1> application:start (inets).
ok
2> http:request (put, { "http://127.0.0.1:9999/", [], "text/plain", [ <<"iodata">> ] }, [], []).
--------

It does the right thing if a string is passed as the body, and technically
this is what the documentation says is the proper type for that argument
... but it's a drag because forcing me to flatten an iolist is not the
Erlang way.

-- p

From elliot@REDACTED  Mon Aug 24 23:49:09 2009
From: elliot@REDACTED (Elliot Murphy)
Date: Mon, 24 Aug 2009 17:49:09 -0400
Subject: 'make release_tests' doesn't work in R13-B01
Message-ID: <4A930AD5.3090700@canonical.com>

Hi!

Running the release_tests: target in the Makefile doesn't work, at least
not in R13-B01. It seems that the root of the problems is that the
various tests/ subdirectories are not included in the source tarball,
although the test_server is. For example the makefile tries to cd into
lib/asn1/tests, and that directory doesn't exist.

Why do I care? I'm working on the Erlang packages for Ubuntu (and this
is probably relevant for Debian too). We're including CouchDB by default
in the next release of Ubuntu, and so this means that Erlang is getting
a lot more attention than it has before since it's going on the CD and
in the default Ubuntu desktop installation. The Ubuntu security team has
asked that the test suite be enabled as part of the Erlang package build
process, so that we can have a higher degree of confidence that applying
a bugfix has not broken anything - it's a standard thing that we do in
Ubuntu for all sorts of important foundational packages like languages,
databases, etc.

Is it deliberate that the tests are not included in the source tarball?
Is that something that could be changed?

We're about to start delivering Erlang to many many millions of Ubuntu
desktops in the next few weeks, and I would really really like to be
able to run 'make release_tests' anytime we need to apply a critical
patch or something when processing a security update sometime in the
next 18 months that we will be supporting the packages we have shipped
with Ubuntu 9.10.

Thanks for making Erlang(yay erlang rocks!) and for your consideration.
-- 
Elliot Murphy | https://launchpad.net/~statik/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090824/359ba1c1/attachment.bin>

From kenneth.lundin@REDACTED  Tue Aug 25 08:57:47 2009
From: kenneth.lundin@REDACTED (Kenneth Lundin)
Date: Tue, 25 Aug 2009 08:57:47 +0200
Subject: [erlang-bugs] 'make release_tests' doesn't work in R13-B01
In-Reply-To: <4A930AD5.3090700@canonical.com>
References: <4A930AD5.3090700@canonical.com>
Message-ID: <de422a40908242357g5c801795o2e89352e4f749992@mail.gmail.com>

Hi,

Yes it is deliberate that the test_suites are currently not included.
We have plans to include the tests but it has not happened yet.
It will require a lot of work before we can release the tests in a
useful way and I think we
must take it stepwise test_suite per test_suite.

Things we have to fix are:
- Makefiles for the tests (make sure that they work outside our
environment as well)
- Copyright and license notices as needed
- Make sure that the tests themselves can be run outside our
environment (or just ship the ones
that can).
...

We will release R13B02 on September 23,
It might  be possible to include a very limited set of tests there but
it seems as if you
are going to include R13B01 in ubuntu?

/Kenneth , Erlang/OTP Ericsson

On Mon, Aug 24, 2009 at 11:49 PM, Elliot Murphy<elliot@REDACTED> wrote:
> Hi!
>
> Running the release_tests: target in the Makefile doesn't work, at least
> not in R13-B01. It seems that the root of the problems is that the
> various tests/ subdirectories are not included in the source tarball,
> although the test_server is. For example the makefile tries to cd into
> lib/asn1/tests, and that directory doesn't exist.
>
> Why do I care? I'm working on the Erlang packages for Ubuntu (and this
> is probably relevant for Debian too). We're including CouchDB by default
> in the next release of Ubuntu, and so this means that Erlang is getting
> a lot more attention than it has before since it's going on the CD and
> in the default Ubuntu desktop installation. The Ubuntu security team has
> asked that the test suite be enabled as part of the Erlang package build
> process, so that we can have a higher degree of confidence that applying
> a bugfix has not broken anything - it's a standard thing that we do in
> Ubuntu for all sorts of important foundational packages like languages,
> databases, etc.
>
> Is it deliberate that the tests are not included in the source tarball?
> Is that something that could be changed?
>
> We're about to start delivering Erlang to many many millions of Ubuntu
> desktops in the next few weeks, and I would really really like to be
> able to run 'make release_tests' anytime we need to apply a critical
> patch or something when processing a security update sometime in the
> next 18 months that we will be supporting the packages we have shipped
> with Ubuntu 9.10.
>
> Thanks for making Erlang(yay erlang rocks!) and for your consideration.
> --
> Elliot Murphy | https://launchpad.net/~statik/
>
>

From vladdu55@REDACTED  Tue Aug 25 11:42:07 2009
From: vladdu55@REDACTED (Vlad Dumitrescu)
Date: Tue, 25 Aug 2009 11:42:07 +0200
Subject: pasting input in werl.exe shell
Message-ID: <95be1d3b0908250242p4f8e2339j534f6d5b92a53e8e@mail.gmail.com>

Hi,

When pasting some input in the werl.exe shell and if that input has
tab characters at the beginning of the lines, the shell will handle
those tabs as requests for completion and will print the list of
modules.

Seen in R13B01. Not a severe problem, but annoying.

regards,
Vlad

From raimo+erlang-bugs@REDACTED  Tue Aug 25 17:40:50 2009
From: raimo+erlang-bugs@REDACTED (Raimo Niskanen)
Date: Tue, 25 Aug 2009 17:40:50 +0200
Subject: R13B01 bug in file:pwrite()?
In-Reply-To: <58692.1249013910@snookles.snookles.com>
References: <58692.1249013910@snookles.snookles.com>
Message-ID: <20090825154050.GA27353@erix.ericsson.se>

Some comments inserted below. Just a small top-post:
Can the OTP team get access to the core dumps produced
at the segfaults, and the erl_core.dump files?

Mail me in private...

On Thu, Jul 30, 2009 at 11:18:30PM -0500, Scott Lystig Fritchie wrote:
> Hi, all.  This sounds really weird, but I have a test case that can
> irregularly trigger this bug within 5-10 minutes.  I can't post all the
> code, in part because it's driven by Quviq's QuickCheck.  :-)  I'll try
> to cobble together as much info as I can gather, for such an
> intermittent problem.
> 
> 100% of the time, I see crashes after the "Use Scribble..." message.
> The error could be happening perhaps after the func has returned, but
> 100% of the time there isn't any output following "Use Scribble...", and
> the surrounding code is fairly verbose.
> 
> scribbles(ArgsList, PathT) ->
>     io:format("Num scribbles = ~p\n", [length(ArgsList)]),
>     lists:map(
>       fun([SeqNum, Offset, NewBlob]) ->
> 	      Path = element((SeqNum rem size(PathT)) + 1, PathT),
> 	      {ok, FI} = file:read_file_info(Path),
> 	      Pos = Offset rem (FI#file_info.size + 1), % in case size = 0.
> 	      {ok, FH} = file:open(Path, [binary, read, write]),
> 	      io:format("Pread ~p at Pos ~p for ~p bytes\n", [Path, Pos, size(NewBlob)]),
> 	      OldBlob = case (catch file:pread(FH, Pos, size(NewBlob))) of
> 			    {ok, BLB} -> BLB;
> 			    _         -> cant_match_any_binary_ha_ha
> 			end,
> 	      io:format("Use Scribble ~p at ~p Pos ~p\n", [NewBlob, Path, Pos]),
> 	      ok = file:pwrite(FH, Pos, NewBlob),
> 	      file:close(FH),
> 	      OldBlob == NewBlob
>       end, ArgsList).
> 
> I'm using R13B01 on a 32-bit install of a Linux Fedora 11 distro,
> 2.6.27.25-170.2.72.fc10.i686 kernel.  I've seen this happen with SMP
> support enabled or disabled, with the +A worker pool enabled or
> disabled, with +K true or false.
> 
>   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>   fritchie 12106 77.8 45.8 1716800 1661460 pts/22 Sl+ 22:22   6:10 /tmp/R13B01-debug/lib/erlang/erts-5.7.2/bin/beam.smp -K true -- -root /tmp/R13B01-debug/lib/erlang -progname erl -- -home /home/fritchie -smp enable -sname foo_dev -boot foo -pz ... [many more -pz flags...]
> 
> (I had "ps u" running in a loop 4x per second.  The above was taken
> during the ERTS_HOLE_MARKER output below.  The reading 0.25 seconds
> earlier was VSZ of about 70MB.)
> 
> The above is a debug build, as best as I've been able to do.  (It isn't
> one-command easy, alas.)
> 
>   Erlang R13B01 (erts-5.7.2) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:true] [type-assertions] [debug-compiled] [lock-checking]
> 
> Sample output after the crash looks like this.  Some messages are
> lacking the "Num scribbles..." output because I'd added that one a bit
> later.
> 
>   Use Scribble <<"ff">> at "./zzz-hlog-qc/2/6/-000000000061.HLOG" Pos 10172
>   Pread "./zzz-hlog-qc/2/2/-000000000085.HLOG" at Pos 64 for 27 bytes
>   Use Scribble <<"RRRRRRRRRRRRRRRRRRRRRRRRRRR">> at "./zzz-hlog-qc/2/2/-000000000085.HLOG" Pos 64
>   Pread "./zzz-hlog-qc/2/6/-000000000061.HLOG" at Pos 1162 for 3 bytes
>   Use Scribble <<"??????">> at "./zzz-hlog-qc/2/6/-000000000061.HLOG" Pos 1162
>   Pread "./zzz-hlog-qc/000000000084.HLOG" at Pos 652 for 22 bytes
>   Use Scribble <<"NNNNNNNNNNNNNNNNNNNNNN">> at "./zzz-hlog-qc/000000000084.HLOG" Pos 652
>   Pread "./zzz-hlog-qc/000000000046.HLOG" at Pos 653 for 8 bytes
>   Use Scribble <<"????????????????">> at "./zzz-hlog-qc/000000000046.HLOG" Pos 653
>   make: *** [run-app1-interactive] Segmentation fault

Does this produce a core dump?

> 
>   .....Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 216 for 1 bytes
>   Use Scribble <<"Z">> at "./zzz-hlog-qc/000000000001.HLOG" Pos 216
>   Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 330 for 1 bytes
>   Use Scribble <<"??">> at "./zzz-hlog-qc/000000000001.HLOG" Pos 330
>   Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 83 for 1 bytes
>   Use Scribble <<"??">> at "./zzz-hlog-qc/000000000001.HLOG" Pos 83
>   Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 176 for 1 bytes
>   Use Scribble <<"?">> at "./zzz-hlog-qc/000000000001.HLOG" Pos 176
> 
>   Crash dump was written to: erl_crash.dump
>   eheap_alloc: Cannot allocate 2147483700 bytes of memory (of type "heap_frag").

That should have produced an erl_crash.dump.
It can be analyzed with the crashdump_viewer.

>   make: *** [run-app1-interactive] Aborted
> 
> ----
> 
>   Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 443 for 0 bytes
>   Use Scribble <<>> at "./zzz-hlog-qc/000000000001.HLOG" Pos 443
>   Pread "./zzz-hlog-qc/000000000065.HLOG" at Pos 2496 for 21 bytes
>   Use Scribble <<"ooooooooooooooooooooo">> at "./zzz-hlog-qc/000000000065.HLOG" Pos 2496
>   Pread "./zzz-hlog-qc/2/2/-000000000064.HLOG" at Pos 70 for 16 bytes
>   Use Scribble <<"????????????????????????????????">> at "./zzz-hlog-qc/2/2/-000000000064.HLOG" Pos 70
>   Pread "./zzz-hlog-qc/3/6/-000000000047.HLOG" at Pos 6226 for 4 bytes
>   Use Scribble <<"????????">> at "./zzz-hlog-qc/3/6/-000000000047.HLOG" Pos 6226
>   make: *** [run-app1-interactive] Segmentation fault
> 
> ----
> 
>   .
>   =GMT ERR REPORT==== 30-Jul-2009::21:05:45 ===
>   fold_a_file: seq -2 offset 0: {error,unknown_file_header,
>                                        {ok,<<"LogVersion1L">>}}
>   .Pread "./zzz-hlog-qc/3/3/-000000000002.HLOG" at Pos 115 for 1 bytes
>   Use Scribble <<"??">> at "./zzz-hlog-qc/3/3/-000000000002.HLOG" Pos 115
>   Pread "./zzz-hlog-qc/3/3/-000000000002.HLOG" at Pos 127 for 1 bytes
>   Use Scribble <<"0">> at "./zzz-hlog-qc/3/3/-000000000002.HLOG" Pos 127
> 
>   Crash dump was written to: erl_crash.dump
>   eheap_alloc: Cannot allocate 3087007804 bytes of memory (of type "heap_frag").
>   make: *** [run-app1-interactive] Aborted
> 
> ----
> 
>   ..nnNum scribbles = 2
>   Pread "./zzz-hlog-qc/000000000023.HLOG" at Pos 183 for 6 bytes
>   Use Scribble <<21,21,21,21,21,21>> at "./zzz-hlog-qc/000000000023.HLOG"
>   Pos 183
>   Pread "./zzz-hlog-qc/1/4/-000000000003.HLOG" at Pos 966 for 13 bytes
>   Use Scribble <<"xxxxxxxxxxxxx">> at
>   "./zzz-hlog-qc/1/4/-000000000003.HLOG" Pos 9
>   66
>   ErrList1  ErrList2 [{seq,23,err,badarg}] [{seq,-3,err,{badmatch,false}}]
>   .Num scribbles = 1
>   Pread "./zzz-hlog-qc/3/3/-000000000002.HLOG" at Pos 32 for 18 bytes
>   Use Scribble
>   <<140,140,140,140,140,140,140,140,140,140,140,140,140,140,140,140,
>                  140,140>> at "./zzz-hlog-qc/3/3/-000000000002.HLOG" Pos
>   	       32
>   beam/erl_debug.c, line 361: ERTS_HOLE_MARKER found at 0x531ca148
>   |            | Range: 0x4e391038 - 0xb29d74a4              |
>   | Address    | Contents                                    |
>   |------------|---------------------------------------------|
>   | 0x4e391038 | 0x000000c0 0x4e391049 0x4e391044 0x00000000 |
>   | 0x4e391048 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x4e391058 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x4e391068 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x4e391078 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x4e391088 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x4e391098 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x4e3910a8 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   [... 7 gazillions of nearly identical lines omitted...]
>   | 0x531ca0f8 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca108 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca118 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca128 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca138 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca148 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca158 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca168 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca178 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca188 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   | 0x531ca198 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc |
>   [... I didn't have enough disk space to record output to 0xb29d74a4...]
> 
> Attaching GDB to the process while QC is running doesn't work very
> well.  After "attach" and "continue", the VM freezes.  Pressing C-c and

That usually works.

> C-g (running GDB within Emacs in gdb-mode) can't interrupt GDB to get a
> prompt back.  I can only kill the GDB process externally.  :-(  So
> catching a SIGSEGV in-the-act hasn't been possible.  Is there some trick
> to doing that?  Or perhaps FC11's GDB is braindamaged somehow?  Or
> Linux?

If you just want to be in GDB at the segfault, run beam from GDB,
or analyze the core dump afterwards.

To run beam from GDB (commands after $ prompts and (gdb) prompts below),
for bash:

$ erl -emu_args
Executing: /usr/local/otp/releases/otp_beam_linux_sles10_x64_r13b_patched/erts-5.7.2/bin/beam.smp /usr/local/otp/releases/otp_beam_linux_sles10_x64_r13b_patched/erts-5.7.2/bin/beam.smp -- -root /usr/local/otp/releases/otp_beam_linux_sles10_x64_r13b_patched -progname erl -- -home /home/raimo

Erlang R13B01 (erts-5.7.2) [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false]

Eshell V5.7.2  (abort with ^G)
1> q().
ok
2>
$ cat `type -p erl`
:
ROOTDIR=/usr/local/otp/releases/otp_beam_linux_sles10_x64_r13b_patched
BINDIR=$ROOTDIR/erts-5.7.2/bin
:

$ export BINDIR=/usr/local/otp/releases/otp_beam_linux_sles10_x64_r13b_patched/erts-5.7.2/bin
$ PATH=$BINDIR:$PATH gdb /usr/local/otp/releases/otp_beam_linux_sles10_x64_r13b_patched/erts-5.7.2/bin/beam.smp
GNU gdb 6.6
Copyright (C) 2006 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 "x86_64-suse-linux"...
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) set args -- -root /usr/local/otp/releases/otp_beam_linux_sles10_x64_r13b_patched -progname erl -- -home /home/raimo
(gdb) run
Starting program: /usr/local/otp_product/releases/otp_beam_linux_sles10_x64_r13b_patched/erts-5.7.2/bin/beam.smp -- -root /usr/local/otp/releases/otp_beam_linux_sles10_x64_r13b_patched -progname erl -- -home /home/raimo
[Thread debugging using libthread_db enabled]
[New Thread 47822751210208 (LWP 28205)]
[New Thread 1082132800 (LWP 28209)]
[New Thread 1090525504 (LWP 28210)]
[New Thread 1090550080 (LWP 28211)]
[New Thread 1098942784 (LWP 28212)]
[New Thread 1107335488 (LWP 28213)]
[New Thread 1115728192 (LWP 28214)]
[New Thread 1124120896 (LWP 28215)]
Erlang R13B01 (erts-5.7.2) [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false]

Eshell V5.7.2  (abort with ^G)
1>






> 
>   % gdb --version
>   GNU gdb Fedora (6.8-32.fc10)
>   [...]
>   This GDB was configured as "i386-redhat-linux-gnu".
> 
> However, while all the ERTS_HOLE_MARKER stuff was dumping, I attached
> GDB and got this info on all threads.
> 
>   (gdb) thread apply all info stack
>   
>   Thread 6 (Thread 0xb7d27b90 (LWP 12113)):
>   #0  0xb8028416 in __kernel_vsyscall ()
>   #1  0x0054f19b in read () from /lib/libpthread.so.0
>   #2  0x081cb5ec in signal_dispatcher_thread_func (unused=0x0)
>       at sys/unix/sys.c:2913
>   #3  0x0823c0b6 in thr_wrapper (vtwd=0xbfaae2bc) at common/ethread.c:475
>   #4  0x0054851f in start_thread () from /lib/libpthread.so.0
>   #5  0x0047e04e in clone () from /lib/libc.so.6
>   
>   Thread 5 (Thread 0xb7326b90 (LWP 12114)):
>   #0  0xb8028416 in __kernel_vsyscall ()
>   #1  0x0054c105 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
>   #2  0x0823cf29 in ethr_cond_wait (cnd=0x82affe0, mtx=0x82aff40)
>       at common/ethread.c:1018
>   #3  0x080c170e in erts_cnd_wait (cnd=0x82affe0, mtx=0x82aff40)
>       at beam/erl_threads.h:634
>   #4  0x080c26f8 in erts_smp_cnd_wait (cnd=0x82affe0, mtx=0x82aff40)
>       at beam/erl_smp.h:417
>   #5  0x080bf963 in sys_msg_dispatcher_func (unused=0x0)
>       at beam/erl_trace.c:3078
>   #6  0x0823c0b6 in thr_wrapper (vtwd=0xbfaae32c) at common/ethread.c:475
>   #7  0x0054851f in start_thread () from /lib/libpthread.so.0
>   #8  0x0047e04e in clone () from /lib/libc.so.6
>   
>   Thread 4 (Thread 0xb8026b90 (LWP 12115)):
>   #0  0xb8028416 in __kernel_vsyscall ()
>   #1  0x0054c105 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
>   #2  0x0823cf29 in ethr_cond_wait (cnd=0x82d8c00, mtx=0x82d8bc0)
>       at common/ethread.c:1018
>   #3  0x080c170e in erts_cnd_wait (cnd=0x82d8c00, mtx=0x82d8bc0)
>       at beam/erl_threads.h:634
>   #4  0x081cb4a9 in child_waiter (unused=0x0) at sys/unix/sys.c:2842
>   #5  0x0823c0b6 in thr_wrapper (vtwd=0xbfaae2cc) at common/ethread.c:475
>   #6  0x0054851f in start_thread () from /lib/libpthread.so.0
>   #7  0x0047e04e in clone () from /lib/libc.so.6
>   
>   Thread 3 (Thread 0xb6925b90 (LWP 12116)):
>   #0  0xb8028416 in __kernel_vsyscall ()
>   #1  0x0046db3b in write () from /lib/libc.so.6
>   #2  0x00404a7c in _IO_new_file_write () from /lib/libc.so.6
>   #3  0x00405bf7 in _IO_new_do_write () from /lib/libc.so.6
>   #4  0x004055a5 in _IO_new_file_overflow () from /lib/libc.so.6
>   #5  0x00408423 in __overflow () from /lib/libc.so.6
>   #6  0x082410f7 in write_f_add_cr (vfp=0x50a4c0, buf=0x8250ffe "|\n", len=2)
>       at common/erl_printf.c:108
>   #7  0x08240c97 in erts_printf_format (fn=0x8241070 <write_f_add_cr>, 
>       arg=0x50a4c0, fmt=0x8250ffe "|\n", ap=0xb6924174 "\b")
>       at common/erl_printf_format.c:832
>   #8  0x08241576 in erts_printf (format=0x8250ffe "|\n")
>       at common/erl_printf.c:218
>   #9  0x080ebf5e in print_untagged_memory (pos=0x641e0338, end=0xb29d74a8)
>       at beam/erl_debug.c:518
>   #10 0x080eba1c in check_memory (start=0x4e391038, end=0xb29d74a8)
>       at beam/erl_debug.c:362
>   #11 0x080eb987 in erts_check_for_holes (p=0xb4e32d94) at beam/erl_debug.c:347
>   #12 0x08199ed4 in process_main () at beam/beam_emu.c:2049
>   #13 0x080f6f67 in sched_thread_func (vesdp=0xb7e0bc00)
>       at beam/erl_process.c:3015
>   #14 0x0823c0b6 in thr_wrapper (vtwd=0xbfaae38c) at common/ethread.c:475
>   #15 0x0054851f in start_thread () from /lib/libpthread.so.0
>   #16 0x0047e04e in clone () from /lib/libc.so.6
>   
>   Thread 2 (Thread 0xb5f24b90 (LWP 12117)):
>   #0  0xb8028416 in __kernel_vsyscall ()
>   #1  0x0047e836 in epoll_wait () from /lib/libc.so.6
>   #2  0x081d07e5 in check_fd_events (ps=0xb7daa400, tv=0xb5f2291c, max_res=256, 
>       ps_locked=0xb5f228d4) at sys/common/erl_poll.c:1906
>   #3  0x081d093b in erts_poll_wait_kp (ps=0xb7daa400, pr=0xb5f22928, 
>       len=0xb5f22924, utvp=0xb5f2291c) at sys/common/erl_poll.c:2042
>   #4  0x081d2f18 in erts_check_io_kp (do_wait=1)
>       at sys/common/erl_check_io.c:1156
>   #5  0x081cb4e1 in erl_sys_schedule (runnable=0) at sys/unix/sys.c:2860
>   #6  0x080f0f3f in sched_sys_wait (no=2, rq=0xb7e0b758)
>       at beam/erl_process.c:774
>   #7  0x080fdcb9 in schedule (p=0xb4f4bd1c, calls=15) at beam/erl_process.c:6023
>   #8  0x081887eb in process_main () at beam/beam_emu.c:1126
>   #9  0x080f6f67 in sched_thread_func (vesdp=0xb7e1dcd0)
>       at beam/erl_process.c:3015
>   #10 0x0823c0b6 in thr_wrapper (vtwd=0xbfaae38c) at common/ethread.c:475
>   #11 0x0054851f in start_thread () from /lib/libpthread.so.0
>   #12 0x0047e04e in clone () from /lib/libc.so.6
>   
>   Thread 1 (Thread 0xb800e6c0 (LWP 12106)):
>   #0  0xb8028416 in __kernel_vsyscall ()
>   #1  0x004763d1 in select () from /lib/libc.so.6
>   #2  0x081cb7d1 in erts_sys_main_thread () at sys/unix/sys.c:3021
>   #3  0x080918b1 in erl_start (argc=62, argv=0xbfaae684) at beam/erl_init.c:1231
>   #4  0x08072e66 in main (argc=Cannot access memory at address 0x0
>   ) at sys/unix/erl_main.c:29
>   (gdb) 
> 
> The ERTS_HOLE_MARKER thing happens much less frequently than the simple
> SIGSEGV or out-of-memory thing, perhaps once every 20 minutes or so of
> constant trying.  I've got a copy of the core image via "gcore", if it'd
> help.
> 
> I'm at a bit of a loss of what other info I can provide, so please let
> me know if I can send something else. 
> 
> -Scott
> 

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

From kristoffer.koch@REDACTED  Fri Aug 28 09:53:01 2009
From: kristoffer.koch@REDACTED (Kristoffer Ellersgaard Koch)
Date: Fri, 28 Aug 2009 09:53:01 +0200
Subject: erlc crashes
Message-ID: <2b868f8f0908280053q24d454eepbafa3df45407009b@mail.gmail.com>

Hi.

I'm stuck with the following error when I'm compiling:

me@REDACTED:~/src$ erlc -I ../include/ hashtree.erl
hashtree: function write_child/7+159:
? Internal consistency check failed - please report this bug.
? Instruction: {bs_context_to_binary,{y,6}}
? Error:?????? {match_context,{y,6}}:

I'm running ubuntu:
me@REDACTED:~/src$ dpkg -l |grep erlang
ii  erlang                                     1:12.b.5-dfsg-2
             Concurrent, real-time, distributed functiona
ii  erlang-base                                1:12.b.5-dfsg-2
             Concurrent, real-time, distributed functiona
ii  erlang-dev                                 1:12.b.5-dfsg-2
             Concurrent, real-time, distributed functiona
ii  erlang-examples                            1:12.b.5-dfsg-2
             Concurrent, real-time, distributed functiona
ii  erlang-manpages                            1:12.b.3-1
             Erlang man pages
ii  erlang-mode                                1:12.b.5-dfsg-2
             Concurrent, real-time, distributed functiona
ii  erlang-nox                                 1:12.b.5-dfsg-2
             Concurrent, real-time, distributed functiona
ii  erlang-src                                 1:12.b.5-dfsg-2
             Concurrent, real-time, distributed functiona
ii  erlang-x11                                 1:12.b.5-dfsg-2
             Concurrent, real-time, distributed functiona
ii  libsdl-erlang                              0.96.0626-11
             Erlang bindings to the Simple Direct Media L

I have a working source tree, and the patch that just makes erlc crash:
http://folk.ntnu.no/koch/erl-bug/

I'm sorry if this is an already fixed bug, and I'll try the latest
release and/or dev branch.

Please don't be too hard on my code; it's just some tinkering.
--
Kristoffer E. Koch
+47 990 26 250

From kristoffer.koch@REDACTED  Fri Aug 28 10:24:54 2009
From: kristoffer.koch@REDACTED (Kristoffer Ellersgaard Koch)
Date: Fri, 28 Aug 2009 10:24:54 +0200
Subject: erlc crashes
In-Reply-To: <2b868f8f0908280053q24d454eepbafa3df45407009b@mail.gmail.com>
References: <2b868f8f0908280053q24d454eepbafa3df45407009b@mail.gmail.com>
Message-ID: <2b868f8f0908280124n7632993cs9a1e57f450471d77@mail.gmail.com>

On Fri, Aug 28, 2009 at 9:53 AM, Kristoffer Ellersgaard Koch
<kristoffer.koch@REDACTED> wrote:
>
> Hi.
>
> I'm stuck with the following error when I'm compiling:
>
> me@REDACTED:~/src$ erlc -I ../include/ hashtree.erl
> hashtree: function write_child/7+159:
> ? Internal consistency check failed - please report this bug.
> ? Instruction: {bs_context_to_binary,{y,6}}
> ? Error:?????? {match_context,{y,6}}:

The bug dissapears with the latest otp (R13B01).

Regards,
--
Kristoffer E. Koch
+47 990 26 250

From aravanchik@REDACTED  Fri Aug 28 12:47:56 2009
From: aravanchik@REDACTED (Aravanchik rava)
Date: Fri, 28 Aug 2009 14:47:56 +0400
Subject: compile attribute problem
Message-ID: <72fb530b0908280347q1dd54b14xec13804961786b3a@mail.gmail.com>

*Hi,*

Erlang R13B-1 (erts-5.7.2) dublicates compilier's options.

*For example,file test.erl:*

-module(test).

-compile(export_all).

double(X)->

        2*X.

*In shell:*

>> c(test.erl).

{ok, test}

>>test:module_info(compile).

[{options, *[export_all, export_all]*},

{version, "4.6.2"},

{time, {2009,8,27,7,7,37}}

{source, "%source_path%"}]

Please could you fix it?