Ingela Anderton Andin | 16 Apr 10:22 2014

Re: ssl

-------- Original Message --------
Subject: Re: [erlang-bugs] ssl
Date: Wed, 16 Apr 2014 09:46:44 +0200
From: Ingela Anderton Andin <Ingela.Anderton.Andin <at>>
To: Samir Sow <samset <at>>


This works, and is equivalent of what you did in the first place!

Erlang/OTP 17 [RELEASE CANDIDATE 2] [erts-6.0] [source-fa45816] [64-bit]
[smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V6.0  (abort with ^G)
1>  ssl:start().
2> {ok, ListenSocket} = gen_tcp:listen(9999, [{reuseaddr, true},
{active, false}]).
3>  {ok, Socket} = gen_tcp:accept(ListenSocket).
{ok,#Port<0.777>}  %%% Will return when you started the openssl client

%% Do the upgrade
4>  ssl:ssl_accept(Socket, [{cacertfile, "cacerts.pem"}, {certfile,
"cert.pem"}, {keyfile, "key.pem"}]).

In an another shell:
(Continue reading)

Samir Sow | 12 Apr 09:37 2014



Still struggling with ssl.
I decided to check what’s going on at the ssl module level. Did a step by step ssl connection using the
erlang ssl doc.
Found an error erlang:size badarg, but could not understand if it’s a problem with the key/cert files or
with the data sent by the client.

The client was openssl s_client.

Any help welcomed. Thx


{ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile,
"priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]).
** exception exit: {{badarg,
(Continue reading)

PAILLEAU Eric | 10 Apr 21:43 2014

[R17.0] Can't compile : "RELEASES" missing

I tried to compile 17.0 on Ubuntu 13.04, doing './otp_build all' .

make[2]: entrant dans le répertoire « 
/home/eric/Téléchargements/otp_src_17.0/erts/start_scripts »
mv: impossible d'évaluer «RELEASES»: Aucun fichier ou dossier de ce type

in erts/start_scripts/Makefile, fails in target RELEASES.src,
file 'RELEASES' is not created and then 'mv' fails.

(Continue reading)

José Valim | 10 Apr 19:54 2014

standard_error IO device is not being set to unicode

Hello OTP Team,

I am using Erlang 17.0 and it seems the standard_error device is not being set to unicode. On a Mac OS X:

1> io:format("~p~n", ["josé"]).
2> io:format(standard_error, "~p~n", ["josé"]).

If we inspect the standard_error process, we can see in the process dictionary that unicode is set to false:

3> process_info(whereis(standard_error), dictionary).

Once I explicitly enable unicode, it works:

4> io:setopts(standard_error, [{unicode, true}]).
5> io:format(standard_error, "~p~n", ["josé"]).

Thank you!

PS: I found it interesting that the standard_error process does not accept the same options as the standard_io one:

6> io:setopts(standard_error, [{encoding, utf8}]).
7> io:setopts(standard_error, [{unicode, true}]).
8> io:setopts(standard_io, [{unicode, true}]).
9> io:setopts(standard_io, [{encoding, utf8}]).

However this seems to be an "old" behaviour (it exists at least in R16 too).

José Valim
Skype: jv.ptec
Founder and Lead Developer
erlang-bugs mailing list
erlang-bugs <at>
José Valim | 10 Apr 19:18 2014

Encoding of IO devices when there is -noshell

Hello OTP team,

I am using Erlang 17.0 and I have noticed that, if -noshell is given, the encoding for IO devices are kept as latin:

    $ erl -eval 'io:format("~p", [io:getopts()]).'

Setting the +fnu flag doesn't change the behaviour:

    $ erl +fnu -eval 'io:format("~p", [io:getopts()]).'

I am pretty sure this behaviour is present in R16, but given the new direction taken in 17.0, I am not sure this is an actual bug or not.

I am using Mac OS X Mountain Lion but this bug was also peer verified on Linux.

Thank you!

José Valim
Skype: jv.ptec
Founder and Lead Developer
erlang-bugs mailing list
erlang-bugs <at>
Boris Mühmer | 10 Apr 05:42 2014

otp_src_17.0.tar.gz: "make docs" fails in "system/doc/top"

Yesterday I did a build with the new otp_src_17.0.tar.gz tarball using my script which served me quite well from R13Bxx to R17RC2, but this time it failed at "make docs":

make[2]: Entering directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual'
make[2]: Nothing to be done for `docs'.
make[2]: Leaving directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/reference_manual'
make[2]: Entering directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples'
make[2]: Nothing to be done for `docs'.
make[2]: Leaving directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/programming_examples'
make[2]: Entering directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top'
make[2]: *** No rule to make target `../../README', needed by `docs'.  Stop.
make[2]: Leaving directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc/top'
make[1]: *** [docs] Error 2
make[1]: Leaving directory `/tmp/tmp.6FO62sEXov-erlang-otp/otp_src_17.0/system/doc'
make: *** [docs] Error 2

I compared the 17.0 to the 17RC2 structure: it looks like the file "system/README" is missing. I could "fix" the build process with a "touch system/README"... not a real fix of course.
Regards, Boris
erlang-bugs mailing list
erlang-bugs <at>
rohit12sh . | 10 Apr 03:04 2014

Memory Leak in beam.smp

I am using CouchDB which is based on Erlang. 

Recently I came across a bug in CouchDB which in-turn seems like a memory leak issue in NIF.

I already have posted the issue to CouchDB community and thought of posting to Erlang community as well to see if this issue can be resolved in early next releases.

Here is the link describing the complete use case:

I have seen this issue from erlang version 5.8-5.10 so far.

Please let me know if you have more questions. 

Rohit Sharma
erlang-bugs mailing list
erlang-bugs <at>
Stavros Aronis | 9 Apr 19:06 2014

erlang:is_builtin(erlang,apply,3) = false


Title says everything. Is this intentional?

1> erlang:is_builtin(erlang,apply,3).



PS: Apologies for just reporting this and not attempting a fix, but this seems to go deeper into C code than I am comfortable patching.
erlang-bugs mailing list
erlang-bugs <at>
Rabbe Fogelholm | 8 Apr 16:00 2014

A dialyzer option not described in the OTP documentation

With R16B02 `dialyzer -h' tells me that there is an option -Wno_undefined_callbacks.
However, the online OTP documentation does not describe that particular option:

BR / Rabbe Fogelholm, Ericsson, Stockholm
erlang-bugs mailing list
erlang-bugs <at>

Aliaksey Artamonau | 7 Apr 23:28 2014

lost quotes in port arguments on Windows

Hi all,

We've recently encountered a problem with application arguments being 
interpreted differently on Windows and on GNU/Linux. Basically if we 
pass something like "\"path\"" to our application, it's then correctly 
returned as string by application:get_env/2 function on GNU/Linux. On 
Windows though, it's being interpreted as an atom. Which causes problems 
if path happens to contain something that can't be part of unquoted atom 
(like colon character). After some investigation, I've come up with the 
following code snippet to demonstrate the root cause of our problem:

(fun () ->
          P = open_port({spawn_executable, os:find_executable("erl")},
                         {line, 2000},
                         {args, ["-noshell", "-noinput",
                                 "-app", "test", "arg with\"\"double 
quotes in it",
                                 "-eval", "io:format([126,112,126,110], 
[init:get_argument(app)]), erlang:halt(0)."]}]),

          F = fun (R) ->
                          {P, {data, {_, L}}} -> io:format("~s~n", [L]), 
                          {P, {exit_status, _}} -> ok

I just paste it into erl shell. If I run this on GNU/Linux with 
R16B03-1, I get this:

{ok,[["test","arg with\"\"double quotes in it"]]}

On Windows with the same Erlang version I get this:

{ok,[["test","arg with\"double quotes in it"]]}

Note that one of the quotes disappeared from the argument.

Best regards,
erlang-bugs mailing list
erlang-bugs <at>

Stefan Zegenhagen | 7 Apr 10:13 2014

SNMP get-request failure

Dear all,

we have discovered at least one SNMP manager that composes get-requests
like this:


Please note that the get-request does not contain 'NULL', 'NULL' as
variabletype and value, but contains a valid type/value pair. To my
knowledge, this is not forbidden.

When the OID is not accessible (e.g. MAX-ACCESS is not-accessible or
accessible-for-notify), the following response-PDU is generated:


Please not again that the variabletype is still the one from the
original requests, e.g. the PDU processing in snmpa_agent:process_pdu/5
fails to update #varbind.variabletype when detecting errors.

This response PDU fails to encode because of the ordering of the clauses
in snmp_pdus:enc_value/2 which checks for basic BER types first, before
considering known error atoms as values.

The same problem does not exist when the instrumentation function for
that object returns {noValue, Error} because the 'noValue' atom is
copied to #varbind.variabletype in that case.

A fix should probably:
      * reorder the clauses in snmp_pdus:enc_value/2,
      * overwrite #varbind.variabletype with 'NULL' or 'noValue' when
        detecting errors,
      * or do both of the above solutions.

Kind regards,

Dr. Stefan Zegenhagen

arcutronix GmbH
Garbsener Landstr. 10
30419 Hannover

Tel:   +49 511 277-2734
Fax:   +49 511 277-2709
Email: stefan.zegenhagen <at>

*Synchronize the Ethernet*

General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer -
Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht
Hannover; Ust-Id: DE257551767.

Please consider the environment before printing this message.

erlang-bugs mailing list
erlang-bugs <at>