From tuncer.ayaz@REDACTED  Tue Jan  8 16:22:04 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Tue, 8 Jan 2013 16:22:04 +0100
Subject: [erlang-bugs] "incompatible runtime system" always reported in R16
Message-ID: <CAOvwQ4i38bUSCDt7h8g3FofrRS6fSBOmqw9s+tW9h3KfK0RY6g@mail.gmail.com>

otp.git 3e8a6c8 built with --enable-native-libs seems to always print
the "incompatible runtime system" warning for native compiled modules.
R15 only does that if for example smp was explicitly disabled on start.

<HiPE (v 3.9.3)> Warning: not loading native code for module sets: it
was compiled for an incompatible runtime system; please regenerate
native code for this runtime system


From tuncer.ayaz@REDACTED  Tue Jan  8 16:51:21 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Tue, 8 Jan 2013 16:51:21 +0100
Subject: [erlang-bugs] R16 EUnit *** context setup failed ***
In-Reply-To: <85BE9BC9-731C-4DAE-BD47-A33FE7B30AD5@gmail.com>
References: <CAOvwQ4jMP6f55Nui6BUSh0SQirKXCFEMV6OBQ2m06XVQcBd4EQ@mail.gmail.com>
 <85BE9BC9-731C-4DAE-BD47-A33FE7B30AD5@gmail.com>
Message-ID: <CAOvwQ4hXD+jhf792HDs-zgqRYg6-5JMvUbAa-1co1JW=QNFFfw@mail.gmail.com>

Same problem with git rev 3e8a6c8.

On Fri, Nov 23, 2012 at 4:20 PM, Anthony Ramine wrote:
> I can reproduce this with the exact same steps.
>
> --
> Anthony Ramine
>
> Le 13 nov. 2012 ? 14:18, Tuncer Ayaz a ?crit :
>
>> If I build and run rebar's EUnit tests with R16, I see "*** context
>> setup failed ***" errors.
>>
>> Interestingly, if I use a tree where ebin/*, rebar, and .eunit/*.beam
>> have been built with R15B02, then neither R16 nor R15 throw the
>> context setup errors.
>>
>> # fetch and build rebar
>> $ git clone git://github.com/rebar/rebar.git
>> $ cd rebar
>> $ make
>> # run tests with new rebar binary
>> $ ./rebar eunit
>> # *** context setup failed *** errors and 50 out of 72 tests
>> # not executed
>> $ rm ebin/* .eunit/* rebar
>> # rebuild rebar and EUnit tests with R15
>> $ make && ./rebar eunit
>> # running EUnit tests with either R15 or R16 works now
>>
>> Can anyone else reproduce this? Could this be caused by compiler
>> changes in R16? I don't see any changes in lib/eunit after R15B02.


From tuncer.ayaz@REDACTED  Tue Jan  8 17:00:59 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Tue, 8 Jan 2013 17:00:59 +0100
Subject: [erlang-bugs] R16 Dialyzer bad_crc error
Message-ID: <CAOvwQ4hvHkwkweFeZD=iTyR62ZAC3DXpvVSyO-4+xVxaDUt2XA@mail.gmail.com>

dialyzer --build_plt with otp.git 3e8a6c8 fails as follows:
{"init terminating in do_boot",{{badmatch,{error,bad_crc}},
  [{hipe,finalize,5,[{file,"hipe.erl"},{line,740}]},
   {hipe,compile_finish,3,[{file,"hipe.erl"},{line,697}]},
   {hipe,'-run_compiler_1/3-fun-0-',4,[{file,"hipe.erl"},{line,658}]}]
  }}

Maybe it's a known but not yet resolved issue caused by the
major code loader changes happening in R16.


From sverker.eriksson@REDACTED  Tue Jan  8 18:48:32 2013
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Tue, 8 Jan 2013 18:48:32 +0100
Subject: [erlang-bugs] "incompatible runtime system" always reported in
 R16
In-Reply-To: <CAOvwQ4i38bUSCDt7h8g3FofrRS6fSBOmqw9s+tW9h3KfK0RY6g@mail.gmail.com>
References: <CAOvwQ4i38bUSCDt7h8g3FofrRS6fSBOmqw9s+tW9h3KfK0RY6g@mail.gmail.com>
Message-ID: <50EC5BF0.7090507@erix.ericsson.se>

Thanks for the reminder.
I have merged the fixing commit f4522c6f39d2eb to master now and it will 
show up on github when our admin does the next push.

/Sverker

Tuncer Ayaz wrote:
> otp.git 3e8a6c8 built with --enable-native-libs seems to always print
> the "incompatible runtime system" warning for native compiled modules.
> R15 only does that if for example smp was explicitly disabled on start.
>
> <HiPE (v 3.9.3)> Warning: not loading native code for module sets: it
> was compiled for an incompatible runtime system; please regenerate
> native code for this runtime system
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
>   



From dan353hehe@REDACTED  Wed Jan  9 18:47:45 2013
From: dan353hehe@REDACTED (Daniel Barney)
Date: Wed, 9 Jan 2013 10:47:45 -0700
Subject: [erlang-bugs] ssl memory leak
Message-ID: <CAMzr5DoVZ-Kw9UiEnNgTQf0tHkGayuq+BOrjNJHhkbrcM6yntQ@mail.gmail.com>

Hey guys so this is what i'm seeing. I'm trying to debug this issue
and have found a few things but I am still missing something.

I'm upgrading a tcp connection so an ssl connection manually. mostly
because i need to serve different certificates, and starting up
another listener to listen on the same port but a different ip address
is just a little cumbersome. So i have one listener that upgrades a
connection based on which ip the client connects to. Right now I have
200+ ip addresses on the machine that have certs associated with them.

This is how i am doing it:

ssl:ssl_accept(Socket,[{active,false},{verify, verify_none}] ++ Certs)

where Socket is a gen_tcp socket. and Certs is a proplist containing
the paths to the certs.

The problem that I am seeing is two ets tables grow linearly as the
system accepts encrypted requests. the tables that grow are the
'ssl_otp_cacertificate_db' and 'ssl_otp_ca_file_ref'. both tables are
started and managed by the ssl_manager process.

I have found one memory leak submitted a patch to fix it, but it has
never shown up on the erlang-patches list. I will include it here

this is the patch that fixes around 90% of the leaks that i saw:

https://gist.github.com/4495139

i put it in a gist, because gmail will mangle it. What the patch does
is it sends the cleaning message to the ssl_manager process, instead
of the ssl_connection process that is requesting the cleaning.

The patch fixes a lot of the leaking. Before applying the patch every
single time a tcp connection was upgraded, the certs would be leaked
and never removed from the 'ssl_otp_cacertificate_db' table. After the
patch, almost all of them are removed, but something is happening that
i can't see, and it is still not removing the certificates from the
table.

This normally grinds my servers to a halt after 2 days, which means
right now I have to log in and restart them every day. So i would
really appreciate any help to track this issue down.

looking for some help,
Daniel


From Ingela.Anderton.Andin@REDACTED  Thu Jan 10 10:13:51 2013
From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin)
Date: Thu, 10 Jan 2013 10:13:51 +0100
Subject: [erlang-bugs] ssl memory leak
In-Reply-To: <CAMzr5DoVZ-Kw9UiEnNgTQf0tHkGayuq+BOrjNJHhkbrcM6yntQ@mail.gmail.com>
References: <CAMzr5DoVZ-Kw9UiEnNgTQf0tHkGayuq+BOrjNJHhkbrcM6yntQ@mail.gmail.com>
Message-ID: <50EE864F.2040502@ericsson.com>

Hi!

Daniel Barney wrote:
> Hey guys so this is what i'm seeing. I'm trying to debug this issue
> and have found a few things but I am still missing something.
> 
> I'm upgrading a tcp connection so an ssl connection manually. mostly
> because i need to serve different certificates, and starting up
> another listener to listen on the same port but a different ip address
> is just a little cumbersome. So i have one listener that upgrades a
> connection based on which ip the client connects to. Right now I have
> 200+ ip addresses on the machine that have certs associated with them.
> 
> This is how i am doing it:
> 
> ssl:ssl_accept(Socket,[{active,false},{verify, verify_none}] ++ Certs)
> 
> where Socket is a gen_tcp socket. and Certs is a proplist containing
> the paths to the certs.
> 
> The problem that I am seeing is two ets tables grow linearly as the
> system accepts encrypted requests. the tables that grow are the
> 'ssl_otp_cacertificate_db' and 'ssl_otp_ca_file_ref'. both tables are
> started and managed by the ssl_manager process.
> 
> I have found one memory leak submitted a patch to fix it, but it has
> never shown up on the erlang-patches list. I will include it here
> 
> this is the patch that fixes around 90% of the leaks that i saw:
> 
> https://gist.github.com/4495139

Good catch, the function used to only be called by the manager but it
was changed when trying to remove bottlenecks. I will apply the patch
for R16.

> i put it in a gist, because gmail will mangle it. What the patch does
> is it sends the cleaning message to the ssl_manager process, instead
> of the ssl_connection process that is requesting the cleaning.
> 
> The patch fixes a lot of the leaking. Before applying the patch every
> single time a tcp connection was upgraded, the certs would be leaked
> and never removed from the 'ssl_otp_cacertificate_db' table. After the
> patch, almost all of them are removed, but something is happening that
> i can't see, and it is still not removing the certificates from the
> table.
> 
> This normally grinds my servers to a halt after 2 days, which means
> right now I have to log in and restart them every day. So i would
> really appreciate any help to track this issue down.
> 
> looking for some help,
> Daniel

You can mail me privately if you want and maybe give me more details to 
go on. We are of course interested in finding and fixing all potential 
problems.

Regards Ingela Erlang/OTP team - Ericsson AB


From tuncer.ayaz@REDACTED  Thu Jan 10 18:36:27 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Thu, 10 Jan 2013 18:36:27 +0100
Subject: [erlang-bugs] "incompatible runtime system" always reported in
	R16
In-Reply-To: <50EC5BF0.7090507@erix.ericsson.se>
References: <CAOvwQ4i38bUSCDt7h8g3FofrRS6fSBOmqw9s+tW9h3KfK0RY6g@mail.gmail.com>
 <50EC5BF0.7090507@erix.ericsson.se>
Message-ID: <CAOvwQ4g4BkRR2UT0pg+8ZM-+rif+9jVfU1RA6ECwuX=t87uD5w@mail.gmail.com>

On Tue, Jan 8, 2013 at 6:48 PM, Sverker Eriksson wrote:
> Thanks for the reminder.
> I have merged the fixing commit f4522c6f39d2eb to master now and it will
> show up on github when our admin does the next push.

Thanks, f4522c6f39d2eb works.

> /Sverker
>
> Tuncer Ayaz wrote:
>>
>> otp.git 3e8a6c8 built with --enable-native-libs seems to always print
>> the "incompatible runtime system" warning for native compiled modules.
>> R15 only does that if for example smp was explicitly disabled on start.
>>
>> <HiPE (v 3.9.3)> Warning: not loading native code for module sets: it
>> was compiled for an incompatible runtime system; please regenerate
>> native code for this runtime system


From tuncer.ayaz@REDACTED  Thu Jan 10 18:49:41 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Thu, 10 Jan 2013 18:49:41 +0100
Subject: [erlang-bugs] R16 Dialyzer bad_crc error
In-Reply-To: <CAOvwQ4hvHkwkweFeZD=iTyR62ZAC3DXpvVSyO-4+xVxaDUt2XA@mail.gmail.com>
References: <CAOvwQ4hvHkwkweFeZD=iTyR62ZAC3DXpvVSyO-4+xVxaDUt2XA@mail.gmail.com>
Message-ID: <CAOvwQ4go_XC3Ji2CVYjegsgFwXtV7B++4feT=WaU7FW97Vdy9g@mail.gmail.com>

On Tue, Jan 8, 2013 at 5:00 PM, Tuncer Ayaz wrote:
> dialyzer --build_plt with otp.git 3e8a6c8 fails as follows:
> {"init terminating in do_boot",{{badmatch,{error,bad_crc}},
>   [{hipe,finalize,5,[{file,"hipe.erl"},{line,740}]},
>    {hipe,compile_finish,3,[{file,"hipe.erl"},{line,697}]},
>    {hipe,'-run_compiler_1/3-fun-0-',4,[{file,"hipe.erl"},{line,658}]}]
>   }}
>
> Maybe it's a known but not yet resolved issue caused by the major
> code loader changes happening in R16.

This is fixed as of today's master update, but now Dialyzer fails
to extract core Erlang code from two erlydtl beams. If the beams
were not compiled with debug_info, Dialyzer would have warned
about extracting abstract code (not core Erlang code) instead.

To reproduce:
$ git clone git://github.com/evanmiller/erlydtl.git
$ cd erlydtl
$ make
$ dialyzer --build_plt --output_plt test_plt ebin
  Creating PLT test_plt ...
dialyzer: Analysis failed with error:
Could not scan the following file(s):
[{"/tmp/foo/ebin/erlydtl_slice.beam",
"  Could not get core Erlang code for: /tmp/foo/ebin/erlydtl_slice.beam"},
{"/tmp/foo/ebin/erlydtl_filters.beam",
"  Could not get core Erlang code for: /tmp/foo/ebin/erlydtl_filters.beam"}]


From tuncer.ayaz@REDACTED  Thu Jan 10 18:59:29 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Thu, 10 Jan 2013 18:59:29 +0100
Subject: [erlang-bugs] make/fakefop skipped/unused in R16?
Message-ID: <CAOvwQ4jF8dNV7kivnLiQNrCKOhg7Dc7tg6a38vXG4k+Ktoapng@mail.gmail.com>

It seems that for some reason fakefop is not used and therefore the
placeholder PDF files are not generated. otp git rev used: 4cd517c.

$ make docs
$ make install-docs
[...]
/usr/bin/install -c -d
"/tmp/otp/master/localinstall/lib/erlang/lib/stdlib-1.19/doc/pdf"
/usr/bin/install -c -m 644 ../pdf/stdlib-1.19.pdf
    "/tmp/otp/master/localinstall/lib/erlang/lib/stdlib-1.19/doc/pdf"
/usr/bin/install: cannot stat '../pdf/stdlib-1.19.pdf': No such file
or directory
make[5]: *** [release_docs_spec] Error 1

Thoughts?


From tuncer.ayaz@REDACTED  Fri Jan 11 14:40:56 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Fri, 11 Jan 2013 14:40:56 +0100
Subject: [erlang-bugs] make/fakefop skipped/unused in R16?
In-Reply-To: <CAOvwQ4jF8dNV7kivnLiQNrCKOhg7Dc7tg6a38vXG4k+Ktoapng@mail.gmail.com>
References: <CAOvwQ4jF8dNV7kivnLiQNrCKOhg7Dc7tg6a38vXG4k+Ktoapng@mail.gmail.com>
Message-ID: <CAOvwQ4gjSboQp7cH2m+Hn0L-Mzd-jKz2VTZw57WdR7B=mqnyaQ@mail.gmail.com>

On Thu, Jan 10, 2013 at 6:59 PM, Tuncer Ayaz wrote:
> It seems that for some reason fakefop is not used and therefore the
> placeholder PDF files are not generated. otp git rev used: 4cd517c.
>
> $ make docs
> $ make install-docs
> [...]
> /usr/bin/install -c -d
> "/tmp/otp/master/localinstall/lib/erlang/lib/stdlib-1.19/doc/pdf"
> /usr/bin/install -c -m 644 ../pdf/stdlib-1.19.pdf
>     "/tmp/otp/master/localinstall/lib/erlang/lib/stdlib-1.19/doc/pdf"
> /usr/bin/install: cannot stat '../pdf/stdlib-1.19.pdf': No such file
> or directory
> make[5]: *** [release_docs_spec] Error 1
>
> Thoughts?

Hans, I've adapted make/fakefop to your make/otp.mk.in changes:
https://github.com/tuncer/otp/compare/master...fakefop

This fixes the regression, but I'm seeing warning/error messages from
mupdf:
$ make/fakefop -c foo -fo foo -pdf test.pdf
$ mupdf test.pdf
error: cannot recognize xref format: '['
error: cannot read trailer
warning: trying to repair broken xref

Also, pdf.js does not seem to render it at all.

Any idea what part of a placeholder PDF is broken?


From n.oxyde@REDACTED  Fri Jan 11 17:12:37 2013
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Fri, 11 Jan 2013 17:12:37 +0100
Subject: [erlang-bugs] Local function names in Core Erlang guards
In-Reply-To: <6BADBA9E-8FD4-4051-B960-A13B64A20B53@gmail.com>
References: <6BADBA9E-8FD4-4051-B960-A13B64A20B53@gmail.com>
Message-ID: <D05422FA-4B09-4170-84D0-5EE9AF7A369F@gmail.com>

Hi,

I wrote a really small patch to forbid local fun variables in Core Erlang guards.
There is no test case as there is no test suite for core_lint.

I know the code freeze for R16 is soon but this is really a very small thing.

	git fetch https://github.com/nox/otp.git forbid-locals-in-core-guards

	https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards
	https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch

Regards,

-- 
Anthony Ramine

Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit :

> Hi,
> 
> While patching the compiler to allow substitutions of variables which values are
> local function names [1], I discovered that core_lint doesn't forbid them in guards,
> even though that makes the compiler passes further down the road generate badly-formed
> BEAM code.
> 
> Is that a bug in core_lint or a bug in the BEAM code generation? Should local function
> names be allowed in guards?
> 
> If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM
> code generation I would love to fix it and remove the code I wrote to avoid the
> substitution in guards... but I lack knowledge about the BEAM innards.
> 
> Regards,
> 
> [1] http://erlang.org/pipermail/erlang-patches/2012-November/003137.html
> 
> -- 
> Anthony Ramine
> 



From tuncer.ayaz@REDACTED  Sat Jan 12 15:38:08 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Sat, 12 Jan 2013 15:38:08 +0100
Subject: [erlang-bugs] make/fakefop skipped/unused in R16?
In-Reply-To: <CAOvwQ4gjSboQp7cH2m+Hn0L-Mzd-jKz2VTZw57WdR7B=mqnyaQ@mail.gmail.com>
References: <CAOvwQ4jF8dNV7kivnLiQNrCKOhg7Dc7tg6a38vXG4k+Ktoapng@mail.gmail.com>
 <CAOvwQ4gjSboQp7cH2m+Hn0L-Mzd-jKz2VTZw57WdR7B=mqnyaQ@mail.gmail.com>
Message-ID: <CAOvwQ4g2tp91Rfy4GZvyCKv2KLq-kHGsuW66qdo2tpS11tE9Rg@mail.gmail.com>

On Fri, Jan 11, 2013 at 2:40 PM, Tuncer Ayaz wrote:
> On Thu, Jan 10, 2013 at 6:59 PM, Tuncer Ayaz wrote:
>> It seems that for some reason fakefop is not used and therefore the
>> placeholder PDF files are not generated. otp git rev used: 4cd517c.
>>
>> $ make docs
>> $ make install-docs
>> [...]
>> /usr/bin/install -c -d
>> "/tmp/otp/master/localinstall/lib/erlang/lib/stdlib-1.19/doc/pdf"
>> /usr/bin/install -c -m 644 ../pdf/stdlib-1.19.pdf
>>     "/tmp/otp/master/localinstall/lib/erlang/lib/stdlib-1.19/doc/pdf"
>> /usr/bin/install: cannot stat '../pdf/stdlib-1.19.pdf': No such file
>> or directory
>> make[5]: *** [release_docs_spec] Error 1
>>
>> Thoughts?
>
> Hans, I've adapted make/fakefop to your make/otp.mk.in changes:
> https://github.com/tuncer/otp/compare/master...fakefop

All issues resolved and patch mail sent to erlang-patches@REDACTED

> This fixes the regression, but I'm seeing warning/error messages from
> mupdf:
> $ make/fakefop -c foo -fo foo -pdf test.pdf
> $ mupdf test.pdf
> error: cannot recognize xref format: '['
> error: cannot read trailer
> warning: trying to repair broken xref
>
> Also, pdf.js does not seem to render it at all.
>
> Any idea what part of a placeholder PDF is broken?


From horst_@REDACTED  Mon Jan 14 07:23:39 2013
From: horst_@REDACTED (Horst Mani)
Date: Mon, 14 Jan 2013 07:23:39 +0100
Subject: [erlang-bugs] SSL issue
Message-ID: <DUB002-W5922E4A57F811BF9DD4F7CF12E0@phx.gbl>

Hi,
I ty to connect to a ssl server with the following command:
ssl:connect(HOST, 636, []).SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown{error,"certificate unknown"}
After debugging the problem, i found that the error occurs inside the public_key module. Please, have a look at my testcase which you can find here : https://gist.github.com/4525223
Note: The ssl connect works with other clients. 
Env : R15B03 32 bit, build by erlang-solutions, OSX 10.7.5, public_key-0.17
I hope that i gave you all the informations you need to fix the problem. I would do it by my own,but i don't know the expected behavior.
Best Regards,Ulf 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130114/5c264a28/attachment.htm>

From ingela.anderton.andin@REDACTED  Mon Jan 14 09:39:50 2013
From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin)
Date: Mon, 14 Jan 2013 09:39:50 +0100
Subject: [erlang-bugs] SSL issue
In-Reply-To: <DUB002-W5922E4A57F811BF9DD4F7CF12E0@phx.gbl>
References: <DUB002-W5922E4A57F811BF9DD4F7CF12E0@phx.gbl>
Message-ID: <50F3C456.9060703@erix.ericsson.se>

Hi!

Looking at your cert,  the values of  authorityCertIssuer, 
authorityCertSerialNumber in #AuthorityKeyIdentifier, are asn1_NOVALUE.
so then it is logical that public_key can not find the issuer.  

pubkey_cert:select_extension/2 -> {'Extension',
                                                            {2,5,29,35},
                                                            false,
                                                            
{'AuthorityKeyIdentifier',
                                                             
[192,122,152,104,
                                                              
141,137,251,171,
                                                              
5,100,12,17,125,
                                                              
170,125,101,184,
                                                              202,204,78],
                                                             asn1_NOVALUE,
                                                             asn1_NOVALUE}}
(<0.43.0>) call 
pubkey_cert:cert_auth_key_id({'AuthorityKeyIdentifier',[192,122,152,104,141,137,251,171,5,100,12,17,125,
                           170,125,101,184,202,204,78],
                          asn1_NOVALUE,asn1_NOVALUE})
(<0.43.0>) returned from pubkey_cert:cert_auth_key_id/1 -> {error,
                                                            
issuer_not_found}


Some old certs does not properly specify the AuthorityKeyIdentifier the 
fallback is to search the entire known CA database which ssl will do if 
it has one, you have
not specified any CA-certs in your call to ssl:connect.  You should try 
doing that.

Regards Ingela Erlang/OTP team - Ericsson AB

Horst Mani wrote:
> Hi,
>
> I ty to connect to a ssl server with the following command:
>
> ssl:connect(HOST, 636, []).
> SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
> {error,"certificate unknown"}
>
> After debugging the problem, i found that the error occurs inside the 
> public_key module. 
> Please, have a look at my testcase which you can find here : 
> https://gist.github.com/4525223
>
> Note: The ssl connect works with other clients. 
>
> Env : R15B03 32 bit, build by erlang-solutions, OSX 10.7.5, 
> public_key-0.17
>
> I hope that i gave you all the informations you need to fix the 
> problem. I would do it by my own,
> but i don't know the expected behavior.
>
> Best Regards,
> Ulf
> ------------------------------------------------------------------------
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>   



From tony@REDACTED  Mon Jan 14 15:00:31 2013
From: tony@REDACTED (Tony Rogvall)
Date: Mon, 14 Jan 2013 15:00:31 +0100
Subject: [erlang-bugs] system_info crash
Message-ID: <4EAE5D56-FD5F-4175-BDDE-A72F62C6531B@rogvall.se>

While designing a system_info debug tool I found this:


7> erlang:system_info(stop_memory_trace).
../include/internal/ethr_mutex.h:655: Fatal error in ethr_mutex_lock(): Invalid argument (22)
             Abort trap: 6

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

uname -a
Darwin p13.local 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64

/Tony





From horst_@REDACTED  Tue Jan 15 15:30:09 2013
From: horst_@REDACTED (Horst Mani)
Date: Tue, 15 Jan 2013 15:30:09 +0100
Subject: [erlang-bugs] FW:  SSL issue
In-Reply-To: <DUB002-W3CB42036F080B1BDE5B4CF12D0@phx.gbl>
References: <DUB002-W5922E4A57F811BF9DD4F7CF12E0@phx.gbl>,
 <50F3C456.9060703@erix.ericsson.se>,
 <DUB002-W3CB42036F080B1BDE5B4CF12D0@phx.gbl>
Message-ID: <DUB002-W7650D2F5944702C66652CF12D0@phx.gbl>



From: horst_@REDACTED
To: ingela.anderton.andin@REDACTED
Subject: RE: [erlang-bugs] SSL issue
Date: Tue, 15 Jan 2013 09:39:12 +0100




Hi,
thanks for the quick answer.
Now, i tried to connect to the server as follow:
ssl:connect(HOST, 636, [{cacertfile, "EquifaxSecureCA.pem"}, {verify, verify_none}]).=ERROR REPORT==== 15-Jan-2013::09:33:14 ===SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown{error,"certificate unknown"}
As i understand from your last mail, the client needs a server certificate with the following informations:








Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
	X509v3 Subject Key Identifier:   48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
This informations are included in the EquifaxSecureCA.pem which i added as a cacertfile to the connect function,but i got the same result.
Please, can you tell me, what i am doing wrong?
Thanks and best regards,Ulf




> Date: Mon, 14 Jan 2013 09:39:50 +0100
> From: ingela.anderton.andin@REDACTED
> To: horst_@REDACTED
> CC: erlang-bugs@REDACTED
> Subject: Re: [erlang-bugs] SSL issue
> 
> Hi!
> 
> Looking at your cert,  the values of  authorityCertIssuer, 
> authorityCertSerialNumber in #AuthorityKeyIdentifier, are asn1_NOVALUE.
> so then it is logical that public_key can not find the issuer.  
> 
> pubkey_cert:select_extension/2 -> {'Extension',
>                                                             {2,5,29,35},
>                                                             false,
>                                                             
> {'AuthorityKeyIdentifier',
>                                                              
> [192,122,152,104,
>                                                               
> 141,137,251,171,
>                                                               
> 5,100,12,17,125,
>                                                               
> 170,125,101,184,
>                                                               202,204,78],
>                                                              asn1_NOVALUE,
>                                                              asn1_NOVALUE}}
> (<0.43.0>) call 
> pubkey_cert:cert_auth_key_id({'AuthorityKeyIdentifier',[192,122,152,104,141,137,251,171,5,100,12,17,125,
>                            170,125,101,184,202,204,78],
>                           asn1_NOVALUE,asn1_NOVALUE})
> (<0.43.0>) returned from pubkey_cert:cert_auth_key_id/1 -> {error,
>                                                             
> issuer_not_found}
> 
> 
> Some old certs does not properly specify the AuthorityKeyIdentifier the 
> fallback is to search the entire known CA database which ssl will do if 
> it has one, you have
> not specified any CA-certs in your call to ssl:connect.  You should try 
> doing that.
> 
> Regards Ingela Erlang/OTP team - Ericsson AB
> 
> Horst Mani wrote:
> > Hi,
> >
> > I ty to connect to a ssl server with the following command:
> >
> > ssl:connect(HOST, 636, []).
> > SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
> > {error,"certificate unknown"}
> >
> > After debugging the problem, i found that the error occurs inside the 
> > public_key module. 
> > Please, have a look at my testcase which you can find here : 
> > https://gist.github.com/4525223
> >
> > Note: The ssl connect works with other clients. 
> >
> > Env : R15B03 32 bit, build by erlang-solutions, OSX 10.7.5, 
> > public_key-0.17
> >
> > I hope that i gave you all the informations you need to fix the 
> > problem. I would do it by my own,
> > but i don't know the expected behavior.
> >
> > Best Regards,
> > Ulf
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > erlang-bugs mailing list
> > erlang-bugs@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-bugs
> >   
> 
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130115/49c2f5cd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EquifaxSecureCA.pem
Type: application/octet-stream
Size: 1143 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130115/49c2f5cd/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cert_chain.txt
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130115/49c2f5cd/attachment.txt>

From dan353hehe@REDACTED  Tue Jan 15 19:41:50 2013
From: dan353hehe@REDACTED (Daniel Barney)
Date: Tue, 15 Jan 2013 11:41:50 -0700
Subject: [erlang-bugs] SSL connection upgrade hangs when timeout is
	specified.
Message-ID: <CAMzr5Doiu5h6CYjibik3b5rt1f3QSZaddU-sXr5QkSz3J1RopA@mail.gmail.com>

Hey Guys,

I'm running R15B03

So i have noticed that the ssl upgrade process hangs even when I have
specified a timeout. After about 2 days, I have 2000+ processes that
sit around and are just waiting, and they never seem to finish the
upgrade process or timeout.

Here is how I am upgrading a tcp to an ssl socket:

%% looks pretty standard to me
%% Socket is a gen_tcp socket

Cert = "cert.crt",
Key = "key.key",
CaCert = "cacert.ca.crt",
Certs = [
		{certfile, Cert}
		,{keyfile, Key}
		,{cacertfile,CaCert}],

ssl:ssl_accept(Socket,[{active,false},{verify, verify_none}] ++
Certs,10000) %% this line doesn't timeout, but not all the time.

Here is what erlang:process_display/2 shows for both processes, this
is just to show where the pair of processes are stuck. I also removed
all sensitive data:

Program counter: 0x00007fc236450618 (gen:do_call/4 + 576)
CP: 0x0000000000000000 (invalid)
arity = 0

0x00007fc21f1c8360 Return addr 0x00007fc2338fa480
(gen_fsm:sync_send_all_state_event/3 + 128)
y(0)     #Ref<0.0.62.36895>
y(1)     'baker@REDACTED'
y(2)     []
y(3)     infinity
y(4)     {start,10000}
y(5)     '$gen_sync_all_state_event'
y(6)     <0.4415.47>

0x00007fc21f1c83a0 Return addr 0x00007fc232730d80
(ssl_connection:sync_send_all_state_event/2 + 80)
y(0)     infinity
y(1)     {start,10000}
y(2)     <0.4415.47>
y(3)     Catch 0x00007fc2338fa480 (gen_fsm:sync_send_all_state_event/3 + 128)

0x00007fc21f1c83c8 Return addr 0x00007fc2327242b0
(ssl_connection:handshake/2 + 200)
y(0)     Catch 0x00007fc232730da0
(ssl_connection:sync_send_all_state_event/2 + 112)

0x00007fc21f1c83d8 Return addr 0x00007fc23272ee60
(ssl_connection:start_fsm/8 + 776)

0x00007fc21f1c83e0 Return addr 0x00007fc2327240f0
(ssl_connection:ssl_accept/6 + 152)
y(0)     []
y(1)     []
y(2)     {sslsocket,new_ssl,<0.4415.47>}
y(3)     Catch 0x00007fc23272eeb8 (ssl_connection:start_fsm/8 + 864)

0x00007fc21f1c8408 Return addr 0x00007fc2320e51a0
(baker_https:encryptConnection/3 + 472)
y(0)     Catch 0x00007fc232724110 (ssl_connection:ssl_accept/6 + 184)

0x00007fc21f1c8418 Return addr 0x000000000087f8a8 (<terminate process normally>)
y(0)     Catch 0x00007fc2320e54c0 (baker_https:encryptConnection/3 + 1272)
y(1)     baker_http
y(2)     []
y(3)     [{cert_ip,{_,_,_,_}}] % removed by daniel
y(4)     []





Program counter: 0x00007fc2338fbd38 (gen_fsm:loop/7 + 280)
CP: 0x0000000000000000 (invalid)
arity = 0

0x00007fc21d842fa0 Return addr 0x00007fc233aea768
(proc_lib:init_p_do_apply/3 + 56)
y(0)     []
y(1)     infinity
y(2)     ssl_connection
y(3)     {state,server,{#Ref<0.0.62.36893>,<0.4414.47>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",443,#Port<0.3254116>,{ssl_options,[],verify_none,{#Fun<ssl.1.127417028>,[]},false,false,undefined,1,<<43
bytes>>,undefined,<<43 bytes>>,undefined,undefined,undefined,<<46
bytes>>,undefined,undefined,[<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2
bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2
bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2
bytes>>],#Fun<ssl.0.127417028>,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,false},{connection_states,{connection_state,{security_parameters,<<2
bytes>>,0,0,0,0,0,0,0,0,0,0,0,undefined,undefined,undefined,undefined},undefined,undefined,undefined,1,true,undefined,undefined},{connection_state,{security_parameters,<<2
bytes>>,0,7,1,16,256,32,unknown,2,4711,20,0,undefined,<<32
bytes>>,<<32 bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2
bytes>>,0,0,0,0,0,0,0,0,0,0,0,undefined,undefined,undefined,undefined},undefined,undefined,undefined,4,true,undefined,undefined},{connection_state,{security_parameters,<<2
bytes>>,0,7,1,16,256,32,unknown,2,4711,20,0,undefined,<<32
bytes>>,<<32 bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0
bytes>>,<<0 bytes>>,{[[14,<<3 bytes>>,<<0 bytes>>],[12,<<3
bytes>>,<<522 bytes>>],[11,<<3 bytes>>,<<2243 bytes>>],[2,<<3
bytes>>,<<77 bytes>>],<<221 bytes>>],[[12,<<3 bytes>>,<<522
bytes>>],[11,<<3 bytes>>,<<2243 bytes>>],[2,<<3 bytes>>,<<77
bytes>>],<<221 bytes>>]},[],12305,{session,<<32
bytes>>,undefined,<<1249 bytes>>,0,<<2
bytes>>,undefined,new,63525415061},24596,ssl_session_cache,{3,1},undefined,false,dhe_rsa,{md5sha,rsa},undefined,{'RSAPrivateKey','two-prime',REMOVED
PRIME KEY STUFF ,asn1_NOVALUE},{'DHParameter',REMOVED DH
PARAMETERS,2,asn1_NOVALUE},{<<132 bytes>>,<<132
bytes>>},undefined,16402,#Ref<0.0.62.1224>,0,<<0
bytes>>,true,{false,first},{<0.4414.47>,#Ref<0.0.62.36895>},{[],[]},false,true}
y(4)     certify
y(5)     <0.4415.47>
y(6)     <0.536.0>

0x00007fc21d842fe0 Return addr 0x000000000087f8a8 (<terminate process normally>)
y(0)     Catch 0x00007fc233aea788 (proc_lib:init_p_do_apply/3 + 88)


And here is what erlang:process_info shows:

%% the gen_fsm:
[{current_function,{gen_fsm,loop,7}},
 {initial_call,{proc_lib,init_p,5}},
 {status,waiting},
 {message_queue_len,0},
 {messages,[]},
 {links,[<0.536.0>,#Port<0.3254116>]},
 {dictionary,[{ssl_manager,ssl_manager},
              {'$ancestors',[ssl_connection_sup,ssl_sup,<0.533.0>]},
              {'$initial_call',{ssl_connection,init,1}}]},
 {trap_exit,false},
 {error_handler,error_handler},
 {priority,normal},
 {group_leader,<0.532.0>},
 {total_heap_size,13530},
 {heap_size,6765},
 {stack_size,10},
 {reductions,16537},
 {garbage_collection,[{min_bin_vheap_size,46368},
                      {min_heap_size,233},
                      {fullsweep_after,65535},
                      {minor_gcs,20}]},
 {suspending,[]}]


%% the process requesting the upgrade:
[{current_function,{gen,do_call,4}},
 {initial_call,{baker_https,clientName,3}},
 {status,waiting},
 {message_queue_len,0},
 {messages,[]},
 {links,[<0.867.0>]},
 {dictionary,[]},
 {trap_exit,false},
 {error_handler,error_handler},
 {priority,normal},
 {group_leader,<0.548.0>},
 {total_heap_size,1974},
 {heap_size,987},
 {stack_size,29},
 {reductions,964},
 {garbage_collection,[{min_bin_vheap_size,46368},
                      {min_heap_size,233},
                      {fullsweep_after,65535},
                      {minor_gcs,2}]},
 {suspending,[]}]

As far as i can tell, the process that requests the connection be
upgrades drops down into a gen_fsm:sync_send_all_state_event that has
a timeout of infinity. The only problem seems to be that the
ssl_connection fsm never receives or never replies to the request, as
its message queue is 0. At least that is what I am seeing, I do not
know what causes the behaviour as it only happens on a live server,
and I haven't been able to replicate it in any tests that I have tried
to write. So i'm not sure why it is happening.

Does anyone know where i could start looking to debug this issue further?
Daniel


From Ingela.Anderton.Andin@REDACTED  Wed Jan 16 15:07:30 2013
From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin)
Date: Wed, 16 Jan 2013 15:07:30 +0100
Subject: [erlang-bugs] FW:  SSL issue
In-Reply-To: <DUB002-W7650D2F5944702C66652CF12D0@phx.gbl>
References: <DUB002-W5922E4A57F811BF9DD4F7CF12E0@phx.gbl>,
 <50F3C456.9060703@erix.ericsson.se>,
 <DUB002-W3CB42036F080B1BDE5B4CF12D0@phx.gbl>
 <DUB002-W7650D2F5944702C66652CF12D0@phx.gbl>
Message-ID: <50F6B422.4020205@ericsson.com>

Hi!

The attached PEM-file is broken! It is missing -----END CERTIFICATE-----
and some data that ought to come before the ending tag.

Regards Ingela Erlang/OTP team - Ericsson AB

Horst Mani wrote:
> 
> 
> ------------------------------------------------------------------------
> From: horst_@REDACTED
> To: ingela.anderton.andin@REDACTED
> Subject: RE: [erlang-bugs] SSL issue
> Date: Tue, 15 Jan 2013 09:39:12 +0100
> 
> Hi,
> 
> thanks for the quick answer.
> 
> Now, i tried to connect to the server as follow:
> 
> ssl:connect(HOST, 636, [{cacertfile, "EquifaxSecureCA.pem"}, {verify, 
> verify_none}]).
> =ERROR REPORT==== 15-Jan-2013::09:33:14 ===
> SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
> {error,"certificate unknown"}
> 
> As i understand from your last mail, the client needs a server 
> certificate with the following informations:
> 
> Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
> 
> X509v3 Subject Key Identifier: 
>   48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
> 
> 
> This informations are included in the EquifaxSecureCA.pem which i added 
> as a cacertfile to the connect function,
> 
> but i got the same result.
> 
> 
> Please, can you tell me, what i am doing wrong?
> 
> 
> Thanks and best regards,
> 
> Ulf
> 
> 
> 
> 
> 
> 
>  > Date: Mon, 14 Jan 2013 09:39:50 +0100
>  > From: ingela.anderton.andin@REDACTED
>  > To: horst_@REDACTED
>  > CC: erlang-bugs@REDACTED
>  > Subject: Re: [erlang-bugs] SSL issue
>  >
>  > Hi!
>  >
>  > Looking at your cert, the values of authorityCertIssuer,
>  > authorityCertSerialNumber in #AuthorityKeyIdentifier, are asn1_NOVALUE.
>  > so then it is logical that public_key can not find the issuer.
>  >
>  > pubkey_cert:select_extension/2 -> {'Extension',
>  > {2,5,29,35},
>  > false,
>  >
>  > {'AuthorityKeyIdentifier',
>  >
>  > [192,122,152,104,
>  >
>  > 141,137,251,171,
>  >
>  > 5,100,12,17,125,
>  >
>  > 170,125,101,184,
>  > 202,204,78],
>  > asn1_NOVALUE,
>  > asn1_NOVALUE}}
>  > (<0.43.0>) call
>  > 
> pubkey_cert:cert_auth_key_id({'AuthorityKeyIdentifier',[192,122,152,104,141,137,251,171,5,100,12,17,125,
>  > 170,125,101,184,202,204,78],
>  > asn1_NOVALUE,asn1_NOVALUE})
>  > (<0.43.0>) returned from pubkey_cert:cert_auth_key_id/1 -> {error,
>  >
>  > issuer_not_found}
>  >
>  >
>  > Some old certs does not properly specify the AuthorityKeyIdentifier the
>  > fallback is to search the entire known CA database which ssl will do if
>  > it has one, you have
>  > not specified any CA-certs in your call to ssl:connect. You should try
>  > doing that.
>  >
>  > Regards Ingela Erlang/OTP team - Ericsson AB
>  >
>  > Horst Mani wrote:
>  > > Hi,
>  > >
>  > > I ty to connect to a ssl server with the following command:
>  > >
>  > > ssl:connect(HOST, 636, []).
>  > > SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
>  > > {error,"certificate unknown"}
>  > >
>  > > After debugging the problem, i found that the error occurs inside the
>  > > public_key module.
>  > > Please, have a look at my testcase which you can find here :
>  > > https://gist.github.com/4525223
>  > >
>  > > Note: The ssl connect works with other clients.
>  > >
>  > > Env : R15B03 32 bit, build by erlang-solutions, OSX 10.7.5,
>  > > public_key-0.17
>  > >
>  > > I hope that i gave you all the informations you need to fix the
>  > > problem. I would do it by my own,
>  > > but i don't know the expected behavior.
>  > >
>  > > Best Regards,
>  > > Ulf
>  > > 
> ------------------------------------------------------------------------
>  > >
>  > > _______________________________________________
>  > > erlang-bugs mailing list
>  > > erlang-bugs@REDACTED
>  > > http://erlang.org/mailman/listinfo/erlang-bugs
>  > >
>  >



From Ingela.Anderton.Andin@REDACTED  Wed Jan 16 15:09:09 2013
From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin)
Date: Wed, 16 Jan 2013 15:09:09 +0100
Subject: [erlang-bugs] SSL connection upgrade hangs when timeout
	is	specified.
In-Reply-To: <CAMzr5Doiu5h6CYjibik3b5rt1f3QSZaddU-sXr5QkSz3J1RopA@mail.gmail.com>
References: <CAMzr5Doiu5h6CYjibik3b5rt1f3QSZaddU-sXr5QkSz3J1RopA@mail.gmail.com>
Message-ID: <50F6B485.3040500@ericsson.com>

Hi!

Is it R15B03 plain?  The reason I ask is:

R15B03-1 is an update of the previously released R15B03. R15B03 
contained a bug in ssl that affected accept calls with timeouts. Due to 
the widespread use of Erlang in i.e. webservers and other network 
application, we recommend everyone using R15B03 to take this update.

http://www.erlang.org/download.html

Regards Ingela Erlang/OTP team - Ericsson AB

Daniel Barney wrote:
> Hey Guys,
> 
> I'm running R15B03
> 
> So i have noticed that the ssl upgrade process hangs even when I have
> specified a timeout. After about 2 days, I have 2000+ processes that
> sit around and are just waiting, and they never seem to finish the
> upgrade process or timeout.
> 
> Here is how I am upgrading a tcp to an ssl socket:
> 
> %% looks pretty standard to me
> %% Socket is a gen_tcp socket
> 
> Cert = "cert.crt",
> Key = "key.key",
> CaCert = "cacert.ca.crt",
> Certs = [
> 		{certfile, Cert}
> 		,{keyfile, Key}
> 		,{cacertfile,CaCert}],
> 
> ssl:ssl_accept(Socket,[{active,false},{verify, verify_none}] ++
> Certs,10000) %% this line doesn't timeout, but not all the time.
> 
> Here is what erlang:process_display/2 shows for both processes, this
> is just to show where the pair of processes are stuck. I also removed
> all sensitive data:
> 
> Program counter: 0x00007fc236450618 (gen:do_call/4 + 576)
> CP: 0x0000000000000000 (invalid)
> arity = 0
> 
> 0x00007fc21f1c8360 Return addr 0x00007fc2338fa480
> (gen_fsm:sync_send_all_state_event/3 + 128)
> y(0)     #Ref<0.0.62.36895>
> y(1)     'baker@REDACTED'
> y(2)     []
> y(3)     infinity
> y(4)     {start,10000}
> y(5)     '$gen_sync_all_state_event'
> y(6)     <0.4415.47>
> 
> 0x00007fc21f1c83a0 Return addr 0x00007fc232730d80
> (ssl_connection:sync_send_all_state_event/2 + 80)
> y(0)     infinity
> y(1)     {start,10000}
> y(2)     <0.4415.47>
> y(3)     Catch 0x00007fc2338fa480 (gen_fsm:sync_send_all_state_event/3 + 128)
> 
> 0x00007fc21f1c83c8 Return addr 0x00007fc2327242b0
> (ssl_connection:handshake/2 + 200)
> y(0)     Catch 0x00007fc232730da0
> (ssl_connection:sync_send_all_state_event/2 + 112)
> 
> 0x00007fc21f1c83d8 Return addr 0x00007fc23272ee60
> (ssl_connection:start_fsm/8 + 776)
> 
> 0x00007fc21f1c83e0 Return addr 0x00007fc2327240f0
> (ssl_connection:ssl_accept/6 + 152)
> y(0)     []
> y(1)     []
> y(2)     {sslsocket,new_ssl,<0.4415.47>}
> y(3)     Catch 0x00007fc23272eeb8 (ssl_connection:start_fsm/8 + 864)
> 
> 0x00007fc21f1c8408 Return addr 0x00007fc2320e51a0
> (baker_https:encryptConnection/3 + 472)
> y(0)     Catch 0x00007fc232724110 (ssl_connection:ssl_accept/6 + 184)
> 
> 0x00007fc21f1c8418 Return addr 0x000000000087f8a8 (<terminate process normally>)
> y(0)     Catch 0x00007fc2320e54c0 (baker_https:encryptConnection/3 + 1272)
> y(1)     baker_http
> y(2)     []
> y(3)     [{cert_ip,{_,_,_,_}}] % removed by daniel
> y(4)     []
> 
> 
> 
> 
> 
> Program counter: 0x00007fc2338fbd38 (gen_fsm:loop/7 + 280)
> CP: 0x0000000000000000 (invalid)
> arity = 0
> 
> 0x00007fc21d842fa0 Return addr 0x00007fc233aea768
> (proc_lib:init_p_do_apply/3 + 56)
> y(0)     []
> y(1)     infinity
> y(2)     ssl_connection
> y(3)     {state,server,{#Ref<0.0.62.36893>,<0.4414.47>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",443,#Port<0.3254116>,{ssl_options,[],verify_none,{#Fun<ssl.1.127417028>,[]},false,false,undefined,1,<<43
> bytes>>,undefined,<<43 bytes>>,undefined,undefined,undefined,<<46
> bytes>>,undefined,undefined,[<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2
> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2
> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2
> bytes>>],#Fun<ssl.0.127417028>,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,false},{connection_states,{connection_state,{security_parameters,<<2
> bytes>>,0,0,0,0,0,0,0,0,0,0,0,undefined,undefined,undefined,undefined},undefined,undefined,undefined,1,true,undefined,undefined},{connection_state,{security_parameters,<<2
> bytes>>,0,7,1,16,256,32,unknown,2,4711,20,0,undefined,<<32
> bytes>>,<<32 bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2
> bytes>>,0,0,0,0,0,0,0,0,0,0,0,undefined,undefined,undefined,undefined},undefined,undefined,undefined,4,true,undefined,undefined},{connection_state,{security_parameters,<<2
> bytes>>,0,7,1,16,256,32,unknown,2,4711,20,0,undefined,<<32
> bytes>>,<<32 bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0
> bytes>>,<<0 bytes>>,{[[14,<<3 bytes>>,<<0 bytes>>],[12,<<3
> bytes>>,<<522 bytes>>],[11,<<3 bytes>>,<<2243 bytes>>],[2,<<3
> bytes>>,<<77 bytes>>],<<221 bytes>>],[[12,<<3 bytes>>,<<522
> bytes>>],[11,<<3 bytes>>,<<2243 bytes>>],[2,<<3 bytes>>,<<77
> bytes>>],<<221 bytes>>]},[],12305,{session,<<32
> bytes>>,undefined,<<1249 bytes>>,0,<<2
> bytes>>,undefined,new,63525415061},24596,ssl_session_cache,{3,1},undefined,false,dhe_rsa,{md5sha,rsa},undefined,{'RSAPrivateKey','two-prime',REMOVED
> PRIME KEY STUFF ,asn1_NOVALUE},{'DHParameter',REMOVED DH
> PARAMETERS,2,asn1_NOVALUE},{<<132 bytes>>,<<132
> bytes>>},undefined,16402,#Ref<0.0.62.1224>,0,<<0
> bytes>>,true,{false,first},{<0.4414.47>,#Ref<0.0.62.36895>},{[],[]},false,true}
> y(4)     certify
> y(5)     <0.4415.47>
> y(6)     <0.536.0>
> 
> 0x00007fc21d842fe0 Return addr 0x000000000087f8a8 (<terminate process normally>)
> y(0)     Catch 0x00007fc233aea788 (proc_lib:init_p_do_apply/3 + 88)
> 
> 
> And here is what erlang:process_info shows:
> 
> %% the gen_fsm:
> [{current_function,{gen_fsm,loop,7}},
>  {initial_call,{proc_lib,init_p,5}},
>  {status,waiting},
>  {message_queue_len,0},
>  {messages,[]},
>  {links,[<0.536.0>,#Port<0.3254116>]},
>  {dictionary,[{ssl_manager,ssl_manager},
>               {'$ancestors',[ssl_connection_sup,ssl_sup,<0.533.0>]},
>               {'$initial_call',{ssl_connection,init,1}}]},
>  {trap_exit,false},
>  {error_handler,error_handler},
>  {priority,normal},
>  {group_leader,<0.532.0>},
>  {total_heap_size,13530},
>  {heap_size,6765},
>  {stack_size,10},
>  {reductions,16537},
>  {garbage_collection,[{min_bin_vheap_size,46368},
>                       {min_heap_size,233},
>                       {fullsweep_after,65535},
>                       {minor_gcs,20}]},
>  {suspending,[]}]
> 
> 
> %% the process requesting the upgrade:
> [{current_function,{gen,do_call,4}},
>  {initial_call,{baker_https,clientName,3}},
>  {status,waiting},
>  {message_queue_len,0},
>  {messages,[]},
>  {links,[<0.867.0>]},
>  {dictionary,[]},
>  {trap_exit,false},
>  {error_handler,error_handler},
>  {priority,normal},
>  {group_leader,<0.548.0>},
>  {total_heap_size,1974},
>  {heap_size,987},
>  {stack_size,29},
>  {reductions,964},
>  {garbage_collection,[{min_bin_vheap_size,46368},
>                       {min_heap_size,233},
>                       {fullsweep_after,65535},
>                       {minor_gcs,2}]},
>  {suspending,[]}]
> 
> As far as i can tell, the process that requests the connection be
> upgrades drops down into a gen_fsm:sync_send_all_state_event that has
> a timeout of infinity. The only problem seems to be that the
> ssl_connection fsm never receives or never replies to the request, as
> its message queue is 0. At least that is what I am seeing, I do not
> know what causes the behaviour as it only happens on a live server,
> and I haven't been able to replicate it in any tests that I have tried
> to write. So i'm not sure why it is happening.
> 
> Does anyone know where i could start looking to debug this issue further?
> Daniel
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs



From horst_@REDACTED  Wed Jan 16 15:38:50 2013
From: horst_@REDACTED (Horst Mani)
Date: Wed, 16 Jan 2013 15:38:50 +0100
Subject: [erlang-bugs] FW:  SSL issue
In-Reply-To: <50F6B422.4020205@ericsson.com>
References: <DUB002-W5922E4A57F811BF9DD4F7CF12E0@phx.gbl>,
 <50F3C456.9060703@erix.ericsson.se>,
 <DUB002-W3CB42036F080B1BDE5B4CF12D0@phx.gbl>
 <DUB002-W7650D2F5944702C66652CF12D0@phx.gbl>,<50F6B422.4020205@ericsson.com>
Message-ID: <DUB002-W45B9AC1B042943D40CDB0F12C0@phx.gbl>

Hi,
perhaps it is broken during the upload, because localy the file seems ok.Now i will paste the EquifaxSecure.pem file also : 
-----BEGIN CERTIFICATE-----MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPRfM6fBeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+AcJkVV5MW8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kCAwEAAaOCAQkwggEFMHAGA1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoGA1UdEAQTMBGBDzIwMTgwODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvSspXXR9gjIBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQFMAMBAf8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUAA4GBAFjOKer89961zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y7qj/WsjTVbJmcVfewCHrPSqnI0kBBIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee9570+sB3c4-----END CERTIFICATE----- The cert_chain.txt contains the certificate chain from the server.
Best Regards,Ulf

> Date: Wed, 16 Jan 2013 15:07:30 +0100
> From: Ingela.Anderton.Andin@REDACTED
> To: horst_@REDACTED
> CC: erlang-bugs@REDACTED
> Subject: Re: [erlang-bugs] FW:  SSL issue
> 
> Hi!
> 
> The attached PEM-file is broken! It is missing -----END CERTIFICATE-----
> and some data that ought to come before the ending tag.
> 
> Regards Ingela Erlang/OTP team - Ericsson AB
> 
> Horst Mani wrote:
> > 
> > 
> > ------------------------------------------------------------------------
> > From: horst_@REDACTED
> > To: ingela.anderton.andin@REDACTED
> > Subject: RE: [erlang-bugs] SSL issue
> > Date: Tue, 15 Jan 2013 09:39:12 +0100
> > 
> > Hi,
> > 
> > thanks for the quick answer.
> > 
> > Now, i tried to connect to the server as follow:
> > 
> > ssl:connect(HOST, 636, [{cacertfile, "EquifaxSecureCA.pem"}, {verify, 
> > verify_none}]).
> > =ERROR REPORT==== 15-Jan-2013::09:33:14 ===
> > SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
> > {error,"certificate unknown"}
> > 
> > As i understand from your last mail, the client needs a server 
> > certificate with the following informations:
> > 
> > Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
> > 
> > X509v3 Subject Key Identifier: 
> >   48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
> > 
> > 
> > This informations are included in the EquifaxSecureCA.pem which i added 
> > as a cacertfile to the connect function,
> > 
> > but i got the same result.
> > 
> > 
> > Please, can you tell me, what i am doing wrong?
> > 
> > 
> > Thanks and best regards,
> > 
> > Ulf
> > 
> > 
> > 
> > 
> > 
> > 
> >  > Date: Mon, 14 Jan 2013 09:39:50 +0100
> >  > From: ingela.anderton.andin@REDACTED
> >  > To: horst_@REDACTED
> >  > CC: erlang-bugs@REDACTED
> >  > Subject: Re: [erlang-bugs] SSL issue
> >  >
> >  > Hi!
> >  >
> >  > Looking at your cert, the values of authorityCertIssuer,
> >  > authorityCertSerialNumber in #AuthorityKeyIdentifier, are asn1_NOVALUE.
> >  > so then it is logical that public_key can not find the issuer.
> >  >
> >  > pubkey_cert:select_extension/2 -> {'Extension',
> >  > {2,5,29,35},
> >  > false,
> >  >
> >  > {'AuthorityKeyIdentifier',
> >  >
> >  > [192,122,152,104,
> >  >
> >  > 141,137,251,171,
> >  >
> >  > 5,100,12,17,125,
> >  >
> >  > 170,125,101,184,
> >  > 202,204,78],
> >  > asn1_NOVALUE,
> >  > asn1_NOVALUE}}
> >  > (<0.43.0>) call
> >  > 
> > pubkey_cert:cert_auth_key_id({'AuthorityKeyIdentifier',[192,122,152,104,141,137,251,171,5,100,12,17,125,
> >  > 170,125,101,184,202,204,78],
> >  > asn1_NOVALUE,asn1_NOVALUE})
> >  > (<0.43.0>) returned from pubkey_cert:cert_auth_key_id/1 -> {error,
> >  >
> >  > issuer_not_found}
> >  >
> >  >
> >  > Some old certs does not properly specify the AuthorityKeyIdentifier the
> >  > fallback is to search the entire known CA database which ssl will do if
> >  > it has one, you have
> >  > not specified any CA-certs in your call to ssl:connect. You should try
> >  > doing that.
> >  >
> >  > Regards Ingela Erlang/OTP team - Ericsson AB
> >  >
> >  > Horst Mani wrote:
> >  > > Hi,
> >  > >
> >  > > I ty to connect to a ssl server with the following command:
> >  > >
> >  > > ssl:connect(HOST, 636, []).
> >  > > SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
> >  > > {error,"certificate unknown"}
> >  > >
> >  > > After debugging the problem, i found that the error occurs inside the
> >  > > public_key module.
> >  > > Please, have a look at my testcase which you can find here :
> >  > > https://gist.github.com/4525223
> >  > >
> >  > > Note: The ssl connect works with other clients.
> >  > >
> >  > > Env : R15B03 32 bit, build by erlang-solutions, OSX 10.7.5,
> >  > > public_key-0.17
> >  > >
> >  > > I hope that i gave you all the informations you need to fix the
> >  > > problem. I would do it by my own,
> >  > > but i don't know the expected behavior.
> >  > >
> >  > > Best Regards,
> >  > > Ulf
> >  > > 
> > ------------------------------------------------------------------------
> >  > >
> >  > > _______________________________________________
> >  > > erlang-bugs mailing list
> >  > > erlang-bugs@REDACTED
> >  > > http://erlang.org/mailman/listinfo/erlang-bugs
> >  > >
> >  >
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130116/a43f3ae1/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cert_chain.txt
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130116/a43f3ae1/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EquifaxSecureCA.pem
Type: application/octet-stream
Size: 1143 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130116/a43f3ae1/attachment.obj>

From ingela.anderton.andin@REDACTED  Wed Jan 16 18:03:28 2013
From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin)
Date: Wed, 16 Jan 2013 18:03:28 +0100
Subject: [erlang-bugs] FW:  SSL issue
In-Reply-To: <DUB002-W45B9AC1B042943D40CDB0F12C0@phx.gbl>
References: <DUB002-W5922E4A57F811BF9DD4F7CF12E0@phx.gbl>,
 <50F3C456.9060703@erix.ericsson.se>,
 <DUB002-W3CB42036F080B1BDE5B4CF12D0@phx.gbl>
 <DUB002-W7650D2F5944702C66652CF12D0@phx.gbl>,
 <50F6B422.4020205@ericsson.com> <DUB002-W45B9AC1B042943D40CDB0F12C0@phx.gbl>
Message-ID: <50F6DD60.3040809@erix.ericsson.se>

Hi!

Horst Mani wrote:
> Hi,
>
> perhaps it is broken during the upload, because localy the file seems ok.
> Now i will paste the EquifaxSecure.pem file also : 
>
> -----BEGIN CERTIFICATE-----
> MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJV
> UzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2Vy
> dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1
> MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
> dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B
> AQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPRfM6f
> BeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+A
> cJkVV5MW8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kC
> AwEAAaOCAQkwggEFMHAGA1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQ
> MA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlm
> aWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoGA1UdEAQTMBGBDzIwMTgw
> ODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvSspXXR9gj
> IBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQF
> MAMBAf8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUA
> A4GBAFjOKer89961zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y
> 7qj/WsjTVbJmcVfewCHrPSqnI0kBBIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh
> 1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee9570+sB3c4
> -----END CERTIFICATE-----
>  
This certificate is fine, it is self signed and will not look at the
AuthorityKeyIdentifier extension.

However among the other certs in you chain from your original mail
This certificate below will crash the ASN-1 decoder and cause the error.

It fails on the field X520StateOrProvinceName. Maybe it is something 
similar to the
problem described like "Workaround for handling certificates that 
wrongly encode X509countryname in utf-8 when the actual value is a valid 
ASCCI value of length 2. Such certificates are accepted by many browsers 
such as Chrome and Fierfox so for interoperability reasons we will too."

-----BEGIN CERTIFICATE-----
MIIEijCCA3KgAwIBAgIDAUACMA0GCSqGSIb3DQEBBQUAMEAxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEYMBYGA1UEAxMPR2VvVHJ1c3QgU1NM
IENBMB4XDTEyMDIyOTE0NTcxM1oXDTEzMDUwMzA1MjE0MlowgaIxKTAnBgNVBAUT
IGYvcWpDZXl2Q1JiM25LaHdMYTNDM0JBZVRXUEh6dWhMMQswCQYDVQQGEwJERTEJ
MAcGA1UECBMAMRkwFwYDVQQHExBNb25oZWltIGFtIFJoZWluMR8wHQYDVQQKExZp
bm5vUSBEZXV0c2NobGFuZCBHbWJIMQswCQYDVQQLEwJJVDEUMBIGA1UEAwwLKi5p
bm5vcS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzCgisRSel
Z5LHTBv4+16yUs76Io0IAOHsxHeSuRRQTHAusTZVfq58otZPuCvMLcXRO4hlrqXq
usth/s+yUgtcA2MWAxeJz0nyiB7/CDv95bV4RVGjwLS2O5mzGOQLq7JRX9q4yK1F
J9GmtfYPpDcsWm/k538Y9/UalxlatSvUouy9qx1y7LcM4hLydRs8wOmjqN6o1LiL
uxOJHS1o6GRAs3JozDJVFcnuxXRCtQYnjorMTtBKpvxzkOXzrpRhlvvxnyv/BrvV
ua/OIyXmM1N2pOSUtNVKXSpaBGLBJpA8BMHpDVu6gJbP9httQQY9ml8/gjFYqVU/
CbLR2KZ8pSB3AgMBAAGjggEoMIIBJDAfBgNVHSMEGDAWgBRCeVQbYc1VKz5j1TxI
V/Wf+0XOSjAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMCEGA1UdEQQaMBiCCyouaW5ub3EuY29tgglpbm5vcS5jb20wPQYDVR0f
BDYwNDAyoDCgLoYsaHR0cDovL2d0c3NsLWNybC5nZW90cnVzdC5jb20vY3Jscy9n
dHNzbC5jcmwwHQYDVR0OBBYEFKoTKF2gAS4WeHt+/yyIbymHGjn4MAwGA1UdEwEB
/wQCMAAwQwYIKwYBBQUHAQEENzA1MDMGCCsGAQUFBzAChidodHRwOi8vZ3Rzc2wt
YWlhLmdlb3RydXN0LmNvbS9ndHNzbC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAAk4
YRTsUXI+pb6ciUCJ0Qya/lcWVUa2CQG46EOZiJatZvXfAsa22SfaTBouf1B2p9p3
S1z1nFVr7/tncEsTpuC01xjlfJBRPzHg6ROnjtR/auMNnU53mF56Bvy25DpVFPJe
wAEL7I0ZFyqfTqVmwtHZ/HLHTMCKIL+XhMEPz/fnJ8NBMW2hUwVmPqFE/SiygXUr
m8sqiD/kw2IA+Yp4g049O6aWGeMa8NLUQ4HRPD+lBtT58S2fYV1i/VtKXybuMf7E
9Rz/2YkE1wn5g/FG8wVha8V/AtYxxgYhxY28lTCv+qiMlGRso8VnZnr/2MwAbRzT
TSpzIpirzDzbp1B6IbQ=
-----END CERTIFICATE-----

I will ask our ASN-1 experts to  have a look.

Regards Ingela Erlang/OTP team - Ericsson AB

> The cert_chain.txt contains the certificate chain from the server.
>
> Best Regards,
> Ulf
>
> > Date: Wed, 16 Jan 2013 15:07:30 +0100
> > From: Ingela.Anderton.Andin@REDACTED
> > To: horst_@REDACTED
> > CC: erlang-bugs@REDACTED
> > Subject: Re: [erlang-bugs] FW: SSL issue
> >
> > Hi!
> >
> > The attached PEM-file is broken! It is missing -----END CERTIFICATE-----
> > and some data that ought to come before the ending tag.
> >
> > Regards Ingela Erlang/OTP team - Ericsson AB
> >
> > Horst Mani wrote:
> > >
> > >
> > > 
> ------------------------------------------------------------------------
> > > From: horst_@REDACTED
> > > To: ingela.anderton.andin@REDACTED
> > > Subject: RE: [erlang-bugs] SSL issue
> > > Date: Tue, 15 Jan 2013 09:39:12 +0100
> > >
> > > Hi,
> > >
> > > thanks for the quick answer.
> > >
> > > Now, i tried to connect to the server as follow:
> > >
> > > ssl:connect(HOST, 636, [{cacertfile, "EquifaxSecureCA.pem"}, {verify,
> > > verify_none}]).
> > > =ERROR REPORT==== 15-Jan-2013::09:33:14 ===
> > > SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
> > > {error,"certificate unknown"}
> > >
> > > As i understand from your last mail, the client needs a server
> > > certificate with the following informations:
> > >
> > > Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
> > >
> > > X509v3 Subject Key Identifier:
> > > 48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
> > >
> > >
> > > This informations are included in the EquifaxSecureCA.pem which i 
> added
> > > as a cacertfile to the connect function,
> > >
> > > but i got the same result.
> > >
> > >
> > > Please, can you tell me, what i am doing wrong?
> > >
> > >
> > > Thanks and best regards,
> > >
> > > Ulf
> > >
> > >
> > >
> > >
> > >
> > >
> > > > Date: Mon, 14 Jan 2013 09:39:50 +0100
> > > > From: ingela.anderton.andin@REDACTED
> > > > To: horst_@REDACTED
> > > > CC: erlang-bugs@REDACTED
> > > > Subject: Re: [erlang-bugs] SSL issue
> > > >
> > > > Hi!
> > > >
> > > > Looking at your cert, the values of authorityCertIssuer,
> > > > authorityCertSerialNumber in #AuthorityKeyIdentifier, are 
> asn1_NOVALUE.
> > > > so then it is logical that public_key can not find the issuer.
> > > >
> > > > pubkey_cert:select_extension/2 -> {'Extension',
> > > > {2,5,29,35},
> > > > false,
> > > >
> > > > {'AuthorityKeyIdentifier',
> > > >
> > > > [192,122,152,104,
> > > >
> > > > 141,137,251,171,
> > > >
> > > > 5,100,12,17,125,
> > > >
> > > > 170,125,101,184,
> > > > 202,204,78],
> > > > asn1_NOVALUE,
> > > > asn1_NOVALUE}}
> > > > (<0.43.0>) call
> > > >
> > > 
> pubkey_cert:cert_auth_key_id({'AuthorityKeyIdentifier',[192,122,152,104,141,137,251,171,5,100,12,17,125,
> > > > 170,125,101,184,202,204,78],
> > > > asn1_NOVALUE,asn1_NOVALUE})
> > > > (<0.43.0>) returned from pubkey_cert:cert_auth_key_id/1 -> {error,
> > > >
> > > > issuer_not_found}
> > > >
> > > >
> > > > Some old certs does not properly specify the 
> AuthorityKeyIdentifier the
> > > > fallback is to search the entire known CA database which ssl 
> will do if
> > > > it has one, you have
> > > > not specified any CA-certs in your call to ssl:connect. You 
> should try
> > > > doing that.
> > > >
> > > > Regards Ingela Erlang/OTP team - Ericsson AB
> > > >
> > > > Horst Mani wrote:
> > > > > Hi,
> > > > >
> > > > > I ty to connect to a ssl server with the following command:
> > > > >
> > > > > ssl:connect(HOST, 636, []).
> > > > > SSL: certify: ssl_handshake.erl:239:Fatal error: certificate 
> unknown
> > > > > {error,"certificate unknown"}
> > > > >
> > > > > After debugging the problem, i found that the error occurs 
> inside the
> > > > > public_key module.
> > > > > Please, have a look at my testcase which you can find here :
> > > > > https://gist.github.com/4525223
> > > > >
> > > > > Note: The ssl connect works with other clients.
> > > > >
> > > > > Env : R15B03 32 bit, build by erlang-solutions, OSX 10.7.5,
> > > > > public_key-0.17
> > > > >
> > > > > I hope that i gave you all the informations you need to fix the
> > > > > problem. I would do it by my own,
> > > > > but i don't know the expected behavior.
> > > > >
> > > > > Best Regards,
> > > > > Ulf
> > > > >
> > > 
> ------------------------------------------------------------------------
> > > > >
> > > > > _______________________________________________
> > > > > erlang-bugs mailing list
> > > > > erlang-bugs@REDACTED
> > > > > http://erlang.org/mailman/listinfo/erlang-bugs
> > > > >
> > > >
> >
> ------------------------------------------------------------------------
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs



From egil@REDACTED  Wed Jan 16 19:15:17 2013
From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=)
Date: Wed, 16 Jan 2013 19:15:17 +0100
Subject: [erlang-bugs] system_info crash
In-Reply-To: <4EAE5D56-FD5F-4175-BDDE-A72F62C6531B@rogvall.se>
References: <4EAE5D56-FD5F-4175-BDDE-A72F62C6531B@rogvall.se>
Message-ID: <50F6EE35.20807@erlang.org>

On 2013-01-14 15:00, Tony Rogvall wrote:
> While designing a system_info debug tool I found this:
>
>
> 7> erlang:system_info(stop_memory_trace).
> ../include/internal/ethr_mutex.h:655: Fatal error in ethr_mutex_lock(): Invalid argument (22)
>               Abort trap: 6
This was one of Rickards pet project and I suspect that the memory 
tracer hasn't been subject to major updates since launch of smp.

It is not used, not documented, and not rigorously tested. The memory 
tracer should be removed IMHO (, or otherwise corrected). Rickard, opinions?

I first recalled, incorrectly, that this was an opt-in configurable 
tracer, but I see now that isn't the case. Does this break through 
testcases or plain usage?

// Bj?rn-Egil

>
> Erlang R15B03 (erts-5.9.3) [source] [64-bit] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false]
>
> uname -a
> Darwin p13.local 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
>
> /Tony
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
>



From tony@REDACTED  Wed Jan 16 19:18:50 2013
From: tony@REDACTED (Tony Rogvall)
Date: Wed, 16 Jan 2013 19:18:50 +0100
Subject: [erlang-bugs] system_info crash
In-Reply-To: <50F6EE35.20807@erlang.org>
References: <4EAE5D56-FD5F-4175-BDDE-A72F62C6531B@rogvall.se>
 <50F6EE35.20807@erlang.org>
Message-ID: <792B5828-1D85-4215-A144-6A07269007BB@rogvall.se>


On 16 jan 2013, at 19:15, Bj?rn-Egil Dahlberg <egil@REDACTED> wrote:

> On 2013-01-14 15:00, Tony Rogvall wrote:
>> While designing a system_info debug tool I found this:
>> 
>> 
>> 7> erlang:system_info(stop_memory_trace).
>> ../include/internal/ethr_mutex.h:655: Fatal error in ethr_mutex_lock(): Invalid argument (22)
>>              Abort trap: 6
> This was one of Rickards pet project and I suspect that the memory tracer hasn't been subject to major updates since launch of smp.
> 
> It is not used, not documented, and not rigorously tested. The memory tracer should be removed IMHO (, or otherwise corrected). Rickard, opinions?
> 
I just picked all system_info I could find :-)

> I first recalled, incorrectly, that this was an opt-in configurable tracer, but I see now that isn't the case. Does this break through testcases or plain usage?
> 
Plain usage. Just call it.
(Have only tried on the config below)
/Tony

> // Bj?rn-Egil
> 
>> 
>> Erlang R15B03 (erts-5.9.3) [source] [64-bit] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false]
>> 
>> uname -a
>> Darwin p13.local 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
>> 
>> /Tony
>> 
>> 
>> 
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>> 
>> 
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130116/63a34daf/attachment.htm>

From egil@REDACTED  Wed Jan 16 19:25:48 2013
From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=)
Date: Wed, 16 Jan 2013 19:25:48 +0100
Subject: [erlang-bugs] system_info crash
In-Reply-To: <792B5828-1D85-4215-A144-6A07269007BB@rogvall.se>
References: <4EAE5D56-FD5F-4175-BDDE-A72F62C6531B@rogvall.se>
 <50F6EE35.20807@erlang.org> <792B5828-1D85-4215-A144-6A07269007BB@rogvall.se>
Message-ID: <50F6F0AC.3000800@erlang.org>

On 2013-01-16 19:18, Tony Rogvall wrote:
>
> On 16 jan 2013, at 19:15, Bj?rn-Egil Dahlberg <egil@REDACTED 
> <mailto:egil@REDACTED>> wrote:
>
>> On 2013-01-14 15:00, Tony Rogvall wrote:
>>> While designing a system_info debug tool I found this:
>>>
>>>
>>> 7> erlang:system_info(stop_memory_trace).
>>> ../include/internal/ethr_mutex.h:655: Fatal error in 
>>> ethr_mutex_lock(): Invalid argument (22)
>>>              Abort trap: 6
>> This was one of Rickards pet project and I suspect that the memory 
>> tracer hasn't been subject to major updates since launch of smp.
>>
>> It is not used, not documented, and not rigorously tested. The memory 
>> tracer should be removed IMHO (, or otherwise corrected). Rickard, 
>> opinions?
>>
> I just picked all system_info I could find :-)
>
>> I first recalled, incorrectly, that this was an opt-in configurable 
>> tracer, but I see now that isn't the case. Does this break through 
>> testcases or plain usage?
>>
> Plain usage. Just call it.
> (Have only tried on the config below)
Right, tried on linux first, was ok.
Then tried on Darwin Kernel Version 11.4.2 and .. yep, sadness. =(
> /Tony
>
>> // Bj?rn-Egil
>>
>>>
>>> Erlang R15B03 (erts-5.9.3) [source] [64-bit] [smp:2:2] 
>>> [async-threads:0] [hipe] [kernel-poll:false]
>>>
>>> uname -a
>>> Darwin p13.local 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 
>>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
>>>
>>> /Tony
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-bugs mailing list
>>> erlang-bugs@REDACTED <mailto:erlang-bugs@REDACTED>
>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>
>>>
>>
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED <mailto:erlang-bugs@REDACTED>
>> http://erlang.org/mailman/listinfo/erlang-bugs
>
> "Installing applications can lead to corruption over time. 
> Applications gradually write over each other's libraries, partial 
> upgrades occur, user and system errors happen, and minute changes may 
> be unnoticeable and difficult to fix"
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130116/02903b57/attachment.htm>

From cao.xu@REDACTED  Thu Jan 17 03:46:47 2013
From: cao.xu@REDACTED (cao xu)
Date: Thu, 17 Jan 2013 10:46:47 +0800
Subject: [erlang-bugs] error headers cause httpc:request hang forever
Message-ID: <DE505D8B-5B4E-4B30-8B94-FBD04378A3F3@rytong.com>

Hi

	I did the following test on R15B and also R1304 from the erlang shell :

Request1= {"http://www.google.com",[{"cookie",undefined}, {"test",123}],"application/x-www-form-urlencoded; charset=utf-8", <<"">>}.
httpc:request(post, Request1, [{timeout,1000}], []).

	You can find the following error messages on R13:

=ERROR REPORT==== 17-Jan-2013::10:22:07 ===
** Generic server <0.50.0> terminating 
** Last message in was {connect_and_send,
                           {request,#Ref<0.0.0.39>,<0.35.0>,0,http,
                               {"www.sina.com.cn",80},
                       ...
** Reason for termination == 
** {badarg,[{erlang,'++',[123,"\r\n"]},
            {http_request,headers_other,2},
            {http_request,http_headers,1},
            {httpc_request,send,4},
            {httpc_handler,connect_and_send_first_request,3},
            {httpc_handler,handle_call,3},
            {gen_server,handle_msg,5},
            {proc_lib,init_p_do_apply,3}]}


	It's obvious that the error headers which contained value other than string caused the httpc_handler exited. But after that, the caller hung at  the 'receive'  in httpc:handle_answer/3 forever since no message was sent to the caller. 
	It seemed like a bug to me. I think  it  would be better if the handler could send the error back to the caller no matter what kind of error it is, otherwise there would be  a memory leak.
	Hoping for your reply.
	Sincerely.




From Ingela.Anderton.Andin@REDACTED  Thu Jan 17 11:10:35 2013
From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin)
Date: Thu, 17 Jan 2013 11:10:35 +0100
Subject: [erlang-bugs] FW:  SSL issue
In-Reply-To: <DUB002-W7650D2F5944702C66652CF12D0@phx.gbl>
References: <DUB002-W5922E4A57F811BF9DD4F7CF12E0@phx.gbl>,
 <50F3C456.9060703@erix.ericsson.se>,
 <DUB002-W3CB42036F080B1BDE5B4CF12D0@phx.gbl>
 <DUB002-W7650D2F5944702C66652CF12D0@phx.gbl>
Message-ID: <50F7CE1B.5040603@ericsson.com>

Hello again!

The problem is that the 'X520StateOrProvinceName' is an empty string and 
according to the spec it should be not be an empty string, however it is 
an optional attribute so I do not understand why you would want to 
include it as an empty string.  The problem could of course be
worked around by relaxing the ASN-1 spec but I think it is Equifax
that is at fault here.

Regards Ingela Erlang/OTP team - Ericsson AB


Horst Mani wrote:
> 
> 
> ------------------------------------------------------------------------
> From: horst_@REDACTED
> To: ingela.anderton.andin@REDACTED
> Subject: RE: [erlang-bugs] SSL issue
> Date: Tue, 15 Jan 2013 09:39:12 +0100
> 
> Hi,
> 
> thanks for the quick answer.
> 
> Now, i tried to connect to the server as follow:
> 
> ssl:connect(HOST, 636, [{cacertfile, "EquifaxSecureCA.pem"}, {verify, 
> verify_none}]).
> =ERROR REPORT==== 15-Jan-2013::09:33:14 ===
> SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
> {error,"certificate unknown"}
> 
> As i understand from your last mail, the client needs a server 
> certificate with the following informations:
> 
> Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
> 
> X509v3 Subject Key Identifier: 
>   48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
> 
> 
> This informations are included in the EquifaxSecureCA.pem which i added 
> as a cacertfile to the connect function,
> 
> but i got the same result.
> 
> 
> Please, can you tell me, what i am doing wrong?
> 
> 
> Thanks and best regards,
> 
> Ulf
> 
> 
> 
> 
> 
> 
>  > Date: Mon, 14 Jan 2013 09:39:50 +0100
>  > From: ingela.anderton.andin@REDACTED
>  > To: horst_@REDACTED
>  > CC: erlang-bugs@REDACTED
>  > Subject: Re: [erlang-bugs] SSL issue
>  >
>  > Hi!
>  >
>  > Looking at your cert, the values of authorityCertIssuer,
>  > authorityCertSerialNumber in #AuthorityKeyIdentifier, are asn1_NOVALUE.
>  > so then it is logical that public_key can not find the issuer.
>  >
>  > pubkey_cert:select_extension/2 -> {'Extension',
>  > {2,5,29,35},
>  > false,
>  >
>  > {'AuthorityKeyIdentifier',
>  >
>  > [192,122,152,104,
>  >
>  > 141,137,251,171,
>  >
>  > 5,100,12,17,125,
>  >
>  > 170,125,101,184,
>  > 202,204,78],
>  > asn1_NOVALUE,
>  > asn1_NOVALUE}}
>  > (<0.43.0>) call
>  > 
> pubkey_cert:cert_auth_key_id({'AuthorityKeyIdentifier',[192,122,152,104,141,137,251,171,5,100,12,17,125,
>  > 170,125,101,184,202,204,78],
>  > asn1_NOVALUE,asn1_NOVALUE})
>  > (<0.43.0>) returned from pubkey_cert:cert_auth_key_id/1 -> {error,
>  >
>  > issuer_not_found}
>  >
>  >
>  > Some old certs does not properly specify the AuthorityKeyIdentifier the
>  > fallback is to search the entire known CA database which ssl will do if
>  > it has one, you have
>  > not specified any CA-certs in your call to ssl:connect. You should try
>  > doing that.
>  >
>  > Regards Ingela Erlang/OTP team - Ericsson AB
>  >
>  > Horst Mani wrote:
>  > > Hi,
>  > >
>  > > I ty to connect to a ssl server with the following command:
>  > >
>  > > ssl:connect(HOST, 636, []).
>  > > SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
>  > > {error,"certificate unknown"}
>  > >
>  > > After debugging the problem, i found that the error occurs inside the
>  > > public_key module.
>  > > Please, have a look at my testcase which you can find here :
>  > > https://gist.github.com/4525223
>  > >
>  > > Note: The ssl connect works with other clients.
>  > >
>  > > Env : R15B03 32 bit, build by erlang-solutions, OSX 10.7.5,
>  > > public_key-0.17
>  > >
>  > > I hope that i gave you all the informations you need to fix the
>  > > problem. I would do it by my own,
>  > > but i don't know the expected behavior.
>  > >
>  > > Best Regards,
>  > > Ulf
>  > > 
> ------------------------------------------------------------------------
>  > >
>  > > _______________________________________________
>  > > erlang-bugs mailing list
>  > > erlang-bugs@REDACTED
>  > > http://erlang.org/mailman/listinfo/erlang-bugs
>  > >
>  >



From peter@REDACTED  Thu Jan 17 11:43:58 2013
From: peter@REDACTED (Peter Membrey)
Date: Thu, 17 Jan 2013 18:43:58 +0800
Subject: [erlang-bugs] VM locks up on write to socket (and now it seems
 to file too)
In-Reply-To: <50C08922.5050801@erlang.org>
References: <CA+Qi7RA9oO1A3zApfuvxzRz-kJdwOh8C8u8X_NDkJ67uszT4+w@mail.gmail.com>
 <CA+Qi7RAO4-uuy6eCrqvp92YHCZKH9jgev-RoNdPjtjPmYK_s-w@mail.gmail.com>
 <50AEC81B.2000908@ninenines.eu> <50AFA09D.4060100@erlang.org>
 <CA+Qi7RCyddxkwHR3FzVarQh8Um_K4eDSnHLUr1v2zykUX-T_Zg@mail.gmail.com>
 <50B633C7.7000709@erlang.org>
 <CA+Qi7RDQO1LD0iiW9D2fe8-bd_vRi589Bfg6Bcfo7_Q+F1+5JQ@mail.gmail.com>
 <50B64897.2050300@erlang.org>
 <CA+Qi7RAOw5O6jj5YGeRbKnwGFvq8tmHV_=ODyo92hURvG0rcpQ@mail.gmail.com>
 <50B7AD7C.3060809@erlang.org>
 <CA+Qi7RCkxgHMHruP2=oZPzepMN4NA8-wTxixP0afQ4+G_HbEwQ@mail.gmail.com>
 <50C08922.5050801@erlang.org>
Message-ID: <CA+Qi7RDPh5xfc+B31LR-SxNKiBAb_tAt1SPxknME0+qVkQ-zXQ@mail.gmail.com>

Hi all,

Found a weird issue that might be related to this patch, but I'm not
entirely sure. Basically my application writes data in append mode
with delayed_write to a file. The data is only written by one process
although it can be read directly off disk from multiple other
processes. I've found recently that some messages appear to be
truncated. Their structure looks something like this:

<3 byte header><payload<3 byte footer>

The strange thing is the header contains a CRC32 check and size that
matches what the payload should be. The footer is added at the same
time as the header. So in theory, if you have the header you should
have the footer. Yet what I'm seeing is the header plus only a small
part of the message itself, followed by a new header. I can't see
anything in the code that would cause it to do this. Literally it puts
messages into a list and then every now and then flattens the list and
writes it out...

I'm still trying to verify it, but it's possible that the corrupt
message is written again in full later. I'm seeing data with a
duplicate ID ( which should be unique ) but I have to confirm this.

Anyway I thought I'd though this out there just in case it's related
to the kernel bug as this issue doesn't seem to be in the data I
collected before the fix...

Sorry for the vagueness...

Kind Regards,

Peter Membrey


On 6 December 2012 20:01, Patrik Nyblom <pan@REDACTED> wrote:
> Hi!
>
> Good! The workaround isn't all that costly either, so I think we could put
> that in R16 as is. It would be good if the OS bug got fixed though, but I
> think that's also on it's way.
>
> Cheers,
> /Patrik
>
>
> On 12/05/2012 02:20 PM, Peter Membrey wrote:
>>
>> Hi Patrik,
>>
>> Really sorry for the delay in getting back to you!
>>
>> I tried the same test on RHEL 6.3 using the patched version and
>> everything seems fine. No stuck threads and the VM is still happy and
>> responsive.
>>
>> I'm currently working on a load testing app to try and trigger the
>> issue on demand in the application itself, but I suspect your patch
>> has done the trick!
>>
>> Thanks for fixing this so fast and sorry again for the delay in
>> getting back in touch!
>>
>> Cheers,
>>
>> Pete
>>
>>
>>
>> On 30 November 2012 02:46, Patrik Nyblom <pan@REDACTED> wrote:
>>>
>>> Hi!
>>>
>>> On 11/29/2012 04:41 AM, Peter Membrey wrote:
>>>>
>>>> Hi Patrik,
>>>>
>>>> I can also confirm that this bug exists on Red Hat Enterprise Linux
>>>> 6.3. I'll raise a support ticket with them as well.
>>>>
>>>> A workaround in the vm would be nice if you have time? :-)
>>>
>>> Could you try the attached diff and see if it works for your environment?
>>> It
>>> would seem nothing is written when 0 is returned, so it should be safe to
>>> try again...
>>>
>>> Cheers,
>>> /Patrik
>>>
>>>
>>>> Cheers,
>>>>
>>>> Pete
>>>>
>>>>
>>>> On 29 November 2012 01:23, Patrik Nyblom <pan@REDACTED> wrote:
>>>>>
>>>>> Hi again!
>>>>>
>>>>> No problem reproducing when I've got CentOS 6.3... The following
>>>>> commands
>>>>> in
>>>>> the Erlang shell:
>>>>> {ok,L} = gen_tcp:listen(4747,[{active,false}]).
>>>>> {ok,S} = gen_tcp:connect("localhost",4747,[{active,false}]).
>>>>> {ok,A} = gen_tcp:accept(L).
>>>>> gen_tcp:send(A,binary:copy(<<$a:8>>,2158022464)).
>>>>>
>>>>> gives the following strace:
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [pid 15859] writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...,
>>>>> 2158022464}], 1) = 0
>>>>> [.....]
>>>>>
>>>>> While on ubuntu for example it works like it should...Looks like a
>>>>> kernel
>>>>> bug to me... I wonder if this should be worked around or just
>>>>> reported...
>>>>> I
>>>>> suppose both... Sigh...
>>>>>
>>>>> /Patrik
>>>>>
>>>>>
>>>>> On 11/28/2012 05:23 PM, Peter Membrey wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> No problem, I'll do what I can to help - thanks for looking into this
>>>>>> so quickly!
>>>>>>
>>>>>> Any idea what might be causing it?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Pete
>>>>>>
>>>>>> On 28 November 2012 23:54, Patrik Nyblom <pan@REDACTED> wrote:
>>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> I'll upgrade the CentOS VM I have to 6.3 (only had 6.1 :() and see if
>>>>>>> I
>>>>>>> can
>>>>>>> reproduce. If that fails, could you run a VM with a patch to try to
>>>>>>> handle
>>>>>>> the unexpected case and see if that fixes it?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> /Patrik
>>>>>>>
>>>>>>> On 11/24/2012 02:57 PM, Peter Membrey wrote:
>>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> Thanks for getting back in touch so quickly!
>>>>>>>>
>>>>>>>> I did do an lsof on the process and I can confirm that it was
>>>>>>>> definitely a socket. However by that time the application it had
>>>>>>>> been
>>>>>>>> trying to send to had been killed. When I checked the sockets were
>>>>>>>> showing as waiting to close. Unfortunately I didn't think to do an
>>>>>>>> lsof until after the apps had been shut down. I was hoping the VM
>>>>>>>> would recover if I killed the app that had upset it. However even
>>>>>>>> after all the apps connected had been shut down, the issue didn't
>>>>>>>> resolve.
>>>>>>>>
>>>>>>>> The application receives requests from a client, which contains two
>>>>>>>> data items. The stream ID and a timestamp. Both are encoded as big
>>>>>>>> integer unsigned numbers. The server then looks through the file
>>>>>>>> referenced by the stream ID and uses the timestamp as an index. The
>>>>>>>> file format is currently really simple, in the form of:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> <Timestamp:64/native-integer,Length:32/native-integer,Data:Length/binary>>
>>>>>>>>
>>>>>>>> There is an index file that provides an offset into the file based
>>>>>>>> on
>>>>>>>> time stamp, but basically it opens the file, and reads sequentially
>>>>>>>> through it until it finds the timestamps that it cares about. In
>>>>>>>> this
>>>>>>>> case it reads all data with a greater timestamp until the end of the
>>>>>>>> file is reached. It's possible the client is sending an incorrect
>>>>>>>> timestamp, and maybe too much data is being read. However the loop
>>>>>>>> is
>>>>>>>> very primitive - it reads all the data in one go before passing it
>>>>>>>> back to the protocol handler to send down the socket; so by that
>>>>>>>> time
>>>>>>>> even though the response is technically incorrect and the app has
>>>>>>>> failed, it should still not cause the VM any issues.
>>>>>>>>
>>>>>>>> The data is polled every 10 seconds by the client app so I would not
>>>>>>>> expect there to be 2GB of new data to send. I'm afraid my C skills
>>>>>>>> are
>>>>>>>> somewhat limited, so I'm not sure how to put together a sample app
>>>>>>>> to
>>>>>>>> try out writev. The platform is 64bit CentOS 6.3 (equivalent to RHEL
>>>>>>>> 6.3) so I'm not expecting any strange or weird behaviour from the OS
>>>>>>>> level but of course I could be completely wrong there. The OS is
>>>>>>>> running directly on hardware, so there's no VM layer to worry about.
>>>>>>>>
>>>>>>>> Hope this might offer some additional clues?
>>>>>>>>
>>>>>>>> Thanks again!
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>>
>>>>>>>> Peter Membrey
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 24 November 2012 00:13, Patrik Nyblom <pan@REDACTED> wrote:
>>>>>>>>>
>>>>>>>>> Hi again!
>>>>>>>>>
>>>>>>>>> Could you go back to the version without the printouts and get back
>>>>>>>>> to
>>>>>>>>> the
>>>>>>>>> situation where writev loops returning 0 (as in the strace)? If so,
>>>>>>>>> it
>>>>>>>>> would
>>>>>>>>> be really interesting to see an 'lsof' of the beam process, to see
>>>>>>>>> if
>>>>>>>>> this
>>>>>>>>> file descriptor really is open and is a socket...
>>>>>>>>>
>>>>>>>>> The thing is that writev with a vector that is not empty, would
>>>>>>>>> never
>>>>>>>>> return
>>>>>>>>> 0 for a non blocking socket. Not on any modern (i.e. not ancient)
>>>>>>>>> POSIX
>>>>>>>>> compliant system anyway. Of course it is a *really* large item you
>>>>>>>>> are
>>>>>>>>> trying to write there, but it should be no problem for a 64bit
>>>>>>>>> linux.
>>>>>>>>>
>>>>>>>>> Also I think there is no use finding the Erlang code, I'll take
>>>>>>>>> that
>>>>>>>>> back,
>>>>>>>>> It would be more interesting to see what really happens at the
>>>>>>>>> OS/VM
>>>>>>>>> level
>>>>>>>>> in this case.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Patrik
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/23/2012 01:49 AM, Lo?c Hoguin wrote:
>>>>>>>>>>
>>>>>>>>>> Sending this on behalf of someone who didn't manage to get the
>>>>>>>>>> email
>>>>>>>>>> sent
>>>>>>>>>> to this list after 2 attempts. If someone can check if he's hold
>>>>>>>>>> up
>>>>>>>>>> or
>>>>>>>>>> something that'd be great.
>>>>>>>>>>
>>>>>>>>>> Anyway he has a big issue so I hope I can relay the conversation
>>>>>>>>>> reliably.
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> On 11/23/2012 01:45 AM, Peter Membrey wrote:
>>>>>>>>>>>
>>>>>>>>>>> From: Peter Membrey <peter@REDACTED>
>>>>>>>>>>> Date: 22 November 2012 19:02
>>>>>>>>>>> Subject: VM locks up on write to socket (and now it seems to file
>>>>>>>>>>> too)
>>>>>>>>>>> To: erlang-bugs@REDACTED
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> I wrote a simple database application called CakeDB
>>>>>>>>>>> (https://github.com/pmembrey/cakedb) that basically spends its
>>>>>>>>>>> time
>>>>>>>>>>> reading and writing files and sockets. There's very little in the
>>>>>>>>>>> way
>>>>>>>>>>> of complex logic. It is running on CentOS 6.3 with all the
>>>>>>>>>>> updates
>>>>>>>>>>> applied. I hit this problem on R15B02 so I rolled back to R15B01
>>>>>>>>>>> but
>>>>>>>>>>> the issue remained. Erlang was built from source.
>>>>>>>>>>>
>>>>>>>>>>> The machine has two Intel X5690 CPUs giving 12 cores plus HT.
>>>>>>>>>>> I've
>>>>>>>>>>> tried various arguments for the VM but so far nothing has
>>>>>>>>>>> prevented
>>>>>>>>>>> the problem. At the moment I'm using:
>>>>>>>>>>>
>>>>>>>>>>> +K
>>>>>>>>>>> +A 6
>>>>>>>>>>> +sbt tnnps
>>>>>>>>>>>
>>>>>>>>>>> The issue I'm seeing is that one of the scheduler threads will
>>>>>>>>>>> hit
>>>>>>>>>>> 100% cpu usage and the entire VM will become unresponsive. When
>>>>>>>>>>> this
>>>>>>>>>>> happens, I am not able to connect via the console with attach and
>>>>>>>>>>> entop is also unable to connect. I can still establish TCP
>>>>>>>>>>> connections
>>>>>>>>>>> to the application, but I never receive a response. A standard
>>>>>>>>>>> kill
>>>>>>>>>>> signal will cause the VM to shut down (it doesn't need -9).
>>>>>>>>>>>
>>>>>>>>>>> Due to the pedigree of the VM I am quite willing to accept that
>>>>>>>>>>> I've
>>>>>>>>>>> made a fundamental mistake in my code. I am pretty sure that the
>>>>>>>>>>> way
>>>>>>>>>>> I
>>>>>>>>>>> am doing the file IO could result in some race conditions.
>>>>>>>>>>> However,
>>>>>>>>>>> my
>>>>>>>>>>> poor code aside, from what I understand, I still shouldn't be
>>>>>>>>>>> able
>>>>>>>>>>> to
>>>>>>>>>>> crash / deadlock the VM like this.
>>>>>>>>>>>
>>>>>>>>>>> The issue doesn't seem to be caused by load. The app can fail
>>>>>>>>>>> when
>>>>>>>>>>> it's very busy, but also when it is practically idle. I haven't
>>>>>>>>>>> been
>>>>>>>>>>> able to find a trigger or any other explanation for the failure.
>>>>>>>>>>>
>>>>>>>>>>> The thread maxing out the CPU is attempting to write data to the
>>>>>>>>>>> socket:
>>>>>>>>>>>
>>>>>>>>>>> (gdb) bt
>>>>>>>>>>> #0  0x00007f9882ab6377 in writev () from /lib64/libc.so.6
>>>>>>>>>>> #1  0x000000000058a81f in tcp_inet_output (data=0x2407570,
>>>>>>>>>>> event=<value optimized out>) at drivers/common/inet_drv.c:9681
>>>>>>>>>>> #2  tcp_inet_drv_output (data=0x2407570, event=<value optimized
>>>>>>>>>>> out>)
>>>>>>>>>>> at drivers/common/inet_drv.c:9601
>>>>>>>>>>> #3  0x00000000004b773f in erts_port_task_execute
>>>>>>>>>>> (runq=0x7f98826019c0,
>>>>>>>>>>> curr_port_pp=0x7f9881639338)  at beam/erl_port_task.c:858
>>>>>>>>>>> #4  0x00000000004afd83 in schedule (p=<value optimized out>,
>>>>>>>>>>> calls=<value optimized out>) at beam/erl_process.c:6533
>>>>>>>>>>> #5  0x0000000000539ca2 in process_main () at beam/beam_emu.c:1268
>>>>>>>>>>> #6  0x00000000004b1279 in sched_thread_func
>>>>>>>>>>> (vesdp=0x7f9881639280)
>>>>>>>>>>> at
>>>>>>>>>>> beam/erl_process.c:4834
>>>>>>>>>>> #7  0x00000000005ba726 in thr_wrapper (vtwd=0x7fff6cfe2300) at
>>>>>>>>>>> pthread/ethread.c:106
>>>>>>>>>>> #8  0x00007f9882f78851 in start_thread () from
>>>>>>>>>>> /lib64/libpthread.so.0
>>>>>>>>>>> #9  0x00007f9882abe11d in clone () from /lib64/libc.so.6
>>>>>>>>>>> (gdb)
>>>>>>>>>>>
>>>>>>>>>>> I then tried running strace on that thread and got
>>>>>>>>>>> (indefinitely):
>>>>>>>>>>>
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> writev(15, [{"", 2158022464}], 1)       = 0
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>>      From what I can tell, it's trying to write data to a socket,
>>>>>>>>>>> which
>>>>>>>>>>> is
>>>>>>>>>>> succeeding, but writing 0 bytes. From the earlier definitions in
>>>>>>>>>>> the
>>>>>>>>>>> source file, an error condition would be signified by a negative
>>>>>>>>>>> number. Any other result is the number of bytes written, in this
>>>>>>>>>>> case
>>>>>>>>>>> 0. I'm not sure if this is desired behaviour or not. I've tried
>>>>>>>>>>> killing the application on the other end of the socket, but it
>>>>>>>>>>> has
>>>>>>>>>>> no
>>>>>>>>>>> effect on the VM.
>>>>>>>>>>>
>>>>>>>>>>> I have enabled debugging for the inet code, so hopefully this
>>>>>>>>>>> will
>>>>>>>>>>> give a little more insight. I am currently trying to reproduce
>>>>>>>>>>> the
>>>>>>>>>>> condition, but as I really have no idea what causes it, it's
>>>>>>>>>>> pretty
>>>>>>>>>>> much a case of wait and see.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> **** UPDATE ****
>>>>>>>>>>>
>>>>>>>>>>> I managed to lock up the VM again, but this time it was caused by
>>>>>>>>>>> file
>>>>>>>>>>> IO,
>>>>>>>>>>> probably from the debugging statements. Although it worked fine
>>>>>>>>>>> for
>>>>>>>>>>> some
>>>>>>>>>>> time
>>>>>>>>>>> the last entry in the file was cut off.
>>>>>>>>>>>
>>>>>>>>>>>      From GDB:
>>>>>>>>>>>
>>>>>>>>>>> (gdb) info threads
>>>>>>>>>>>        53 Thread 0x7f83e988b700 (LWP 8621)  0x00007f83ea6da54d in
>>>>>>>>>>> read
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libpthread.so.0
>>>>>>>>>>>        52 Thread 0x7f83e8c8f700 (LWP 8622)  0x00007f83ea6d743c in
>>>>>>>>>>> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>>>>>>>>>>>        51 Thread 0x7f83e818d700 (LWP 8623)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        50 Thread 0x7f83e816b700 (LWP 8624)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        49 Thread 0x7f83e8149700 (LWP 8625)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        48 Thread 0x7f83e8127700 (LWP 8626)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        47 Thread 0x7f83e8105700 (LWP 8627)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        46 Thread 0x7f83e80e3700 (LWP 8628)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        45 Thread 0x7f83e80c1700 (LWP 8629)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        44 Thread 0x7f83e809f700 (LWP 8630)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        43 Thread 0x7f83e807d700 (LWP 8631)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        42 Thread 0x7f83e805b700 (LWP 8632)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        41 Thread 0x7f83e8039700 (LWP 8633)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        40 Thread 0x7f83e8017700 (LWP 8634)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        39 Thread 0x7f83e7ff5700 (LWP 8635)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        38 Thread 0x7f83e7fd3700 (LWP 8636)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        37 Thread 0x7f83e7fb1700 (LWP 8637)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        36 Thread 0x7f83e7f8f700 (LWP 8638)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        35 Thread 0x7f83e7f6d700 (LWP 8639)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        34 Thread 0x7f83e7f4b700 (LWP 8640)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        33 Thread 0x7f83e7f29700 (LWP 8641)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        32 Thread 0x7f83e7f07700 (LWP 8642)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        31 Thread 0x7f83e7ee5700 (LWP 8643)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        30 Thread 0x7f83e7ec3700 (LWP 8644)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        29 Thread 0x7f83e7ea1700 (LWP 8645)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        28 Thread 0x7f83e7e7f700 (LWP 8646)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        27 Thread 0x7f83d7c5a700 (LWP 8647)  0x00007f83ea6db09d in
>>>>>>>>>>> waitpid
>>>>>>>>>>> () from /lib64/libpthread.so.0
>>>>>>>>>>>        26 Thread 0x7f83d7c53700 (LWP 8648)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        25 Thread 0x7f83d7252700 (LWP 8649)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        24 Thread 0x7f83d6851700 (LWP 8650)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        23 Thread 0x7f83d5e50700 (LWP 8651)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        22 Thread 0x7f83d544f700 (LWP 8652)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        21 Thread 0x7f83d4a4e700 (LWP 8653)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        20 Thread 0x7f83d404d700 (LWP 8654)  0x00007f83ea20be7d in
>>>>>>>>>>> write
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>>        19 Thread 0x7f83d364c700 (LWP 8655)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        18 Thread 0x7f83d2c4b700 (LWP 8656)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        17 Thread 0x7f83d224a700 (LWP 8657)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        16 Thread 0x7f83d1849700 (LWP 8658)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        15 Thread 0x7f83d0e48700 (LWP 8659)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        14 Thread 0x7f83d0447700 (LWP 8660)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        13 Thread 0x7f83cfa46700 (LWP 8661)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        12 Thread 0x7f83cf045700 (LWP 8662)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        11 Thread 0x7f83ce644700 (LWP 8663)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        10 Thread 0x7f83cdc43700 (LWP 8664)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> () from /lib64/libc.so.6
>>>>>>>>>>>        9 Thread 0x7f83cd242700 (LWP 8665)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>>        8 Thread 0x7f83cc841700 (LWP 8666)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>>        7 Thread 0x7f83cbe40700 (LWP 8667)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>>        6 Thread 0x7f83cb43f700 (LWP 8668)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>>        5 Thread 0x7f83caa3e700 (LWP 8669)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>>        4 Thread 0x7f83ca03d700 (LWP 8670)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>>        3 Thread 0x7f83c963c700 (LWP 8671)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>>        2 Thread 0x7f83c8c3b700 (LWP 8672)  0x00007f83ea215ae9 in
>>>>>>>>>>> syscall
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>> * 1 Thread 0x7f83eb3a8700 (LWP 8597)  0x00007f83ea211d03 in
>>>>>>>>>>> select
>>>>>>>>>>> ()
>>>>>>>>>>> from /lib64/libc.so.6
>>>>>>>>>>> (gdb)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (gdb) bt
>>>>>>>>>>> #0  0x00007f83ea20be7d in write () from /lib64/libc.so.6
>>>>>>>>>>> #1  0x00007f83ea1a2583 in _IO_new_file_write () from
>>>>>>>>>>> /lib64/libc.so.6
>>>>>>>>>>> #2  0x00007f83ea1a3b35 in _IO_new_do_write () from
>>>>>>>>>>> /lib64/libc.so.6
>>>>>>>>>>> #3  0x00007f83ea1a21fd in _IO_new_file_xsputn () from
>>>>>>>>>>> /lib64/libc.so.6
>>>>>>>>>>> #4  0x00007f83ea17589d in vfprintf () from /lib64/libc.so.6
>>>>>>>>>>> #5  0x00007f83ea18003a in printf () from /lib64/libc.so.6
>>>>>>>>>>> #6  0x000000000058f0e8 in tcp_recv (desc=0x2c3d350,
>>>>>>>>>>> request_len=0)
>>>>>>>>>>> at
>>>>>>>>>>> drivers/common/inet_drv.c:8976
>>>>>>>>>>> #7  0x000000000058f63a in tcp_inet_input (data=0x2c3d350,
>>>>>>>>>>> event=<value
>>>>>>>>>>> optimized out>) at drivers/common/inet_drv.c:9326
>>>>>>>>>>> #8  tcp_inet_drv_input (data=0x2c3d350, event=<value optimized
>>>>>>>>>>> out>)
>>>>>>>>>>> at drivers/common/inet_drv.c:9604
>>>>>>>>>>> #9  0x00000000004b770f in erts_port_task_execute
>>>>>>>>>>> (runq=0x7f83e9d5d3c0,
>>>>>>>>>>> curr_port_pp=0x7f83e8dc6e78) at beam/erl_port_task.c:851
>>>>>>>>>>> #10 0x00000000004afd83 in schedule (p=<value optimized out>,
>>>>>>>>>>> calls=<value optimized out>) at beam/erl_process.c:6533
>>>>>>>>>>> #11 0x0000000000539ca2 in process_main () at beam/beam_emu.c:1268
>>>>>>>>>>> #12 0x00000000004b1279 in sched_thread_func
>>>>>>>>>>> (vesdp=0x7f83e8dc6dc0)
>>>>>>>>>>> at
>>>>>>>>>>> beam/erl_process.c:4834
>>>>>>>>>>> #13 0x00000000005bb3e6 in thr_wrapper (vtwd=0x7fffe8266da0) at
>>>>>>>>>>> pthread/ethread.c:106
>>>>>>>>>>> #14 0x00007f83ea6d3851 in start_thread () from
>>>>>>>>>>> /lib64/libpthread.so.0
>>>>>>>>>>> #15 0x00007f83ea21911d in clone () from /lib64/libc.so.6
>>>>>>>>>>> (gdb)
>>>>>>>>>>>
>>>>>>>>>>> (gdb) bt
>>>>>>>>>>> #0  0x00007f83ea6da54d in read () from /lib64/libpthread.so.0
>>>>>>>>>>> #1  0x0000000000554b6e in signal_dispatcher_thread_func
>>>>>>>>>>> (unused=<value
>>>>>>>>>>> optimized out>) at sys/unix/sys.c:2776
>>>>>>>>>>> #2  0x00000000005bb3e6 in thr_wrapper (vtwd=0x7fffe8266c80) at
>>>>>>>>>>> pthread/ethread.c:106
>>>>>>>>>>> #3  0x00007f83ea6d3851 in start_thread () from
>>>>>>>>>>> /lib64/libpthread.so.0
>>>>>>>>>>> #4  0x00007f83ea21911d in clone () from /lib64/libc.so.6
>>>>>>>>>>> (gdb)
>>>>>>>>>>>
>>>>>>>>>>> (gdb) bt
>>>>>>>>>>> #0  0x00007f83ea215ae9 in syscall () from /lib64/libc.so.6
>>>>>>>>>>> #1  0x00000000005bba35 in wait__ (e=0x2989390) at
>>>>>>>>>>> pthread/ethr_event.c:92
>>>>>>>>>>> #2  ethr_event_wait (e=0x2989390) at pthread/ethr_event.c:218
>>>>>>>>>>> #3  0x00000000004ae5bd in erts_tse_wait (fcalls=<value optimized
>>>>>>>>>>> out>,
>>>>>>>>>>> esdp=0x7f83e8e2c440, rq=0x7f83e9d5e7c0) at
>>>>>>>>>>> beam/erl_threads.h:2319
>>>>>>>>>>> #4  scheduler_wait (fcalls=<value optimized out>,
>>>>>>>>>>> esdp=0x7f83e8e2c440,
>>>>>>>>>>> rq=0x7f83e9d5e7c0) at beam/erl_process.c:2087
>>>>>>>>>>> #5  0x00000000004afb94 in schedule (p=<value optimized out>,
>>>>>>>>>>> calls=<value optimized out>) at beam/erl_process.c:6467
>>>>>>>>>>> #6  0x0000000000539ca2 in process_main () at beam/beam_emu.c:1268
>>>>>>>>>>> #7  0x00000000004b1279 in sched_thread_func
>>>>>>>>>>> (vesdp=0x7f83e8e2c440)
>>>>>>>>>>> at
>>>>>>>>>>> beam/erl_process.c:4834
>>>>>>>>>>> #8  0x00000000005bb3e6 in thr_wrapper (vtwd=0x7fffe8266da0) at
>>>>>>>>>>> pthread/ethread.c:106
>>>>>>>>>>> #9  0x00007f83ea6d3851 in start_thread () from
>>>>>>>>>>> /lib64/libpthread.so.0
>>>>>>>>>>> #10 0x00007f83ea21911d in clone () from /lib64/libc.so.6
>>>>>>>>>>> (gdb)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (gdb) bt
>>>>>>>>>>> #0  0x00007f83ea6db09d in waitpid () from /lib64/libpthread.so.0
>>>>>>>>>>> #1  0x0000000000555a9f in child_waiter (unused=<value optimized
>>>>>>>>>>> out>)
>>>>>>>>>>> at sys/unix/sys.c:2700
>>>>>>>>>>> #2  0x00000000005bb3e6 in thr_wrapper (vtwd=0x7fffe8266d50) at
>>>>>>>>>>> pthread/ethread.c:106
>>>>>>>>>>> #3  0x00007f83ea6d3851 in start_thread () from
>>>>>>>>>>> /lib64/libpthread.so.0
>>>>>>>>>>> #4  0x00007f83ea21911d in clone () from /lib64/libc.so.6
>>>>>>>>>>> (gdb)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> **** END UPDATE ****
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm happy to provide any information I can, so please don't
>>>>>>>>>>> hesitate
>>>>>>>>>>> to
>>>>>>>>>>> ask.
>>>>>>>>>>>
>>>>>>>>>>> Thanks in advance!
>>>>>>>>>>>
>>>>>>>>>>> Kind Regards,
>>>>>>>>>>>
>>>>>>>>>>> Peter Membrey
>>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> erlang-bugs mailing list
>>>>>>>>> erlang-bugs@REDACTED
>>>>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>>>>>
>>>>>>>
>


From horst_@REDACTED  Fri Jan 18 04:59:12 2013
From: horst_@REDACTED (Horst Mani)
Date: Fri, 18 Jan 2013 04:59:12 +0100
Subject: [erlang-bugs] FW:  SSL issue
In-Reply-To: <50F7CE1B.5040603@ericsson.com>
References: <DUB002-W5922E4A57F811BF9DD4F7CF12E0@phx.gbl>,
 <50F3C456.9060703@erix.ericsson.se>,
 <DUB002-W3CB42036F080B1BDE5B4CF12D0@phx.gbl>
 <DUB002-W7650D2F5944702C66652CF12D0@phx.gbl>,<50F7CE1B.5040603@ericsson.com>
Message-ID: <DUB002-W986A4BD554DA2EEB6EB944F1120@phx.gbl>

Hi,
thanks for your help. 
I will try it, when i have the new certificate and when i am back from vacation.
Best Regards,Ulf

> Date: Thu, 17 Jan 2013 11:10:35 +0100
> From: Ingela.Anderton.Andin@REDACTED
> To: horst_@REDACTED
> CC: erlang-bugs@REDACTED
> Subject: Re: [erlang-bugs] FW:  SSL issue
> 
> Hello again!
> 
> The problem is that the 'X520StateOrProvinceName' is an empty string and 
> according to the spec it should be not be an empty string, however it is 
> an optional attribute so I do not understand why you would want to 
> include it as an empty string.  The problem could of course be
> worked around by relaxing the ASN-1 spec but I think it is Equifax
> that is at fault here.
> 
> Regards Ingela Erlang/OTP team - Ericsson AB
> 
> 
> Horst Mani wrote:
> > 
> > 
> > ------------------------------------------------------------------------
> > From: horst_@REDACTED
> > To: ingela.anderton.andin@REDACTED
> > Subject: RE: [erlang-bugs] SSL issue
> > Date: Tue, 15 Jan 2013 09:39:12 +0100
> > 
> > Hi,
> > 
> > thanks for the quick answer.
> > 
> > Now, i tried to connect to the server as follow:
> > 
> > ssl:connect(HOST, 636, [{cacertfile, "EquifaxSecureCA.pem"}, {verify, 
> > verify_none}]).
> > =ERROR REPORT==== 15-Jan-2013::09:33:14 ===
> > SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
> > {error,"certificate unknown"}
> > 
> > As i understand from your last mail, the client needs a server 
> > certificate with the following informations:
> > 
> > Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
> > 
> > X509v3 Subject Key Identifier: 
> >   48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
> > 
> > 
> > This informations are included in the EquifaxSecureCA.pem which i added 
> > as a cacertfile to the connect function,
> > 
> > but i got the same result.
> > 
> > 
> > Please, can you tell me, what i am doing wrong?
> > 
> > 
> > Thanks and best regards,
> > 
> > Ulf
> > 
> > 
> > 
> > 
> > 
> > 
> >  > Date: Mon, 14 Jan 2013 09:39:50 +0100
> >  > From: ingela.anderton.andin@REDACTED
> >  > To: horst_@REDACTED
> >  > CC: erlang-bugs@REDACTED
> >  > Subject: Re: [erlang-bugs] SSL issue
> >  >
> >  > Hi!
> >  >
> >  > Looking at your cert, the values of authorityCertIssuer,
> >  > authorityCertSerialNumber in #AuthorityKeyIdentifier, are asn1_NOVALUE.
> >  > so then it is logical that public_key can not find the issuer.
> >  >
> >  > pubkey_cert:select_extension/2 -> {'Extension',
> >  > {2,5,29,35},
> >  > false,
> >  >
> >  > {'AuthorityKeyIdentifier',
> >  >
> >  > [192,122,152,104,
> >  >
> >  > 141,137,251,171,
> >  >
> >  > 5,100,12,17,125,
> >  >
> >  > 170,125,101,184,
> >  > 202,204,78],
> >  > asn1_NOVALUE,
> >  > asn1_NOVALUE}}
> >  > (<0.43.0>) call
> >  > 
> > pubkey_cert:cert_auth_key_id({'AuthorityKeyIdentifier',[192,122,152,104,141,137,251,171,5,100,12,17,125,
> >  > 170,125,101,184,202,204,78],
> >  > asn1_NOVALUE,asn1_NOVALUE})
> >  > (<0.43.0>) returned from pubkey_cert:cert_auth_key_id/1 -> {error,
> >  >
> >  > issuer_not_found}
> >  >
> >  >
> >  > Some old certs does not properly specify the AuthorityKeyIdentifier the
> >  > fallback is to search the entire known CA database which ssl will do if
> >  > it has one, you have
> >  > not specified any CA-certs in your call to ssl:connect. You should try
> >  > doing that.
> >  >
> >  > Regards Ingela Erlang/OTP team - Ericsson AB
> >  >
> >  > Horst Mani wrote:
> >  > > Hi,
> >  > >
> >  > > I ty to connect to a ssl server with the following command:
> >  > >
> >  > > ssl:connect(HOST, 636, []).
> >  > > SSL: certify: ssl_handshake.erl:239:Fatal error: certificate unknown
> >  > > {error,"certificate unknown"}
> >  > >
> >  > > After debugging the problem, i found that the error occurs inside the
> >  > > public_key module.
> >  > > Please, have a look at my testcase which you can find here :
> >  > > https://gist.github.com/4525223
> >  > >
> >  > > Note: The ssl connect works with other clients.
> >  > >
> >  > > Env : R15B03 32 bit, build by erlang-solutions, OSX 10.7.5,
> >  > > public_key-0.17
> >  > >
> >  > > I hope that i gave you all the informations you need to fix the
> >  > > problem. I would do it by my own,
> >  > > but i don't know the expected behavior.
> >  > >
> >  > > Best Regards,
> >  > > Ulf
> >  > > 
> > ------------------------------------------------------------------------
> >  > >
> >  > > _______________________________________________
> >  > > erlang-bugs mailing list
> >  > > erlang-bugs@REDACTED
> >  > > http://erlang.org/mailman/listinfo/erlang-bugs
> >  > >
> >  >
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130118/8565fd00/attachment.htm>

From n.oxyde@REDACTED  Sat Jan 19 14:27:18 2013
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Sat, 19 Jan 2013 14:27:18 +0100
Subject: [erlang-bugs] Native compilation hangs with
	rm-reverse-eta-conversion
Message-ID: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>

Hi,

A bug was found by Tuncer Ayaz last week and I managed to reproduce it
and find where does it come from.

Building this module on latest master with +native hangs forever:

	-module(blah).
	-compile(export_all).
	foo(T) -> lists:all(fun foo/1, T).

Replacing "fun foo/1" by "fun (X) -> foo(X) end" makes the compilation
succeed, so I'm convinced it comes from my patch
rm-reverse-eta-conversion.

I'll look for a fix until code freeze, otherwise the patch will have
to be reverted.

Regards,


From n.oxyde@REDACTED  Sat Jan 19 15:24:19 2013
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Sat, 19 Jan 2013 15:24:19 +0100
Subject: [erlang-bugs] Native compilation hangs with
	rm-reverse-eta-conversion
In-Reply-To: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
Message-ID: <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>

Apparently, this bug is related to concurrent_comp, as the following
won't hang forever:

	erlc +'{hipe, [{concurrent_comp, false}]}' +native blah.erl

On Sat, Jan 19, 2013 at 2:27 PM, Anthony Ramine <n.oxyde@REDACTED> wrote:
> Hi,
>
> A bug was found by Tuncer Ayaz last week and I managed to reproduce it
> and find where does it come from.
>
> Building this module on latest master with +native hangs forever:
>
>         -module(blah).
>         -compile(export_all).
>         foo(T) -> lists:all(fun foo/1, T).
>
> Replacing "fun foo/1" by "fun (X) -> foo(X) end" makes the compilation
> succeed, so I'm convinced it comes from my patch
> rm-reverse-eta-conversion.
>
> I'll look for a fix until code freeze, otherwise the patch will have
> to be reverted.
>
> Regards,


From tuncer.ayaz@REDACTED  Sat Jan 19 19:07:05 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Sat, 19 Jan 2013 19:07:05 +0100
Subject: [erlang-bugs] =?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
Message-ID: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>

Can anyone else reproduce the following build error in current git
master? The locale in use is en_US.iso88591.

 ERLC   ../ebin/erl_scan.beam
erl_scan.erl:539: syntax error before: '?'
erl_scan.erl:708: syntax error before: '?'
erl_scan.erl:462: function scan1/5 undefined
erl_scan.erl:479: function scan1/5 undefined
erl_scan.erl:666: function scan_name/2 undefined
[...]
erl_scan.erl:1226: Warning: function scan_exponent/6 is unused
erl_scan.erl:1233: Warning: function float_end/6 is unused
erl_scan.erl:1243: Warning: function skip_comment/6 is unused
erl_scan.erl:1246: Warning: function skip_comment/7 is unused
:make[1]: *** [../ebin/erl_scan.beam] Error 1


From tuncer.ayaz@REDACTED  Sat Jan 19 19:13:39 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Sat, 19 Jan 2013 19:13:39 +0100
Subject: [erlang-bugs]
	=?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
In-Reply-To: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
References: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
Message-ID: <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>

On Sat, Jan 19, 2013 at 7:07 PM, Tuncer Ayaz wrote:
> Can anyone else reproduce the following build error in current git
> master? The locale in use is en_US.iso88591.

Steps to reproduce:
$ git clean -fxdq
$ MAKEFLAGS=-j2 ./otp_build setup -a --enable-native-libs

It seems to only break with --enable-native-libs, but without
knowing the cause I don't want to blame that.

>  ERLC   ../ebin/erl_scan.beam
> erl_scan.erl:539: syntax error before: '?'
> erl_scan.erl:708: syntax error before: '?'
> erl_scan.erl:462: function scan1/5 undefined
> erl_scan.erl:479: function scan1/5 undefined
> erl_scan.erl:666: function scan_name/2 undefined
> [...]
> erl_scan.erl:1226: Warning: function scan_exponent/6 is unused
> erl_scan.erl:1233: Warning: function float_end/6 is unused
> erl_scan.erl:1243: Warning: function skip_comment/6 is unused
> erl_scan.erl:1246: Warning: function skip_comment/7 is unused
> :make[1]: *** [../ebin/erl_scan.beam] Error 1


From wallentin.dahlberg@REDACTED  Sat Jan 19 19:42:23 2013
From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=)
Date: Sat, 19 Jan 2013 19:42:23 +0100
Subject: [erlang-bugs]
	=?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
In-Reply-To: <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>
References: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
 <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>
Message-ID: <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>

HiPE seems to have problem compiling erl_scan. Probably due to utf8
enhancements.
I don't have access to daily builds right now, but I think this passes on
our build servers (or it has gone unnoticed due to massive test data
overload).

I do get stalls when compiling erlc +native erl_scan.erl on my mac at home
though. Something bad is going on.

// Bj?rn-Egil

2013/1/19 Tuncer Ayaz <tuncer.ayaz@REDACTED>

> On Sat, Jan 19, 2013 at 7:07 PM, Tuncer Ayaz wrote:
> > Can anyone else reproduce the following build error in current git
> > master? The locale in use is en_US.iso88591.
>
> Steps to reproduce:
> $ git clean -fxdq
> $ MAKEFLAGS=-j2 ./otp_build setup -a --enable-native-libs
>
> It seems to only break with --enable-native-libs, but without
> knowing the cause I don't want to blame that.
>
> >  ERLC   ../ebin/erl_scan.beam
> > erl_scan.erl:539: syntax error before: '?'
> > erl_scan.erl:708: syntax error before: '?'
> > erl_scan.erl:462: function scan1/5 undefined
> > erl_scan.erl:479: function scan1/5 undefined
> > erl_scan.erl:666: function scan_name/2 undefined
> > [...]
> > erl_scan.erl:1226: Warning: function scan_exponent/6 is unused
> > erl_scan.erl:1233: Warning: function float_end/6 is unused
> > erl_scan.erl:1243: Warning: function skip_comment/6 is unused
> > erl_scan.erl:1246: Warning: function skip_comment/7 is unused
> > :make[1]: *** [../ebin/erl_scan.beam] Error 1
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130119/a7b8fbad/attachment.htm>

From wallentin.dahlberg@REDACTED  Sat Jan 19 19:44:06 2013
From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=)
Date: Sat, 19 Jan 2013 19:44:06 +0100
Subject: [erlang-bugs]
	=?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
In-Reply-To: <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>
References: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
 <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>
 <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>
Message-ID: <CAMjYFoOriT-VjOAd3jEQjGXUKXHTnXo88-oDNeaSg5k_r0rXSg@mail.gmail.com>

2013/1/19 Bj?rn-Egil Dahlberg <wallentin.dahlberg@REDACTED>

> HiPE seems to have problem compiling erl_scan. Probably due to utf8
> enhancements.
> I don't have access to daily builds right now, but I think this passes on
> our build servers (or it has gone unnoticed due to massive test data
> overload).
>
> I do get stalls when compiling erlc +native erl_scan.erl on my mac at home
> though. Something bad is going on.
>

Forgot to say,

This is on R16A (dev) - master - b0e4f20f2abde9fc264995317966f373775e2b2b


>
> // Bj?rn-Egil
>
> 2013/1/19 Tuncer Ayaz <tuncer.ayaz@REDACTED>
>
>> On Sat, Jan 19, 2013 at 7:07 PM, Tuncer Ayaz wrote:
>> > Can anyone else reproduce the following build error in current git
>> > master? The locale in use is en_US.iso88591.
>>
>> Steps to reproduce:
>> $ git clean -fxdq
>> $ MAKEFLAGS=-j2 ./otp_build setup -a --enable-native-libs
>>
>> It seems to only break with --enable-native-libs, but without
>> knowing the cause I don't want to blame that.
>>
>> >  ERLC   ../ebin/erl_scan.beam
>> > erl_scan.erl:539: syntax error before: '?'
>> > erl_scan.erl:708: syntax error before: '?'
>> > erl_scan.erl:462: function scan1/5 undefined
>> > erl_scan.erl:479: function scan1/5 undefined
>> > erl_scan.erl:666: function scan_name/2 undefined
>> > [...]
>> > erl_scan.erl:1226: Warning: function scan_exponent/6 is unused
>> > erl_scan.erl:1233: Warning: function float_end/6 is unused
>> > erl_scan.erl:1243: Warning: function skip_comment/6 is unused
>> > erl_scan.erl:1246: Warning: function skip_comment/7 is unused
>> > :make[1]: *** [../ebin/erl_scan.beam] Error 1
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130119/0ada0691/attachment.htm>

From tuncer.ayaz@REDACTED  Sat Jan 19 19:47:29 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Sat, 19 Jan 2013 19:47:29 +0100
Subject: [erlang-bugs]
	=?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
In-Reply-To: <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>
References: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
 <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>
 <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>
Message-ID: <CAOvwQ4io7mnVnxdMK+P0yGXgBhASJbmSYcjL2cRJUUSFsUdw2Q@mail.gmail.com>

On Sat, Jan 19, 2013 at 7:42 PM, Bj?rn-Egil Dahlberg wrote:
> HiPE seems to have problem compiling erl_scan. Probably due to utf8
> enhancements.
> I don't have access to daily builds right now, but I think this
> passes on our build servers (or it has gone unnoticed due to massive
> test data overload).

Is --enable-native-libs part of the daily build configurations?

> I do get stalls when compiling erlc +native erl_scan.erl on my mac
> at home though. Something bad is going on.

In a previous build I got the same error in edlin.erl. That's after
working around the other hang (Anthony is busy researching) by cd'ing
into lib/syntax_tools and calling make locally.

> // Bj?rn-Egil
>
> 2013/1/19 Tuncer Ayaz
>>
>> On Sat, Jan 19, 2013 at 7:07 PM, Tuncer Ayaz wrote:
>> > Can anyone else reproduce the following build error in current git
>> > master? The locale in use is en_US.iso88591.
>>
>> Steps to reproduce:
>> $ git clean -fxdq
>> $ MAKEFLAGS=-j2 ./otp_build setup -a --enable-native-libs
>>
>> It seems to only break with --enable-native-libs, but without
>> knowing the cause I don't want to blame that.
>>
>> >  ERLC   ../ebin/erl_scan.beam
>> > erl_scan.erl:539: syntax error before: '?'
>> > erl_scan.erl:708: syntax error before: '?'
>> > erl_scan.erl:462: function scan1/5 undefined
>> > erl_scan.erl:479: function scan1/5 undefined
>> > erl_scan.erl:666: function scan_name/2 undefined
>> > [...]
>> > erl_scan.erl:1226: Warning: function scan_exponent/6 is unused
>> > erl_scan.erl:1233: Warning: function float_end/6 is unused
>> > erl_scan.erl:1243: Warning: function skip_comment/6 is unused
>> > erl_scan.erl:1246: Warning: function skip_comment/7 is unused
>> > :make[1]: *** [../ebin/erl_scan.beam] Error 1


From tuncer.ayaz@REDACTED  Sat Jan 19 19:48:54 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Sat, 19 Jan 2013 19:48:54 +0100
Subject: [erlang-bugs]
	=?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
In-Reply-To: <CAMjYFoOriT-VjOAd3jEQjGXUKXHTnXo88-oDNeaSg5k_r0rXSg@mail.gmail.com>
References: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
 <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>
 <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>
 <CAMjYFoOriT-VjOAd3jEQjGXUKXHTnXo88-oDNeaSg5k_r0rXSg@mail.gmail.com>
Message-ID: <CAOvwQ4hwN2tboyZWJs-CyjqLLO21BpQgGL_bGcSL6c57CGE5ZA@mail.gmail.com>

On Sat, Jan 19, 2013 at 7:44 PM, Bj?rn-Egil Dahlberg wrote:
>
>
> 2013/1/19 Bj?rn-Egil Dahlberg
>>
>> HiPE seems to have problem compiling erl_scan. Probably due to utf8
>> enhancements.
>> I don't have access to daily builds right now, but I think this passes on
>> our build servers (or it has gone unnoticed due to massive test data
>> overload).
>>
>> I do get stalls when compiling erlc +native erl_scan.erl on my mac at home
>> though. Something bad is going on.
>
>
> Forgot to say,
>
> This is on R16A (dev) - master - b0e4f20f2abde9fc264995317966f373775e2b2b

Same here.


From wallentin.dahlberg@REDACTED  Sat Jan 19 20:00:11 2013
From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=)
Date: Sat, 19 Jan 2013 20:00:11 +0100
Subject: [erlang-bugs]
	=?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
In-Reply-To: <CAOvwQ4io7mnVnxdMK+P0yGXgBhASJbmSYcjL2cRJUUSFsUdw2Q@mail.gmail.com>
References: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
 <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>
 <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>
 <CAOvwQ4io7mnVnxdMK+P0yGXgBhASJbmSYcjL2cRJUUSFsUdw2Q@mail.gmail.com>
Message-ID: <CAMjYFoMEDtUkrxTzW2yBxRUHUyv7Rbq_mcG7NssLTLPTgCGDiw@mail.gmail.com>

2013/1/19 Tuncer Ayaz <tuncer.ayaz@REDACTED>

> On Sat, Jan 19, 2013 at 7:42 PM, Bj?rn-Egil Dahlberg wrote:
> > HiPE seems to have problem compiling erl_scan. Probably due to utf8
> > enhancements.
> > I don't have access to daily builds right now, but I think this
> > passes on our build servers (or it has gone unnoticed due to massive
> > test data overload).
>
> Is --enable-native-libs part of the daily build configurations?
>
>
It is, we have at least two separate builds on it. Which is
kinda surprising since enable-native-libs is not really encouraged by us.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130119/21606977/attachment.htm>

From wallentin.dahlberg@REDACTED  Sat Jan 19 20:05:15 2013
From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=)
Date: Sat, 19 Jan 2013 20:05:15 +0100
Subject: [erlang-bugs]
	=?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
In-Reply-To: <CAMjYFoMEDtUkrxTzW2yBxRUHUyv7Rbq_mcG7NssLTLPTgCGDiw@mail.gmail.com>
References: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
 <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>
 <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>
 <CAOvwQ4io7mnVnxdMK+P0yGXgBhASJbmSYcjL2cRJUUSFsUdw2Q@mail.gmail.com>
 <CAMjYFoMEDtUkrxTzW2yBxRUHUyv7Rbq_mcG7NssLTLPTgCGDiw@mail.gmail.com>
Message-ID: <CAMjYFoPiOOgDhRTt2fRJcYB1+05G2dADh0WdRUyDodgg2gWt2g@mail.gmail.com>

2013/1/19 Bj?rn-Egil Dahlberg <wallentin.dahlberg@REDACTED>

>
>
> 2013/1/19 Tuncer Ayaz <tuncer.ayaz@REDACTED>
>
>> On Sat, Jan 19, 2013 at 7:42 PM, Bj?rn-Egil Dahlberg wrote:
>> > HiPE seems to have problem compiling erl_scan. Probably due to utf8
>> > enhancements.
>> > I don't have access to daily builds right now, but I think this
>> > passes on our build servers (or it has gone unnoticed due to massive
>> > test data overload).
>>
>> Is --enable-native-libs part of the daily build configurations?
>>
>>
> It is, we have at least two separate builds on it. Which is
> kinda surprising since enable-native-libs is not really encouraged by us.
>
>

Our daily builds runs on about 60+ different platforms and erts
configurations generating about 800.000+ tests and results. Most are
monitored automatically through something called Monitor/OTP .. failures
are then manually inspected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130119/77d1f2a7/attachment.htm>

From tuncer.ayaz@REDACTED  Sat Jan 19 23:43:19 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Sat, 19 Jan 2013 23:43:19 +0100
Subject: [erlang-bugs]
	=?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
In-Reply-To: <CAMjYFoMEDtUkrxTzW2yBxRUHUyv7Rbq_mcG7NssLTLPTgCGDiw@mail.gmail.com>
References: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
 <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>
 <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>
 <CAOvwQ4io7mnVnxdMK+P0yGXgBhASJbmSYcjL2cRJUUSFsUdw2Q@mail.gmail.com>
 <CAMjYFoMEDtUkrxTzW2yBxRUHUyv7Rbq_mcG7NssLTLPTgCGDiw@mail.gmail.com>
Message-ID: <CAOvwQ4hJ4CKy7Jv=J4_2vpv=Vk+fPvxPkSvOe4pY7WGXAyH_ug@mail.gmail.com>

On Sat, Jan 19, 2013 at 8:00 PM, Bj?rn-Egil Dahlberg wrote:
>
>
> 2013/1/19 Tuncer Ayaz
>>
>> On Sat, Jan 19, 2013 at 7:42 PM, Bj?rn-Egil Dahlberg wrote:
>> > HiPE seems to have problem compiling erl_scan. Probably due to
>> > utf8 enhancements.
>> > I don't have access to daily builds right now, but I think this
>> > passes on our build servers (or it has gone unnoticed due to
>> > massive test data overload).
>>
>> Is --enable-native-libs part of the daily build configurations?
>>
>
> It is, we have at least two separate builds on it. Which is kinda
> surprising since enable-native-libs is not really encouraged by us.

I use enable-native-libs to speed up Dialyzer initialization and avoid
having to pass -nn (and potentially slow down overall analysis time).
The disadvantage is that general vm startup takes 100 to 200 ms longer
due to native module loading.

$ dialyzer --help
[...]
--no_native (or -nn)
      Bypass the native code compilation of some key files that Dialyzer
      heuristically performs when dialyzing many files; this avoids the
      compilation time but it may result in (much) longer analysis time
[...]


From kostis@REDACTED  Sun Jan 20 09:30:22 2013
From: kostis@REDACTED (Kostis Sagonas)
Date: Sun, 20 Jan 2013 10:30:22 +0200
Subject: [erlang-bugs] Native compilation hangs with
	rm-reverse-eta-conversion
In-Reply-To: <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
 <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
Message-ID: <50FBAB1E.2070703@cs.ntua.gr>

On 01/19/2013 04:24 PM, Anthony Ramine wrote:
> Apparently, this bug is related to concurrent_comp, as the following
> won't hang forever:
>
> 	erlc +'{hipe, [{concurrent_comp, false}]}' +native blah.erl

I also noticed that the commits which were pushed on 'master' make 
native code compilation hang.  Everything worked well before that.

If it's of any help, what concurrent_comp does, which the native code 
compiler does not do when this option is off, is to analyze the code of 
all functions and funs in order to find detailed type information. It 
does this in a concurrent fashion (i.e. spawns one process per strongly 
connected component/function) hence the option name.

The following is just a guess, but I suspect that your patch either 
broke a bytecode invariant that the hipe type analyzer relied on (in 
which case your code needs to respect this invariant), or generated code 
which is OK but it's code that had never been tested before (so it's a 
bug in the analysis of the native code compiler)

Hope this helps,
Kostis

> On Sat, Jan 19, 2013 at 2:27 PM, Anthony Ramine<n.oxyde@REDACTED>  wrote:
>> Hi,
>>
>> A bug was found by Tuncer Ayaz last week and I managed to reproduce it
>> and find where does it come from.
>>
>> Building this module on latest master with +native hangs forever:
>>
>>          -module(blah).
>>          -compile(export_all).
>>          foo(T) ->  lists:all(fun foo/1, T).
>>
>> Replacing "fun foo/1" by "fun (X) ->  foo(X) end" makes the compilation
>> succeed, so I'm convinced it comes from my patch
>> rm-reverse-eta-conversion.
>>
>> I'll look for a fix until code freeze, otherwise the patch will have
>> to be reverted.
>>
>> Regards,
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs



From kostis@REDACTED  Sun Jan 20 09:33:58 2013
From: kostis@REDACTED (Kostis Sagonas)
Date: Sun, 20 Jan 2013 10:33:58 +0200
Subject: [erlang-bugs] Native compilation hangs with
	rm-reverse-eta-conversion
In-Reply-To: <50FBAB1E.2070703@cs.ntua.gr>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
 <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
 <50FBAB1E.2070703@cs.ntua.gr>
Message-ID: <50FBABF6.1080402@cs.ntua.gr>

On 01/20/2013 10:30 AM, Kostis Sagonas wrote:
> On 01/19/2013 04:24 PM, Anthony Ramine wrote:
>> Apparently, this bug is related to concurrent_comp, as the following
>> won't hang forever:
>>
>> erlc +'{hipe, [{concurrent_comp, false}]}' +native blah.erl
>
> I also noticed that the commits which were pushed on 'master' make
> native code compilation hang. Everything worked well before that.

I forgot the word "Friday" in the first sentence.

Kostis


From norton@REDACTED  Sun Jan 20 15:23:17 2013
From: norton@REDACTED (=?utf-8?B?44OO44O844OI44OzIOOCuOODp+ODvOOCu+ODlSDjgqbjgqfjgqQg?= =?utf-8?B?44Oz?=)
Date: Sun, 20 Jan 2013 23:23:17 +0900
Subject: [erlang-bugs] master (commit b0e4f20)/master-pu (commit 95924c8)
	compilation warnings report
Message-ID: <9DB2C8D7-AF88-418A-ABC7-F15443F459E8@lovely.email.ne.jp>


Hello.

In my local environment, I see the following plus other compilation warnings with the latest master/master-pu branches.

$  head make.log-master-stderr.txt
beam/beam_emu.c: In function ?process_main?:
beam/beam_emu.c:1271: warning: cast from pointer to integer of different size
In file included from beam/beam_emu.c:1281:
i386-apple-darwin12.2.0/opt/smp/beam_hot.h:12: warning: cast from pointer to integer of different size
i386-apple-darwin12.2.0/opt/smp/beam_hot.h:21: warning: cast from pointer to integer of different size
  :
  :

I attached the stderr/stdout logs below.  If this is a known issue, please ignore this e-mail.  If you need more information or want further investigation, please let me know.  

thanks,

Joe N.


Build Recipe:

https://github.com/norton/manifests/blob/dev/rebar.mk#L209


How To Repeat:

$ git clone git://github.com/norton/manifests.git
$ cd manifests
$ make -f rebar.mk otp
$ head make.log-master-stderr.txt


Environment Details:

$ uname -a
Darwin hostname 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130120/bf0ccf3a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log-master-pu-stdout.txt.gz
Type: application/x-gzip
Size: 42407 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130120/bf0ccf3a/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130120/bf0ccf3a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log-master-stdout.txt.gz
Type: application/x-gzip
Size: 42300 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130120/bf0ccf3a/attachment-0001.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130120/bf0ccf3a/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log-master-pu-stderr.txt.gz
Type: application/x-gzip
Size: 8173 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130120/bf0ccf3a/attachment-0002.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130120/bf0ccf3a/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log-master-stderr.txt.gz
Type: application/x-gzip
Size: 7574 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130120/bf0ccf3a/attachment-0003.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130120/bf0ccf3a/attachment-0004.htm>

From n.oxyde@REDACTED  Mon Jan 21 10:09:14 2013
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Mon, 21 Jan 2013 10:09:14 +0100
Subject: [erlang-bugs] Native compilation hangs with
	rm-reverse-eta-conversion
In-Reply-To: <50FBAB1E.2070703@cs.ntua.gr>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
 <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
 <50FBAB1E.2070703@cs.ntua.gr>
Message-ID: <A0DE1949-B2F2-43E9-95A4-85A35B2B0CBD@gmail.com>

Hi Kostis,

My patch removes the automatic eta-abstraction for function references from the BEAM code generation [1]. The consequence of this is that some fun references labels (the ones which are from exported functions) are now taken from the exports table in beam_dict.

This makes hipe pass exported functions which are used as fun references to hipe_coordinator both in `Closures` and `Exported`, and that makes everything hang if the exported function contains a fun reference to itself, like in erl_syntax:is_literal/1 [3].

Could you explain to me what `Escaping` and `NonEscaping` means? More specifically, what the boolean() value in the pairs of `NonEscaping` mean.

Regards,

[1] https://github.com/nox/otp/commit/42b87b
[2] https://github.com/nox/otp/blob/master/lib/hipe/main/hipe.erl#L762-770
[3] https://github.com/nox/otp/blob/master/lib/syntax_tools/src/erl_syntax.erl#L5909-5929

-- 
Anthony Ramine

Le 20 janv. 2013 ? 09:30, Kostis Sagonas a ?crit :

> The following is just a guess, but I suspect that your patch either broke a bytecode invariant that the hipe type analyzer relied on (in which case your code needs to respect this invariant), or generated code which is OK but it's code that had never been tested before (so it's a bug in the analysis of the native code compiler)



From bgustavsson@REDACTED  Mon Jan 21 12:00:10 2013
From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=)
Date: Mon, 21 Jan 2013 12:00:10 +0100
Subject: [erlang-bugs] Native compilation hangs with
	rm-reverse-eta-conversion
In-Reply-To: <A0DE1949-B2F2-43E9-95A4-85A35B2B0CBD@gmail.com>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
 <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
 <50FBAB1E.2070703@cs.ntua.gr>
 <A0DE1949-B2F2-43E9-95A4-85A35B2B0CBD@gmail.com>
Message-ID: <CA+yh78Qp9Nqg10r6uJwr38q00TfeKzEvKJ1d3vp5N3FnZiZEzw@mail.gmail.com>

You mean the boolan in `Escaping`?

I am not an expert on the hipe compiler, but I just had
a look at the code and I think I have some answers.

`Escaping` is  the functions that can be called from
outside the module (they presumably needs stubs).
The boolean seems to be `true` for funs and `false`
for exports.

But the boolean is not actually used!
hipe_icode_coordinator filters it away! (See
coordinate/4 and initialize_server/2.)

I have attached a crude fix that eliminates the
duplicate entry in `Escaping`. I have verified that
the compiler no long hangs, but I have not verified
anything else.




On Mon, Jan 21, 2013 at 10:09 AM, Anthony Ramine <n.oxyde@REDACTED> wrote:

> Hi Kostis,
>
> My patch removes the automatic eta-abstraction for function references
> from the BEAM code generation [1]. The consequence of this is that some fun
> references labels (the ones which are from exported functions) are now
> taken from the exports table in beam_dict.
>
> This makes hipe pass exported functions which are used as fun references
> to hipe_coordinator both in `Closures` and `Exported`, and that makes
> everything hang if the exported function contains a fun reference to
> itself, like in erl_syntax:is_literal/1 [3].
>
> Could you explain to me what `Escaping` and `NonEscaping` means? More
> specifically, what the boolean() value in the pairs of `NonEscaping` mean.
>
> Regards,
>
> [1] https://github.com/nox/otp/commit/42b87b
> [2] https://github.com/nox/otp/blob/master/lib/hipe/main/hipe.erl#L762-770
> [3]
> https://github.com/nox/otp/blob/master/lib/syntax_tools/src/erl_syntax.erl#L5909-5929
>
> --
> Anthony Ramine
>
> Le 20 janv. 2013 ? 09:30, Kostis Sagonas a ?crit :
>
> > The following is just a guess, but I suspect that your patch either
> broke a bytecode invariant that the hipe type analyzer relied on (in which
> case your code needs to respect this invariant), or generated code which is
> OK but it's code that had never been tested before (so it's a bug in the
> analysis of the native code compiler)
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>



-- 
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130121/c0b2f0b1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crude-fix.patch
Type: application/octet-stream
Size: 900 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130121/c0b2f0b1/attachment.obj>

From norton@REDACTED  Tue Jan 22 04:28:05 2013
From: norton@REDACTED (=?utf-8?B?44OO44O844OI44OzIOOCuOODp+ODvOOCu+ODlSDjgqbjgqfjgqQg?= =?utf-8?B?44Oz?=)
Date: Tue, 22 Jan 2013 12:28:05 +0900
Subject: [erlang-bugs] dialyzer typename/0 and typename/1 names are treated
	the same?
Message-ID: <E428C8D7-1528-492C-B325-B0560E7CD75C@lovely.email.ne.jp>


Given the sample module below, dialyzer reports that f_datum is already defined.

This behaviour is strange to me because I'm expecting f_datum/0 and f_datum/1 to be treated as two independent types.  Is this a bug or specification?

thanks,

Joe N.


NG case:

$ dialyzer --src --plt ~/.dialyzer_plt.R15B03  src/foobar.erl 
  Checking whether the PLT /Users/norton/.dialyzer_plt.R15B03 is up-to-date... yes
  Proceeding with analysis...
dialyzer: Analysis failed with error:
Could not scan the following file(s): [{"/Users/norton/appfoobar/src/foobar.erl",
                                        "Type f_datum already defined\n"}]
Last messages in the log cache:
  Reading files and computing callgraph? 


$ cat src/foobar.erl 

-module(foobar).

-type foo() :: foo.
-type bar(T) :: list(T).

-type f_datum(T) :: foo() | bar(T).
-type f_datum() :: f_datum(f_datum()).



OK case:

$ dialyzer --src --plt ~/.dialyzer_plt.R15B03  src/foobar.erl 
  Checking whether the PLT /Users/norton/.dialyzer_plt.R15B03 is up-to-date... yes
  Proceeding with analysis... done in 0m26.28s
done (passed successfully)


$ cat src/foobar.erl 

-module(foobar).

-type foo() :: foo.
-type bar(T) :: list(T).

-type f_datum(T) :: foo() | bar(T).
-type f_datums() :: f_datum(f_datums()).



Erlang/OTP version info:

$ erl -v
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false]

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



From gtsiour@REDACTED  Tue Jan 22 12:07:26 2013
From: gtsiour@REDACTED (Yiannis Tsiouris)
Date: Tue, 22 Jan 2013 13:07:26 +0200
Subject: [erlang-bugs] Bug in debug build?
Message-ID: <50FE72EE.8010309@softlab.ntua.gr>

Hi all,

We 're trying to build a debug-enabled runtime system in a freshly
cloned Erlang/OTP system using the 'master' branch by following the
instructions from [1]. In a nutshell, we do:

> cd $ERL_OTP/
> make
> cd erts/emulator
> env ERL_TOP=$ERL_OTP make debug FLAVOR=plain

(where ERL_OTP is the directory of the erlang/otp cloned repository)

We use the 'master' branch for this and we get an error. The error
message is:

In file included from hipe/hipe_amd64_gc.h:28,
                 from hipe/hipe_gc.h:31,
                 from hipe/hipe_gc.c:30:
hipe/hipe_x86_gc.h: In function ?nstack_walk_init_sdesc?:
hipe/hipe_x86_gc.h:74: error: ?am_init? undeclared (first use in this
function)
hipe/hipe_x86_gc.h:74: error: (Each undeclared identifier is reported
only once
hipe/hipe_x86_gc.h:74: error: for each function it appears in.)

I also attach the complete log from the build for completeness.

Can anyone reproduce this or we're doing something wrong?


Thanks,
yiannis

[1]:
http://www.erlang.org/doc/installation_guide/INSTALL.html#How-to-Build-a-Debug-Enabled-Erlang-RunTime-System

-- 
Yiannis Tsiouris
Ph.D. student,
Software Engineering Laboratory,
National Technical University of Athens
WWW: http://www.softlab.ntua.gr/~gtsiour
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.log
Type: text/x-log
Size: 86262 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130122/cffb662a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130122/cffb662a/attachment-0001.bin>

From egil@REDACTED  Tue Jan 22 12:10:17 2013
From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=)
Date: Tue, 22 Jan 2013 12:10:17 +0100
Subject: [erlang-bugs] Bug in debug build?
In-Reply-To: <50FE72EE.8010309@softlab.ntua.gr>
References: <50FE72EE.8010309@softlab.ntua.gr>
Message-ID: <50FE7399.9000809@erlang.org>

Yep, it is noticed and will be merged to master shortly. Apparently a 
definition am_init got lost for 64bit linux in debug.

On 2013-01-22 12:07, Yiannis Tsiouris wrote:
> Hi all,
>
> We 're trying to build a debug-enabled runtime system in a freshly
> cloned Erlang/OTP system using the 'master' branch by following the
> instructions from [1]. In a nutshell, we do:
>
>> cd $ERL_OTP/
>> make
>> cd erts/emulator
>> env ERL_TOP=$ERL_OTP make debug FLAVOR=plain
> (where ERL_OTP is the directory of the erlang/otp cloned repository)
>
> We use the 'master' branch for this and we get an error. The error
> message is:
>
> In file included from hipe/hipe_amd64_gc.h:28,
>                   from hipe/hipe_gc.h:31,
>                   from hipe/hipe_gc.c:30:
> hipe/hipe_x86_gc.h: In function 'nstack_walk_init_sdesc':
> hipe/hipe_x86_gc.h:74: error: 'am_init' undeclared (first use in this
> function)
> hipe/hipe_x86_gc.h:74: error: (Each undeclared identifier is reported
> only once
> hipe/hipe_x86_gc.h:74: error: for each function it appears in.)
>
> I also attach the complete log from the build for completeness.
>
> Can anyone reproduce this or we're doing something wrong?
>
>
> Thanks,
> yiannis
>
> [1]:
> http://www.erlang.org/doc/installation_guide/INSTALL.html#How-to-Build-a-Debug-Enabled-Erlang-RunTime-System
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

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

From egil@REDACTED  Tue Jan 22 14:27:28 2013
From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=)
Date: Tue, 22 Jan 2013 14:27:28 +0100
Subject: [erlang-bugs] Bug in debug build?
In-Reply-To: <50FE7399.9000809@erlang.org>
References: <50FE72EE.8010309@softlab.ntua.gr> <50FE7399.9000809@erlang.org>
Message-ID: <50FE93C0.4040902@erlang.org>

On 2013-01-22 12:10, Bj?rn-Egil Dahlberg wrote:
> Yep, it is noticed and will be merged to master shortly. Apparently a 
> definition am_init got lost for 64bit linux in debug.

The current master @github should now be ok.

>
> On 2013-01-22 12:07, Yiannis Tsiouris wrote:
>> Hi all,
>>
>> We 're trying to build a debug-enabled runtime system in a freshly
>> cloned Erlang/OTP system using the 'master' branch by following the
>> instructions from [1]. In a nutshell, we do:
>>
>>> cd $ERL_OTP/
>>> make
>>> cd erts/emulator
>>> env ERL_TOP=$ERL_OTP make debug FLAVOR=plain
>> (where ERL_OTP is the directory of the erlang/otp cloned repository)
>>
>> We use the 'master' branch for this and we get an error. The error
>> message is:
>>
>> In file included from hipe/hipe_amd64_gc.h:28,
>>                   from hipe/hipe_gc.h:31,
>>                   from hipe/hipe_gc.c:30:
>> hipe/hipe_x86_gc.h: In function 'nstack_walk_init_sdesc':
>> hipe/hipe_x86_gc.h:74: error: 'am_init' undeclared (first use in this
>> function)
>> hipe/hipe_x86_gc.h:74: error: (Each undeclared identifier is reported
>> only once
>> hipe/hipe_x86_gc.h:74: error: for each function it appears in.)
>>
>> I also attach the complete log from the build for completeness.
>>
>> Can anyone reproduce this or we're doing something wrong?
>>
>>
>> Thanks,
>> yiannis
>>
>> [1]:
>> http://www.erlang.org/doc/installation_guide/INSTALL.html#How-to-Build-a-Debug-Enabled-Erlang-RunTime-System
>>
>>
>>
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

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

From gtsiour@REDACTED  Tue Jan 22 14:52:24 2013
From: gtsiour@REDACTED (Yiannis Tsiouris)
Date: Tue, 22 Jan 2013 15:52:24 +0200
Subject: [erlang-bugs] Bug in debug build?
In-Reply-To: <50FE93C0.4040902@erlang.org>
References: <50FE72EE.8010309@softlab.ntua.gr> <50FE7399.9000809@erlang.org>
 <50FE93C0.4040902@erlang.org>
Message-ID: <50FE9998.8060501@softlab.ntua.gr>

On 01/22/2013 03:27 PM, Bj?rn-Egil Dahlberg wrote:
> On 2013-01-22 12:10, Bj?rn-Egil Dahlberg wrote:
>> Yep, it is noticed and will be merged to master shortly. Apparently a
>> definition am_init got lost for 64bit linux in debug.
> 
> The current master @github should now be ok.

Yeap, that worked!

Thanks!

yiannis

-- 
Yiannis Tsiouris
Ph.D. student,
Software Engineering Laboratory,
National Technical University of Athens
WWW: http://www.softlab.ntua.gr/~gtsiour

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

From tuncer.ayaz@REDACTED  Tue Jan 22 18:22:19 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Tue, 22 Jan 2013 18:22:19 +0100
Subject: [erlang-bugs] R16 Dialyzer bad_crc error
In-Reply-To: <CABOX0Z-_Xo1t7-fTr-2PeU+UTHvLUKUV=YZgGyQfstTaU_+2Yg@mail.gmail.com>
References: <CAOvwQ4hvHkwkweFeZD=iTyR62ZAC3DXpvVSyO-4+xVxaDUt2XA@mail.gmail.com>
 <CAOvwQ4go_XC3Ji2CVYjegsgFwXtV7B++4feT=WaU7FW97Vdy9g@mail.gmail.com>
 <CABOX0Z-_Xo1t7-fTr-2PeU+UTHvLUKUV=YZgGyQfstTaU_+2Yg@mail.gmail.com>
Message-ID: <CAOvwQ4g1aF9TarBebwK31+T4_GFTa-2wOsuSjAoJrOL2dQT4Cw@mail.gmail.com>

On Tue, Jan 22, 2013 at 2:44 PM, Stavros Aronis wrote:
> Hi Tuncer,
>
> sorry for the long delay. I am using the latest master branch from
> erlang/otp repository (with HiPE disabled due to the recent known
> issues :-( ), and I cannot reproduce the error that you are
> reporting.
>
> SHAs
> otp: 9b01d95
> erlydtl: c18f2a0
>
> What version of erlydtl and otp are you seeing this on? (SHAs would
> be useful).

When that particular error happened erlydtl.git was at 3306858. It
doesn't happen with today's otp.git, but there's a new issue with
today's otp.git. Should I try to checkout otp.git from Jan 10th and
retry with that? erlydtl.git c18f2a0 also doesn't provoke the Jan 10th
issue when using otp.git.

$ cd otp
$ git describe
OTP_R15B03-1-1421-g9b01d95
$ git clean -fxdq
$ export ERL_TOP=$PWD
$ export PATH=$ERL_TOP/bin:$PATH
$ MAKEFLAGS=-j2 ./otp_build setup -a --prefix=$PWD/localinst
$ make install
$ export PATH=$PWD/localinst/bin:$PATH
$ dialyzer --build_plt --verbose --apps BIG_LIST_OF_APPS SOME_EBIN_DIRS
Compiling some key modules to native code...

It's stuck at that step:
$ ps -Ao fname,bsdtime,tmout,wchan|grep beam
beam.smp   0:30     - poll_schedule_timeout

I didn't enable --enable-native-libs because that breaks the build
right now, but I did so on Jan 10th.

> On Thu, Jan 10, 2013 at 6:49 PM, Tuncer Ayaz wrote:
>>
>> On Tue, Jan 8, 2013 at 5:00 PM, Tuncer Ayaz wrote:
>> > dialyzer --build_plt with otp.git 3e8a6c8 fails as follows:
>> > {"init terminating in do_boot",{{badmatch,{error,bad_crc}},
>> >   [{hipe,finalize,5,[{file,"hipe.erl"},{line,740}]},
>> >    {hipe,compile_finish,3,[{file,"hipe.erl"},{line,697}]},
>> >    {hipe,'-run_compiler_1/3-fun-0-',4,[{file,"hipe.erl"},{line,658}]}]
>> >   }}
>> >
>> > Maybe it's a known but not yet resolved issue caused by the major
>> > code loader changes happening in R16.
>>
>> This is fixed as of today's master update, but now Dialyzer fails
>> to extract core Erlang code from two erlydtl beams. If the beams
>> were not compiled with debug_info, Dialyzer would have warned about
>> extracting abstract code (not core Erlang code) instead.
>>
>> To reproduce:
>> $ git clone git://github.com/evanmiller/erlydtl.git
>> $ cd erlydtl
>> $ make
>> $ dialyzer --build_plt --output_plt test_plt ebin
>>   Creating PLT test_plt ...
>> dialyzer: Analysis failed with error:
>> Could not scan the following file(s):
>> [{"/tmp/foo/ebin/erlydtl_slice.beam",
>> "  Could not get core Erlang code for: /tmp/foo/ebin/erlydtl_slice.beam"},
>> {"/tmp/foo/ebin/erlydtl_filters.beam",
>> "  Could not get core Erlang code for:
>> /tmp/foo/ebin/erlydtl_filters.beam"}]


From tuncer.ayaz@REDACTED  Tue Jan 22 19:22:03 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Tue, 22 Jan 2013 19:22:03 +0100
Subject: [erlang-bugs] R16 Dialyzer bad_crc error
In-Reply-To: <CABOX0Z9CLctaxCwb7FAer=cH5kKjYachXuofg5Ux7tgOqjYyGg@mail.gmail.com>
References: <CAOvwQ4hvHkwkweFeZD=iTyR62ZAC3DXpvVSyO-4+xVxaDUt2XA@mail.gmail.com>
 <CAOvwQ4go_XC3Ji2CVYjegsgFwXtV7B++4feT=WaU7FW97Vdy9g@mail.gmail.com>
 <CABOX0Z-_Xo1t7-fTr-2PeU+UTHvLUKUV=YZgGyQfstTaU_+2Yg@mail.gmail.com>
 <CAOvwQ4g1aF9TarBebwK31+T4_GFTa-2wOsuSjAoJrOL2dQT4Cw@mail.gmail.com>
 <CABOX0Z9CLctaxCwb7FAer=cH5kKjYachXuofg5Ux7tgOqjYyGg@mail.gmail.com>
Message-ID: <CAOvwQ4hQc1OAMpe4h8p+A5vbOJDoutppqpCyk8kRw7KmJYMQDA@mail.gmail.com>

On Tue, Jan 22, 2013 at 6:45 PM, Stavros Aronis wrote:
> Well, as HiPE is currently broken, the 'Compiling some key modules
> to native code...' message is a good hint to either configure OTP
> with --disable-hipe (haven't EVER tried it) or just run Dialyzer
> with -nn.
>
> Current master's Dialyzer (with -nn) runs on erlydtl 3306858 without
> any issues on my machine. Can you confirm that?

Without HiPE it doesn't hang but I have copies of the two beams which
provoke the error. The beams have debug_info and don't look corrupted,
but maybe there's something wrong in them. I'll send you the files for
inspection.


From tuncer.ayaz@REDACTED  Tue Jan 22 19:26:39 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Tue, 22 Jan 2013 19:26:39 +0100
Subject: [erlang-bugs] R16 Dialyzer bad_crc error
In-Reply-To: <CAOvwQ4hQc1OAMpe4h8p+A5vbOJDoutppqpCyk8kRw7KmJYMQDA@mail.gmail.com>
References: <CAOvwQ4hvHkwkweFeZD=iTyR62ZAC3DXpvVSyO-4+xVxaDUt2XA@mail.gmail.com>
 <CAOvwQ4go_XC3Ji2CVYjegsgFwXtV7B++4feT=WaU7FW97Vdy9g@mail.gmail.com>
 <CABOX0Z-_Xo1t7-fTr-2PeU+UTHvLUKUV=YZgGyQfstTaU_+2Yg@mail.gmail.com>
 <CAOvwQ4g1aF9TarBebwK31+T4_GFTa-2wOsuSjAoJrOL2dQT4Cw@mail.gmail.com>
 <CABOX0Z9CLctaxCwb7FAer=cH5kKjYachXuofg5Ux7tgOqjYyGg@mail.gmail.com>
 <CAOvwQ4hQc1OAMpe4h8p+A5vbOJDoutppqpCyk8kRw7KmJYMQDA@mail.gmail.com>
Message-ID: <CAOvwQ4hpBABEVkQ5BZsUDfe+F7taHydhoJBotDS76hoLL6vq1Q@mail.gmail.com>

On Tue, Jan 22, 2013 at 7:22 PM, Tuncer Ayaz wrote:
> On Tue, Jan 22, 2013 at 6:45 PM, Stavros Aronis wrote:
>> Well, as HiPE is currently broken, the 'Compiling some key modules
>> to native code...' message is a good hint to either configure OTP
>> with --disable-hipe (haven't EVER tried it) or just run Dialyzer
>> with -nn.
>>
>> Current master's Dialyzer (with -nn) runs on erlydtl 3306858 without
>> any issues on my machine. Can you confirm that?
>
> Without HiPE it doesn't hang but I have copies of the two beams which
> provoke the error. The beams have debug_info and don't look corrupted,
> but maybe there's something wrong in them. I'll send you the files for
> inspection.

Forgot to make it clear that the two files _still_ provoke the same error.


From n.oxyde@REDACTED  Wed Jan 23 12:49:04 2013
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Wed, 23 Jan 2013 12:49:04 +0100
Subject: [erlang-bugs] Native compilation hangs with
	rm-reverse-eta-conversion
In-Reply-To: <A0DE1949-B2F2-43E9-95A4-85A35B2B0CBD@gmail.com>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
 <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
 <50FBAB1E.2070703@cs.ntua.gr>
 <A0DE1949-B2F2-43E9-95A4-85A35B2B0CBD@gmail.com>
Message-ID: <EA8474BB-3593-4098-9AAC-750632E8FE40@gmail.com>

Hi,

The bytecode invariant that I broke is the fact that a function cannot be used as
a closure and as a normal function both at the same time, thus the eta-abstraction
is needed by HiPE.

Fredrik, for the time being you should probably revert rm-reverse-eta-conversion
because I don't think I'll be able to make HiPE work with the eta-abstraction in
that much time.

Kostis, could you give me directions on how to make HiPE not need the intermediate
closures when doing fun Name/Arity?

Regards,

-- 
Anthony Ramine

Le 21 janv. 2013 ? 10:09, Anthony Ramine a ?crit :

> Hi Kostis,
> 
> My patch removes the automatic eta-abstraction for function references from the BEAM code generation [1]. The consequence of this is that some fun references labels (the ones which are from exported functions) are now taken from the exports table in beam_dict.
> 
> This makes hipe pass exported functions which are used as fun references to hipe_coordinator both in `Closures` and `Exported`, and that makes everything hang if the exported function contains a fun reference to itself, like in erl_syntax:is_literal/1 [3].
> 
> Could you explain to me what `Escaping` and `NonEscaping` means? More specifically, what the boolean() value in the pairs of `NonEscaping` mean.
> 
> Regards,
> 
> [1] https://github.com/nox/otp/commit/42b87b
> [2] https://github.com/nox/otp/blob/master/lib/hipe/main/hipe.erl#L762-770
> [3] https://github.com/nox/otp/blob/master/lib/syntax_tools/src/erl_syntax.erl#L5909-5929
> 
> -- 
> Anthony Ramine
> 
> Le 20 janv. 2013 ? 09:30, Kostis Sagonas a ?crit :
> 
>> The following is just a guess, but I suspect that your patch either broke a bytecode invariant that the hipe type analyzer relied on (in which case your code needs to respect this invariant), or generated code which is OK but it's code that had never been tested before (so it's a bug in the analysis of the native code compiler)
> 



From fredrik@REDACTED  Wed Jan 23 14:01:22 2013
From: fredrik@REDACTED (Fredrik)
Date: Wed, 23 Jan 2013 14:01:22 +0100
Subject: [erlang-bugs] Native compilation hangs with
	rm-reverse-eta-conversion
In-Reply-To: <EA8474BB-3593-4098-9AAC-750632E8FE40@gmail.com>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
 <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
 <50FBAB1E.2070703@cs.ntua.gr>
 <A0DE1949-B2F2-43E9-95A4-85A35B2B0CBD@gmail.com>
 <EA8474BB-3593-4098-9AAC-750632E8FE40@gmail.com>
Message-ID: <50FFDF22.5030501@erlang.org>

It's reverted from master now.

BR Fredrik Gustafsson
Erlang OTP Team
On 01/23/2013 12:49 PM, Anthony Ramine wrote:
> Hi,
>
> The bytecode invariant that I broke is the fact that a function cannot be used as
> a closure and as a normal function both at the same time, thus the eta-abstraction
> is needed by HiPE.
>
> Fredrik, for the time being you should probably revert rm-reverse-eta-conversion
> because I don't think I'll be able to make HiPE work with the eta-abstraction in
> that much time.
>
> Kostis, could you give me directions on how to make HiPE not need the intermediate
> closures when doing fun Name/Arity?
>
> Regards,
>



From gtsiour@REDACTED  Wed Jan 23 14:18:10 2013
From: gtsiour@REDACTED (Yiannis Tsiouris)
Date: Wed, 23 Jan 2013 15:18:10 +0200
Subject: [erlang-bugs] Native compilation hangs
	with	rm-reverse-eta-conversion
In-Reply-To: <50FFDF22.5030501@erlang.org>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
 <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
 <50FBAB1E.2070703@cs.ntua.gr>
 <A0DE1949-B2F2-43E9-95A4-85A35B2B0CBD@gmail.com>
 <EA8474BB-3593-4098-9AAC-750632E8FE40@gmail.com>
 <50FFDF22.5030501@erlang.org>
Message-ID: <50FFE312.5050505@softlab.ntua.gr>

On 01/23/2013 03:01 PM, Fredrik wrote:
> It's reverted from master now.
Is it? 'cause I can't see it... :-)

yiannis

-- 
Yiannis Tsiouris
Ph.D. student,
Software Engineering Laboratory,
National Technical University of Athens
WWW: http://www.softlab.ntua.gr/~gtsiour



From fredrik@REDACTED  Wed Jan 23 14:21:01 2013
From: fredrik@REDACTED (Fredrik)
Date: Wed, 23 Jan 2013 14:21:01 +0100
Subject: [erlang-bugs] Native compilation hangs
	with	rm-reverse-eta-conversion
In-Reply-To: <50FFE312.5050505@softlab.ntua.gr>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
 <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
 <50FBAB1E.2070703@cs.ntua.gr>
 <A0DE1949-B2F2-43E9-95A4-85A35B2B0CBD@gmail.com>
 <EA8474BB-3593-4098-9AAC-750632E8FE40@gmail.com>
 <50FFDF22.5030501@erlang.org> <50FFE312.5050505@softlab.ntua.gr>
Message-ID: <50FFE3BD.6010303@erlang.org>

On 01/23/2013 02:18 PM, Yiannis Tsiouris wrote:
> On 01/23/2013 03:01 PM, Fredrik wrote:
>> It's reverted from master now.
> Is it? 'cause I can't see it... :-)
>
> yiannis
>
When I am pushing 'master' to github, that is ;)

BR Fredrik Gustafsson
Erlang OTP Team


From kostis@REDACTED  Wed Jan 23 14:26:52 2013
From: kostis@REDACTED (Kostis Sagonas)
Date: Wed, 23 Jan 2013 15:26:52 +0200
Subject: [erlang-bugs] Native compilation hangs with
	rm-reverse-eta-conversion
In-Reply-To: <EA8474BB-3593-4098-9AAC-750632E8FE40@gmail.com>
References: <CAKJNF0c56fbuEnDEUcW1KnSSE514-nS8gncOJ_exFf2h=DuR+w@mail.gmail.com>
 <CAKJNF0dZX1rveZnnXiCW+dktvYUW7tzvMmSCODyvRm2MDDf+4g@mail.gmail.com>
 <50FBAB1E.2070703@cs.ntua.gr>
 <A0DE1949-B2F2-43E9-95A4-85A35B2B0CBD@gmail.com>
 <EA8474BB-3593-4098-9AAC-750632E8FE40@gmail.com>
Message-ID: <50FFE51C.9070002@cs.ntua.gr>

On 01/23/2013 01:49 PM, Anthony Ramine wrote:
> Hi,
>
> The bytecode invariant that I broke is the fact that a function cannot be used as
> a closure and as a normal function both at the same time, thus the eta-abstraction
> is needed by HiPE.
>
> Kostis, could you give me directions on how to make HiPE not need the intermediate
> closures when doing fun Name/Arity?

Hi Antony,

I am attending a conference this week and will look at this issue during 
the weekend or early next week.

Kostis


From tuncer.ayaz@REDACTED  Wed Jan 23 14:39:26 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Wed, 23 Jan 2013 14:39:26 +0100
Subject: [erlang-bugs] R16 Dialyzer bad_crc error
In-Reply-To: <CAOvwQ4hpBABEVkQ5BZsUDfe+F7taHydhoJBotDS76hoLL6vq1Q@mail.gmail.com>
References: <CAOvwQ4hvHkwkweFeZD=iTyR62ZAC3DXpvVSyO-4+xVxaDUt2XA@mail.gmail.com>
 <CAOvwQ4go_XC3Ji2CVYjegsgFwXtV7B++4feT=WaU7FW97Vdy9g@mail.gmail.com>
 <CABOX0Z-_Xo1t7-fTr-2PeU+UTHvLUKUV=YZgGyQfstTaU_+2Yg@mail.gmail.com>
 <CAOvwQ4g1aF9TarBebwK31+T4_GFTa-2wOsuSjAoJrOL2dQT4Cw@mail.gmail.com>
 <CABOX0Z9CLctaxCwb7FAer=cH5kKjYachXuofg5Ux7tgOqjYyGg@mail.gmail.com>
 <CAOvwQ4hQc1OAMpe4h8p+A5vbOJDoutppqpCyk8kRw7KmJYMQDA@mail.gmail.com>
 <CAOvwQ4hpBABEVkQ5BZsUDfe+F7taHydhoJBotDS76hoLL6vq1Q@mail.gmail.com>
Message-ID: <CAOvwQ4hFgzXWM+_5z-8OMgsK9_uXX1WRKxQ_u9KJOwLo41zTGQ@mail.gmail.com>

On Tue, Jan 22, 2013 at 7:26 PM, Tuncer Ayaz wrote:
> On Tue, Jan 22, 2013 at 7:22 PM, Tuncer Ayaz wrote:
>> On Tue, Jan 22, 2013 at 6:45 PM, Stavros Aronis wrote:
>>> Well, as HiPE is currently broken, the 'Compiling some key modules
>>> to native code...' message is a good hint to either configure OTP
>>> with --disable-hipe (haven't EVER tried it) or just run Dialyzer
>>> with -nn.
>>>
>>> Current master's Dialyzer (with -nn) runs on erlydtl 3306858
>>> without any issues on my machine. Can you confirm that?
>>
>> Without HiPE it doesn't hang but I have copies of the two beams
>> which provoke the error. The beams have debug_info and don't look
>> corrupted, but maybe there's something wrong in them. I'll send you
>> the files for inspection.
>
> Forgot to make it clear that the two files _still_ provoke the same error.

Stavros, thanks for inspecting the beams and the hint. If you build
the beams with R15 and try to feed those to R16 Dialyzer, you can
easily reproduce the "Could not get core Erlang code" error. I don't
know whether this is intended to be due to the R16 feature removals or
an unintended bug.


From tuncer.ayaz@REDACTED  Wed Jan 23 18:36:45 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Wed, 23 Jan 2013 18:36:45 +0100
Subject: [erlang-bugs] otp.git f5170af unknown types
Message-ID: <CAOvwQ4h4VHkf6whqhMvzes6bxYbhV5da=baGhMhnRS8xggz4aQ@mail.gmail.com>

I finally built a new otp.git master (f5170af) PLT and there are two
unknown types:
  epp:source_coding/0
  ssl:sslsock/0

Bug or intentional? If I had to guess, I'd say something was forgotten.


From tuncer.ayaz@REDACTED  Wed Jan 23 18:39:08 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Wed, 23 Jan 2013 18:39:08 +0100
Subject: [erlang-bugs]
	=?iso-8859-1?q?R16_build_error=3A_syntax_error_befo?=
	=?iso-8859-1?q?re=3A_=27=BF=27?=
In-Reply-To: <CAOvwQ4hJ4CKy7Jv=J4_2vpv=Vk+fPvxPkSvOe4pY7WGXAyH_ug@mail.gmail.com>
References: <CAOvwQ4h+eMQvcg9y7Ahs6A9F+nVN-Oz=baryaMTj=-SMG5XRQw@mail.gmail.com>
 <CAOvwQ4h0giEAFKYskRRySOt5VwhfjBQ_sONSXvwPmzdauxwbrg@mail.gmail.com>
 <CAMjYFoN6h1_4O2Q7Fyt0xkgGoOb8saCaFH6X2D_dU-GKKW=S0g@mail.gmail.com>
 <CAOvwQ4io7mnVnxdMK+P0yGXgBhASJbmSYcjL2cRJUUSFsUdw2Q@mail.gmail.com>
 <CAMjYFoMEDtUkrxTzW2yBxRUHUyv7Rbq_mcG7NssLTLPTgCGDiw@mail.gmail.com>
 <CAOvwQ4hJ4CKy7Jv=J4_2vpv=Vk+fPvxPkSvOe4pY7WGXAyH_ug@mail.gmail.com>
Message-ID: <CAOvwQ4h+URi6qoC2NXQmpP1JFv=wY4tm-q--nevzeiJotXsXZA@mail.gmail.com>

On Sat, Jan 19, 2013 at 11:43 PM, Tuncer Ayaz wrote:
> On Sat, Jan 19, 2013 at 8:00 PM, Bj?rn-Egil Dahlberg wrote:
>>
>>
>> 2013/1/19 Tuncer Ayaz
>>>
>>> On Sat, Jan 19, 2013 at 7:42 PM, Bj?rn-Egil Dahlberg wrote:
>>> > HiPE seems to have problem compiling erl_scan. Probably due to
>>> > utf8 enhancements.
>>> > I don't have access to daily builds right now, but I think this
>>> > passes on our build servers (or it has gone unnoticed due to
>>> > massive test data overload).
>>>
>>> Is --enable-native-libs part of the daily build configurations?
>>>
>>
>> It is, we have at least two separate builds on it. Which is kinda
>> surprising since enable-native-libs is not really encouraged by us.
>
> I use enable-native-libs to speed up Dialyzer initialization and avoid
> having to pass -nn (and potentially slow down overall analysis time).
> The disadvantage is that general vm startup takes 100 to 200 ms longer
> due to native module loading.
>
> $ dialyzer --help
> [...]
> --no_native (or -nn)
>       Bypass the native code compilation of some key files that Dialyzer
>       heuristically performs when dialyzing many files; this avoids the
>       compilation time but it may result in (much) longer analysis time
> [...]

Issues have been resolved by the rm-reverse-eta-conversion reversal.


From tuncer.ayaz@REDACTED  Fri Jan 25 18:09:09 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Fri, 25 Jan 2013 18:09:09 +0100
Subject: [erlang-bugs] otp.git f5170af unknown types
In-Reply-To: <CAOvwQ4h4VHkf6whqhMvzes6bxYbhV5da=baGhMhnRS8xggz4aQ@mail.gmail.com>
References: <CAOvwQ4h4VHkf6whqhMvzes6bxYbhV5da=baGhMhnRS8xggz4aQ@mail.gmail.com>
Message-ID: <CAOvwQ4gHRe_1W4bpiPzUK+0QCGOcZoNQ=wYF1iL7HRVMGRLBZQ@mail.gmail.com>

On Wed, Jan 23, 2013 at 6:36 PM, Tuncer Ayaz wrote:
> I finally built a new otp.git master (f5170af) PLT and there are two
> unknown types:
>   epp:source_coding/0
>   ssl:sslsock/0
>
> Bug or intentional? If I had to guess, I'd say something was forgotten.

Resolved with 907d498.


From tuncer.ayaz@REDACTED  Fri Jan 25 18:41:28 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Fri, 25 Jan 2013 18:41:28 +0100
Subject: [erlang-bugs] otp.git 907d498 Dialyzer
Message-ID: <CAOvwQ4h9LCn5b=PhgXu3=sUQ_7903cW6OYXsQQMO-BNeZ-_nOg@mail.gmail.com>

Dialyzing rebar with otp.git 907d498 produced a long list of new
discrepances which to me look like an accidental slip caused by
today's push to otp master.

To trim the lines I replaced 'function' with 'fun'.

getopt.erl:0: Call to missing or unexported fun erlang:get_module_info/2
getopt.erl:0: Call to missing or unexported fun erlang:get_module_info/1
getopt.erl:374: Call to missing or unexported fun erlang:list_to_binary/1
getopt.erl:376: Call to missing or unexported fun erlang:list_to_atom/1
getopt.erl:378: Call to missing or unexported fun erlang:list_to_integer/1
getopt.erl:380: Call to missing or unexported fun erlang:list_to_float/1
getopt.erl:549: Call to missing or unexported fun erlang:atom_to_list/1
getopt.erl:570: Call to missing or unexported fun erlang:atom_to_list/1

mustache.erl:0: Call to missing or unexported fun erlang:get_module_info/2
mustache.erl:0: Call to missing or unexported fun erlang:get_module_info/1
mustache.erl:86: Call to missing or unexported fun re:compile/2
mustache.erl:93: Call to missing or unexported fun re:run/2
mustache.erl:111: Call to missing or unexported fun erlang:atom_to_list/1
mustache.erl:124: Call to missing or unexported fun re:run/2
mustache.erl:149: Call to missing or unexported fun erlang:atom_to_list/1
mustache.erl:166: Call to missing or unexported fun erlang:atom_to_list/1
mustache.erl:171: Call to missing or unexported fun erlang:list_to_atom/1
mustache.erl:177: Call to missing or unexported fun erlang:list_to_atom/1
mustache.erl:190: Call to missing or unexported fun erlang:function_exported/3
mustache.erl:202: Call to missing or unexported fun erlang:integer_to_list/1
mustache.erl:206: Call to missing or unexported fun erlang:atom_to_list/1
mustache.erl:227: Call to missing or unexported fun erlang:list_to_atom/1

rebar.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar.erl:112: Call to missing or unexported fun os:getenv/1
rebar.erl:149: Call to missing or unexported fun erlang:list_to_atom/1
rebar.erl:368: Call to missing or unexported fun erlang:list_to_atom/1
rebar.erl:371: Call to missing or unexported fun erlang:list_to_integer/1

rebar_abnfc_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_abnfc_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1

rebar_app_utils.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_app_utils.erl:0: Call to missing or unexported fun
erlang:get_module_info/1
rebar_app_utils.erl:128: Call to missing or unexported fun erlang:list_to_atom/1

rebar_appups.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_appups.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_appups.erl:127: Call to missing or unexported fun erlang:list_to_atom/1
rebar_appups.erl:149: Call to missing or unexported fun erlang:atom_to_list/1
rebar_appups.erl:165: Call to missing or unexported fun erlang:list_to_atom/1

rebar_asn1_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_asn1_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1

rebar_base_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_base_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1

rebar_cleaner.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_cleaner.erl:0: Call to missing or unexported fun erlang:get_module_info/1

rebar_config.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_config.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_config.erl:97: Call to missing or unexported fun erlang:list_to_integer/1

rebar_core.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_core.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_core.erl:305: Call to missing or unexported fun erlang:atom_to_list/1
rebar_core.erl:305: Call to missing or unexported fun erlang:list_to_atom/1
rebar_core.erl:314: Call to missing or unexported fun erlang:atom_to_list/1
rebar_core.erl:395: Call to missing or unexported fun erlang:function_exported/3
rebar_core.erl:434: Call to missing or unexported fun erlang:function_exported/3
rebar_core.erl:512: Call to missing or unexported fun erlang:atom_to_list/1

rebar_ct.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_ct.erl:0: Call to missing or unexported fun erlang:get_module_info/1

rebar_deps.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_deps.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_deps.erl:82: Call to missing or unexported fun erlang:list_to_atom/1
rebar_deps.erl:124: Call to missing or unexported fun os:getenv/1
rebar_deps.erl:354: Call to missing or unexported fun re:run/3
rebar_deps.erl:550: Call to missing or unexported fun re:run/3
rebar_deps.erl:552: Call to missing or unexported fun erlang:list_to_integer/1
rebar_deps.erl:552: Call to missing or unexported fun erlang:list_to_tuple/1

rebar_dia_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_dia_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1

rebar_edoc.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_edoc.erl:0: Call to missing or unexported fun erlang:get_module_info/1

rebar_erlc_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_erlc_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1
rebar_erlc_compiler.erl:101: Call to missing or unexported fun
erlang:iolist_to_binary/1
rebar_erlc_compiler.erl:101: Call to missing or unexported fun
erlang:binary_to_list/1
rebar_erlc_compiler.erl:181: Call to missing or unexported fun
erlang:list_to_atom/1
rebar_erlc_compiler.erl:306: Call to missing or unexported fun
erlang:atom_to_list/1

rebar_erlydtl_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_erlydtl_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1

rebar_escripter.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_escripter.erl:0: Call to missing or unexported fun
erlang:get_module_info/1
rebar_escripter.erl:43: Call to missing or unexported fun erlang:atom_to_list/1
rebar_escripter.erl:77: Call to missing or unexported fun
erlang:iolist_to_binary/1
rebar_escripter.erl:119: Call to missing or unexported fun erlang:atom_to_list/1

rebar_eunit.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_eunit.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_eunit.erl:183: Call to missing or unexported fun erlang:list_to_atom/1
rebar_eunit.erl:227: Call to missing or unexported fun erlang:list_to_atom/1
rebar_eunit.erl:245: Call to missing or unexported fun erlang:atom_to_list/1
rebar_eunit.erl:252: Call to missing or unexported fun erlang:list_to_atom/1
rebar_eunit.erl:260: Call to missing or unexported fun erlang:atom_to_list/1
rebar_eunit.erl:269: Call to missing or unexported fun erlang:atom_to_list/1
rebar_eunit.erl:293: Call to missing or unexported fun erlang:list_to_atom/1
rebar_eunit.erl:307: Call to missing or unexported fun erlang:atom_to_list/1
rebar_eunit.erl:308: Call to missing or unexported fun re:run/2
rebar_eunit.erl:323: Call to missing or unexported fun
erlang:function_exported/3
rebar_eunit.erl:331: Call to missing or unexported fun erlang:atom_to_list/1
rebar_eunit.erl:333: Call to missing or unexported fun re:run/2
rebar_eunit.erl:351: Call to missing or unexported fun
eunit_test:function_wrapper/2
rebar_eunit.erl:445: Call to missing or unexported fun erlang:whereis/1
rebar_eunit.erl:457: Call to missing or unexported fun erlang:group_leader/2
rebar_eunit.erl:567: Call to missing or unexported fun erlang:atom_to_list/1
rebar_eunit.erl:584: Call to missing or unexported fun erlang:atom_to_list/1
rebar_eunit.erl:598: Call to missing or unexported fun erlang:integer_to_list/1
rebar_eunit.erl:607: Call to missing or unexported fun erlang:is_alive/0
rebar_eunit.erl:607: Call to missing or unexported fun erlang:processes/0
rebar_eunit.erl:613: Call to missing or unexported fun erlang:is_alive/0
rebar_eunit.erl:636: Call to missing or unexported fun erlang:processes/0
rebar_eunit.erl:655: Call to missing or unexported fun erlang:process_info/1
rebar_eunit.erl:680: Call to missing or unexported fun erlang:exit/2
rebar_eunit.erl:695: Call to missing or unexported fun erlang:list_to_atom/1
rebar_eunit.erl:698: Call to missing or unexported fun erlang:atom_to_list/1
rebar_eunit.erl:748: Call to missing or unexported fun erlang:monitor/2

rebar_file_utils.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_file_utils.erl:0: Call to missing or unexported fun
erlang:get_module_info/1
rebar_file_utils.erl:116: Call to missing or unexported fun
erlang:iolist_to_binary/1

rebar_lfe_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_lfe_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1

rebar_log.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_log.erl:0: Call to missing or unexported fun erlang:get_module_info/1

rebar_neotoma_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_neotoma_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1
rebar_neotoma_compiler.erl:99: Call to missing or unexported fun
erlang:list_to_atom/1

rebar_otp_app.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_otp_app.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_otp_app.erl:142: Call to missing or unexported fun erlang:list_to_atom/1

rebar_port_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_port_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1
rebar_port_compiler.erl:307: Call to missing or unexported fun erlang:make_fun/3
rebar_port_compiler.erl:403: Call to missing or unexported fun re:run/3
rebar_port_compiler.erl:450: Call to missing or unexported fun re:run/3
rebar_port_compiler.erl:476: Call to missing or unexported fun
erlang:list_to_tuple/1
rebar_port_compiler.erl:476: Call to missing or unexported fun os:getenv/0

rebar_protobuffs_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_protobuffs_compiler.erl:0: Call to missing or unexported fun
erlang:get_module_info/1

rebar_qc.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_qc.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_qc.erl:169: Call to missing or unexported fun erlang:atom_to_list/1

rebar_rel_utils.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_rel_utils.erl:0: Call to missing or unexported fun
erlang:get_module_info/1

rebar_reltool.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_reltool.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_reltool.erl:249: Call to missing or unexported fun erlang:list_to_binary/1

rebar_require_vsn.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_require_vsn.erl:0: Call to missing or unexported fun
erlang:get_module_info/1
rebar_require_vsn.erl:63: Call to missing or unexported fun re:run/3
rebar_require_vsn.erl:91: Call to missing or unexported fun re:run/3
rebar_require_vsn.erl:95: Call to missing or unexported fun
erlang:list_to_integer/1

rebar_shell.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_shell.erl:0: Call to missing or unexported fun erlang:get_module_info/1

rebar_subdirs.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_subdirs.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_subdirs.erl:42: Call to missing or unexported fun erlang:make_fun/3

rebar_templater.erl:0: Call to missing or unexported fun
erlang:get_module_info/2
rebar_templater.erl:0: Call to missing or unexported fun
erlang:get_module_info/1
rebar_templater.erl:64: Call to missing or unexported fun erlang:atom_to_list/1
rebar_templater.erl:82: Call to missing or unexported fun
erlang:list_to_binary/1
rebar_templater.erl:203: Call to missing or unexported fun re:run/3
rebar_templater.erl:207: Call to missing or unexported fun os:getenv/1
rebar_templater.erl:270: Call to missing or unexported fun
erlang:binary_to_list/1

rebar_upgrade.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_upgrade.erl:0: Call to missing or unexported fun erlang:get_module_info/1

rebar_utils.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_utils.erl:0: Call to missing or unexported fun erlang:get_module_info/1
rebar_utils.erl:68: Call to missing or unexported fun re:run/3
rebar_utils.erl:86: Call to missing or unexported fun erlang:integer_to_list/1
rebar_utils.erl:111: Call to missing or unexported fun erlang:open_port/2
rebar_utils.erl:158: Call to missing or unexported fun
erlang:function_exported/3
rebar_utils.erl:162: Call to missing or unexported fun escript:foldl/3
rebar_utils.erl:219: Call to missing or unexported fun erlang:make_fun/3
rebar_utils.erl:223: Call to missing or unexported fun erlang:make_fun/3
rebar_utils.erl:226: Call to missing or unexported fun erlang:make_fun/3
rebar_utils.erl:232: Call to missing or unexported fun erlang:make_fun/3
rebar_utils.erl:239: Call to missing or unexported fun erlang:make_fun/3
rebar_utils.erl:271: Call to missing or unexported fun erlang:is_builtin/3
rebar_utils.erl:290: Call to missing or unexported fun erlang:list_to_atom/1
rebar_utils.erl:413: Call to missing or unexported fun erlang:list_to_atom/1
rebar_utils.erl:416: Call to missing or unexported fun erlang:list_to_atom/1
rebar_utils.erl:466: Call to missing or unexported fun erlang:binary_to_list/1

rebar_xref.erl:0: Call to missing or unexported fun erlang:get_module_info/2
rebar_xref.erl:0: Call to missing or unexported fun erlang:get_module_info/1


From arif@REDACTED  Tue Jan 29 11:31:10 2013
From: arif@REDACTED (arif@REDACTED)
Date: Tue, 29 Jan 2013 02:31:10 -0800
Subject: [erlang-bugs] erlang:decode_packet - wrong parsing of
	Sec-WebSock-Accept header
Message-ID: <e3cdda51ddc367e76cfa894bcbd47cd2.squirrel@fruiteater.riseup.net>

Hi,

In R15B (erts-5.9) erlang:decode_packet/3 seems to be making an error
parsing the Sec-WebSock-Accept header

43> erlang:decode_packet(httph, <<"Sec-WebSocket-Accept:
whatever\r\n\r\n">>, []).
{ok,{http_header,0,"Sec-Websocket-Accept",undefined,
                 "whatever"},
    <<"\r\n">>}
44>

One, it doesn't parse it as an atom, but as a string (but that much can be
guessed from the documentation).

Two, the character S in WebSocket is parsed as lowercase instead of the
uppercase it is in the parsed string.

Best regards
Arif




From tuncer.ayaz@REDACTED  Tue Jan 29 13:54:46 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Tue, 29 Jan 2013 13:54:46 +0100
Subject: [erlang-bugs] otp.git 907d498 Dialyzer
In-Reply-To: <CAOvwQ4h9LCn5b=PhgXu3=sUQ_7903cW6OYXsQQMO-BNeZ-_nOg@mail.gmail.com>
References: <CAOvwQ4h9LCn5b=PhgXu3=sUQ_7903cW6OYXsQQMO-BNeZ-_nOg@mail.gmail.com>
Message-ID: <CAOvwQ4jUDp9T37+_bg0K_nQC6r52J8oqamGiVKWgZiF89nV+eA@mail.gmail.com>

On Fri, Jan 25, 2013 at 6:41 PM, Tuncer Ayaz wrote:
> Dialyzing rebar with otp.git 907d498 produced a long list of new
> discrepances which to me look like an accidental slip caused by
> today's push to otp master.
>
> To trim the lines I replaced 'function' with 'fun'.
>
> getopt.erl:0: Call to missing or unexported fun erlang:get_module_info/2
> getopt.erl:0: Call to missing or unexported fun erlang:get_module_info/1
> getopt.erl:374: Call to missing or unexported fun erlang:list_to_binary/1
> getopt.erl:376: Call to missing or unexported fun erlang:list_to_atom/1
> getopt.erl:378: Call to missing or unexported fun erlang:list_to_integer/1
> getopt.erl:380: Call to missing or unexported fun erlang:list_to_float/1
> getopt.erl:549: Call to missing or unexported fun erlang:atom_to_list/1
> getopt.erl:570: Call to missing or unexported fun erlang:atom_to_list/1

[...]

Resolved with git://github.com/psyeugenic/otp.git at b30420d.
Thanks Bjorn-Egil.


From vinoski@REDACTED  Tue Jan 29 14:57:56 2013
From: vinoski@REDACTED (Steve Vinoski)
Date: Tue, 29 Jan 2013 08:57:56 -0500
Subject: [erlang-bugs] erlang:decode_packet - wrong parsing of
 Sec-WebSock-Accept header
In-Reply-To: <e3cdda51ddc367e76cfa894bcbd47cd2.squirrel@fruiteater.riseup.net>
References: <e3cdda51ddc367e76cfa894bcbd47cd2.squirrel@fruiteater.riseup.net>
Message-ID: <CAO+zUOWKXOBwn5TRENc=W8=_mR3yhyVYO89RCWAGZh3Bywvs9A@mail.gmail.com>

On Tue, Jan 29, 2013 at 5:31 AM, <arif@REDACTED> wrote:

> Hi,
>
> In R15B (erts-5.9) erlang:decode_packet/3 seems to be making an error
> parsing the Sec-WebSock-Accept header
>
> 43> erlang:decode_packet(httph, <<"Sec-WebSocket-Accept:
> whatever\r\n\r\n">>, []).
> {ok,{http_header,0,"Sec-Websocket-Accept",undefined,
>                  "whatever"},
>     <<"\r\n">>}
> 44>
>
> One, it doesn't parse it as an atom, but as a string (but that much can be
> guessed from the documentation).
>


Not all headers are parsed as atom, since doing that would allow a
malicious client to send a wide variety of different headers that would
eventually overflow the server's atom table and crash the server. Only
common headers are parsed as atoms. Your code needs to be able to handle
both atom and string results from decode_packet.



> Two, the character S in WebSocket is parsed as lowercase instead of the
> uppercase it is in the parsed string.



All HTTP headers are case-insensitive, so regardless of whether the headers
contain SEC-WEBSOCKET-ACCEPT, sEC-wEbSoCkEt-AcCePt, or sec-websocket-accept
as the header name, the parser produces Sec-Websocket-Accept:

1> erlang:decode_packet(httph, <<"SEC-WEBSOCKET-ACCEPT:
whatever\r\n\r\n">>, []).
{ok,{http_header,0,"Sec-Websocket-Accept",undefined,
                 "whatever"},
    <<"\r\n">>}
2> erlang:decode_packet(httph, <<"sEC-wEbSoCkEt-AcCePt:
whatever\r\n\r\n">>, []).
{ok,{http_header,0,"Sec-Websocket-Accept",undefined,
                 "whatever"},
    <<"\r\n">>}
3> erlang:decode_packet(httph, <<"sec-websocket-accept:
whatever\r\n\r\n">>, []).
{ok,{http_header,0,"Sec-Websocket-Accept",undefined,
                 "whatever"},
    <<"\r\n">>}

So, neither of these issues is a bug IMO.

--steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130129/c4e3b7a9/attachment.htm>

From sverker.eriksson@REDACTED  Tue Jan 29 15:06:54 2013
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Tue, 29 Jan 2013 15:06:54 +0100
Subject: [erlang-bugs] erlang:decode_packet - wrong parsing
 of	Sec-WebSock-Accept header
In-Reply-To: <e3cdda51ddc367e76cfa894bcbd47cd2.squirrel@fruiteater.riseup.net>
References: <e3cdda51ddc367e76cfa894bcbd47cd2.squirrel@fruiteater.riseup.net>
Message-ID: <5107D77E.4050705@erix.ericsson.se>


arif@REDACTED wrote:
> Hi,
>
> In R15B (erts-5.9) erlang:decode_packet/3 seems to be making an error
> parsing the Sec-WebSock-Accept header
>
> 43> erlang:decode_packet(httph, <<"Sec-WebSocket-Accept:
> whatever\r\n\r\n">>, []).
> {ok,{http_header,0,"Sec-Websocket-Accept",undefined,
>                  "whatever"},
>     <<"\r\n">>}
> 44>
>
> One, it doesn't parse it as an atom, but as a string (but that much can be
> guessed from the documentation).
>
>   
"Recognized request methods and header fields are returned as atoms. 
Others are returned as strings."

As we don't want to create atoms dynamically from arbitrary input, we 
only recognize a constant number of the most common method and field names.
Sec-Websocket-Accept is not one of them, hence returned as a string.


> Two, the character S in WebSocket is parsed as lowercase instead of the
> uppercase it is in the parsed string.
>
>   
Header names are case insensitive according to HTTP. To ease matching we 
always return unrecognized strings on a format with capital letters only 
first and after hyphen, like "Sec-Websocket-Accept".


/Sverker, Erlang/OTP Ericsson




From essen@REDACTED  Tue Jan 29 16:59:03 2013
From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
Date: Tue, 29 Jan 2013 16:59:03 +0100
Subject: [erlang-bugs] erlang:decode_packet - wrong parsing
 of	Sec-WebSock-Accept header
In-Reply-To: <5107D77E.4050705@erix.ericsson.se>
References: <e3cdda51ddc367e76cfa894bcbd47cd2.squirrel@fruiteater.riseup.net>
 <5107D77E.4050705@erix.ericsson.se>
Message-ID: <5107F1C7.5030308@ninenines.eu>

On 01/29/2013 03:06 PM, Sverker Eriksson wrote:
>> Two, the character S in WebSocket is parsed as lowercase instead of the
>> uppercase it is in the parsed string.
>>
> Header names are case insensitive according to HTTP. To ease matching we
> always return unrecognized strings on a format with capital letters only
> first and after hyphen, like "Sec-Websocket-Accept".

Not exactly true.

3> erlang:decode_packet(httph_bin, <<"sec-websocket-version: 
abc\r\n\r\n">>, []).
{ok,{http_header,0,<<"sec-websocket-version">>,undefined,
                  <<"abc">>},
     <<"\r\n">>}
4> erlang:decode_packet(httph_bin, <<"sec-websocket-versio: 
abc\r\n\r\n">>, []).
{ok,{http_header,0,<<"Sec-Websocket-Versio">>,undefined,
                  <<"abc">>},
     <<"\r\n">>}

Past a certain number of characters, erlang:decode_packet do not attempt 
that. Problem is this header is used in the wild and standardized. You 
should consider increasing that limit slightly.

Also, although probably not having any impact in real applications:

6> erlang:decode_packet(httph_bin, <<"sec-websocket--ver: 
abc\r\n\r\n">>, []).  {ok,{http_header,0,<<"Sec-Websocket--ver">>,undefined,
                  <<"abc">>},
     <<"\r\n">>}

If you got two -- the next word do not get capitalized. Minor oddity.

-- 
Lo?c Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu


From sverker.eriksson@REDACTED  Tue Jan 29 17:32:19 2013
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Tue, 29 Jan 2013 17:32:19 +0100
Subject: [erlang-bugs] erlang:decode_packet - wrong parsing
 of	Sec-WebSock-Accept header
In-Reply-To: <5107F1C7.5030308@ninenines.eu>
References: <e3cdda51ddc367e76cfa894bcbd47cd2.squirrel@fruiteater.riseup.net>
 <5107D77E.4050705@erix.ericsson.se> <5107F1C7.5030308@ninenines.eu>
Message-ID: <5107F993.5070700@erix.ericsson.se>

Lo?c Hoguin wrote:
> On 01/29/2013 03:06 PM, Sverker Eriksson wrote:
>>> Two, the character S in WebSocket is parsed as lowercase instead of the
>>> uppercase it is in the parsed string.
>>>
>> Header names are case insensitive according to HTTP. To ease matching we
>> always return unrecognized strings on a format with capital letters only
>> first and after hyphen, like "Sec-Websocket-Accept".
>
> Not exactly true.
>
> 3> erlang:decode_packet(httph_bin, <<"sec-websocket-version: 
> abc\r\n\r\n">>, []).
> {ok,{http_header,0,<<"sec-websocket-version">>,undefined,
>                  <<"abc">>},
>     <<"\r\n">>}
> 4> erlang:decode_packet(httph_bin, <<"sec-websocket-versio: 
> abc\r\n\r\n">>, []).
> {ok,{http_header,0,<<"Sec-Websocket-Versio">>,undefined,
>                  <<"abc">>},
>     <<"\r\n">>}
>
> Past a certain number of characters, erlang:decode_packet do not 
> attempt that. Problem is this header is used in the wild and 
> standardized. You should consider increasing that limit slightly.
>
Deja vu. I thought we fixed this, apparently not.
The limiting factor is an internal buffer with a static size of 20 
characters. I guess increasing the buffer to... say 50 characters would 
do as a pragmatic solution.

/Sverker



From arif@REDACTED  Tue Jan 29 22:52:28 2013
From: arif@REDACTED (Arif)
Date: Tue, 29 Jan 2013 22:52:28 +0100
Subject: [erlang-bugs] erlang:decode_packet - wrong parsing
 of	Sec-WebSock-Accept header
In-Reply-To: <5107D77E.4050705@erix.ericsson.se>
References: <e3cdda51ddc367e76cfa894bcbd47cd2.squirrel@fruiteater.riseup.net>
 <5107D77E.4050705@erix.ericsson.se>
Message-ID: <5108449C.3070802@riseup.net>

On 01/29/2013 03:06 PM, Sverker Eriksson wrote:

Header names are case insensitive according to HTTP. To ease matching we 
always return unrecognized strings on a format with capital letters only 
first and after hyphen, like "Sec-Websocket-Accept".
>
>
> /Sverker, Erlang/OTP Ericsson
>
>

Thank you for the explanation of the convention. As I was only 
interested in one of the headers, having to lower or uppercase all of 
them just to get to the right one seemed too much of a waste.

Regards
Arif



From norton@REDACTED  Wed Jan 30 04:14:29 2013
From: norton@REDACTED (=?utf-8?B?44OO44O844OI44OzIOOCuOODp+ODvOOCu+ODlSDjgqbjgqfjgqQg?= =?utf-8?B?44Oz?=)
Date: Wed, 30 Jan 2013 12:14:29 +0900
Subject: [erlang-bugs] master (commit b0e4f20)/master-pu (commit
	95924c8) compilation warnings report
In-Reply-To: <9DB2C8D7-AF88-418A-ABC7-F15443F459E8@lovely.email.ne.jp>
References: <9DB2C8D7-AF88-418A-ABC7-F15443F459E8@lovely.email.ne.jp>
Message-ID: <4A87765D-EF69-4859-9607-56A4C8ADAA01@lovely.email.ne.jp>


Hello.

In my local environment, I repeated these steps again with the latest master branch (commit 68b804f) and a homebrew built version of gcc (4.7.2).  Fortunately, these warnings have disappeared with the homebrew built version of gcc.  I apologise for the noise.

thanks,

Joe N.


$ gcc --version
gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.




On Jan 20, 2013, at 23:23 , ???? ????? ??? ? <norton@REDACTED> wrote:

> 
> Hello.
> 
> In my local environment, I see the following plus other compilation warnings with the latest master/master-pu branches.
> 
> $  head make.log-master-stderr.txt
> beam/beam_emu.c: In function ?process_main?:
> beam/beam_emu.c:1271: warning: cast from pointer to integer of different size
> In file included from beam/beam_emu.c:1281:
> i386-apple-darwin12.2.0/opt/smp/beam_hot.h:12: warning: cast from pointer to integer of different size
> i386-apple-darwin12.2.0/opt/smp/beam_hot.h:21: warning: cast from pointer to integer of different size
>   :
>   :
> 
> I attached the stderr/stdout logs below.  If this is a known issue, please ignore this e-mail.  If you need more information or want further investigation, please let me know.  
> 
> thanks,
> 
> Joe N.
> 
> 
> Build Recipe:
> 
> https://github.com/norton/manifests/blob/dev/rebar.mk#L209
> 
> 
> How To Repeat:
> 
> $ git clone git://github.com/norton/manifests.git
> $ cd manifests
> $ make -f rebar.mk otp
> $ head make.log-master-stderr.txt
> 
> 
> Environment Details:
> 
> $ uname -a
> Darwin hostname 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
> 
> $ gcc --version
> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> <make.log-master-pu-stdout.txt.gz>
> <make.log-master-stdout.txt.gz>
> <make.log-master-pu-stderr.txt.gz>
> <make.log-master-stderr.txt.gz>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130130/2e01d918/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log-master-stderr.txt.gz
Type: application/x-gzip
Size: 4713 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130130/2e01d918/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130130/2e01d918/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log-master-stdout.txt.gz
Type: application/x-gzip
Size: 41868 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130130/2e01d918/attachment-0001.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130130/2e01d918/attachment-0002.htm>

From essen@REDACTED  Wed Jan 30 17:01:54 2013
From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
Date: Wed, 30 Jan 2013 17:01:54 +0100
Subject: [erlang-bugs] R16A: tuple funs still work in the shell
Message-ID: <510943F2.1010701@ninenines.eu>

README says:

   OTP-10170  Tuple funs (deprecated in R15B) are no longer supported.

However in the shell:

4> {lists,seq}(1,100).
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,
  23,24,25,26,27,28,29|...]

It's properly removed in a compiled module:

2> test:t().
** exception error: bad function {lists,seq}
      in function  test:t/0 (test.erl, line 5)

-- 
Lo?c Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu


From essen@REDACTED  Wed Jan 30 17:33:00 2013
From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
Date: Wed, 30 Jan 2013 17:33:00 +0100
Subject: [erlang-bugs] Dialyzer PLT update takes too much memory
Message-ID: <51094B3C.2090504@ninenines.eu>

Going from R15B03 to R16A and trying to dialyze has Dialyzer complains 
about the outdated PLT. So far so good. Problem is Dialyzer never 
manages to update said PLT due to an excessive amount of memory use.

With 2GB of free memory the following command fails when the PLT is 
outdated:

dialyzer --src src --plt .cowboy.plt --no_native -Werror_handling 
-Wrace_conditions -Wunmatched_returns

The following output is observed:

   Checking whether the PLT .cowboy.plt is up-to-date... no
     (the PLT .cowboy.plt was built with an old version of Dialyzer)
   Rebuilding the information in .cowboy.plt...
Crash dump was written to: erl_crash.dump
eheap_alloc: Cannot allocate 762886488 bytes of memory (of type "heap").
make: *** [dialyze] Aborted (core dumped)

The crash dump is a mighty 102MB.

Building the PLT from scratch works.

-- 
Lo?c Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu


From kostis@REDACTED  Wed Jan 30 17:53:05 2013
From: kostis@REDACTED (Kostis Sagonas)
Date: Wed, 30 Jan 2013 17:53:05 +0100
Subject: [erlang-bugs] Dialyzer PLT update takes too much memory
In-Reply-To: <51094B3C.2090504@ninenines.eu>
References: <51094B3C.2090504@ninenines.eu>
Message-ID: <51094FF1.7090905@cs.ntua.gr>

On 01/30/2013 05:33 PM, Lo?c Hoguin wrote:
> Going from R15B03 to R16A and trying to dialyze has Dialyzer complains
> about the outdated PLT. So far so good. Problem is Dialyzer never
> manages to update said PLT due to an excessive amount of memory use.
>
> With 2GB of free memory the following command fails when the PLT is
> outdated:
>
> dialyzer --src src --plt .cowboy.plt --no_native -Werror_handling
> -Wrace_conditions -Wunmatched_returns
>
> The following output is observed:
>
> Checking whether the PLT .cowboy.plt is up-to-date... no
> (the PLT .cowboy.plt was built with an old version of Dialyzer)
> Rebuilding the information in .cowboy.plt...
> Crash dump was written to: erl_crash.dump
> eheap_alloc: Cannot allocate 762886488 bytes of memory (of type "heap").
> make: *** [dialyze] Aborted (core dumped)
>
> The crash dump is a mighty 102MB.
>
> Building the PLT from scratch works.

You cannot expect the update to work. In R16* there have been major 
changes related to where the type information of BIFs is located: before 
most of it was hardcoded in erl_bif_types while now it appears in the 
corresponding files (e.g. erlang.erl). I am not sure whether this is the 
culprit or not, but I can understand that changes like this one cause 
serious confusion.

I suggest that you always build the PLT from scratch in each new version 
which, as you mention, works.

Kostis


From essen@REDACTED  Wed Jan 30 17:45:40 2013
From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
Date: Wed, 30 Jan 2013 17:45:40 +0100
Subject: [erlang-bugs] Dialyzer PLT update takes too much memory
In-Reply-To: <51094FF1.7090905@cs.ntua.gr>
References: <51094B3C.2090504@ninenines.eu> <51094FF1.7090905@cs.ntua.gr>
Message-ID: <51094E34.4090207@ninenines.eu>

On 01/30/2013 05:53 PM, Kostis Sagonas wrote:
> On 01/30/2013 05:33 PM, Lo?c Hoguin wrote:
>> Going from R15B03 to R16A and trying to dialyze has Dialyzer complains
>> about the outdated PLT. So far so good. Problem is Dialyzer never
>> manages to update said PLT due to an excessive amount of memory use.
>>
>> With 2GB of free memory the following command fails when the PLT is
>> outdated:
>>
>> dialyzer --src src --plt .cowboy.plt --no_native -Werror_handling
>> -Wrace_conditions -Wunmatched_returns
>>
>> The following output is observed:
>>
>> Checking whether the PLT .cowboy.plt is up-to-date... no
>> (the PLT .cowboy.plt was built with an old version of Dialyzer)
>> Rebuilding the information in .cowboy.plt...
>> Crash dump was written to: erl_crash.dump
>> eheap_alloc: Cannot allocate 762886488 bytes of memory (of type "heap").
>> make: *** [dialyze] Aborted (core dumped)
>>
>> The crash dump is a mighty 102MB.
>>
>> Building the PLT from scratch works.
>
> You cannot expect the update to work. In R16* there have been major
> changes related to where the type information of BIFs is located: before
> most of it was hardcoded in erl_bif_types while now it appears in the
> corresponding files (e.g. erlang.erl). I am not sure whether this is the
> culprit or not, but I can understand that changes like this one cause
> serious confusion.
>
> I suggest that you always build the PLT from scratch in each new version
> which, as you mention, works.

I'm fine with it, but then the message

   (the PLT .cowboy.plt was built with an old version of Dialyzer)

should probably be replaced by a suggestion to build the PLT from 
scratch; as it is Dialyzer makes it sound like it can take care of it 
without problem. Thing is, if it eats all the memory, under Linux the 
kernel might decide to kill another application to allocate the space, 
which requires at the very least a fair warning.

-- 
Lo?c Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu


From essen@REDACTED  Wed Jan 30 21:48:57 2013
From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
Date: Wed, 30 Jan 2013 21:48:57 +0100
Subject: [erlang-bugs] R16A: Small inconvenience with Unicode strings in the
	shell
Message-ID: <51098739.8020308@ninenines.eu>

Erlang R16A (erts-5.10) [source] [64-bit] [smp:4:4] [async-threads:10] 
[hipe] [kernel-poll:false]

Eshell V5.10  (abort with ^G)
1> "aaa".
"aaa"
2> "??".
"??"
3>3>3>3>3>3>3>3>3>3>3>3>3>3>3>3>3>3>

In 1> I wrote an ASCII string, got the result, then tried to 
up-down-up-down-up-down-up-down and it adds/remove "aaa" as intended.

Then in 2> I wrote an Unicode string, got the result (nice!), then tried 
to do the same up-down mimic except everytime I did down when the 
Unicode text was printed, it added a 3> on the line. It only does so for 
the Unicode and not for ASCII.

Thinking there's some missing cleanup there.

-- 
Lo?c Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu


From tuncer.ayaz@REDACTED  Thu Jan 31 01:11:56 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Thu, 31 Jan 2013 01:11:56 +0100
Subject: [erlang-bugs] R16 EUnit *** context setup failed ***
In-Reply-To: <85BE9BC9-731C-4DAE-BD47-A33FE7B30AD5@gmail.com>
References: <CAOvwQ4jMP6f55Nui6BUSh0SQirKXCFEMV6OBQ2m06XVQcBd4EQ@mail.gmail.com>
 <85BE9BC9-731C-4DAE-BD47-A33FE7B30AD5@gmail.com>
Message-ID: <CAOvwQ4gHHQfnjE7iE_F7-oW7n02NWABSNtkkNA=w9wu0cFS9cw@mail.gmail.com>

On Fri, Nov 23, 2012 at 4:20 PM, Anthony Ramine wrote:
> I can reproduce this with the exact same steps.

This is the git-bisect result:

70b5e24c9498225fadc08d19503269c8aad851bf is the first bad commit
commit 70b5e24c9498225fadc08d19503269c8aad851bf
Author: Bjorn Gustavsson <bjorn@REDACTED>
Date:   Tue Sep 11 15:03:53 2012 +0200

    Fix filelib:wildcard/2

    filelib:wildcard("some/relative/path/*.beam", Path) would fail to
    match any file. That is, filelib:wildcard/2 would not work if the
    first component of the pattern did not contain any wildcard
    characters.

    Noticed-by: Samuel Rivas

> Le 13 nov. 2012 ? 14:18, Tuncer Ayaz a ?crit :
>
>> If I build and run rebar's EUnit tests with R16, I see "*** context
>> setup failed ***" errors.
>>
>> Interestingly, if I use a tree where ebin/*, rebar, and .eunit/*.beam
>> have been built with R15B02, then neither R16 nor R15 throw the
>> context setup errors.
>>
>> # fetch and build rebar
>> $ git clone git://github.com/rebar/rebar.git
>> $ cd rebar
>> $ make
>> # run tests with new rebar binary
>> $ ./rebar eunit
>> # *** context setup failed *** errors and 50 out of 72 tests
>> # not executed
>> $ rm ebin/* .eunit/* rebar
>> # rebuild rebar and EUnit tests with R15
>> $ make && ./rebar eunit
>> # running EUnit tests with either R15 or R16 works now
>>
>> Can anyone else reproduce this? Could this be caused by compiler
>> changes in R16? I don't see any changes in lib/eunit after R15B02.


From bgustavsson@REDACTED  Thu Jan 31 16:51:33 2013
From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=)
Date: Thu, 31 Jan 2013 16:51:33 +0100
Subject: [erlang-bugs] R16 EUnit *** context setup failed ***
In-Reply-To: <CAOvwQ4gHHQfnjE7iE_F7-oW7n02NWABSNtkkNA=w9wu0cFS9cw@mail.gmail.com>
References: <CAOvwQ4jMP6f55Nui6BUSh0SQirKXCFEMV6OBQ2m06XVQcBd4EQ@mail.gmail.com>
 <85BE9BC9-731C-4DAE-BD47-A33FE7B30AD5@gmail.com>
 <CAOvwQ4gHHQfnjE7iE_F7-oW7n02NWABSNtkkNA=w9wu0cFS9cw@mail.gmail.com>
Message-ID: <CA+yh78QVq5cGkRBSPJ_+oAUufKKQQNRge=dBnmNO8ZbTxqPxiw@mail.gmail.com>

Thanks for bisecting!

I will fix the bug in R16B.


On Thu, Jan 31, 2013 at 1:11 AM, Tuncer Ayaz <tuncer.ayaz@REDACTED> wrote:

> On Fri, Nov 23, 2012 at 4:20 PM, Anthony Ramine wrote:
> > I can reproduce this with the exact same steps.
>
> This is the git-bisect result:
>
> 70b5e24c9498225fadc08d19503269c8aad851bf is the first bad commit
> commit 70b5e24c9498225fadc08d19503269c8aad851bf
> Author: Bjorn Gustavsson <bjorn@REDACTED>
> Date:   Tue Sep 11 15:03:53 2012 +0200
>
>     Fix filelib:wildcard/2
>
>     filelib:wildcard("some/relative/path/*.beam", Path) would fail to
>     match any file. That is, filelib:wildcard/2 would not work if the
>     first component of the pattern did not contain any wildcard
>     characters.
>
>     Noticed-by: Samuel Rivas
>
> > Le 13 nov. 2012 ? 14:18, Tuncer Ayaz a ?crit :
> >
> >> If I build and run rebar's EUnit tests with R16, I see "*** context
> >> setup failed ***" errors.
> >>
> >> Interestingly, if I use a tree where ebin/*, rebar, and .eunit/*.beam
> >> have been built with R15B02, then neither R16 nor R15 throw the
> >> context setup errors.
> >>
> >> # fetch and build rebar
> >> $ git clone git://github.com/rebar/rebar.git
> >> $ cd rebar
> >> $ make
> >> # run tests with new rebar binary
> >> $ ./rebar eunit
> >> # *** context setup failed *** errors and 50 out of 72 tests
> >> # not executed
> >> $ rm ebin/* .eunit/* rebar
> >> # rebuild rebar and EUnit tests with R15
> >> $ make && ./rebar eunit
> >> # running EUnit tests with either R15 or R16 works now
> >>
> >> Can anyone else reproduce this? Could this be caused by compiler
> >> changes in R16? I don't see any changes in lib/eunit after R15B02.
>



-- 
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130131/4dde5ae5/attachment.htm>

From EMcDowell@REDACTED  Thu Jan 31 19:10:16 2013
From: EMcDowell@REDACTED (McDowell, Edward D.)
Date: Thu, 31 Jan 2013 13:10:16 -0500
Subject: [erlang-bugs] R16A erl.exe does not exit properly on Windows.
Message-ID: <79EEF8FD7A3DA9458F4886A20D3F35B401EFF91847E7@mailsvr4.RICOL.EDU>

The Erlang command line program erl.exe release R16A does not exit properly
on Windows 7 Starter Edition using a 32-bit processor.

When the shell is terminated using either init:stop() or halt() several
hundred carriage-return line-feed sequences are printed and then Windows
displays "erl.exe has stopped working."  No crash dump is produced.

This problem does not occur with the Windows shell werl.exe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130131/6888263c/attachment.htm>

From tuncer.ayaz@REDACTED  Thu Jan 31 21:09:53 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Thu, 31 Jan 2013 21:09:53 +0100
Subject: [erlang-bugs] megaco flex warning
Message-ID: <CAOvwQ4i4+f2S=dBTNT0qicgKObTsTfRi2e30j-J6LPigu-DPjg@mail.gmail.com>

There's a warning while processing megaco_flex_scanner_drv.flex:
megaco_flex_scanner_drv.flex:443: warning, the character range [~-?]
    is ambiguous in a case-insensitive scanner

Maybe flex should print decimal or hex values in the character range
instead to make it clearer and potentially more portable.

flex vsn: 2.5.37
perl vsn 5.16.2
locale: en_US.iso88591
otp.git: 68b804f


From tuncer.ayaz@REDACTED  Thu Jan 31 21:33:43 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Thu, 31 Jan 2013 21:33:43 +0100
Subject: [erlang-bugs] binary:matches/3 fails in R14A
Message-ID: <CAOvwQ4jM54V6qBunwJh+4vc_Uu8O00-Sn4nbOQG95MbAhdKwPA@mail.gmail.com>

Originally reported by Bartosz Kolodziej as part of [1]
is the following a bug or intentionally throwing badarg?

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

Tested with otp.git at 68b804f.

[1] http://erlang.org/pipermail/erlang-bugs/2010-August/001967.html
[2] http://erlang.org/pipermail/erlang-bugs/2011-December/002693.html


From mononcqc@REDACTED  Thu Jan 31 22:26:18 2013
From: mononcqc@REDACTED (Fred Hebert)
Date: Thu, 31 Jan 2013 16:26:18 -0500
Subject: [erlang-bugs] megaco flex warning
In-Reply-To: <CAOvwQ4i4+f2S=dBTNT0qicgKObTsTfRi2e30j-J6LPigu-DPjg@mail.gmail.com>
References: <CAOvwQ4i4+f2S=dBTNT0qicgKObTsTfRi2e30j-J6LPigu-DPjg@mail.gmail.com>
Message-ID: <20130131212617.GA59775@ferdmbp.gateway.2wire.net>

I agree the output should be either decimal or hex. Hex is likely nicer
for the usual looking upwhat characters are online, though decimal works
nicer for Erang handling given decimal is the default output.

If flex is in charge of that, I'm all for blaming Flex for the problem.

Regards,
Fred.

On 01/31, Tuncer Ayaz wrote:
> There's a warning while processing megaco_flex_scanner_drv.flex:
> megaco_flex_scanner_drv.flex:443: warning, the character range [~-?]
>     is ambiguous in a case-insensitive scanner
> 
> Maybe flex should print decimal or hex values in the character range
> instead to make it clearer and potentially more portable.
> 
> flex vsn: 2.5.37
> perl vsn 5.16.2
> locale: en_US.iso88591
> otp.git: 68b804f
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs


From mononcqc@REDACTED  Thu Jan 31 22:31:02 2013
From: mononcqc@REDACTED (Fred Hebert)
Date: Thu, 31 Jan 2013 16:31:02 -0500
Subject: [erlang-bugs] binary:matches/3 fails in R14A
In-Reply-To: <CAOvwQ4jM54V6qBunwJh+4vc_Uu8O00-Sn4nbOQG95MbAhdKwPA@mail.gmail.com>
References: <CAOvwQ4jM54V6qBunwJh+4vc_Uu8O00-Sn4nbOQG95MbAhdKwPA@mail.gmail.com>
Message-ID: <20130131213101.GB59775@ferdmbp.gateway.2wire.net>

I'm looking at the doc at
http://www.erlang.org/doc/man/binary.html#matches-3

The type spec mentions the following:

    matches(Subject, Pattern, Options) -> Found
    
    Types:
    Subject = binary()
    Pattern = binary() | [binary()] | cp()
    Found = [part()]
    Options = [Option]
    Option = {scope, part()}
    part() = {Start :: integer() >= 0, Length :: integer()}

It seems [global]?as an option is not valid. Could this be the problem?
I was under the impression `re` functions would take a `global` option,
not `binary` module stuff.

Regards,
Fred.

On 01/31, Tuncer Ayaz wrote:
> Originally reported by Bartosz Kolodziej as part of [1]
> is the following a bug or intentionally throwing badarg?
> 
> 1> binary:matches(<<>>,<<"a">>,[global]).
> ** exception error: bad argument
>      in function  binary:matches/3
>         called as binary:matches(<<>>,<<"a">>,[global])
> 
> Tested with otp.git at 68b804f.
> 
> [1] http://erlang.org/pipermail/erlang-bugs/2010-August/001967.html
> [2] http://erlang.org/pipermail/erlang-bugs/2011-December/002693.html
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs


From tuncer.ayaz@REDACTED  Thu Jan 31 22:40:15 2013
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Thu, 31 Jan 2013 22:40:15 +0100
Subject: [erlang-bugs] binary:matches/3 fails in R14A
In-Reply-To: <20130131213101.GB59775@ferdmbp.gateway.2wire.net>
References: <CAOvwQ4jM54V6qBunwJh+4vc_Uu8O00-Sn4nbOQG95MbAhdKwPA@mail.gmail.com>
 <20130131213101.GB59775@ferdmbp.gateway.2wire.net>
Message-ID: <CAOvwQ4hEo_KvLy7baw7+Tb7e-wTnrbxRG2ggLtYo=e9OgD9d9Q@mail.gmail.com>

On Thu, Jan 31, 2013 at 10:31 PM, Fred Hebert wrote:
> I'm looking at the doc at
> http://www.erlang.org/doc/man/binary.html#matches-3
>
> The type spec mentions the following:
>
>     matches(Subject, Pattern, Options) -> Found
>
>     Types:
>     Subject = binary()
>     Pattern = binary() | [binary()] | cp()
>     Found = [part()]
>     Options = [Option]
>     Option = {scope, part()}
>     part() = {Start :: integer() >= 0, Length :: integer()}
>
> It seems [global] as an option is not valid. Could this be the problem?
> I was under the impression `re` functions would take a `global` option,
> not `binary` module stuff.

Yeah, you're probably right, I may have been misled by previous
re:run/3 use :).

> On 01/31, Tuncer Ayaz wrote:
>> Originally reported by Bartosz Kolodziej as part of [1]
>> is the following a bug or intentionally throwing badarg?
>>
>> 1> binary:matches(<<>>,<<"a">>,[global]).
>> ** exception error: bad argument
>>      in function  binary:matches/3
>>         called as binary:matches(<<>>,<<"a">>,[global])
>>
>> Tested with otp.git at 68b804f.
>>
>> [1] http://erlang.org/pipermail/erlang-bugs/2010-August/001967.html
>> [2] http://erlang.org/pipermail/erlang-bugs/2011-December/002693.html


From eric.pailleau@REDACTED  Thu Jan 31 23:05:29 2013
From: eric.pailleau@REDACTED (PAILLEAU Eric)
Date: Thu, 31 Jan 2013 23:05:29 +0100
Subject: [erlang-bugs] R16A : can't compile
Message-ID: <510AEAA9.2070304@wanadoo.fr>

obj/i686-pc-linux-gnu/opt/smp/unix_efile.o: In function `efile_fallocate':
/home/eric/otp_src_R16A/erts/emulator/drivers/unix/unix_efile.c:1013:
undefined reference to `fallocate64'

gcc version 4.4.1 (GCC)

Linux Mandriva 2010 : 2.6.31.14-desktop-1mnb #1 SMP i686 Intel(R)
Core(TM)2 Duo CPU T7250  @ 2.00GHz GNU/Linux

erts/autoconf/config.guess  returns i686-pc-linux-gnu

I tried to change/comment some values in erts/i686-pc-linux-gnu/config.h
like :
#define HAVE_FALLOCATE 0
#define HAVE_POSIX_FALLOCATE

but without success.

Any tip ?

Regards