From matthias@REDACTED  Sun Apr  1 12:00:27 2007
From: matthias@REDACTED (Matthias Radestock)
Date: Sun, 01 Apr 2007 11:00:27 +0100
Subject: [erlang-bugs] erlang.el breaks Emacs unicode handling
Message-ID: <lyd52oo1ms.fsf@tanto.lshift.net>

The Erlang Emacs mode under lib/tools/emacs/erlang.el in the OTP
distribution contains a bug that breaks unicode handling in other parts
of Emacs after an Erlang buffer has been visited.

I noticed the problem on XEmacs 21.4.19 where after loading an Erlang
file, visiting a Gnus (v5.10.7) summary buffer containing unicode
subject lines produces an error like this:

(args-out-of-range "<unicode string>" 34)
  string-match("\\b[^@ 	<>]+[!@][^@ 	<>]+\\b" "<unicode string>")

I subsequently managed to reproduce the problem using the following
sequence:
1) start XEmacs
2) visit an Erlang buffer
3) execute the following Elisp expression: (string-match "\\b" "?")
--> args-out-of-range-error

When omitting step 2, step 3 succeeds.

I tracked down the problem to a missing buffer-local declaration in
erlang.el. Adding

  (make-local-variable 'parse-sexp-lookup-properties)

to erlang-electric-init fixes that. I have attached a patch.

The bug is present in R11B-4 and R11B-3. I haven't looked back further,
but chances are it has been there for a while. It is also present in the
erlang-mode debian package.

I cannot reproduce the bug on Gnu Emacs, though I suspect that there too
some undesirable behaviour can result from erlang.el stomping on
parse-sexp-lookup-properties. The fix certainly doesn't appear to do any
harm.


Regards,

Matthias.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: erlang-mode.patch
Type: text/x-diff
Size: 416 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20070401/35f3f382/attachment.bin>

From ulf.wiger@REDACTED  Mon Apr  2 18:48:00 2007
From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB))
Date: Mon, 2 Apr 2007 18:48:00 +0200
Subject: [erlang-bugs] compile and syntax_tools disagree
Message-ID: <6616D98C65DD514BA2E1DDC5F9223155018E71C2@esealmw115.eemea.ericsson.se>


I'm getting a bit cross-eyed, but this has got to be a bug *somewhere*:

12> M = [{attribute,1,module,m},{attribute,1,export,[{foo,1}]}|Fs] ++
[{eof,1}]. 
[{attribute,1,module,m},
 {attribute,1,export,[{foo,1}]},
 {function,1,
           foo,
           1,
           [{clause,1,
                    [{var,1,'R'}],
                    [{op,1,'==',{var,1,'R'},{integer,1,1}}],
                    [{atom,1,true}]}]},
 {eof,1}]
13> compile:forms(M).
.:none: internal error in expand_module;
crash reason: {function_clause,
                  [{erl_expand_records,
                       guard_tests1,
                       [{op,1,'==',{var,1,'R'},{integer,1,1}},
...
                   {erl_expand_records,guard_tests,2},
                   {erl_expand_records,guard,2},
                   {erl_expand_records,clauses,2},
                   {erl_expand_records,forms,2},
                   {erl_expand_records,forms,2},
                   {erl_expand_records,module,2},
                   {sys_pre_expand,module,2}]}
error
14> M1 = [{attribute,1,module,m},{attribute,1,export,[{foo,1}]}|Fs1] ++
[{eof,1}].
[{attribute,1,module,m},
 {attribute,1,export,[{foo,1}]},
 {function,1,
           foo,
           1,
           [{clause,1,
                    [{var,1,'R'}],
                    [[{op,1,'==',{var,1,'R'},{integer,1,1}}]],
                    [{atom,1,true}]}]},
 {eof,1}]
15> compile:forms(M1).
{ok,m,
 
<<70,79,82,49,0,0,1,184,66,69,65,77,65,116,111,109,0,0,0,50,0,0,0,6,1,10
9,
      ...>>}

When pretty-printing the two form lists using erl_prettypr:format/2, 
you get the same output, and according to the ERTS User's Guide,
the two guard representations should be equivalent. A list of lists
in the Guard represents a disjunction, and a list of Guard expressions
represents a conjunction. In this case, there's only one guard expr.

6> erl_prettypr:format(erl_syntax:form_list(Fs)).
"foo(R) when R == 1 -> true."      
6> erl_prettypr:format(erl_syntax:form_list(Fs1)).
"foo(R) when R == 1 -> true."      

It seems to me as if the bug is in the compiler (version 4.4.3).

Forgive me for not diving into the compiler source code to verify
this claim. Time to put the kids to sleep.

BR,
Ulf W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20070402/4010393b/attachment.htm>

From bjorn@REDACTED  Tue Apr  3 10:30:31 2007
From: bjorn@REDACTED (Bjorn Gustavsson)
Date: 03 Apr 2007 10:30:31 +0200
Subject: [erlang-bugs] compile and syntax_tools disagree
In-Reply-To: <6616D98C65DD514BA2E1DDC5F9223155018E71C2@esealmw115.eemea.ericsson.se>
References: <6616D98C65DD514BA2E1DDC5F9223155018E71C2@esealmw115.eemea.ericsson.se>
Message-ID: <o1ircdeu6w.fsf@erix.ericsson.se>

As far as I understand, The ERTS User's Guide says that you'll need two
layers of lists to represent a guard sequence.

syntax_tools still accepts the older format of guards (before semicolons
in guards were introduced), so that it can still be used for the abstract
format in old Beam files.

So as I see, there is no bug.

/Bj?rn

"Ulf Wiger \(TN/EAB\)" <ulf.wiger@REDACTED> writes:

> I'm getting a bit cross-eyed, but this has got to be a bug *somewhere*:
> 
> 12> M = [{attribute,1,module,m},{attribute,1,export,[{foo,1}]}|Fs] ++
> [{eof,1}]. 
> [{attribute,1,module,m},
>  {attribute,1,export,[{foo,1}]},
>  {function,1,
>            foo,
>            1,
>            [{clause,1,
>                     [{var,1,'R'}],
>                     [{op,1,'==',{var,1,'R'},{integer,1,1}}],
>                     [{atom,1,true}]}]},
>  {eof,1}]
> 13> compile:forms(M).
> .:none: internal error in expand_module;
> crash reason: {function_clause,
>                   [{erl_expand_records,
>                        guard_tests1,
>                        [{op,1,'==',{var,1,'R'},{integer,1,1}},
> ...
>                    {erl_expand_records,guard_tests,2},
>                    {erl_expand_records,guard,2},
>                    {erl_expand_records,clauses,2},
>                    {erl_expand_records,forms,2},
>                    {erl_expand_records,forms,2},
>                    {erl_expand_records,module,2},
>                    {sys_pre_expand,module,2}]}
> error
> 14> M1 = [{attribute,1,module,m},{attribute,1,export,[{foo,1}]}|Fs1] ++
> [{eof,1}].
> [{attribute,1,module,m},
>  {attribute,1,export,[{foo,1}]},
>  {function,1,
>            foo,
>            1,
>            [{clause,1,
>                     [{var,1,'R'}],
>                     [[{op,1,'==',{var,1,'R'},{integer,1,1}}]],
>                     [{atom,1,true}]}]},
>  {eof,1}]
> 15> compile:forms(M1).
> {ok,m,
>  
> <<70,79,82,49,0,0,1,184,66,69,65,77,65,116,111,109,0,0,0,50,0,0,0,6,1,10
> 9,
>       ...>>}
> 
> When pretty-printing the two form lists using erl_prettypr:format/2, 
> you get the same output, and according to the ERTS User's Guide,
> the two guard representations should be equivalent. A list of lists
> in the Guard represents a disjunction, and a list of Guard expressions
> represents a conjunction. In this case, there's only one guard expr.
> 
> 6> erl_prettypr:format(erl_syntax:form_list(Fs)).
> "foo(R) when R == 1 -> true."      
> 6> erl_prettypr:format(erl_syntax:form_list(Fs1)).
> "foo(R) when R == 1 -> true."      
> 
> It seems to me as if the bug is in the compiler (version 4.4.3).
> 
> Forgive me for not diving into the compiler source code to verify
> this claim. Time to put the kids to sleep.
> 
> BR,
> Ulf W
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-bugs

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



From ulf.wiger@REDACTED  Tue Apr  3 12:04:07 2007
From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB))
Date: Tue, 3 Apr 2007 12:04:07 +0200
Subject: [erlang-bugs] compile and syntax_tools disagree
In-Reply-To: <o1ircdeu6w.fsf@erix.ericsson.se>
Message-ID: <6616D98C65DD514BA2E1DDC5F9223155018E78F1@esealmw115.eemea.ericsson.se>


Maybe it's just I who don't understand how to read the 
doc on abstract forms, but quoted from
http://www.erlang.org/doc/doc-5.5.4/erts-5.5.4/doc/html/part_frame.html

"If C is a function clause ( Ps ) when Gs -> B where Ps 
is a pattern sequence, Gs is a guard sequence and B 
is a body, then 
Rep(C) = {clause,LINE,Rep(Ps),Rep(Gs),Rep(B)}. 

...

A guard Gs is a nonempty sequence of guard tests G_1, ..., 
G_k, and Rep(Gs) = [Rep(G_1), ..., Rep(G_k)]. 

...
If G is true, then Rep(G) = {atom,LINE,true}. 
...
If G is an operator expression E_1 Op E_2, where 
Op is a binary operator, and E_1, E_2 are guard 
expressions, then 
Rep(G) = {op,LINE,Op,Rep(E_1),Rep(E_2)}. "

I read this as 
Rep(C) = {clause,LINE,Rep(Ps),Rep(Gs),Rep(B)}
Rep(Gs) = [Rep(G)|...]
Rep(G) = {op,LINE,Op,Rep(E_1),Rep(E_2)}|...

In other words, as if 
  Guard = [{op,1,'==',{integer,1,1},{var,1,'R'}}]
would actually be valid.

BR,
Ulf W

> -----Original Message-----
> From: Bjorn Gustavsson [mailto:bjorn@REDACTED] 
> Sent: den 3 april 2007 10:31
> To: Ulf Wiger (TN/EAB)
> Cc: erlang-bugs@REDACTED
> Subject: Re: [erlang-bugs] compile and syntax_tools disagree
> 
> As far as I understand, The ERTS User's Guide says that 
> you'll need two layers of lists to represent a guard sequence.
> 
> syntax_tools still accepts the older format of guards (before 
> semicolons in guards were introduced), so that it can still 
> be used for the abstract format in old Beam files.
> 
> So as I see, there is no bug.
> 
> /Bj?rn
> 
> "Ulf Wiger \(TN/EAB\)" <ulf.wiger@REDACTED> writes:
> 
> > I'm getting a bit cross-eyed, but this has got to be a bug 
> *somewhere*:
> > 
> > 12> M = 
> [{attribute,1,module,m},{attribute,1,export,[{foo,1}]}|Fs] ++
> > [{eof,1}]. 
> > [{attribute,1,module,m},
> >  {attribute,1,export,[{foo,1}]},
> >  {function,1,
> >            foo,
> >            1,
> >            [{clause,1,
> >                     [{var,1,'R'}],
> >                     [{op,1,'==',{var,1,'R'},{integer,1,1}}],
> >                     [{atom,1,true}]}]},  {eof,1}]
> > 13> compile:forms(M).
> > .:none: internal error in expand_module; crash reason: 
> > {function_clause,
> >                   [{erl_expand_records,
> >                        guard_tests1,
> >                        [{op,1,'==',{var,1,'R'},{integer,1,1}},
> > ...
> >                    {erl_expand_records,guard_tests,2},
> >                    {erl_expand_records,guard,2},
> >                    {erl_expand_records,clauses,2},
> >                    {erl_expand_records,forms,2},
> >                    {erl_expand_records,forms,2},
> >                    {erl_expand_records,module,2},
> >                    {sys_pre_expand,module,2}]} error
> > 14> M1 = 
> [{attribute,1,module,m},{attribute,1,export,[{foo,1}]}|Fs1] 
> > 14> ++
> > [{eof,1}].
> > [{attribute,1,module,m},
> >  {attribute,1,export,[{foo,1}]},
> >  {function,1,
> >            foo,
> >            1,
> >            [{clause,1,
> >                     [{var,1,'R'}],
> >                     [[{op,1,'==',{var,1,'R'},{integer,1,1}}]],
> >                     [{atom,1,true}]}]},  {eof,1}]
> > 15> compile:forms(M1).
> > {ok,m,
> >  
> > 
> <<70,79,82,49,0,0,1,184,66,69,65,77,65,116,111,109,0,0,0,50,0,0,0,6,1,
> > 10
> > 9,
> >       ...>>}
> > 
> > When pretty-printing the two form lists using 
> erl_prettypr:format/2, 
> > you get the same output, and according to the ERTS User's 
> Guide, the 
> > two guard representations should be equivalent. A list of 
> lists in the 
> > Guard represents a disjunction, and a list of Guard expressions 
> > represents a conjunction. In this case, there's only one guard expr.
> > 
> > 6> erl_prettypr:format(erl_syntax:form_list(Fs)).
> > "foo(R) when R == 1 -> true."      
> > 6> erl_prettypr:format(erl_syntax:form_list(Fs1)).
> > "foo(R) when R == 1 -> true."      
> > 
> > It seems to me as if the bug is in the compiler (version 4.4.3).
> > 
> > Forgive me for not diving into the compiler source code to 
> verify this 
> > claim. Time to put the kids to sleep.
> > 
> > BR,
> > Ulf W
> > _______________________________________________
> > erlang-bugs mailing list
> > erlang-bugs@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-bugs
> 
> --
> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
> 



From richardc@REDACTED  Tue Apr  3 13:00:37 2007
From: richardc@REDACTED (Richard Carlsson)
Date: Tue, 03 Apr 2007 13:00:37 +0200
Subject: [erlang-bugs] compile and syntax_tools disagree
In-Reply-To: <6616D98C65DD514BA2E1DDC5F9223155018E78F1@esealmw115.eemea.ericsson.se>
References: <6616D98C65DD514BA2E1DDC5F9223155018E78F1@esealmw115.eemea.ericsson.se>
Message-ID: <461233D5.2030701@it.uu.se>

Ulf Wiger (TN/EAB) wrote:
> Maybe it's just I who don't understand how to read the 
> doc on abstract forms, but quoted from
> http://www.erlang.org/doc/doc-5.5.4/erts-5.5.4/doc/html/part_frame.html
> 
> "If C is a function clause ( Ps ) when Gs -> B where Ps 
> is a pattern sequence, Gs is a guard sequence and B 
> is a body, then 
> Rep(C) = {clause,LINE,Rep(Ps),Rep(Gs),Rep(B)}. 
> ...
> A guard Gs is a nonempty sequence of guard tests G_1, ..., 
> G_k, and Rep(Gs) = [Rep(G_1), ..., Rep(G_k)]. 

Don't miss the immediately following paragraph:

"A guard sequence Gss is a sequence of guards Gs_1; ...; Gs_k, and 
Rep(Gss) = [Rep(Gs_1), ..., Rep(Gs_k)]. If the guard sequence is empty, 
Rep(Gss) = []."

The description of {clause, ...} that you quote above says "Gs is a 
guard sequence". It would have been more obvious if that paragraph had 
used Gss instead of Gs.

     /Richard



From ulf.wiger@REDACTED  Tue Apr  3 14:22:05 2007
From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB))
Date: Tue, 3 Apr 2007 14:22:05 +0200
Subject: [erlang-bugs] compile and syntax_tools disagree
In-Reply-To: <461233D5.2030701@it.uu.se>
Message-ID: <6616D98C65DD514BA2E1DDC5F9223155019177F8@esealmw115.eemea.ericsson.se>


I didn't miss out on it. I was trying to 
keep the email short. (:

The way I read the documentation in it's current
state is that it is supposed to work as syntax_tools  
does, where

[G1, G2, ...] is a conjunction of guards, and 
[[G11,G12,...],[G21,G22,...],...] is a disjunction.

I have no problem with the compiler requiring 
[[G]] rather than [G]. I have changed the output
of my code generator to this, since clearly - 
bug or no bug - this would have been a correct
pattern.

If Rep(Gss) had been used, as you suggest, it 
would indeed have been more obvious, and also 
correctly described the current behaviour of
the compiler.  ,-)

BR,
Ulf W

> -----Original Message-----
> From: Richard Carlsson [mailto:richardc@REDACTED] 
> Sent: den 3 april 2007 13:01
> To: Ulf Wiger (TN/EAB)
> Cc: Bjorn Gustavsson; erlang-bugs@REDACTED
> Subject: Re: [erlang-bugs] compile and syntax_tools disagree
> 
> Ulf Wiger (TN/EAB) wrote:
> > Maybe it's just I who don't understand how to read the doc 
> on abstract 
> > forms, but quoted from 
> > 
> http://www.erlang.org/doc/doc-5.5.4/erts-5.5.4/doc/html/part_frame.htm
> > l
> > 
> > "If C is a function clause ( Ps ) when Gs -> B where Ps is 
> a pattern 
> > sequence, Gs is a guard sequence and B is a body, then
> > Rep(C) = {clause,LINE,Rep(Ps),Rep(Gs),Rep(B)}. 
> > ...
> > A guard Gs is a nonempty sequence of guard tests G_1, ..., G_k, and 
> > Rep(Gs) = [Rep(G_1), ..., Rep(G_k)].
> 
> Don't miss the immediately following paragraph:
> 
> "A guard sequence Gss is a sequence of guards Gs_1; ...; Gs_k, and
> Rep(Gss) = [Rep(Gs_1), ..., Rep(Gs_k)]. If the guard sequence 
> is empty,
> Rep(Gss) = []."
> 
> The description of {clause, ...} that you quote above says 
> "Gs is a guard sequence". It would have been more obvious if 
> that paragraph had used Gss instead of Gs.
> 
>      /Richard
> 
> 



From bjorn@REDACTED  Tue Apr  3 14:41:06 2007
From: bjorn@REDACTED (Bjorn Gustavsson)
Date: 03 Apr 2007 14:41:06 +0200
Subject: [erlang-bugs] compile and syntax_tools disagree
In-Reply-To: <6616D98C65DD514BA2E1DDC5F9223155019177F8@esealmw115.eemea.ericsson.se>
References: <6616D98C65DD514BA2E1DDC5F9223155019177F8@esealmw115.eemea.ericsson.se>
Message-ID: <o1ircdzl3x.fsf@erix.ericsson.se>

We'll clarify the documentation in R11B-5.

/Bj?rn

"Ulf Wiger \(TN/EAB\)" <ulf.wiger@REDACTED> writes:

> I didn't miss out on it. I was trying to 
> keep the email short. (:
> 
> The way I read the documentation in it's current
> state is that it is supposed to work as syntax_tools  
> does, where
> 
> [G1, G2, ...] is a conjunction of guards, and 
> [[G11,G12,...],[G21,G22,...],...] is a disjunction.
> 
> I have no problem with the compiler requiring 
> [[G]] rather than [G]. I have changed the output
> of my code generator to this, since clearly - 
> bug or no bug - this would have been a correct
> pattern.
> 
> If Rep(Gss) had been used, as you suggest, it 
> would indeed have been more obvious, and also 
> correctly described the current behaviour of
> the compiler.  ,-)
> 
> BR,
> Ulf W
> 
> > -----Original Message-----
> > From: Richard Carlsson [mailto:richardc@REDACTED] 
> > Sent: den 3 april 2007 13:01
> > To: Ulf Wiger (TN/EAB)
> > Cc: Bjorn Gustavsson; erlang-bugs@REDACTED
> > Subject: Re: [erlang-bugs] compile and syntax_tools disagree
> > 
> > Ulf Wiger (TN/EAB) wrote:
> > > Maybe it's just I who don't understand how to read the doc 
> > on abstract 
> > > forms, but quoted from 
> > > 
> > http://www.erlang.org/doc/doc-5.5.4/erts-5.5.4/doc/html/part_frame.htm
> > > l
> > > 
> > > "If C is a function clause ( Ps ) when Gs -> B where Ps is 
> > a pattern 
> > > sequence, Gs is a guard sequence and B is a body, then
> > > Rep(C) = {clause,LINE,Rep(Ps),Rep(Gs),Rep(B)}. 
> > > ...
> > > A guard Gs is a nonempty sequence of guard tests G_1, ..., G_k, and 
> > > Rep(Gs) = [Rep(G_1), ..., Rep(G_k)].
> > 
> > Don't miss the immediately following paragraph:
> > 
> > "A guard sequence Gss is a sequence of guards Gs_1; ...; Gs_k, and
> > Rep(Gss) = [Rep(Gs_1), ..., Rep(Gs_k)]. If the guard sequence 
> > is empty,
> > Rep(Gss) = []."
> > 
> > The description of {clause, ...} that you quote above says 
> > "Gs is a guard sequence". It would have been more obvious if 
> > that paragraph had used Gss instead of Gs.
> > 
> >      /Richard
> > 
> > 
> 

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



From jrsantos@REDACTED  Tue Apr  3 20:51:22 2007
From: jrsantos@REDACTED (jrsantos@REDACTED)
Date: Tue, 3 Apr 2007 14:51:22 -0400
Subject: [erlang-bugs] gen_sctp:open fails on linux
Message-ID: <20070403185122.GA24988@vanu.com>

I was testing out the SCTP support included in Erlang/OTP R11B-4 on a
linux 2.6.8 system.  Calls to gen_sctp:open were failing.  I narrowed
the problem down to an einval being returned while trying to set the
sndbuf socket option.

Looking at erts/emulator/drivers/common/inet_drv.c, it looks like it is
calling setsockopt(IPPROTO_SCTP, SO_SNDBUF, ...), which fails.  I
believe that this should be calling setsockopt(SOL_SOCKET, SO_SNDBUF,
...) instead.  Also, I think the same thing holds for SO_RCVBUF.

I made these changes in inet_drv.c, and the gen_sctp:open call succeeds
and I am able to use the SCTP socket.

        -Jon


From raimo+erlang-bugs@REDACTED  Wed Apr  4 10:49:33 2007
From: raimo+erlang-bugs@REDACTED (Raimo Niskanen)
Date: Wed, 4 Apr 2007 10:49:33 +0200
Subject: [erlang-bugs] gen_sctp:open fails on linux
In-Reply-To: <20070403185122.GA24988@vanu.com>
References: <20070403185122.GA24988@vanu.com>
Message-ID: <20070404084933.GB19613@erix.ericsson.se>

Allright, very good. We will fix this at least to R11B-5.
I notice you do not need a patch yourself....


On Tue, Apr 03, 2007 at 02:51:22PM -0400, jrsantos@REDACTED wrote:
> I was testing out the SCTP support included in Erlang/OTP R11B-4 on a
> linux 2.6.8 system.  Calls to gen_sctp:open were failing.  I narrowed
> the problem down to an einval being returned while trying to set the
> sndbuf socket option.
> 
> Looking at erts/emulator/drivers/common/inet_drv.c, it looks like it is
> calling setsockopt(IPPROTO_SCTP, SO_SNDBUF, ...), which fails.  I
> believe that this should be calling setsockopt(SOL_SOCKET, SO_SNDBUF,
> ...) instead.  Also, I think the same thing holds for SO_RCVBUF.
> 
> I made these changes in inet_drv.c, and the gen_sctp:open call succeeds
> and I am able to use the SCTP socket.
> 
>         -Jon
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-bugs

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB


From hpjcon@REDACTED  Wed Apr  4 22:46:31 2007
From: hpjcon@REDACTED (Jan Jacobs)
Date: Wed, 4 Apr 2007 22:46:31 +0200
Subject: [erlang-bugs] erlang:open_port  bug!
Message-ID: <004d01c776fa$55e1ee40$c800a8c0@jan03>

Hi All,

The erlang:open_port is drive sensitive. Meaning if the software is installed on the C: drive it works. If the same software is installed on the D: (or E:)  the following error occurs:

1> system_srv:start_link(). 
** exited: {einval,[{erlang,open_port,
                            [{spawn,"d:/Program Files/Ecs/UniNetscan-0.0.25/lib/system-0.0.1/priv/win32_system_info.exe"},
                             [{packet,2},binary,exit_status]]},
                    {port_api,open_port,2},
                    {system_srv,init,1},
                    {gen_server,init_it,6},
                    {proc_lib,init_p,5}]} **

I have noticed this for the first time today on a HP server which is running Windows 2003. The above example is done on my
noname AMD box running Windows XP.

If I reduce the length from "d:/Program Files/Ecs/UniNetscan-0.0.25/lib/system-0.0.1/priv/win32_system_info.exe" to 
"d:/Ecs/UniNetscan-0.0.25/lib/system-0.0.1/priv/win32_system_info.exe" it works. (work around to get the software working!)
If I install the exact same software on the C: drive "c:/Program Files/Ecs/UniNetscan-0.0.25/lib/system-0.0.1/priv/win32_system_info.exe" it works.

The same thing happens with the erlang software:

Eshell V5.5.3  (abort with ^G)
1> pwd().
D:/Program Files/Ecs/EcsProman-0.1.4
ok
2> odbc:connect("DSN=printspool;UID=SYSDBA;PWD=masterkey",[]).

=INFO REPORT==== 4-Apr-2007::22:39:47 ===
The odbc application was not started. Has now been started as a temporary applic
ation.
{error,{einval,[{erlang,open_port,
                        [{spawn,"d:/Program Files/Ecs/EcsProman-0.1.4/lib/odbc-2.0.7/priv/bin/odbcserver.exe"},
                         [{packet,4},binary,exit_status]]},
                {odbc,init,1},
                {gen_server,init_it,6},
                {proc_lib,init_p,5}]}}

Thanks
Jan Jacobs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20070404/d0c787c2/attachment.htm>

From anders.nygren@REDACTED  Tue Apr 10 05:04:43 2007
From: anders.nygren@REDACTED (Anders Nygren)
Date: Mon, 9 Apr 2007 22:04:43 -0500
Subject: [erlang-bugs] ssh dependency on asn1
Message-ID: <d3520a2f0704092004o210422d6j3f93b8ee145cfceb@mail.gmail.com>

Hi
I have found that in R11B-4 ssh has a dependency on asn1, but asn1 is not
included in the ssh.app file.

/Anders


From anders.nygren@REDACTED  Wed Apr 11 16:26:13 2007
From: anders.nygren@REDACTED (Anders Nygren)
Date: Wed, 11 Apr 2007 09:26:13 -0500
Subject: [erlang-bugs] erl_interface pdf doc
Message-ID: <d3520a2f0704110726t1c8e70e0o7cc631df1303b94a@mail.gmail.com>

Hi
The pdf version of the erl_interface manual contains
1.1 The EI Library User's Guide
1.2 The Erl_interface Library

But the text in the two chapters seems to be identical.

/Anders


From mickael.remond@REDACTED  Fri Apr 13 17:43:08 2007
From: mickael.remond@REDACTED (=?ISO-8859-1?Q?Micka=EBl_R=E9mond?=)
Date: Fri, 13 Apr 2007 17:43:08 +0200
Subject: [erlang-bugs] Missing the tcp_closed event
Message-ID: <81631994-506C-4D80-93D2-BC125FF851E0@process-one.net>

Hello,

We feel that under hard to reproduce conditions (production system  
with ten of thousands connected users), the Erlang TCP module can  
miss the tcp_close event.
The process is receiving event in active once mode. It is not stuck  
in a send.
It seems to happen with the new Erlang R11 in SMP mode.
The port is in a enotconn state, but the process has not been  
informed that the tcp connection has been closed.

Has anyone the same feeling ?
Any idea how to debug that possible problem ?

-- 
Micka?l R?mond
  http://www.process-one.net/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20070413/8ab9bd0b/attachment.htm>

From mickael.remond@REDACTED  Fri Apr 13 18:23:45 2007
From: mickael.remond@REDACTED (=?ISO-8859-1?Q?Micka=EBl_R=E9mond?=)
Date: Fri, 13 Apr 2007 18:23:45 +0200
Subject: [erlang-bugs] Missing the tcp_closed event
In-Reply-To: <81631994-506C-4D80-93D2-BC125FF851E0@process-one.net>
References: <81631994-506C-4D80-93D2-BC125FF851E0@process-one.net>
Message-ID: <948C5676-9293-4719-9C56-0A3BFA303694@process-one.net>

Hello,

Alexey managed to find the steps to reproduced the problem.
You can have a process managing a TCP connection linked to a dead  
socket under the following conditions.

0. Use active once to receive your TCP message to benefit from TCP  
regulation
1. Assume we have a socket in {Active, false} state
2. Close its connection from the other end
3. call gen_tcp:send on the socket two times (It returns ok on the  
first send, which is also wrong. The problem happens only with two or  
more sends).
4. swith to {active, once} state
=> no {tcp_closed, ...} message is received by the process.

If you check the state of your port after step 4 (for example with  
inet:peername) you will receive an error enotconn.

You end up with a stuck process. If you send messages to the process  
queue to send messages on the socket it will accumulate indefinitely.

Please, let me know if we can do something more to help.

-- 
Micka?l R?mond
  http://www.process-one.net/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20070413/8a974c2a/attachment.htm>

From matthias@REDACTED  Fri Apr 13 21:20:42 2007
From: matthias@REDACTED (Matthias Radestock)
Date: Fri, 13 Apr 2007 20:20:42 +0100
Subject: [erlang-bugs] erl_syntax:type/1 fails for binary comprehensions
Message-ID: <ly1wio3wtx.fsf@tanto.lshift.net>

The code in erl_syntax:type/1 is missing a case for the bc (binary
comprehension) nodes produced by erl_parse.

As a result several of the erl_syntax functions fail when invoked with
syntax trees containing binary comprehensions, which in turn breaks a
whole bunch of tools (in my case some of distel's functionality).


This is bug is present in R11B-4. I haven't checked earlier releases.


Regards,

Matthias


From matthias@REDACTED  Sat Apr 14 08:44:10 2007
From: matthias@REDACTED (Matthias Radestock)
Date: Sat, 14 Apr 2007 07:44:10 +0100
Subject: [erlang-bugs] erl_syntax:type/1 fails for binary comprehensions
In-Reply-To: <ly1wio3wtx.fsf@tanto.lshift.net> (Matthias Radestock's message
	of "Fri, 13 Apr 2007 20:20:42 +0100")
References: <ly1wio3wtx.fsf@tanto.lshift.net>
Message-ID: <lyslb3316t.fsf@tanto.lshift.net>

Matthias Radestock <matthias@REDACTED> writes:

> The code in erl_syntax:type/1 is missing a case for the bc (binary
> comprehension) nodes produced by erl_parse.

Here's an example demonstrating this problem:

(fun(Str) ->
         {ok, Tokens, _} = erl_scan:string(Str),
         {ok, [Expr]} = erl_parse:parse_exprs(Tokens),
         erl_prettypr:format(Expr) end)
("<< <<X:1>> || X <- [] >>.").
** exited: {{badarg,
                {bc,1,
                    {bin,
                        1,
                        [{bin_element,1,{var,1,'X'},{integer,1,1},default}]},
                    [{generate,1,{var,1,'X'},{nil,1}}]}},
            [{erl_syntax,type,1},
             {erl_prettypr,lay_2,2},
             {erl_prettypr,format,2},
             {erl_eval,do_apply,5},
             {shell,exprs,6},
             {shell,eval_loop,3}]} **


This, of course, isn't the only place in erl_syntax where support for
binary comprehensions is missing. There's also revert_root/1,
subtrees/1, and make_tree/3

Plus there should be various constructor/accessor functions analogous to
list_comp/2, list_comp_body/1, list_comp_template/1.

Then there are a whole bunch of modules that call into erl_syntax and
are also lacking cases for binary comprehension. For example
erl_prettypr and erl_tidy.


AFAIK binary comprehensions were introduced in R11B-0, which was
released on May 17, 2006. I am somewhat surprised that these bugs have
managed to slip through the net for almost a year. Granted, binary
comprehensions aren't that common, since they are a new feature. In
fact, it appears that the OTP sources only contain one use - in
eval_bits:convert_list/1 - and that was only introduced in R11B-4.

There is an easy way to spot this and other potential bugs in erl_syntax
and friends: run erl_tidy on the OTP sources. Perhaps that should be
added to the OTP test suite?


Regards,

Matthias.


From tim@REDACTED  Sat Apr 14 14:47:15 2007
From: tim@REDACTED (Tim Bates)
Date: Sat, 14 Apr 2007 22:17:15 +0930
Subject: [erlang-bugs] Parallel make (-j) fails in R11B-4
Message-ID: <1176554835.4620cd532eba0@mail.bates.id.au>

Using the -j (jobs) option for GNU make on an Athlon64 X2 (dual-core) machine
causes the compilation of open-source Erlang R11B-4 to fail. On one occasion I
saw an error message from ld about being unable to find -lethread, but usually
there is no error message from ld and Make just exits with Error 2.

I assume this is some sort of error in the Makefile that causes a race
condition, making it start linking the object before all the dependencies are
completely built. The workaround is to not use -j option, (it builds fine
without it), but then the build is much slower as it only uses one core.

Tim.

-- 
Tim Bates
tim@REDACTED


From gunilla@REDACTED  Wed Apr 18 12:56:26 2007
From: gunilla@REDACTED (Gunilla Arendt)
Date: Wed, 18 Apr 2007 12:56:26 +0200
Subject: [erlang-bugs] ssh dependency on asn1
In-Reply-To: <d3520a2f0704092004o210422d6j3f93b8ee145cfceb@mail.gmail.com>
References: <d3520a2f0704092004o210422d6j3f93b8ee145cfceb@mail.gmail.com>
Message-ID: <4625F95A.4060501@erix.ericsson.se>

Hi,

Some aspects of the application concept are a bit fuzzy, and this is
one of them. The 'applications' field in the .app file is used to
specify which applications should be started before this application is.

asn1, however, is a library application in the sense that it has no
supervision tree and thus does not need to be started before it can
be used. What ssh needs is the code for asn1 being available, not that
it is started, but there is (currently) no way of expressing that in
the .app file.

Regards,
Gunilla, Erlang/OTP team


Anders Nygren wrote:
> Hi
> I have found that in R11B-4 ssh has a dependency on asn1, but asn1 is not
> included in the ssh.app file.
> 
> /Anders



From anders.nygren@REDACTED  Thu Apr 19 07:46:21 2007
From: anders.nygren@REDACTED (Anders Nygren)
Date: Thu, 19 Apr 2007 00:46:21 -0500
Subject: [erlang-bugs] ssh dependency on asn1
In-Reply-To: <4625F95A.4060501@erix.ericsson.se>
References: <d3520a2f0704092004o210422d6j3f93b8ee145cfceb@mail.gmail.com>
	<4625F95A.4060501@erix.ericsson.se>
Message-ID: <d3520a2f0704182246w6919007ufe5aa63b4fa7653d@mail.gmail.com>

On 4/18/07, Gunilla Arendt <gunilla@REDACTED> wrote:
> Hi,
>
> Some aspects of the application concept are a bit fuzzy, and this is
> one of them. The 'applications' field in the .app file is used to
> specify which applications should be started before this application is.
>

The documentation is a bit unclear, both "Design Principles" and
app(4) says about the 'applications' field that it is all applications that
shall be started, but then they add the comment that
"...all applications have dependencies to at least kernel and stdlib."
Which can give the impression that You actually have to include the
library applications as well.

> asn1, however, is a library application in the sense that it has no
> supervision tree and thus does not need to be started before it can
> be used. What ssh needs is the code for asn1 being available, not that
> it is started, but there is (currently) no way of expressing that in
> the .app file.
>

Unfortunately ssh converts any errors from 'DSS':decode/2 to {error, bad_format}

The "guilty" party is ssh_file:decode_private_key_v2(Private, "ssh-dss")

/Anders


> Regards,
> Gunilla, Erlang/OTP team
>
>
> Anders Nygren wrote:
> > Hi
> > I have found that in R11B-4 ssh has a dependency on asn1, but asn1 is not
> > included in the ssh.app file.
> >
> > /Anders
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-bugs
>


From mickael.remond@REDACTED  Fri Apr 27 10:28:28 2007
From: mickael.remond@REDACTED (=?ISO-8859-1?Q?Micka=EBl_R=E9mond?=)
Date: Fri, 27 Apr 2007 10:28:28 +0200
Subject: [erlang-bugs] Missing the tcp_closed event
In-Reply-To: <948C5676-9293-4719-9C56-0A3BFA303694@process-one.net>
References: <81631994-506C-4D80-93D2-BC125FF851E0@process-one.net>
	<948C5676-9293-4719-9C56-0A3BFA303694@process-one.net>
Message-ID: <008BBA30-4E36-4F73-8032-8FE58629B2E2@process-one.net>

Hello,

Can this problem be reproduced by your side ?
Do you need more informations ?

Le 13 avr. 07 ? 18:23, Micka?l R?mond a ?crit :

> Hello,
>
> Alexey managed to find the steps to reproduced the problem.
> You can have a process managing a TCP connection linked to a dead  
> socket under the following conditions.
>
> 0. Use active once to receive your TCP message to benefit from TCP  
> regulation
> 1. Assume we have a socket in {Active, false} state
> 2. Close its connection from the other end
> 3. call gen_tcp:send on the socket two times (It returns ok on the  
> first send, which is also wrong. The problem happens only with two  
> or more sends).
> 4. swith to {active, once} state
> => no {tcp_closed, ...} message is received by the process.
>
> If you check the state of your port after step 4 (for example with  
> inet:peername) you will receive an error enotconn.
>
> You end up with a stuck process. If you send messages to the  
> process queue to send messages on the socket it will accumulate  
> indefinitely.
>
> Please, let me know if we can do something more to help.
>
> -- 
> Micka?l R?mond
>  http://www.process-one.net/
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-bugs

-- 
Micka?l R?mond
  http://www.process-one.net/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20070427/0effd90e/attachment.htm>

From matthias@REDACTED  Sun Apr 29 22:32:34 2007
From: matthias@REDACTED (Matthias Lang)
Date: Sun, 29 Apr 2007 22:32:34 +0200
Subject: [erlang-bugs] trivial typo bug in reference manual,
	section 12.3 "code replacement"
Message-ID: <17973.226.670338.673217@antilipe.corelatus.se>


The third paragraph reads

  "Bot old and current code is valid, and may be evaluated concurrently."

The first word should be "Both".

Matthias