From prikrutil@REDACTED  Mon Aug  2 12:19:02 2010
From: prikrutil@REDACTED (Sergey Samokhin)
Date: Mon, 2 Aug 2010 14:19:02 +0400
Subject: epmd floods my errors.log
Message-ID: <AANLkTinXywS9LNSfTqLY877nArS3oBc3h-b4R9xGkXmf@mail.gmail.com>

Hello.

Description
----------------

Every time I do "erl -sname foo" or just "epmd -daemon" I see this
message written to errors.log:

Aug  2 13:22:13 myhost epmd: epmd: epmd running - daemon = 1

Usually my errors.log is full of these messages, which aren't actually
errors. It looks like loglevel for these messages is wrong.

Why and where this happens
------------------------------------------

Code we are interested in is in erts/epmd/src/epmd.c file

#1 First dbg_printf() is called with "epmd running - daemon = %d" format string
Source: http://github.com/erlang/otp/blob/dev/erts/epmd/src/epmd.c#L239

#2 Then dbg_printf() calls dbg_gen_printf()
Source: http://github.com/erlang/otp/blob/dev/erts/epmd/src/epmd.c#L494

#3 And here the message is actually sent to syslog.
Source: http://github.com/erlang/otp/blob/dev/erts/epmd/src/epmd.c#L449

The problem is that for the message LOG_ERR priority is used, which
seems to be wrong.
LOG_NOTICE, LOG_INFO or LOG_DEBUG seem more suitable here.

Environment
------------------

Related part of my /etc/syslog-ng.conf:

destination d_errors { file("/var/log/errors.log"); };
(...)
log { source(src); filter(f_err); destination(d_errors); };

There was similar letter some month ago:
http://www.erlang.org/cgi-bin/ezmlm-cgi?4:sss:50616:201004:gpmnkdkhkkmnlcghliek#b

Thanks.

-- 
Sergey Samokhin

From nick@REDACTED  Mon Aug  2 14:22:09 2010
From: nick@REDACTED (Niclas Eklund)
Date: Mon, 2 Aug 2010 14:22:09 +0200 (CEST)
Subject: [erlang-bugs] standard ssh to erlang sshd gives default shell,
 not the one specified in ssh:daemon/3
In-Reply-To: <20100726183216.58169f6a@christian>
References: <20100726183216.58169f6a@christian>
Message-ID: <Pine.LNX.4.64.1008021412350.4997@mallor.du.uab.ericsson.se>


Hello!

Try something like:

   Exec = {Module, Function, ArgList},
   ssh:daemon({0,0,0,0}, <PORT>, [{exec, Exec}|Options]).

Best regards,

Niclas @ Erlang/OTP

On Mon, 26 Jul 2010, andrei zavada wrote:

> Hi,
>
> Consider the case of starting ssh:daemon/3 with bespoke shell supplied as
> {shell, {Module, Function, Args}} in the proplist as its third parameter.
>
> Everything works as expected if I just do (using openssh-5.5_p1, the current
> version in Gentoo per this writing)
>
> $ ssh -p<port> localhost
>
> My shell is now invoked and is happily serving commands.  Once I try the same
> with a command-line parameter, i.e.,
>
> $ ssh -p<port> localhost fafa
>
> (expecting "fafa" to be passed to my shell function), the server hands "fafa"
> over to the Erlang standard shell, which prints:
>
> {error,{1,erl_parse,["syntax error before: ",[]]}}
>
> And, logically, appending a dot to "fafa" makes it a valid Erlang expression,
> which gets me a nice
>
> fafa
>
> The expected behaviour is that sshd accept the command and feed it to the
> custom shell the user specified in the Options proplist.
>
> This misbehaviour is verified in otp-12B-5, otp-13B04, as well as in otp-14A.
> All systems were tested on a Gentoo box (~amd64 arch), built from unpatched
> sources from erlang.org.
>
> Is this a bug, as I suppose it is?
>
> Regards
> Andrei Zavada
>
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>



From michael.santos@REDACTED  Tue Aug  3 15:44:27 2010
From: michael.santos@REDACTED (Michael Santos)
Date: Tue, 3 Aug 2010 09:44:27 -0400
Subject: [erlang-bugs] epmd floods my errors.log
In-Reply-To: <AANLkTinXywS9LNSfTqLY877nArS3oBc3h-b4R9xGkXmf@mail.gmail.com>
References: <AANLkTinXywS9LNSfTqLY877nArS3oBc3h-b4R9xGkXmf@mail.gmail.com>
Message-ID: <20100803134427.GB21835@ecn.lan>

On Mon, Aug 02, 2010 at 02:19:02PM +0400, Sergey Samokhin wrote:

> Every time I do "erl -sname foo" or just "epmd -daemon" I see this
> message written to errors.log:

> 
> Aug  2 13:22:13 myhost epmd: epmd: epmd running - daemon = 1
> 
> Usually my errors.log is full of these messages, which aren't actually
> errors. It looks like loglevel for these messages is wrong.

> There was similar letter some month ago:
> http://www.erlang.org/cgi-bin/ezmlm-cgi?4:sss:50616:201004:gpmnkdkhkkmnlcghliek#b

Is the pid of the epmd process changing? Do you have more than one
epmd running? Check ps and netstat for port 4369.

For example, I can reproduce this behaviour by running "epmd" in one
shell and trying to start a second epmd in another shell.



From prikrutil@REDACTED  Tue Aug  3 16:05:41 2010
From: prikrutil@REDACTED (Sergey Samokhin)
Date: Tue, 3 Aug 2010 18:05:41 +0400
Subject: [erlang-bugs] epmd floods my errors.log
In-Reply-To: <20100803134427.GB21835@ecn.lan>
References: <AANLkTinXywS9LNSfTqLY877nArS3oBc3h-b4R9xGkXmf@mail.gmail.com> 
	<20100803134427.GB21835@ecn.lan>
Message-ID: <AANLkTim8u3W=NZc4nCGR4f=jqsWSkj8dvbq9DKU2XOko@mail.gmail.com>

> Is the pid of the epmd process changing? Do you have more than one
> epmd running? Check ps and netstat for port 4369.

pid of epmd isn't changed and I have only one epmd running.

Every "erl -sname foo -run init stop" adds one "epmd running - daemon
= 1" to the errors.log

Steps to reproduce are quite easy (have just tested on clear virtual machine)

1. Install Erlang R13B04
2. Do "erl -sname foo -run init stop" N times
3. Take a look at "sudo cat /var/log/errors.log"; you will see N "epmd
running - daemon = 1" messages

-- 
Sergey Samokhin

From michael.santos@REDACTED  Tue Aug  3 16:32:38 2010
From: michael.santos@REDACTED (Michael Santos)
Date: Tue, 3 Aug 2010 10:32:38 -0400
Subject: [erlang-bugs] epmd floods my errors.log
In-Reply-To: <AANLkTim8u3W=NZc4nCGR4f=jqsWSkj8dvbq9DKU2XOko@mail.gmail.com>
References: <AANLkTinXywS9LNSfTqLY877nArS3oBc3h-b4R9xGkXmf@mail.gmail.com> <20100803134427.GB21835@ecn.lan> <AANLkTim8u3W=NZc4nCGR4f=jqsWSkj8dvbq9DKU2XOko@mail.gmail.com>
Message-ID: <20100803143238.GC21835@ecn.lan>

On Tue, Aug 03, 2010 at 06:05:41PM +0400, Sergey Samokhin wrote:
> > Is the pid of the epmd process changing? Do you have more than one
> > epmd running? Check ps and netstat for port 4369.
> 
> pid of epmd isn't changed and I have only one epmd running.
> 
> Every "erl -sname foo -run init stop" adds one "epmd running - daemon
> = 1" to the errors.log
> 
> Steps to reproduce are quite easy (have just tested on clear virtual machine)
> 
> 1. Install Erlang R13B04
> 2. Do "erl -sname foo -run init stop" N times
> 3. Take a look at "sudo cat /var/log/errors.log"; you will see N "epmd
> running - daemon = 1" messages

Thanks! I understand the issue now.

You suggested in your first email using LOG_INFO, but do you think this
patch would be sufficient? epmd will log (at LOG_ERR) only when one or
more "-d" flags are passed.


diff --git a/erts/epmd/src/epmd.c b/erts/epmd/src/epmd.c
index 6ddf30e..9c2ce06 100644
--- a/erts/epmd/src/epmd.c
+++ b/erts/epmd/src/epmd.c
@@ -237,5 +237,5 @@ int main(int argc, char** argv)
 	    usage(g);
     }
-    dbg_printf(g,0,"epmd running - daemon = %d",g->is_daemon);
+    dbg_printf(g,1,"epmd running - daemon = %d",g->is_daemon);
 
 #ifndef NO_SYSCONF




From johnhommer@REDACTED  Tue Aug  3 16:58:22 2010
From: johnhommer@REDACTED (andrei zavada)
Date: Tue, 3 Aug 2010 17:58:22 +0300
Subject: [erlang-bugs] standard ssh to erlang sshd gives default shell,
 not the one specified in ssh:daemon/3
In-Reply-To: <Pine.LNX.4.64.1008021412350.4997@mallor.du.uab.ericsson.se>
References: <20100726183216.58169f6a@christian>
 <Pine.LNX.4.64.1008021412350.4997@mallor.du.uab.ericsson.se>
Message-ID: <20100803175822.78d87a39@christian>

Hi Niclas & all,

I gave it a try, and have a few things to note.

1. The exec option is not documented; it would be nice if it was.

2. Execution of command passed on ssh commandline is indeed suppressed if
ssh:daemon is started with an {exec, {M,F,A}} option.  Plugging an empty
function as "F" could be a simple solution for the folks recently (rightly)
raising this as a security issue.

3. However, {exec, {M,F,A}} doesn't seem to work.  Following your example, I
couldn't get my fun called.  Looking into the sources in ssh_cli.erl, it
appears in this branch of handle_ssh_msg:

handle_ssh_msg({ssh_cm, ConnectionManager, 
		{exec, ChannelId, WantReply, Cmd}}, #state{exec=undefined} = State) -> {Reply, Status} =
		 exec(Cmd), write_chars(ConnectionManager, 
		ChannelId, io_lib:format("~p\n", [Reply])),
    ssh_connection:reply_request(ConnectionManager, WantReply, 
				 success, ChannelId),
    ssh_connection:exit_status(ConnectionManager, ChannelId, Status),
    ssh_connection:send_eof(ConnectionManager, ChannelId),
    {stop, ChannelId, State#state{channel = ChannelId, cm = ConnectionManager}};

handle_ssh_msg({ssh_cm, ConnectionManager,
		{exec, ChannelId, WantReply, Cmd}}, State) ->
    NewState = start_shell(ConnectionManager, Cmd, State),
    ssh_connection:reply_request(ConnectionManager, WantReply,
				 success, ChannelId),
    {ok, NewState#state{channel = ChannelId,
			cm = ConnectionManager}};

the second one, which is supposed to take effect when the user has supplied
an {exec, {M, F, A}} option, seems to never be reachable.

3. Down in start_shell and below, there is a call starting a group, similarly
to the way this is done for the regular, interactive shell.  IMHO, if all I
need is connect via ssh, exec my command and return, a simple function call
will suffice.

4. In the context of the project I am fitting ssh into, I need to know who is
the user wanting to exec a command via ssh <host> <command>; hence, the
solution you pointed out with {exec, {M,F,A}}, isn't suitable.  Even before, I
have prepared a patch (attached) for otp-13B04 to do exactly this.  This
patch will, likely with some fuzz, apply to otp-14A as well.

With my patch, you would call ssh:daemon/3 with something like this in the
Options parameter:

  Exec4User = fun(User, Cmd) -> do_something(User, Cmd), "Done" end,
  ssh:daemon(Port, Address, {{exec4user, Exec4User} | OtherOptions}),

5. The solution I am proposing is of a "works-for-me" kind; someone has to
look into why the {exec, {M,F,A}} fails.  In other words, there is little
sense for both exec and exec4user to coexist: let upstream decide.

Cheers,
Andrei Zavada


On Mon, 2 Aug 2010 14:22:09 +0200 (CEST)
Niclas Eklund <nick@REDACTED> wrote:

> 
> Hello!
> 
> Try something like:
> 
>    Exec = {Module, Function, ArgList},
>    ssh:daemon({0,0,0,0}, <PORT>, [{exec, Exec}|Options]).
> 
> Best regards,
> 
> Niclas @ Erlang/OTP
> 
> On Mon, 26 Jul 2010, andrei zavada wrote:
> 
> > Hi,
> >
> > Consider the case of starting ssh:daemon/3 with bespoke shell supplied as
> > {shell, {Module, Function, Args}} in the proplist as its third parameter.
> >
> > Everything works as expected if I just do (using openssh-5.5_p1, the
> > current version in Gentoo per this writing)
> >
> > $ ssh -p<port> localhost
> >
> > My shell is now invoked and is happily serving commands.  Once I try the
> > same with a command-line parameter, i.e.,
> >
> > $ ssh -p<port> localhost fafa
> >
> > (expecting "fafa" to be passed to my shell function), the server hands
> > "fafa" over to the Erlang standard shell, which prints:
> >
> > {error,{1,erl_parse,["syntax error before: ",[]]}}
> >
> > And, logically, appending a dot to "fafa" makes it a valid Erlang
> > expression, which gets me a nice
> >
> > fafa
> >
> > The expected behaviour is that sshd accept the command and feed it to the
> > custom shell the user specified in the Options proplist.
> >
> > This misbehaviour is verified in otp-12B-5, otp-13B04, as well as in
> > otp-14A. All systems were tested on a Gentoo box (~amd64 arch), built
> > from unpatched sources from erlang.org.
> >
> > Is this a bug, as I suppose it is?
> >
> > Regards
> > Andrei Zavada
> >
> > ________________________________________________________________
> > erlang-bugs (at) erlang.org mailing list.
> > See http://www.erlang.org/faq.html
> > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
> >
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: exec4user.patch
Type: text/x-patch
Size: 5175 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100803/e005216c/attachment.bin>

From prikrutil@REDACTED  Tue Aug  3 17:51:22 2010
From: prikrutil@REDACTED (Sergey Samokhin)
Date: Tue, 3 Aug 2010 19:51:22 +0400
Subject: [erlang-bugs] epmd floods my errors.log
In-Reply-To: <20100803143238.GC21835@ecn.lan>
References: <AANLkTinXywS9LNSfTqLY877nArS3oBc3h-b4R9xGkXmf@mail.gmail.com> 
	<20100803134427.GB21835@ecn.lan> <AANLkTim8u3W=NZc4nCGR4f=jqsWSkj8dvbq9DKU2XOko@mail.gmail.com> 
	<20100803143238.GC21835@ecn.lan>
Message-ID: <AANLkTinJ=P6GDt4-i=Sv0YnGqpE_8+-bHpjbZjbfZ3d8@mail.gmail.com>

Hello, Michael!

> You suggested in your first email using LOG_INFO, but do you think this
> patch would be sufficient? epmd will log (at LOG_ERR) only when one or
> more "-d" flags are passed.

I have just tested your patch in VirtualBox, it is completely
sufficient! No more annoying messages in errors.log (untill -d is
specified, as you said)!

Big thanks! I would be very happy to see this patch in the next Erlang release!

-- 
Sergey Samokhin

From michael.santos@REDACTED  Tue Aug  3 18:43:48 2010
From: michael.santos@REDACTED (Michael Santos)
Date: Tue, 3 Aug 2010 12:43:48 -0400
Subject: [erlang-bugs] epmd floods my errors.log
In-Reply-To: <AANLkTinJ=P6GDt4-i=Sv0YnGqpE_8+-bHpjbZjbfZ3d8@mail.gmail.com>
References: <AANLkTinXywS9LNSfTqLY877nArS3oBc3h-b4R9xGkXmf@mail.gmail.com> <20100803134427.GB21835@ecn.lan> <AANLkTim8u3W=NZc4nCGR4f=jqsWSkj8dvbq9DKU2XOko@mail.gmail.com> <20100803143238.GC21835@ecn.lan> <AANLkTinJ=P6GDt4-i=Sv0YnGqpE_8+-bHpjbZjbfZ3d8@mail.gmail.com>
Message-ID: <20100803164348.GA23560@ecn.lan>

On Tue, Aug 03, 2010 at 07:51:22PM +0400, Sergey Samokhin wrote:
> Hello, Michael!
> 
> > You suggested in your first email using LOG_INFO, but do you think this
> > patch would be sufficient? epmd will log (at LOG_ERR) only when one or
> > more "-d" flags are passed.
> 
> I have just tested your patch in VirtualBox, it is completely
> sufficient! No more annoying messages in errors.log (untill -d is
> specified, as you said)!
> 
> Big thanks! I would be very happy to see this patch in the next Erlang release!

Awesome! I will submit the patch to erlang-patches later today.


From nick@REDACTED  Wed Aug  4 10:40:21 2010
From: nick@REDACTED (Niclas Eklund)
Date: Wed, 4 Aug 2010 10:40:21 +0200 (CEST)
Subject: [erlang-bugs] standard ssh to erlang sshd gives default shell,
 not the one specified in ssh:daemon/3
In-Reply-To: <20100803175822.78d87a39@christian>
References: <20100726183216.58169f6a@christian>
 <Pine.LNX.4.64.1008021412350.4997@mallor.du.uab.ericsson.se>
 <20100803175822.78d87a39@christian>
Message-ID: <Pine.LNX.4.64.1008041001100.4997@mallor.du.uab.ericsson.se>


Hello!

#1 It will be documented when it's supported.

#2 Will be considered.

#3 Use the following trace to confirm that your callback module is called:

  dbg:tracer().
  dbg:p(all, [call]).
  dbg:tpl(group,start, [{'_',[],[{return_trace}]}]).
  dbg:tpl(group,start_shell1, [{'_',[],[{return_trace}]}]).

If Exec == {shell, start, ["foo"]} and you run 'ssh -p 9999 localhost bar' 
you should see:

(<0.68.0>) call group:start_shell1(shell,start,["foo","bar"])

#4 The exec option will perhaps be extended with similar options that 
shell accepts.

Best regards,

Niclas @ Erlang/OTP

On Tue, 3 Aug 2010, andrei zavada wrote:

> Hi Niclas & all,
>
> I gave it a try, and have a few things to note.
>
> 1. The exec option is not documented; it would be nice if it was.
>
> 2. Execution of command passed on ssh commandline is indeed suppressed if
> ssh:daemon is started with an {exec, {M,F,A}} option.  Plugging an empty
> function as "F" could be a simple solution for the folks recently (rightly)
> raising this as a security issue.
>
> 3. However, {exec, {M,F,A}} doesn't seem to work.  Following your example, I
> couldn't get my fun called.  Looking into the sources in ssh_cli.erl, it
> appears in this branch of handle_ssh_msg:
>
> handle_ssh_msg({ssh_cm, ConnectionManager,
> 		{exec, ChannelId, WantReply, Cmd}}, #state{exec=undefined} = State) -> {Reply, Status} =
> 		 exec(Cmd), write_chars(ConnectionManager,
> 		ChannelId, io_lib:format("~p\n", [Reply])),
>    ssh_connection:reply_request(ConnectionManager, WantReply,
> 				 success, ChannelId),
>    ssh_connection:exit_status(ConnectionManager, ChannelId, Status),
>    ssh_connection:send_eof(ConnectionManager, ChannelId),
>    {stop, ChannelId, State#state{channel = ChannelId, cm = ConnectionManager}};
>
> handle_ssh_msg({ssh_cm, ConnectionManager,
> 		{exec, ChannelId, WantReply, Cmd}}, State) ->
>    NewState = start_shell(ConnectionManager, Cmd, State),
>    ssh_connection:reply_request(ConnectionManager, WantReply,
> 				 success, ChannelId),
>    {ok, NewState#state{channel = ChannelId,
> 			cm = ConnectionManager}};
>
> the second one, which is supposed to take effect when the user has supplied
> an {exec, {M, F, A}} option, seems to never be reachable.
>
> 3. Down in start_shell and below, there is a call starting a group, similarly
> to the way this is done for the regular, interactive shell.  IMHO, if all I
> need is connect via ssh, exec my command and return, a simple function call
> will suffice.
>
> 4. In the context of the project I am fitting ssh into, I need to know who is
> the user wanting to exec a command via ssh <host> <command>; hence, the
> solution you pointed out with {exec, {M,F,A}}, isn't suitable.  Even before, I
> have prepared a patch (attached) for otp-13B04 to do exactly this.  This
> patch will, likely with some fuzz, apply to otp-14A as well.
>
> With my patch, you would call ssh:daemon/3 with something like this in the
> Options parameter:
>
>  Exec4User = fun(User, Cmd) -> do_something(User, Cmd), "Done" end,
>  ssh:daemon(Port, Address, {{exec4user, Exec4User} | OtherOptions}),
>
> 5. The solution I am proposing is of a "works-for-me" kind; someone has to
> look into why the {exec, {M,F,A}} fails.  In other words, there is little
> sense for both exec and exec4user to coexist: let upstream decide.
>
> Cheers,
> Andrei Zavada
>
>
> On Mon, 2 Aug 2010 14:22:09 +0200 (CEST)
> Niclas Eklund <nick@REDACTED> wrote:
>
>>
>> Hello!
>>
>> Try something like:
>>
>>    Exec = {Module, Function, ArgList},
>>    ssh:daemon({0,0,0,0}, <PORT>, [{exec, Exec}|Options]).
>>
>> Best regards,
>>
>> Niclas @ Erlang/OTP
>>
>> On Mon, 26 Jul 2010, andrei zavada wrote:
>>
>>> Hi,
>>>
>>> Consider the case of starting ssh:daemon/3 with bespoke shell supplied as
>>> {shell, {Module, Function, Args}} in the proplist as its third parameter.
>>>
>>> Everything works as expected if I just do (using openssh-5.5_p1, the
>>> current version in Gentoo per this writing)
>>>
>>> $ ssh -p<port> localhost
>>>
>>> My shell is now invoked and is happily serving commands.  Once I try the
>>> same with a command-line parameter, i.e.,
>>>
>>> $ ssh -p<port> localhost fafa
>>>
>>> (expecting "fafa" to be passed to my shell function), the server hands
>>> "fafa" over to the Erlang standard shell, which prints:
>>>
>>> {error,{1,erl_parse,["syntax error before: ",[]]}}
>>>
>>> And, logically, appending a dot to "fafa" makes it a valid Erlang
>>> expression, which gets me a nice
>>>
>>> fafa
>>>
>>> The expected behaviour is that sshd accept the command and feed it to the
>>> custom shell the user specified in the Options proplist.
>>>
>>> This misbehaviour is verified in otp-12B-5, otp-13B04, as well as in
>>> otp-14A. All systems were tested on a Gentoo box (~amd64 arch), built
>>> from unpatched sources from erlang.org.
>>>
>>> Is this a bug, as I suppose it is?
>>>
>>> Regards
>>> Andrei Zavada
>>>
>>> ________________________________________________________________
>>> erlang-bugs (at) erlang.org mailing list.
>>> See http://www.erlang.org/faq.html
>>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>>>
>>
>>
>
>



From pguyot@REDACTED  Wed Aug  4 11:51:25 2010
From: pguyot@REDACTED (Paul Guyot)
Date: Wed, 4 Aug 2010 11:51:25 +0200
Subject: Fix SSL 4.0.1 handshake bug
Message-ID: <37E96D08-659A-4640-BA49-08ED6C21E71B@kallisys.net>

Hello,

There is a bug in SSL 4.0.1 handshake from the client side. When a client certificate is used, SSL 4.0.1 filters ciphers to only send those compatible with the certificate (e.g. of the same algorithm dsa/rsa, and in the case of RSA, it depends on the key usage extension of the certificate).

This behavior differs from common implementations (e.g. openssl s_client) and from what the TLS 1.0 specification says.

RFC2246 mentions filtering cipher suites based on the *server* certificate (7.4.2). The public key in the server certificate is sent to the client to encrypt the pre-master.

However, RFC2246 does not say clients should do the same with the client certificate. The key in the client certificate is never used to encrypt any key (therefore, there is no reason to filter on keyEncipherment usage), it is only used to sign the exchange so far *if the certificate has signing capability* (7.4.6, 7.4.8). As a result, the client should send all the ciphers it is capable of using (this is what openssl s_client as well as {ssl_imp, old} does).

Since openssl blindly sends all the cipher suites, this is what I suggest and what is implemented in the patch.

However, I am not sure if the client should refuse to send the certificate verify message if the certificate usage extension does not include digitalSignature (and the critical bit is set ?).

A patch with a non-regression test is available here:

git fetch git://github.com/pguyot/otp.git pg/fix-ssl-handshake-client-certificate
http://github.com/pguyot/otp/commit/0975941a5b2684158ec8e94107a531f12827ca66

Paul
-- 
Semiocast                    http://semiocast.com/
+33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris


From bgustavsson@REDACTED  Wed Aug  4 11:56:36 2010
From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=)
Date: Wed, 4 Aug 2010 11:56:36 +0200
Subject: [erlang-patches] Fix SSL 4.0.1 handshake bug
In-Reply-To: <37E96D08-659A-4640-BA49-08ED6C21E71B@kallisys.net>
References: <37E96D08-659A-4640-BA49-08ED6C21E71B@kallisys.net>
Message-ID: <AANLkTinNMvbzxKzNKsq=T-9ymF2KEG0J-uVGN1wBWga+@mail.gmail.com>

On Wed, Aug 4, 2010 at 11:51 AM, Paul Guyot <pguyot@REDACTED> wrote:
>
> git fetch git://github.com/pguyot/otp.git pg/fix-ssl-handshake-client-certificate
> http://github.com/pguyot/otp/commit/0975941a5b2684158ec8e94107a531f12827ca66

Thanks! Included in 'pu'.

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

From nick@REDACTED  Mon Aug  9 15:57:16 2010
From: nick@REDACTED (Niclas Eklund)
Date: Mon, 9 Aug 2010 15:57:16 +0200 (CEST)
Subject: [erlang-bugs] SSH-1.1.8, incomplete application reference
 dependence
In-Reply-To: <AANLkTikdxsks5LsYiS5F88Q6mjEEQ_EWXXEgEtCfvSWs@mail.gmail.com>
References: <AANLkTikdxsks5LsYiS5F88Q6mjEEQ_EWXXEgEtCfvSWs@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008091544570.4997@mallor.du.uab.ericsson.se>


Hello!

This issue was addressed earlier when a suggestion was sent via Git. The 
short version is that pulic_key (currently) doesn't contain any processes, 
i.e. only a set of library functions. Thus, changing ssh.app.src so it 
would list pulic_key as an application that must be started before SSH is, 
would not be a backward compatible change (it would be necessary to add 
application:start(public_key) in ones code). This could cause problems 
during a hot code upgrade. I'll consider this change for R14B.

Best regards,

Niclas @ Erlang/OTP

On Fri, 2 Jul 2010, Alexander Demidenko wrote:

> Erlang application ssh, use function from pulic_key,
> but inside ssh.app is no reference dependence from public_key.
> as a result, tools like Sinan, build invalid packages.
>
> PS Tested on Erlang 13b4, ssh-1.1.8.
>
> -- 
> ---------------------------------------------
> With best regards,
> Alexander.
>
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>



From matthew@REDACTED  Mon Aug  9 17:41:12 2010
From: matthew@REDACTED (Matthew Sackman)
Date: Mon, 9 Aug 2010 16:41:12 +0100
Subject: Supervisor.erl erroreously removes the child_spec on reaching
 max_restart_intensity
Message-ID: <20100809154112.GA16223@rabbitmq.com>

It doesn't actually cause a crash, but in the following:

restart(Child, State) ->
    case add_restart(State) of
	{ok, NState} ->
	    restart(NState#state.strategy, Child, NState, fun restart/2);
	{terminate, NState} ->
	    report_error(shutdown, reached_max_restart_intensity,
			 Child, State#state.name),
	    {shutdown, remove_child(Child, NState)}
    end.

the call to remove_child is wrong. It removes the child spec. In the
case of a simple_one_for_one, that then means that in terminate, we have
a pid in the dynamics dictionary, but no child spec at all, whilst in
the case of non simple_one_for_one the spec is simply not there.

This doesn't cause any crashes, but it means the state is inconsistent
in the subsequent terminate function. It should be a call to
state_del_child (blank the child pid in the non-simple case, or remove
the pid from the dynamics dict for the simple case).

Matthew

From daniel.goertzen@REDACTED  Wed Aug 11 17:00:33 2010
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Wed, 11 Aug 2010 10:00:33 -0500
Subject: Windows fd_driver performs unconditional CR translation
Message-ID: <AANLkTinP_XXtOUh4-Sac=MMqqh37Hm7NUDqsx40eGB98@mail.gmail.com>

On Windows, ports that operate on file descriptors, ie open_port(
{fd,0,1}...), will perform unconditional carriage return mangling.

I want to run erlang as a child process, and I want to perform unmangled IO
with it via stdin/stdout.  Currently this is impossible due to CR mangling.

The DF_XLAT_CR flag is assigned unconditionally in
erts/emulator/sys/win32/sys.c fd_start().

A solution might be to add an option, say "nomangle", to open_port
(erts/emulator/beam/erl_bif_port.c), and then have fd_start() examine that
option to enable or disable DF_XLAT_CR.


Dan.

From matthew@REDACTED  Thu Aug 12 13:32:18 2010
From: matthew@REDACTED (Matthew Sackman)
Date: Thu, 12 Aug 2010 12:32:18 +0100
Subject: Supervisor.erl erroreously reports error when child exits with
 normal during shutdown
Message-ID: <20100812113218.GI16223@rabbitmq.com>

(You can guess what I'm hacking on atm...)

In supervisor, when it terminates a child, if that child happens to have
exited fractionally early, with normal, the supervisor reports this as
an error.

For permanent children, that's likely the right thing to do, but for all
other types of children it's wrong and leads to polluted logs. Both
temporary and transient children do not get restarted on normal
self-destruction, and nor do they get logged about. Just because they
happen to destruct as the supervisor is trying to stop them shouldn't
alter this.

Diff attached.

Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: supervisor.patch
Type: text/x-diff
Size: 879 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100812/c01801aa/attachment.bin>

From helllamer@REDACTED  Thu Aug 12 18:08:47 2010
From: helllamer@REDACTED (Konstantin Nikiforov)
Date: Thu, 12 Aug 2010 20:08:47 +0400
Subject: beam.smp segfault if there are disabled cpu cores
Message-ID: <AANLkTimAPtgJmiMvb5RTG_evWv0b1F0drhLLj=xbF2dt@mail.gmail.com>

Archlinux x86_64

Steps to demonstrate the segfault:

0) starting erlang
$ erl
Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2]
[async-threads:0] [hipe] [kernel-poll:false]

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


1) disabling one of two cpu cores in power-saving purposes
echo 0 > /sys/devices/system/cpu/cpu1/online


2) starting erlang
$ erl
zsh: segmentation fault  erl
$ dmesg
...
CPU 1 is now offline
SMP alternatives: switching to UP code
beam.smp[14894]: segfault at 7f07a9d3e560 ip 00000000004403f8 sp
00007fff336e70e0 error 6 in beam.smp[400000+1dc000]


3) enabling cpu core back
echo 1 > /sys/devices/system/cpu/cpu1/online


4) starting erlang
$ erl
Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2]
[async-threads:0] [hipe] [kernel-poll:false]

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


All ok then all CPU cores enabled. CPU cores goes to offline automatically
in linux notebooks to minimize power consumption then AC plug off.

From andrew@REDACTED  Fri Aug 13 20:01:22 2010
From: andrew@REDACTED (Andrew Thompson)
Date: Fri, 13 Aug 2010 14:01:22 -0400
Subject: Can't connect to smtp.gmail.com via SSL in R14
Message-ID: <20100813180122.GL14935@hijacked.us>

So, when I try to connect to the SSL SMTP socket for gmail, I get this
failure:

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

Eshell V5.8.1  (abort with ^G)
1> application:start(crypto).
ok
2> application:start(public_key).
ok
3> application:start(ssl).
ok
4> ssl:connect("smtp.gmail.com", 465, []).
{ok,{sslsocket,new_ssl,<0.51.0>}}
5> 
=ERROR REPORT==== 13-Aug-2010::13:27:09 ===
SSL: decipher_error: ./ssl_record.erl:648:Fatal error: bad record mac
flush().
Shell got {#Ref<0.0.0.59>,{error,"bad record mac"}}
ok


This happens with the R14A release, with the latest github/dev AND the
latest github/pu branches on OSX. 

It doesn't happen on R13b02 on another machine, there it works as
expected. It should be pretty easy to reproduce without further
information.

Andrew

From xramtsov@REDACTED  Sat Aug 14 16:20:29 2010
From: xramtsov@REDACTED (Evgeniy Khramtsov)
Date: Sun, 15 Aug 2010 00:20:29 +1000
Subject: Supervisor and its children arguments
Message-ID: <4C66A62D.90206@gmail.com>

It seems like a supervisor stores it's children data even if the 
children are temporary. Is it really needed? We experience ~500Mb of RAM 
consumed by such supervisor because children arguments contain lots of data.
Is it possible to improve such behaviour?

Thank you.

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram@REDACTED


From sgolovan@REDACTED  Sun Aug 15 12:02:06 2010
From: sgolovan@REDACTED (Sergei Golovan)
Date: Sun, 15 Aug 2010 14:02:06 +0400
Subject: Segmentation fault in wxErlang
Message-ID: <AANLkTikG6js9XWX03eQ1cFgAo5JJ17BWduKTOC=XFppH@mail.gmail.com>

Hi!

A Debian user recently found a bug in wxErlang (in the current Erlang
R14A). It consistently segfaults when playing with sudoku demo.

I couldn't reproduce it with my default SMP settings (+S 8) but it
breaks soon (in a few minutes) after the application start and
interacting with the game field if Erlang VM is started with +S 1
option.

So, I run

% erl -pa /usr/lib/erlang/lib/wx-0.98.6/examples/sudoku +S 1
Erlang R14A (erts-5.8) [source] [smp:1:1] [rq:1] [async-threads:0]
[kernel-poll:false]

Eshell V5.8  (abort with ^G)
1> sudoku:start().
<0.34.0>
sudoku:40: Time: 3556875
Below level 39 40
Below level 34 35
Below level 29 30
Below level 24 25
No left 24

Then I start playing, putting numbers there and there...
After a while:

2> zsh: segmentation fault (core dumped)  erl -pa
/usr/lib/erlang/lib/wx-0.98.6/examples/sudoku +S 1

Below is a GDB session listing. I would be glad to provide any
additional info if required.

Core was generated by `/usr/lib/erlang/erts-5.8/bin/beam.smp -S 1 --
-root /usr/lib/erlang -progname e'.
Program terminated with signal 11, Segmentation fault.
[New process 11376]
[New process 11387]
[New process 11366]
[New process 11373]
[New process 11372]
[New process 11370]
[New process 11371]
#0  0xf51e7a75 in WxeApp::dispatch_cb (this=0x8453398,
batch=0x84942b0, temp=0x8494240, process=835)
    at wxe_impl.cpp:411
411               if(event->caller == process ||  // Callbacks from CB
process only
(gdb) bt
#0  0xf51e7a75 in WxeApp::dispatch_cb (this=0x8453398,
batch=0x84942b0, temp=0x8494240, process=835)
    at wxe_impl.cpp:411
#1  0xf51e7c0a in handle_event_callback (port=0x240, process=643) at
wxe_impl.cpp:306
#2  0xf528d0cc in sendevent (event=0xf2c81ab4, port=0x240) at
gen/wxe_events.cpp:821
#3  0xf528e496 in wxeEvtListener::forward (this=0x857ece0,
event=@0xf2c81ab4) at gen/wxe_events.cpp:328
#4  0xf49e77f1 in wxAppConsole::HandleEvent () from
/usr/lib/libwx_baseu-2.8.so.0
#5  0xf4a849ca in wxEvtHandler::ProcessEventIfMatches () from
/usr/lib/libwx_baseu-2.8.so.0
#6  0xf4a84b56 in wxEvtHandler::SearchDynamicEventTable () from
/usr/lib/libwx_baseu-2.8.so.0
#7  0xf4a85c8d in wxEvtHandler::ProcessEvent () from
/usr/lib/libwx_baseu-2.8.so.0
#8  0xf4c45fd0 in wxWindow::GtkSendPaintEvents () from
/usr/lib/libwx_gtk2u_core-2.8.so.0
#9  0xf4c4658d in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#10 0xf45e6816 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x084aa220 in ?? ()
#12 0xf2c82070 in ?? ()
#13 0x085ec2f8 in ?? ()
#14 0xf4398678 in ?? () from /usr/lib/libgobject-2.0.so.0
#15 0x0857ee30 in ?? ()
#16 0x0857f320 in ?? ()
#17 0xf2c81c18 in ?? ()
#18 0xf436790b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
Backtrace stopped: frame did not save the PC
Current language:  auto; currently c++
(gdb) print event
$1 = (wxeCommand *) 0xf11023e8
(gdb) print event->caller
$2 = 611
(gdb) print process
$3 = 835
(gdb) print event->op
$4 = 10
(gdb) print memenv
$5 = (wxeMemEnv *) 0x0
(gdb) print event->port
$6 = (ErlDrvPort) 0x23f
(gdb)

All observed segfaults were at the same place in WxeApp::dispatch_cb() function.

(The Erlang was built without Debian-specific patches and with symbols enabled.)

Cheers!
-- 
Sergei Golovan

From dgud@REDACTED  Sun Aug 15 12:54:22 2010
From: dgud@REDACTED (Dan Gudmundsson)
Date: Sun, 15 Aug 2010 12:54:22 +0200
Subject: [erlang-bugs] Segmentation fault in wxErlang
In-Reply-To: <AANLkTikG6js9XWX03eQ1cFgAo5JJ17BWduKTOC=XFppH@mail.gmail.com>
References: <AANLkTikG6js9XWX03eQ1cFgAo5JJ17BWduKTOC=XFppH@mail.gmail.com>
Message-ID: <AANLkTiku5KS+37hppB1t44MJLuLqeHxGhhvHUkqfK7BE@mail.gmail.com>

Thanks
I will have a look at it.

/Dan

On Sun, Aug 15, 2010 at 12:02 PM, Sergei Golovan <sgolovan@REDACTED> wrote:
> Hi!
>
> A Debian user recently found a bug in wxErlang (in the current Erlang
> R14A). It consistently segfaults when playing with sudoku demo.
>
> I couldn't reproduce it with my default SMP settings (+S 8) but it
> breaks soon (in a few minutes) after the application start and
> interacting with the game field if Erlang VM is started with +S 1
> option.
>
> So, I run
>
> % erl -pa /usr/lib/erlang/lib/wx-0.98.6/examples/sudoku +S 1
> Erlang R14A (erts-5.8) [source] [smp:1:1] [rq:1] [async-threads:0]
> [kernel-poll:false]
>
> Eshell V5.8 ?(abort with ^G)
> 1> sudoku:start().
> <0.34.0>
> sudoku:40: Time: 3556875
> Below level 39 40
> Below level 34 35
> Below level 29 30
> Below level 24 25
> No left 24
>
> Then I start playing, putting numbers there and there...
> After a while:
>
> 2> zsh: segmentation fault (core dumped) ?erl -pa
> /usr/lib/erlang/lib/wx-0.98.6/examples/sudoku +S 1
>
> Below is a GDB session listing. I would be glad to provide any
> additional info if required.
>
> Core was generated by `/usr/lib/erlang/erts-5.8/bin/beam.smp -S 1 --
> -root /usr/lib/erlang -progname e'.
> Program terminated with signal 11, Segmentation fault.
> [New process 11376]
> [New process 11387]
> [New process 11366]
> [New process 11373]
> [New process 11372]
> [New process 11370]
> [New process 11371]
> #0 ?0xf51e7a75 in WxeApp::dispatch_cb (this=0x8453398,
> batch=0x84942b0, temp=0x8494240, process=835)
> ? ?at wxe_impl.cpp:411
> 411 ? ? ? ? ? ? ? if(event->caller == process || ?// Callbacks from CB
> process only
> (gdb) bt
> #0 ?0xf51e7a75 in WxeApp::dispatch_cb (this=0x8453398,
> batch=0x84942b0, temp=0x8494240, process=835)
> ? ?at wxe_impl.cpp:411
> #1 ?0xf51e7c0a in handle_event_callback (port=0x240, process=643) at
> wxe_impl.cpp:306
> #2 ?0xf528d0cc in sendevent (event=0xf2c81ab4, port=0x240) at
> gen/wxe_events.cpp:821
> #3 ?0xf528e496 in wxeEvtListener::forward (this=0x857ece0,
> event=@0xf2c81ab4) at gen/wxe_events.cpp:328
> #4 ?0xf49e77f1 in wxAppConsole::HandleEvent () from
> /usr/lib/libwx_baseu-2.8.so.0
> #5 ?0xf4a849ca in wxEvtHandler::ProcessEventIfMatches () from
> /usr/lib/libwx_baseu-2.8.so.0
> #6 ?0xf4a84b56 in wxEvtHandler::SearchDynamicEventTable () from
> /usr/lib/libwx_baseu-2.8.so.0
> #7 ?0xf4a85c8d in wxEvtHandler::ProcessEvent () from
> /usr/lib/libwx_baseu-2.8.so.0
> #8 ?0xf4c45fd0 in wxWindow::GtkSendPaintEvents () from
> /usr/lib/libwx_gtk2u_core-2.8.so.0
> #9 ?0xf4c4658d in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
> #10 0xf45e6816 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #11 0x084aa220 in ?? ()
> #12 0xf2c82070 in ?? ()
> #13 0x085ec2f8 in ?? ()
> #14 0xf4398678 in ?? () from /usr/lib/libgobject-2.0.so.0
> #15 0x0857ee30 in ?? ()
> #16 0x0857f320 in ?? ()
> #17 0xf2c81c18 in ?? ()
> #18 0xf436790b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
> Backtrace stopped: frame did not save the PC
> Current language: ?auto; currently c++
> (gdb) print event
> $1 = (wxeCommand *) 0xf11023e8
> (gdb) print event->caller
> $2 = 611
> (gdb) print process
> $3 = 835
> (gdb) print event->op
> $4 = 10
> (gdb) print memenv
> $5 = (wxeMemEnv *) 0x0
> (gdb) print event->port
> $6 = (ErlDrvPort) 0x23f
> (gdb)
>
> All observed segfaults were at the same place in WxeApp::dispatch_cb() function.
>
> (The Erlang was built without Debian-specific patches and with symbols enabled.)
>
> Cheers!
> --
> Sergei Golovan
>
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>
>

From rickard@REDACTED  Mon Aug 16 11:51:15 2010
From: rickard@REDACTED (Rickard Green)
Date: Mon, 16 Aug 2010 11:51:15 +0200
Subject: beam.smp segfault if there are disabled cpu cores
Message-ID: <4C690A13.3050609@erlang.org>

Konstantin Nikiforov wrote:
> Archlinux x86_64
> 
> Steps to demonstrate the segfault:
> 
> 0) starting erlang
> $ erl
> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2]
> [async-threads:0] [hipe] [kernel-poll:false]
> 
> Eshell V5.7.5  (abort with ^G)
> 1>
> 
> 
> 1) disabling one of two cpu cores in power-saving purposes
> echo 0 > /sys/devices/system/cpu/cpu1/online
> 
> 
> 2) starting erlang
> $ erl
> zsh: segmentation fault  erl
> $ dmesg
> ...
> CPU 1 is now offline
> SMP alternatives: switching to UP code
> beam.smp[14894]: segfault at 7f07a9d3e560 ip 00000000004403f8 sp
> 00007fff336e70e0 error 6 in beam.smp[400000+1dc000]
> 
> 
> 3) enabling cpu core back
> echo 1 > /sys/devices/system/cpu/cpu1/online
> 
> 
> 4) starting erlang
> $ erl
> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2]
> [async-threads:0] [hipe] [kernel-poll:false]
> 
> Eshell V5.7.5  (abort with ^G)
> 1>
> 
> 
> All ok then all CPU cores enabled. CPU cores goes to offline automatically
> in linux notebooks to minimize power consumption then AC plug off.
> 

This bug has been fixed in R14A. The fix can be found in our github 
repository at 
<http://github.com/erlang/otp/commit/943ad16fa4b6335b6e170cc94fc7df9041ff4e47>.

Regards,
Rickard Green
-- 
Rickard Green, Erlang/OTP, Ericsson AB.

From lars@REDACTED  Tue Aug 17 10:22:03 2010
From: lars@REDACTED (Lars Thorsen)
Date: Tue, 17 Aug 2010 10:22:03 +0200
Subject: [erlang-bugs] Wrong transform of eunit docs from edoc to html
In-Reply-To: <AANLkTi=Mo=zSmC+EyR_309bKkpuizXO3L-u1Lb_MhznO@mail.gmail.com>
References: <AANLkTi=Mo=zSmC+EyR_309bKkpuizXO3L-u1Lb_MhznO@mail.gmail.com>
Message-ID: <4C6A46AB.4010308@erix.ericsson.se>

Tuncer Ayaz wrote:
> Part of lib/eunit/doc/overview.edoc happens to be transformed into
> mis-formatted html. Is this a problem in the edoc source or the
> transformation process?
> 
> Is this a problem in xsltproc, edoc, or the edoc sources?
> 
> The following source from lib/eunit/doc/overview.edoc
> 
> --->8---
> To make the descriptions simpler, we first list some definitions:
> <center>
> <table border="0" cellspacing="4">
> <tr>
> <td>`Setup'</td><td>`() -> (R::any())'</td>
> </tr>
> <tr>
> <td>`SetupX'</td><td>`(X::any()) -> (R::any())'</td>
> </tr>
> <tr>
> <td>`Cleanup'</td><td>`(R::any()) -> any()'</td>
> </tr>
> <tr>
> <td>`CleanupX'</td><td>`(X::any(), R::any()) -> any()'</td>
> </tr>
> <tr>
> <td>`Instantiator'</td><td>`((R::any()) -> Tests) | {with,
> [AbstractTestFun::((any()) -> any())]}'</td>
> </tr>
> <tr>
> <td>`Where'</td><td>`local | spawn | {spawn, Node::atom()}'</td>
> </tr>
> </table>
> </center>
> (these are explained in more detail further below.)
> --->8---
>

Thanks for reporting this.

The center tag was wrongly matched in two different clauses in
the special edoc backend which generates xml from the edoc format.

This will be fixed in R14B.

------------
Lars Thorsen, Erlang/OTP, Ericsson AB

From ingela@REDACTED  Wed Aug 18 09:44:07 2010
From: ingela@REDACTED (Ingela Anderton Andin)
Date: Wed, 18 Aug 2010 09:44:07 +0200
Subject: [erlang-bugs] Can't connect to smtp.gmail.com via SSL in R14
In-Reply-To: <20100813180122.GL14935@hijacked.us>
References: <20100813180122.GL14935@hijacked.us>
Message-ID: <4C6B8F47.40509@erix.ericsson.se>

Hi!

Thank you for reporting this we will look further into this, I managed 
to repeat it from home but
currently I can not do it from work due to our firewall.  A work around 
for the moment would
be to use {ssl_impl, old}.

Regards Ingela Erlang/OTP team - Ericsson AB

Andrew Thompson wrote:
> So, when I try to connect to the SSL SMTP socket for gmail, I get this
> failure:
>
> Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:4:4] [rq:4]
> [async-threads:0] [hipe] [kernel-poll:false]
>
> Eshell V5.8.1  (abort with ^G)
> 1> application:start(crypto).
> ok
> 2> application:start(public_key).
> ok
> 3> application:start(ssl).
> ok
> 4> ssl:connect("smtp.gmail.com", 465, []).
> {ok,{sslsocket,new_ssl,<0.51.0>}}
> 5> 
> =ERROR REPORT==== 13-Aug-2010::13:27:09 ===
> SSL: decipher_error: ./ssl_record.erl:648:Fatal error: bad record mac
> flush().
> Shell got {#Ref<0.0.0.59>,{error,"bad record mac"}}
> ok
>
>
> This happens with the R14A release, with the latest github/dev AND the
> latest github/pu branches on OSX. 
>
> It doesn't happen on R13b02 on another machine, there it works as
> expected. It should be pretty easy to reproduce without further
> information.
>
> Andrew
>
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>
>   


From dgud@REDACTED  Thu Aug 19 10:47:11 2010
From: dgud@REDACTED (Dan Gudmundsson)
Date: Thu, 19 Aug 2010 10:47:11 +0200
Subject: [erlang-bugs] Segmentation fault in wxErlang
In-Reply-To: <AANLkTiku5KS+37hppB1t44MJLuLqeHxGhhvHUkqfK7BE@mail.gmail.com>
References: <AANLkTikG6js9XWX03eQ1cFgAo5JJ17BWduKTOC=XFppH@mail.gmail.com>
	<AANLkTiku5KS+37hppB1t44MJLuLqeHxGhhvHUkqfK7BE@mail.gmail.com>
Message-ID: <AANLkTimOtqf8iU2wj=_vb-wRTYh2eLk4Mgsiep_FmcD6@mail.gmail.com>

Fixed in dev OTP-8766.

This was also the bug (or one of) that caused the crashes for Li on windows,
reported in erlang-questions "On Windows XP (SP2): wx broken"

Thanks for the report and nice backtrace.

/Dan

On Sun, Aug 15, 2010 at 12:54 PM, Dan Gudmundsson <dgud@REDACTED> wrote:
> Thanks
> I will have a look at it.
>
> /Dan
>
> On Sun, Aug 15, 2010 at 12:02 PM, Sergei Golovan <sgolovan@REDACTED> wrote:
>> Hi!
>>
>> A Debian user recently found a bug in wxErlang (in the current Erlang
>> R14A). It consistently segfaults when playing with sudoku demo.
>>
>> I couldn't reproduce it with my default SMP settings (+S 8) but it
>> breaks soon (in a few minutes) after the application start and
>> interacting with the game field if Erlang VM is started with +S 1
>> option.
>>
>> So, I run
>>
>> % erl -pa /usr/lib/erlang/lib/wx-0.98.6/examples/sudoku +S 1
>> Erlang R14A (erts-5.8) [source] [smp:1:1] [rq:1] [async-threads:0]
>> [kernel-poll:false]
>>
>> Eshell V5.8 ?(abort with ^G)
>> 1> sudoku:start().
>> <0.34.0>
>> sudoku:40: Time: 3556875
>> Below level 39 40
>> Below level 34 35
>> Below level 29 30
>> Below level 24 25
>> No left 24
>>
>> Then I start playing, putting numbers there and there...
>> After a while:
>>
>> 2> zsh: segmentation fault (core dumped) ?erl -pa
>> /usr/lib/erlang/lib/wx-0.98.6/examples/sudoku +S 1
>>
>> Below is a GDB session listing. I would be glad to provide any
>> additional info if required.
>>
>> Core was generated by `/usr/lib/erlang/erts-5.8/bin/beam.smp -S 1 --
>> -root /usr/lib/erlang -progname e'.
>> Program terminated with signal 11, Segmentation fault.
>> [New process 11376]
>> [New process 11387]
>> [New process 11366]
>> [New process 11373]
>> [New process 11372]
>> [New process 11370]
>> [New process 11371]
>> #0 ?0xf51e7a75 in WxeApp::dispatch_cb (this=0x8453398,
>> batch=0x84942b0, temp=0x8494240, process=835)
>> ? ?at wxe_impl.cpp:411
>> 411 ? ? ? ? ? ? ? if(event->caller == process || ?// Callbacks from CB
>> process only
>> (gdb) bt
>> #0 ?0xf51e7a75 in WxeApp::dispatch_cb (this=0x8453398,
>> batch=0x84942b0, temp=0x8494240, process=835)
>> ? ?at wxe_impl.cpp:411
>> #1 ?0xf51e7c0a in handle_event_callback (port=0x240, process=643) at
>> wxe_impl.cpp:306
>> #2 ?0xf528d0cc in sendevent (event=0xf2c81ab4, port=0x240) at
>> gen/wxe_events.cpp:821
>> #3 ?0xf528e496 in wxeEvtListener::forward (this=0x857ece0,
>> event=@0xf2c81ab4) at gen/wxe_events.cpp:328
>> #4 ?0xf49e77f1 in wxAppConsole::HandleEvent () from
>> /usr/lib/libwx_baseu-2.8.so.0
>> #5 ?0xf4a849ca in wxEvtHandler::ProcessEventIfMatches () from
>> /usr/lib/libwx_baseu-2.8.so.0
>> #6 ?0xf4a84b56 in wxEvtHandler::SearchDynamicEventTable () from
>> /usr/lib/libwx_baseu-2.8.so.0
>> #7 ?0xf4a85c8d in wxEvtHandler::ProcessEvent () from
>> /usr/lib/libwx_baseu-2.8.so.0
>> #8 ?0xf4c45fd0 in wxWindow::GtkSendPaintEvents () from
>> /usr/lib/libwx_gtk2u_core-2.8.so.0
>> #9 ?0xf4c4658d in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
>> #10 0xf45e6816 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
>> #11 0x084aa220 in ?? ()
>> #12 0xf2c82070 in ?? ()
>> #13 0x085ec2f8 in ?? ()
>> #14 0xf4398678 in ?? () from /usr/lib/libgobject-2.0.so.0
>> #15 0x0857ee30 in ?? ()
>> #16 0x0857f320 in ?? ()
>> #17 0xf2c81c18 in ?? ()
>> #18 0xf436790b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
>> Backtrace stopped: frame did not save the PC
>> Current language: ?auto; currently c++
>> (gdb) print event
>> $1 = (wxeCommand *) 0xf11023e8
>> (gdb) print event->caller
>> $2 = 611
>> (gdb) print process
>> $3 = 835
>> (gdb) print event->op
>> $4 = 10
>> (gdb) print memenv
>> $5 = (wxeMemEnv *) 0x0
>> (gdb) print event->port
>> $6 = (ErlDrvPort) 0x23f
>> (gdb)
>>
>> All observed segfaults were at the same place in WxeApp::dispatch_cb() function.
>>
>> (The Erlang was built without Debian-specific patches and with symbols enabled.)
>>
>> Cheers!
>> --
>> Sergei Golovan
>>
>> ________________________________________________________________
>> erlang-bugs (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>>
>>
>

From vincent.dephily@REDACTED  Fri Aug 20 13:36:29 2010
From: vincent.dephily@REDACTED (Vincent de Phily)
Date: Fri, 20 Aug 2010 13:36:29 +0200
Subject: asn1 uper en/decoding of constrained numbers
Message-ID: <201008201336.29493.vincent.dephily@mobile-devices.fr>

asn1rt_uper_bin:num_bits/1 can give wrong results for values above 1024. To be 
precice, all values matching (2^N + 1) when N >= 10 give a result that is too 
low by 1.

The end result is that for example this asn1 grammar:
MyInt11 ::= INTEGER(0..1024)
will be encoded (and decoded) using 10 bits instead of 11, and the encoded 
value "1024" will be decoded as "0".


The least-disruptive fix is to change the last clause of num_bits/1 like this:
num_bits(R) ->
   1+num_bits((R+1) bsr 1).

But I find the logic a bit obscure. Here's one that I find more readable 
(YMMV), and is also faster for big numbers (slower for small ones) :
num_bits(N) -> num_bits(N, 1, 0).                                                                                                                                                            
num_bits(N, T, B) when N =< T -> B;                                                                                                                                                          
num_bits(N, T, B) -> num_bits(N, T bsl 1, B + 1).


Of course, ideally num_bits/1 should only be called at compiletime, not 
runtime as is currently the case, so that execution speed does not matter :p




Sorry for not providing a proper patch and a place to pull from, but time to 
do this always get preempted by more important stuff, and this is such a 
simple bug that I think an email would suffice.



Cheers.
-- 
Vincent de Phily
-------------- next part --------------
A non-text attachment was scrubbed...
Name: num_bits.es
Type: application/ecmascript
Size: 1128 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100820/8d149758/attachment.bin>

From kenneth.lundin@REDACTED  Fri Aug 20 15:21:37 2010
From: kenneth.lundin@REDACTED (Kenneth Lundin)
Date: Fri, 20 Aug 2010 15:21:37 +0200
Subject: [erlang-bugs] asn1 uper en/decoding of constrained numbers
In-Reply-To: <201008201336.29493.vincent.dephily@mobile-devices.fr>
References: <201008201336.29493.vincent.dephily@mobile-devices.fr>
Message-ID: <AANLkTimVwhx2G6ErgDEmwNpxnx4wgJgfkFr93PDhWkQ2@mail.gmail.com>

Tanks for the report, I will take a look at this.

/Regards Kenneth Erlang/OTP, Ericsson

On Fri, Aug 20, 2010 at 1:36 PM, Vincent de Phily
<vincent.dephily@REDACTED> wrote:
> asn1rt_uper_bin:num_bits/1 can give wrong results for values above 1024. To be
> precice, all values matching (2^N + 1) when N >= 10 give a result that is too
> low by 1.
>
> The end result is that for example this asn1 grammar:
> MyInt11 ::= INTEGER(0..1024)
> will be encoded (and decoded) using 10 bits instead of 11, and the encoded
> value "1024" will be decoded as "0".
>
>
> The least-disruptive fix is to change the last clause of num_bits/1 like this:
> num_bits(R) ->
> ? 1+num_bits((R+1) bsr 1).
>
> But I find the logic a bit obscure. Here's one that I find more readable
> (YMMV), and is also faster for big numbers (slower for small ones) :
> num_bits(N) -> num_bits(N, 1, 0).
> num_bits(N, T, B) when N =< T -> B;
> num_bits(N, T, B) -> num_bits(N, T bsl 1, B + 1).
>
>
> Of course, ideally num_bits/1 should only be called at compiletime, not
> runtime as is currently the case, so that execution speed does not matter :p
>
>
>
>
> Sorry for not providing a proper patch and a place to pull from, but time to
> do this always get preempted by more important stuff, and this is such a
> simple bug that I think an email would suffice.
>
>
>
> Cheers.
> --
> Vincent de Phily
>
>
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>

From pguyot@REDACTED  Fri Aug 20 15:21:43 2010
From: pguyot@REDACTED (Paul Guyot)
Date: Fri, 20 Aug 2010 15:21:43 +0200
Subject: Fix crypto:rc4_encrypt_with_state/2 (Gmail SSL issue)
Message-ID: <BAA272BD-FBEB-44AE-82C2-F01581E55C81@kallisys.net>

Hello,

There is a simple bug in crypto:rc4_encrypt_with_state/2 NIF binding. As a result, RC4 stream cipher does not work, and one cannot connect to SSL servers that want to use an RC4 cipher suite (e.g. smtp.gmail.com).

The fix is available here, with a non-regression test:
git fetch git://github.com/pguyot/otp.git pg/fix-crypto-rc4_encrypt_with_state
http://github.com/pguyot/otp/commit/c1af26a59c46a6f9d295a0374326574157f6d8a5

Regards,

Paul
-- 
Semiocast                    http://semiocast.com/
+33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris


From bgustavsson@REDACTED  Fri Aug 20 15:39:20 2010
From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=)
Date: Fri, 20 Aug 2010 15:39:20 +0200
Subject: [erlang-bugs] Fix crypto:rc4_encrypt_with_state/2 (Gmail SSL issue)
In-Reply-To: <BAA272BD-FBEB-44AE-82C2-F01581E55C81@kallisys.net>
References: <BAA272BD-FBEB-44AE-82C2-F01581E55C81@kallisys.net>
Message-ID: <AANLkTi=5ua3MiTat6pD3UKT87HRtHArMpHCJpVdcgWp-@mail.gmail.com>

On Fri, Aug 20, 2010 at 3:21 PM, Paul Guyot <pguyot@REDACTED> wrote:
> Hello,
>
> There is a simple bug in crypto:rc4_encrypt_with_state/2 NIF binding. As a result, RC4 stream cipher does not work, and one cannot connect to SSL servers that want to use an RC4 cipher suite (e.g. smtp.gmail.com).
>
> The fix is available here, with a non-regression test:
> git fetch git://github.com/pguyot/otp.git pg/fix-crypto-rc4_encrypt_with_state
> http://github.com/pguyot/otp/commit/c1af26a59c46a6f9d295a0374326574157f6d8a5

Thanks! Included in pu.

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

From ingela@REDACTED  Fri Aug 20 16:05:42 2010
From: ingela@REDACTED (Ingela Anderton Andin)
Date: Fri, 20 Aug 2010 16:05:42 +0200
Subject: [erlang-bugs] Can't connect to smtp.gmail.com via SSL in R14
In-Reply-To: <4C6B8F47.40509@erix.ericsson.se>
References: <20100813180122.GL14935@hijacked.us> <4C6B8F47.40509@erix.ericsson.se>
Message-ID: <4C6E8BB6.3070307@erix.ericsson.se>

Hi!

I have been looking into this and I have all reasons to belive
this is the same problem as reported  by: [erlang-bugs] Fix 
crypto:rc4_encrypt_with_state/2 (Gmail SSL issue)

Regards Ingela Erlang/OTP team - Ericsson AB

Ingela Anderton Andin wrote:
> Hi!
>
> Thank you for reporting this we will look further into this, I managed 
> to repeat it from home but
> currently I can not do it from work due to our firewall.  A work 
> around for the moment would
> be to use {ssl_impl, old}.
>
> Regards Ingela Erlang/OTP team - Ericsson AB
>
> Andrew Thompson wrote:
>> So, when I try to connect to the SSL SMTP socket for gmail, I get this
>> failure:
>>
>> Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:4:4] [rq:4]
>> [async-threads:0] [hipe] [kernel-poll:false]
>>
>> Eshell V5.8.1  (abort with ^G)
>> 1> application:start(crypto).
>> ok
>> 2> application:start(public_key).
>> ok
>> 3> application:start(ssl).
>> ok
>> 4> ssl:connect("smtp.gmail.com", 465, []).
>> {ok,{sslsocket,new_ssl,<0.51.0>}}
>> 5> =ERROR REPORT==== 13-Aug-2010::13:27:09 ===
>> SSL: decipher_error: ./ssl_record.erl:648:Fatal error: bad record mac
>> flush().
>> Shell got {#Ref<0.0.0.59>,{error,"bad record mac"}}
>> ok
>>
>>
>> This happens with the R14A release, with the latest github/dev AND the
>> latest github/pu branches on OSX.
>> It doesn't happen on R13b02 on another machine, there it works as
>> expected. It should be pretty easy to reproduce without further
>> information.
>>
>> Andrew
>>
>> ________________________________________________________________
>> erlang-bugs (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>>
>>   
>
>
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>


From tuncer.ayaz@REDACTED  Fri Aug 20 16:57:29 2010
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Fri, 20 Aug 2010 16:57:29 +0200
Subject: [erlang-bugs] SSL Problems with R14A
In-Reply-To: <alpine.LNX.2.00.1007222348510.21629@dakota>
References: <alpine.LNX.2.00.1007221731580.2650@dakota> <AANLkTikPNE0w6rZ9Onq1p-Rw_seSzBs-MTaHXcDFCF7R@mail.gmail.com>
 <alpine.LNX.2.00.1007222348510.21629@dakota>
Message-ID: <AANLkTins1cqNNicfwMMwtd1ERCgt92QdTcKh=jnuOwji@mail.gmail.com>

On Fri, Jul 23, 2010 at 12:52 AM, Alexandru Scvor?ov wrote:
>
>
> On Thu, 22 Jul 2010, Tuncer Ayaz wrote:
>
>> I think it's the same issue as in
>> http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:52313:201007:mohnjgfideamidobdnhk
>>
>
> I don't think so. ?The error isn't raised by the padding checks (as in
> that bug); it's raised when checking the Mac against the MacHash.
>
> I don't claim to know what's happening but it appears to be miscalculating
> a checksum.

Haven't tested myself yet, but this rather looks like the bug which
has been fixed
by "[erlang-bugs] Fix crypto:rc4_encrypt_with_state/2 (Gmail SSL issue)".

From matthew@REDACTED  Fri Aug 20 17:42:43 2010
From: matthew@REDACTED (Matthew Sackman)
Date: Fri, 20 Aug 2010 16:42:43 +0100
Subject: [erlang-bugs] Supervisor.erl erroreously removes the
 child_spec on reaching max_restart_intensity
In-Reply-To: <20100809154112.GA16223@rabbitmq.com>
References: <20100809154112.GA16223@rabbitmq.com>
Message-ID: <20100820154243.GA25761@rabbitmq.com>

Hello? Anyone out there who looks after supervisor?

On Mon, Aug 09, 2010 at 04:41:12PM +0100, Matthew Sackman wrote:
> It doesn't actually cause a crash, but in the following:
> 
> restart(Child, State) ->
>     case add_restart(State) of
> 	{ok, NState} ->
> 	    restart(NState#state.strategy, Child, NState, fun restart/2);
> 	{terminate, NState} ->
> 	    report_error(shutdown, reached_max_restart_intensity,
> 			 Child, State#state.name),
> 	    {shutdown, remove_child(Child, NState)}
>     end.
> 
> the call to remove_child is wrong. It removes the child spec. In the
> case of a simple_one_for_one, that then means that in terminate, we have
> a pid in the dynamics dictionary, but no child spec at all, whilst in
> the case of non simple_one_for_one the spec is simply not there.
> 
> This doesn't cause any crashes, but it means the state is inconsistent
> in the subsequent terminate function. It should be a call to
> state_del_child (blank the child pid in the non-simple case, or remove
> the pid from the dynamics dict for the simple case).
> 
> Matthew
> 
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
> 

From matthew@REDACTED  Fri Aug 20 17:43:50 2010
From: matthew@REDACTED (Matthew Sackman)
Date: Fri, 20 Aug 2010 16:43:50 +0100
Subject: [erlang-bugs] Supervisor.erl erroreously reports error when
 child exits with normal during shutdown
In-Reply-To: <20100812113218.GI16223@rabbitmq.com>
References: <20100812113218.GI16223@rabbitmq.com>
Message-ID: <20100820154350.GB25761@rabbitmq.com>

Again, is there anyone who can look at this?

On Thu, Aug 12, 2010 at 12:32:18PM +0100, Matthew Sackman wrote:
> (You can guess what I'm hacking on atm...)
> 
> In supervisor, when it terminates a child, if that child happens to have
> exited fractionally early, with normal, the supervisor reports this as
> an error.
> 
> For permanent children, that's likely the right thing to do, but for all
> other types of children it's wrong and leads to polluted logs. Both
> temporary and transient children do not get restarted on normal
> self-destruction, and nor do they get logged about. Just because they
> happen to destruct as the supervisor is trying to stop them shouldn't
> alter this.
> 
> Diff attached.
> 
> Matthew

> --- /usr/local/lib/erlang/lib/stdlib-1.17/src/supervisor.erl	2010-07-22 14:27:32.000000000 +0100
> +++ supervisor.erl	2010-08-12 12:31:32.000000000 +0100
> @@ -660,14 +660,15 @@
>      Res.
>  
>  do_terminate(Child, SupName) when Child#child.pid =/= undefined ->
> -    case shutdown(Child#child.pid,
> -		  Child#child.shutdown) of
> -	ok ->
> -	    Child#child{pid = undefined};
> -	{error, OtherReason} ->
> -	    report_error(shutdown_error, OtherReason, Child, SupName),
> -	    Child#child{pid = undefined}
> -    end;
> +    case shutdown(Child#child.pid, Child#child.shutdown) of
> +        ok ->
> +            ok;
> +        {error, normal} when Child#child.restart_type =/= permanent ->
> +            ok;
> +        {error, OtherReason} ->
> +            report_error(shutdown_error, OtherReason, Child, SupName)
> +    end,
> +    Child#child{pid = undefined};
>  do_terminate(Child, _SupName) ->
>      Child.
>  
> 

> 
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED


From andrew@REDACTED  Sun Aug 22 03:11:48 2010
From: andrew@REDACTED (Andrew Thompson)
Date: Sat, 21 Aug 2010 21:11:48 -0400
Subject: [erlang-bugs] Can't connect to smtp.gmail.com via SSL in R14
In-Reply-To: <4C6E8BB6.3070307@erix.ericsson.se>
References: <20100813180122.GL14935@hijacked.us> <4C6B8F47.40509@erix.ericsson.se> <4C6E8BB6.3070307@erix.ericsson.se>
Message-ID: <20100822011148.GO18924@hijacked.us>

On Fri, Aug 20, 2010 at 04:05:42PM +0200, Ingela Anderton Andin wrote:
> Hi!
> 
> I have been looking into this and I have all reasons to belive
> this is the same problem as reported  by: [erlang-bugs] Fix 
> crypto:rc4_encrypt_with_state/2 (Gmail SSL issue)
>

Yes, this fixes the bug. +1 for putting it into R14B.

Andrew

From hans.bolinder@REDACTED  Mon Aug 23 08:46:55 2010
From: hans.bolinder@REDACTED (Hans Bolinder)
Date: Mon, 23 Aug 2010 08:46:55 +0200
Subject: [erlang-bugs] Bug in HiPE compiled compiler
In-Reply-To: <4C34305F.2060105@cs.ntua.gr>
References: <850646195.570961278415308824.JavaMail.root@zimbra>
	<4C34305F.2060105@cs.ntua.gr>
Message-ID: <19570.6495.567919.127333@ornendil.du.uab.ericsson.se>

[Adam Lindberg:]
> The following module produces a compiler error in R13B03 and R13B04:
> ...

[Kostis Sagonas:]
> The good news is that there is no problem in the code generated by the 
> hipe compiler.
> 
> Instead, the problem is that the code of yeccpre.hrl heavily relies on 
> generated exceptions having stack traces of particular forms, which is 
> currently not something that native code guarantees.

Thanks for pointing this out. The problem will be fixed in R14B.

Best regards,

Hans Bolinder, Erlang OTP team, Ericsson

From nicolas@REDACTED  Tue Aug 24 11:05:08 2010
From: nicolas@REDACTED (Nicolas Niclausse)
Date: Tue, 24 Aug 2010 11:05:08 +0200
Subject: ssl handshake failure on R14A (and git)
Message-ID: <4C738B44.4050808@niclux.org>

I'm not able to connect to a server using ssl v4.0 (R14A) and up (current git)

Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:2:2] [rq:2]
[async-threads:0] [hipe] [kernel-poll:false]

4> ssl:connect("jabber.grid5000.fr",5223,[]).

=ERROR REPORT==== 24-Aug-2010::10:56:37 ===
SSL: hello: ./ssl_handshake.erl:830:Fatal error: handshake failure
{error,esslconnect}

but it works with old ssl:

5> ssl:connect("jabber.grid5000.fr",5223,[{ssl_imp,old}]).
{ok,{sslsocket,5,<0.57.0>}}

-- 
Nicolas

From ingela@REDACTED  Tue Aug 24 12:04:45 2010
From: ingela@REDACTED (Ingela Anderton Andin)
Date: Tue, 24 Aug 2010 12:04:45 +0200
Subject: [erlang-bugs] ssl handshake failure on R14A (and git)
In-Reply-To: <4C738B44.4050808@niclux.org>
References: <4C738B44.4050808@niclux.org>
Message-ID: <4C73993D.6070807@erix.ericsson.se>

Hi!

I am not able to test this from work due to the firewall.     
What does ssl:connection_info/1 return when you connect using
{ssl_imp, old} ?

Regards Ingela Erlang/OTP team - Ericsson AB

Nicolas Niclausse wrote:
> I'm not able to connect to a server using ssl v4.0 (R14A) and up (current git)
>
> Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:2:2] [rq:2]
> [async-threads:0] [hipe] [kernel-poll:false]
>
> 4> ssl:connect("jabber.grid5000.fr",5223,[]).
>
> =ERROR REPORT==== 24-Aug-2010::10:56:37 ===
> SSL: hello: ./ssl_handshake.erl:830:Fatal error: handshake failure
> {error,esslconnect}
>
> but it works with old ssl:
>
> 5> ssl:connect("jabber.grid5000.fr",5223,[{ssl_imp,old}]).
> {ok,{sslsocket,5,<0.57.0>}}
>
>   


From nicolas@REDACTED  Tue Aug 24 12:37:58 2010
From: nicolas@REDACTED (Nicolas Niclausse)
Date: Tue, 24 Aug 2010 12:37:58 +0200
Subject: [erlang-bugs] ssl handshake failure on R14A (and git)
In-Reply-To: <4C73993D.6070807@erix.ericsson.se>
References: <4C738B44.4050808@niclux.org> <4C73993D.6070807@erix.ericsson.se>
Message-ID: <4C73A106.8030204@niclux.org>

Ingela Anderton Andin ecrivait le 24/08/2010 12:04:
> Hi!
> 
> I am not able to test this from work due to the firewall.     What does
> ssl:connection_info/1 return when you connect using
> {ssl_imp, old} ?

Hello,

{ok,{tlsv1,"EDH-RSA-DES-CBC3-SHA"}}


-- 
Nicolas

From andrew@REDACTED  Tue Aug 24 19:27:10 2010
From: andrew@REDACTED (Andrew Thompson)
Date: Tue, 24 Aug 2010 13:27:10 -0400
Subject: [erlang-bugs] ssl handshake failure on R14A (and git)
In-Reply-To: <4C73A106.8030204@niclux.org>
References: <4C738B44.4050808@niclux.org> <4C73993D.6070807@erix.ericsson.se> <4C73A106.8030204@niclux.org>
Message-ID: <20100824172710.GI14928@hijacked.us>

On Tue, Aug 24, 2010 at 12:37:58PM +0200, Nicolas Niclausse wrote:
> Ingela Anderton Andin ecrivait le 24/08/2010 12:04:
> > Hi!
> > 
> > I am not able to test this from work due to the firewall.     What does
> > ssl:connection_info/1 return when you connect using
> > {ssl_imp, old} ?
> 
> Hello,
> 
> {ok,{tlsv1,"EDH-RSA-DES-CBC3-SHA"}}
> 
> 

Try with the 'pu' git branch and not 'dev', there's some SSL fixes in
there that helped with my problem.

Andrew

From vinoski@REDACTED  Wed Aug 25 07:28:00 2010
From: vinoski@REDACTED (Steve Vinoski)
Date: Wed, 25 Aug 2010 01:28:00 -0400
Subject: R14A can't cross-compile due to ssl certs examples
Message-ID: <AANLkTi=S6OHyq7JfwaVgPmfi=pXEJO6NZPCqJQziVMsY@mail.gmail.com>

Cross-building the current dev branch of R14A fails due to the
lib/ssl/examples/certs directory. It tries to run the openssl command
based on the target architecture rather than the build architecture.

In erts/configure.in at line 3608, we have this:

                    if test "$cross_compiling" = "yes"; then
                        dnl Cannot test it; hope it is working...
                        OPENSSL_CMD="$SSL_BINDIR/openssl"

which can't work if the openssl executable was built for the target
architecture and so can't execute on the build architecture.

IMO it would be nice if one could just override OPENSSL_CMD in the
xcomp file or even with an environment variable.

--steve

From ulf.norell@REDACTED  Wed Aug 25 09:41:37 2010
From: ulf.norell@REDACTED (Ulf Norell)
Date: Wed, 25 Aug 2010 09:41:37 +0200
Subject: ct:run_testspec/1 broken in R14A
Message-ID: <AANLkTin07aG96CRsLe2qYw30VBNGa2yy_qN5KAN+eSX3@mail.gmail.com>

The culprit seems to be line 1141 in ct_run.erl:

  log_ts_names(Opts1#opts.testspecs),

log_ts_names/1 expects a list of strings but is getting the testspec given
to ct:run_testspec/1. Here's what happens:

Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe]
[kernel-poll:false]

Eshell V5.8  (abort with ^G)
1> ct:run_testspec([{suites, ".", all}]).

Common Test starting (cwd is /tmp/test)


Common Test: Running make in test directories...


ct_util_server got EXIT from <0.39.0>: {badarg,
                                        [{io,format,
                                          [<0.44.0>,"~s",
                                           [[{suites,".",all},32]]]},
                                         {ct_logs,
                                          '-logger_loop/1-lc$^1/1-0-',2},
                                         {ct_logs,logger_loop,1}]}

** exception exit: badarg
     in function  io:format/3
        called as io:format(<0.44.0>,"~s",[[{suites,".",all},32]])
     in call from ct_logs:'-logger_loop/1-lc$^1/1-0-'/2
     in call from ct_logs:logger_loop/1

/ Ulf

From nicolas@REDACTED  Wed Aug 25 09:58:29 2010
From: nicolas@REDACTED (Nicolas Niclausse)
Date: Wed, 25 Aug 2010 09:58:29 +0200
Subject: [erlang-bugs] ssl handshake failure on R14A (and git)
In-Reply-To: <20100824172710.GI14928@hijacked.us>
References: <4C738B44.4050808@niclux.org> <4C73993D.6070807@erix.ericsson.se> <4C73A106.8030204@niclux.org> <20100824172710.GI14928@hijacked.us>
Message-ID: <4C74CD25.9070603@niclux.org>

Andrew Thompson ecrivait le 24/08/2010 19:27:
> On Tue, Aug 24, 2010 at 12:37:58PM +0200, Nicolas Niclausse wrote:
>> Ingela Anderton Andin ecrivait le 24/08/2010 12:04:
>>> Hi!
>>>
>>> I am not able to test this from work due to the firewall.     What does
>>> ssl:connection_info/1 return when you connect using
>>> {ssl_imp, old} ?
>>
>> Hello,
>>
>> {ok,{tlsv1,"EDH-RSA-DES-CBC3-SHA"}}
>>
>>
> 
> Try with the 'pu' git branch and not 'dev', there's some SSL fixes in
> there that helped with my problem.

Thanks for the tip, but the handshake problem is still there.

-- 
Nicolas

From bartosz.kolodziej@REDACTED  Wed Aug 25 18:31:55 2010
From: bartosz.kolodziej@REDACTED (=?UTF-8?Q?Bartosz_Ko=C5=82odziej?=)
Date: Wed, 25 Aug 2010 18:31:55 +0200
Subject: binary:matches/3 fails in R14A
Message-ID: <AANLkTin63VRia=nRbC4_1TzenCXK5YugtM099khWxO9q@mail.gmail.com>

binary:split/3 fails when option "global" is set and input is an empty
binary.

1> binary:split(<<>>,<<"a">>,[global]) gives:
** exception error: bad argument
     in function  binary:split/3

The problem lays in binary:matches/3 function:

2> binary:matches(<<>>,<<"a">>,[global]).
** exception error: bad argument
     in function  binary:matches/3
        called as binary:matches(<<>>,<<"a">>,[global])

Without "global" option it works just fine.

From michal.ptaszek@REDACTED  Thu Aug 26 08:44:40 2010
From: michal.ptaszek@REDACTED (Michal Ptaszek)
Date: Thu, 26 Aug 2010 06:44:40 +0000 (GMT)
Subject: SSL - can not verify server's certificate
In-Reply-To: <1170844481.739371282805060834.JavaMail.root@zimbra>
Message-ID: <1534575439.739391282805080930.JavaMail.root@zimbra>

Hello,

I am trying to set up a client-server application where client
communicates with the server using SSL connections. However,
I would like client to verify the server's certificate validity.

Configuration on the server side:
[{verify, verify_none},
 {certfile, PATH_TO_MY_CERT},
 {keyfile, PATH_TO_MY_KEY},
 {ssl_imp, new}]

Certificate is a self-signed, so the verification should fail.
Client's request:
ssl:connect(Host, Port, [{verify, 2}, {depth, 1}, {ssl_imp, new},
                         {fail_if_no_peer_cert, true},
                         {verify_fun, fun(Errors) -> io:format(user, "~p~n", [Errors]), false end},
                         {cacertfile, "/tmp/somecacert"}]).

Unfortunately, all connect attempts are succeeds.

However, if I change the 'verify' option on the server side to 'verify_peer', i.e.:
[{verify, verify_peer},
 {certfile, PATH_TO_MY_CERT},
 {keyfile, PATH_TO_MY_KEY},
 {ssl_imp, new}]

I am getting an error on the client side:
[{bad_cert,unknown_ca}]

=ERROR REPORT==== 25-Aug-2010::15:53:26 ===
SSL: certify_certificate: ./ssl_handshake.erl:528:Fatal error: handshake failure
{error,esslconnect}

Which is an expected behaviour. Moreover, if I provide a 'cacertfile'
with a server's PEM inside, verification is done correctly. Should not
client be server-setting agnostic?

The issue has been observed on R14A and R13B4
openssl version:
0.9.8k-7ubuntu8
uname -a:
Linux coltrane 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64 GNU/Linux

Nevertheless, I could not make old SSL verification work
on R12B5, R13B4 and R14A.

Best regards,
Michal Ptaszek

From ingela@REDACTED  Thu Aug 26 14:39:06 2010
From: ingela@REDACTED (Ingela Anderton Andin)
Date: Thu, 26 Aug 2010 14:39:06 +0200
Subject: [erlang-bugs] SSL - can not verify server's certificate
In-Reply-To: <1534575439.739391282805080930.JavaMail.root@zimbra>
References: <1534575439.739391282805080930.JavaMail.root@zimbra>
Message-ID: <4C76606A.5020108@erix.ericsson.se>

Hi!

Michal Ptaszek wrote:
> Hello,
>
> I am trying to set up a client-server application where client
> communicates with the server using SSL connections. However,
> I would like client to verify the server's certificate validity.
>
> Configuration on the server side:
> [{verify, verify_none},
>  {certfile, PATH_TO_MY_CERT},
>  {keyfile, PATH_TO_MY_KEY},
>  {ssl_imp, new}]
>
> Certificate is a self-signed, so the verification should fail.
> Client's request:
> ssl:connect(Host, Port, [{verify, 2}, {depth, 1}, {ssl_imp, new},
>                          {fail_if_no_peer_cert, true},
>                          {verify_fun, fun(Errors) -> io:format(user, "~p~n", [Errors]), false end},
>                          {cacertfile, "/tmp/somecacert"}]).
>
>   
To begin with I would like to point out that fail_if_no_peer_cert is a 
server option.

 From doc:

*"{fail_if_no_peer_cert, boolean()}*
    Used together with {verify, verify_peer} by a ssl server. If set to
    true, the server will fail if the client does not have a certificate
    to send, e.i sends a empty certificate, if set to false it will only
    fail if the client sends a invalid certificate (an empty certificate
    is considered valid)." 


{verify, 2} 

Works for backwards comparability reasons and should be equivalent to 
[{verify, verify_peer} , {fail_if_no_peer_cert, true}]

For the client to fail on certificate errors this can be done in two ways.

[{verify, verify_peer}] will fail the the client at all certificate path 
errors or [{verify, verify_none}, {verify_fun, Fun}]
will fail the client for all path validation errors of the applications 
choice. The default verify_fun will accept {bad_cert, unknown_ca}
errors. (On a side note, I now remember the reason is to try to  
resemble openssl)

> Unfortunately, all connect attempts are succeeds.
>
>   
This patch to public_key should help that problem.

index 95c3d71..06d8d2b 100644
--- a/lib/public_key/src/public_key.erl
+++ b/lib/public_key/src/public_key.erl
@@ -447,6 +447,21 @@ pkix_normalize_name(Issuer) ->
                                  {error, {bad_cert, Reason :: term()}}.
 %% Description: Performs a basic path validation according to RFC 5280.
 %%--------------------------------------------------------------------
+pkix_path_validation(#'OTPCertificate'{} = TrustedCert, [], Options) ->
+    case proplists:get_value(verify, Options, true) of
+       true ->
+           {error, {bad_cert, unknown_ca}};
+       false ->
+           DummyState = 
#path_validation_state{working_public_key_algorithm = 'NULL'},
+           #path_validation_state{working_public_key_algorithm
+                                  = Algorithm,
+                                  working_public_key = PublicKey,
+                                  working_public_key_parameters = 
PublicKeyParams
+                                 } =
+               pubkey_cert:prepare_for_next_cert(TrustedCert, DummyState),
+           {ok, {{Algorithm, PublicKey, PublicKeyParams}, [], 
[{bad_cert, unknown_ca}]}}
+    end;
+
 pkix_path_validation(TrustedCert, CertChain, Options)
   when is_binary(TrustedCert) ->
     OtpCert = pkix_decode_cert(TrustedCert, otp),


[...]

Regards Ingela Erlang/OTP team - Ericsson AB


From peppe@REDACTED  Thu Aug 26 16:16:44 2010
From: peppe@REDACTED (Peter Andersson)
Date: Thu, 26 Aug 2010 16:16:44 +0200
Subject: [erlang-bugs] ct:run_testspec/1 broken in R14A
In-Reply-To: <AANLkTin07aG96CRsLe2qYw30VBNGa2yy_qN5KAN+eSX3@mail.gmail.com>
References: <AANLkTin07aG96CRsLe2qYw30VBNGa2yy_qN5KAN+eSX3@mail.gmail.com>
Message-ID: <4C76774C.3020703@erix.ericsson.se>

Hi Ulf!

Thanks for the report! I'll look into this and get it fixed before R14B.

Regards,
Peter

Erlang/OTP, Ericsson AB

Ulf Norell wrote:
> The culprit seems to be line 1141 in ct_run.erl:
>
>   log_ts_names(Opts1#opts.testspecs),
>
> log_ts_names/1 expects a list of strings but is getting the testspec given
> to ct:run_testspec/1. Here's what happens:
>
> Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe]
> [kernel-poll:false]
>
> Eshell V5.8  (abort with ^G)
> 1> ct:run_testspec([{suites, ".", all}]).
>
> Common Test starting (cwd is /tmp/test)
>
>
> Common Test: Running make in test directories...
>
>
> ct_util_server got EXIT from <0.39.0>: {badarg,
>                                         [{io,format,
>                                           [<0.44.0>,"~s",
>                                            [[{suites,".",all},32]]]},
>                                          {ct_logs,
>                                           '-logger_loop/1-lc$^1/1-0-',2},
>                                          {ct_logs,logger_loop,1}]}
>
> ** exception exit: badarg
>      in function  io:format/3
>         called as io:format(<0.44.0>,"~s",[[{suites,".",all},32]])
>      in call from ct_logs:'-logger_loop/1-lc$^1/1-0-'/2
>      in call from ct_logs:logger_loop/1
>
> / Ulf
>
>   


From peppe@REDACTED  Fri Aug 27 17:33:28 2010
From: peppe@REDACTED (Peter Andersson)
Date: Fri, 27 Aug 2010 17:33:28 +0200
Subject: [erlang-bugs] ct:run_testspec/1 broken in R14A
In-Reply-To: <AANLkTin07aG96CRsLe2qYw30VBNGa2yy_qN5KAN+eSX3@mail.gmail.com>
References: <AANLkTin07aG96CRsLe2qYw30VBNGa2yy_qN5KAN+eSX3@mail.gmail.com>
Message-ID: <4C77DAC8.1000908@erix.ericsson.se>

Ulf,

I have a good memory, but it's terribly short unfortunately...

As it turns out, I had already found and corrected this bug during R14B
development. The fix is on the dev branch on github.

Again, thanks for reporting and sorry for the inconvenience!

  /Peter

Ulf Norell wrote:
> The culprit seems to be line 1141 in ct_run.erl:
>
>   log_ts_names(Opts1#opts.testspecs),
>
> log_ts_names/1 expects a list of strings but is getting the testspec given
> to ct:run_testspec/1. Here's what happens:
>
> Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe]
> [kernel-poll:false]
>
> Eshell V5.8  (abort with ^G)
> 1> ct:run_testspec([{suites, ".", all}]).
>
> Common Test starting (cwd is /tmp/test)
>
>
> Common Test: Running make in test directories...
>
>
> ct_util_server got EXIT from <0.39.0>: {badarg,
>                                         [{io,format,
>                                           [<0.44.0>,"~s",
>                                            [[{suites,".",all},32]]]},
>                                          {ct_logs,
>                                           '-logger_loop/1-lc$^1/1-0-',2},
>                                          {ct_logs,logger_loop,1}]}
>
> ** exception exit: badarg
>      in function  io:format/3
>         called as io:format(<0.44.0>,"~s",[[{suites,".",all},32]])
>      in call from ct_logs:'-logger_loop/1-lc$^1/1-0-'/2
>      in call from ct_logs:logger_loop/1
>
> / Ulf
>
>   


From Bernhard.Lichtinger@REDACTED  Fri Aug 27 16:23:07 2010
From: Bernhard.Lichtinger@REDACTED (Lichtinger, Bernhard)
Date: Fri, 27 Aug 2010 16:23:07 +0200
Subject: [erlang-bugs] ssl handshake failure on R14A (and git) 
Message-ID: <A3CC8149-2C20-4482-A629-707FFB4BED34@lrz.de>

Hi,

I had also the same problem. 
The debugger helped in my case: We have certificates with depth 4, so adding the ssl_option {depth,4} resolved the problem. 
e.g. ssl:connect("my-jabber-server",5223,[{depth,4}]).


But I'm still wondering, why ssl:connect without this option works also when i connect to one of our Microsoft IIS webservers, which has also a certificate of depth 4. My jabber server is an ejabberd on erlang R13. 

-- 
Bernhard

From Bernhard.Lichtinger@REDACTED  Mon Aug 30 15:51:42 2010
From: Bernhard.Lichtinger@REDACTED (Lichtinger, Bernhard)
Date: Mon, 30 Aug 2010 15:51:42 +0200
Subject: [erlang-bugs] ssl handshake failure on R14A (and git) 
In-Reply-To: <A3CC8149-2C20-4482-A629-707FFB4BED34@lrz.de>
References: <A3CC8149-2C20-4482-A629-707FFB4BED34@lrz.de>
Message-ID: <A18A6FB0-CE79-40F7-99A8-8638C7C75AE1@lrz.de>


> The debugger helped in my case: We have certificates with depth 4, so adding the ssl_option {depth,4} resolved the problem. 
> e.g. ssl:connect("my-jabber-server",5223,[{depth,4}]).
I did some more debugging:

SSL handshakes also fail with {bad_cert,invalid_subject_altname} if the server's certificate has an Subject Alternative Name of the type othername. E.g. hermes.jabber.org has such Subject Alternative Names.

-- 
Bernhard

From ingela@REDACTED  Mon Aug 30 16:16:38 2010
From: ingela@REDACTED (Ingela Anderton Andin)
Date: Mon, 30 Aug 2010 16:16:38 +0200
Subject: [erlang-bugs] ssl handshake failure on R14A (and git)
In-Reply-To: <4C738B44.4050808@niclux.org>
References: <4C738B44.4050808@niclux.org>
Message-ID: <4C7BBD46.8050501@erix.ericsson.se>

Hi!

We have located this bug and fixed it, it has to do with the fact that 
your server sends
several handshake protocol messages in the same TLS record protocol 
message, which is fine
and allowed but not all servers do. We had to move some of our code 
hinger up in our model to properly
handle this. We will push this to the public repository soon but due to 
some failing test cases it may be a couple
of days.

Regards Ingela Erlang/OTP team - Ericsson AB

Nicolas Niclausse wrote:
> I'm not able to connect to a server using ssl v4.0 (R14A) and up (current git)
>
> Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:2:2] [rq:2]
> [async-threads:0] [hipe] [kernel-poll:false]
>
> 4> ssl:connect("jabber.grid5000.fr",5223,[]).
>
> =ERROR REPORT==== 24-Aug-2010::10:56:37 ===
> SSL: hello: ./ssl_handshake.erl:830:Fatal error: handshake failure
> {error,esslconnect}
>
> but it works with old ssl:
>
> 5> ssl:connect("jabber.grid5000.fr",5223,[{ssl_imp,old}]).
> {ok,{sslsocket,5,<0.57.0>}}
>
>   


From ingela@REDACTED  Mon Aug 30 16:28:00 2010
From: ingela@REDACTED (Ingela Anderton Andin)
Date: Mon, 30 Aug 2010 16:28:00 +0200
Subject: [erlang-bugs] ssl handshake failure on R14A (and git)
In-Reply-To: <A3CC8149-2C20-4482-A629-707FFB4BED34@lrz.de>
References: <A3CC8149-2C20-4482-A629-707FFB4BED34@lrz.de>
Message-ID: <4C7BBFF0.8090000@erix.ericsson.se>

Hi!

Does not really sound like the same error.  Do you have any server to 
which we can connect to try and reproduce this?

Regards Ingela Erlang/OTP team - Ericsson AB

Lichtinger, Bernhard wrote:
> Hi,
>
> I had also the same problem. 
> The debugger helped in my case: We have certificates with depth 4, so adding the ssl_option {depth,4} resolved the problem. 
> e.g. ssl:connect("my-jabber-server",5223,[{depth,4}]).
>
>
> But I'm still wondering, why ssl:connect without this option works also when i connect to one of our Microsoft IIS webservers, which has also a certificate of depth 4. My jabber server is an ejabberd on erlang R13. 
>
>   


From kruber@REDACTED  Tue Aug 31 14:59:02 2010
From: kruber@REDACTED (Nico Kruber)
Date: Tue, 31 Aug 2010 14:59:02 +0200
Subject: nocatch error in dialyzer, R14A
Message-ID: <201008311459.09585.kruber@zib.de>

While I was trying to make a minimal example for another strange behaviour of 
the dialyzer I found the following bug calling

> dialyzer -Werror_handling -Wrace_conditions --src -c rec*.erl --no_native

with the attached files in the current directory:

  Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes
  Proceeding with analysis...
=ERROR REPORT==== 31-Aug-2010::14:53:04 ===
Error in process <0.29.0> with exit value: {{nocatch,{error,
[73,108,108,101,103,97,108,32,100,101,99,108,97,114,97,116,105,111,110,32,111,102,32,"rec2",35,123,"id",125,10]}},
[{erl_types,record_from_form,5},{erl_types,t_from_form,3},{erl_types,'-
t_opaque_from_records/1-anonymous-2-',3},{dict,map_bucket,2},
{dict,map_bkt_list,2},{dict... 


dialyzer: Analysis failed with error: {{nocatch,{error,
[73,108,108,101,103,97|...]}},
 [{erl_types,record_from_form,5},
  {erl_types,t_from_form,3},
  {erl_types,'-t_opaque_from_records/1-anonymous-2-',3},
  {dict,map_bucket,2},
  {dict,map_bkt_list,2},
  {dict,map_bkt_list,2},
  {dict,map_seg_list,...},
  {dict,...}]}
Last messages in the log cache:
  Reading files and computing callgraph... done in 0.06 secs
  Removing edges... done in 0.01 secs
  Typesig analysis for SCC: [{rec2,module_info,1}]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rec1.erl
Type: text/x-erlang
Size: 73 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/4b004812/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rec2.erl
Type: text/x-erlang
Size: 97 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/4b004812/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/4b004812/attachment-0002.bin>

From kruber@REDACTED  Tue Aug 31 15:02:10 2010
From: kruber@REDACTED (Nico Kruber)
Date: Tue, 31 Aug 2010 15:02:10 +0200
Subject: [erlang-bugs] nocatch error in dialyzer, R14A
In-Reply-To: <201008311459.09585.kruber@zib.de>
References: <201008311459.09585.kruber@zib.de>
Message-ID: <201008311502.10956.kruber@zib.de>

On Tuesday 31 August 2010 14:59:02 Nico Kruber wrote:
> While I was trying to make a minimal example for another strange behaviour
> of the dialyzer I found the following bug calling
> 
> > dialyzer -Werror_handling -Wrace_conditions --src -c rec*.erl --no_native
> 
> with the attached files in the current directory:
> 
>   Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes
>   Proceeding with analysis...
> =ERROR REPORT==== 31-Aug-2010::14:53:04 ===
> Error in process <0.29.0> with exit value: {{nocatch,{error,
> [73,108,108,101,103,97,108,32,100,101,99,108,97,114,97,116,105,111,110,32,1
> 11,102,32,"rec2",35,123,"id",125,10]}},
> [{erl_types,record_from_form,5},{erl_types,t_from_form,3},{erl_types,'-
> t_opaque_from_records/1-anonymous-2-',3},{dict,map_bucket,2},
> {dict,map_bkt_list,2},{dict...
> 
> 
> dialyzer: Analysis failed with error: {{nocatch,{error,
> [73,108,108,101,103,97|...]}},
>  [{erl_types,record_from_form,5},
>   {erl_types,t_from_form,3},
>   {erl_types,'-t_opaque_from_records/1-anonymous-2-',3},
>   {dict,map_bucket,2},
>   {dict,map_bkt_list,2},
>   {dict,map_bkt_list,2},
>   {dict,map_seg_list,...},
>   {dict,...}]}
> Last messages in the log cache:
>   Reading files and computing callgraph... done in 0.06 secs
>   Removing edges... done in 0.01 secs
>   Typesig analysis for SCC: [{rec2,module_info,1}]

I forgot to mention that if you replace opaque with type in rec2.erl, it works

Regards,
Nico Kruber
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/f3789563/attachment.bin>

From kruber@REDACTED  Tue Aug 31 15:26:11 2010
From: kruber@REDACTED (Nico Kruber)
Date: Tue, 31 Aug 2010 15:26:11 +0200
Subject: illegal declaration of pertially defined record types in dialyzer, R14A
Message-ID: <201008311526.18180.kruber@zib.de>

here's the other bug I originally intendet to report:

I declare a remote type rec1:rec1() in the rec1 module,
a record rec2 in module rec2 along with a rec2:rec2() type.

If I use the rec2:rec2() type in a third module, i.e. rec3, dialyzer reports 
an illegal declaration of rec2#{id}:

------------------------
> dialyzer -Werror_handling -Wrace_conditions --src -c rec*.erl --no_native
  Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes
  Proceeding with analysis...
dialyzer: Analysis failed with error: Illegal declaration of rec2#{id}

Last messages in the log cache:
  Reading files and computing callgraph... done in 0.06 secs
  Removing edges... done in 0.01 secs
------------------------

even if I put the record in a .hrl file and include it in both, rec2 and rec3, 
the error stays the same.
Syntax should be correct according to 
http://www.erlang.org/doc/reference_manual/typespec.html#id2272601

Regards
Nico Kruber
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rec1.erl
Type: text/x-erlang
Size: 76 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/7a2cb21a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rec2.erl
Type: text/x-erlang
Size: 140 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/7a2cb21a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rec3.erl
Type: text/x-erlang
Size: 111 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/7a2cb21a/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/7a2cb21a/attachment-0003.bin>

From kostis@REDACTED  Tue Aug 31 15:48:50 2010
From: kostis@REDACTED (Kostis Sagonas)
Date: Tue, 31 Aug 2010 16:48:50 +0300
Subject: [erlang-bugs] illegal declaration of pertially defined record
 types in dialyzer, R14A
In-Reply-To: <201008311526.18180.kruber@zib.de>
References: <201008311526.18180.kruber@zib.de>
Message-ID: <4C7D0842.7010106@cs.ntua.gr>

Nico Kruber wrote:
> here's the other bug I originally intendet to report:
> 
> I declare a remote type rec1:rec1() in the rec1 module,
> a record rec2 in module rec2 along with a rec2:rec2() type.
> 
> If I use the rec2:rec2() type in a third module, i.e. rec3, dialyzer reports 
> an illegal declaration of rec2#{id}:

There is probably something that needs improvement (or fine tuning) in 
dialyzer, but what you are doing below is totally unnecessary:

-record(rec2, {id::rec1:rec1(), pid::pid()}).
-type(rec2() :: #rec2{id::rec1:rec1(), pid::pid()}).

Here you declare a typed record and in the next line you duplicate the 
declaration of the types of its fields.  There is no real reason to do this.

Simply change the type declaration to the following equivalent one:

-type(rec2() :: #rec{}).

and the problem you reported will go away.

Kostis

From kostis@REDACTED  Tue Aug 31 16:00:28 2010
From: kostis@REDACTED (Kostis Sagonas)
Date: Tue, 31 Aug 2010 17:00:28 +0300
Subject: [erlang-bugs] nocatch error in dialyzer, R14A
In-Reply-To: <201008311502.10956.kruber@zib.de>
References: <201008311459.09585.kruber@zib.de> <201008311502.10956.kruber@zib.de>
Message-ID: <4C7D0AFC.5040804@cs.ntua.gr>

Nico Kruber wrote:
> On Tuesday 31 August 2010 14:59:02 Nico Kruber wrote:
>> While I was trying to make a minimal example for another strange behaviour
>> of the dialyzer I found the following bug calling
>>
>>> dialyzer -Werror_handling -Wrace_conditions --src -c rec*.erl --no_native
>> with the attached files in the current directory:
>>
>>   Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes
>>   Proceeding with analysis...
>> =ERROR REPORT==== 31-Aug-2010::14:53:04 ===
>> Error in process <0.29.0> with exit value: {{nocatch,{error,
>> [73,108,108,101,103,97,108,32,100,101,99,108,97,114,97,116,105,111,110,32,1
>> 11,102,32,"rec2",35,123,"id",125,10]}},
>> [{erl_types,record_from_form,5},{erl_types,t_from_form,3},{erl_types,'-
>> t_opaque_from_records/1-anonymous-2-',3},{dict,map_bucket,2},
>> {dict,map_bkt_list,2},{dict...
>>
>>
>> dialyzer: Analysis failed with error: {{nocatch,{error,
>> [73,108,108,101,103,97|...]}},
>>  [{erl_types,record_from_form,5},
>>   {erl_types,t_from_form,3},
>>   {erl_types,'-t_opaque_from_records/1-anonymous-2-',3},
>>   {dict,map_bucket,2},
>>   {dict,map_bkt_list,2},
>>   {dict,map_bkt_list,2},
>>   {dict,map_seg_list,...},
>>   {dict,...}]}
>> Last messages in the log cache:
>>   Reading files and computing callgraph... done in 0.06 secs
>>   Removing edges... done in 0.01 secs
>>   Typesig analysis for SCC: [{rec2,module_info,1}]
> 
> I forgot to mention that if you replace opaque with type in rec2.erl, it works

Same issue here with the other one.  Simply change the declaration:

-record(rec2, {id :: rec1:rec1()}).
-opaque(rec2() :: #rec2{id :: rec1:rec1()}).

to the equivalent ones:

-record(rec2, {id :: rec1:rec1()}).
-opaque(rec2() :: #rec2{}).

and the crash will go away.

Kostis

From kruber@REDACTED  Tue Aug 31 16:03:38 2010
From: kruber@REDACTED (Nico Kruber)
Date: Tue, 31 Aug 2010 16:03:38 +0200
Subject: [erlang-bugs] illegal declaration of pertially defined record types in dialyzer, R14A
In-Reply-To: <4C7D0842.7010106@cs.ntua.gr>
References: <201008311526.18180.kruber@zib.de> <4C7D0842.7010106@cs.ntua.gr>
Message-ID: <201008311603.43854.kruber@zib.de>

On Tuesday 31 August 2010 15:48:50 Kostis Sagonas wrote:
> Nico Kruber wrote:
> > here's the other bug I originally intendet to report:
> > 
> > I declare a remote type rec1:rec1() in the rec1 module,
> > a record rec2 in module rec2 along with a rec2:rec2() type.
> > 
> > If I use the rec2:rec2() type in a third module, i.e. rec3, dialyzer
> > reports
> 
> > an illegal declaration of rec2#{id}:
> There is probably something that needs improvement (or fine tuning) in
> dialyzer, but what you are doing below is totally unnecessary:
> 
> -record(rec2, {id::rec1:rec1(), pid::pid()}).
> -type(rec2() :: #rec2{id::rec1:rec1(), pid::pid()}).
> 
> Here you declare a typed record and in the next line you duplicate the
> declaration of the types of its fields.  There is no real reason to do
> this.
> 
> Simply change the type declaration to the following equivalent one:
> 
> -type(rec2() :: #rec{}).
> 
> and the problem you reported will go away.

actually this is a minimal case - I use it a bit differently:

If I specify the type as you said, erlang will silently convert it to the 
following (as there are no initialisers in the record definition):

-type(rec2() :: #rec{id::'undefined | rec1:rec1(), pid::'undefined | pid()}).

as stated here:
http://www.erlang.org/doc/reference_manual/typespec.html#id2272601

We implemented a helper module to ease writing test suites. It parses those 
specs from the beam files and generates values from it.
The type I use now is defined opaque but every method in the according module 
gets well-formed records, i.e. no 'undefined' fields. I cannot provide useful 
initialisers though because we store pids, for example.
We not have to distinguish well-formed records and those that may be partially 
undefined and the given declaration would solve this problem.

Nico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/2c796f59/attachment.bin>