James Fish | 29 Jul 18:24 2015

Type assertion failure when tracing with process_dump message

When using {message, {process_dump}} in a trace the VM can abort on OTP R16B03 to 18.0.2 (not R16B02 and earlier) on a linux 3.19.0-21-generic x86_64:

TYPE ASSERTION FAILED, file beam/erl_term.c, line 115: tag_val_def: 0x7f9c183ee6d2
Aborted (core dumped)

#0  0x00007f9c1c56f267 in __GI_raise (sig=sig <at> entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007f9c1c570eca in __GI_abort () at abort.c:89
#2  0x000000000056dfd1 in et_abort (expr=0x9081e0 <msg> "tag_val_def: 0x7f9c183ee6d2", file=0x64fe45 "beam/erl_term.c", line=115) at beam/erl_term.c:48
#3  tag_val_def (x=x <at> entry=140308398401234) at beam/erl_term.c:115
#4  0x00000000004cf12e in print_term (obj_base=<optimised out>, dcount=<synthetic pointer>, obj=140308398401234, arg=0x7f9c1d780078, fn=0x630a10 <write_ds>) at beam/erl_printf_term.c:352
#5  erts_printf_term (fn=0x630a10 <write_ds>, arg=0x7f9c1d780078, term=<optimised out>, precision=99999, term_base=<optimised out>) at beam/erl_printf_term.c:657
#6  0x000000000062ed17 in erts_printf_format (fn=fn <at> entry=0x630a10 <write_ds>, arg=arg <at> entry=0x7f9c1d780078, fmt=fmt <at> entry=0x64830b "%T\n", ap=ap <at> entry=0x7f9c198fc640) at common/erl_printf_format.c:847
#7  0x0000000000631750 in erts_vdsprintf (dsbufp=dsbufp <at> entry=0x7f9c1d780078, format=format <at> entry=0x64830b "%T\n", arglist=arglist <at> entry=0x7f9c198fc640) at common/erl_printf.c:459
#8  0x00000000004a9696 in erts_print (to=to <at> entry=-4, arg=arg <at> entry=0x7f9c1d780078, format=format <at> entry=0x64830b "%T\n") at beam/utils.c:400
#9  0x00000000004ea8cf in stack_element_dump (yreg=2, sp=0x7f9c183ef258, to_arg=0x7f9c1d780078, to=-4) at beam/erl_process.c:12546
#10 erts_stack_dump (to=to <at> entry=-4, to_arg=to_arg <at> entry=0x7f9c1d780078, p=p <at> entry=0x7f9c1bb003d8) at beam/erl_process.c:12466
#11 0x000000000055b56d in print_process_info (to=to <at> entry=-4, to_arg=to_arg <at> entry=0x7f9c1d780078, p=p <at> entry=0x7f9c1bb003d8) at beam/break.c:339
#12 0x000000000052cc20 in db_prog_match (c_p=c_p <at> entry=0x7f9c1bb003d8, bprog=0x7f9c1bdc0b78, term=term <at> entry=18446744073709551611, base=base <at> entry=0x0, termp=termp <at> entry=0x7f9c198fca70, arity=arity <at> entry=1,
    in_flags=ERTS_PAM_TMP_RESULT, return_flags=0x7f9c198fca14) at beam/erl_db_util.c:2404
#13 0x000000000052e5ec in erts_match_set_run (p=p <at> entry=0x7f9c1bb003d8, mpsp=<optimised out>, args=args <at> entry=0x7f9c198fca70, num_args=num_args <at> entry=1, in_flags=in_flags <at> entry=ERTS_PAM_TMP_RESULT,
    return_flags=return_flags <at> entry=0x7f9c198fca14) at beam/erl_db_util.c:1243
#14 0x00000000004a0c55 in erts_call_trace (p=p <at> entry=0x7f9c1bb003d8, mfa=mfa <at> entry=0x7f9c1822f058, match_spec=<optimised out>, args=0x7f9c198fca70, args <at> entry=0x7f9c1bfc4180, local=local <at> entry=1,
    tracer_pid=0x7f9c1bb003e8, tracer_pid <at> entry=0x7f9c198fdcc8) at beam/erl_trace.c:1873
#15 0x0000000000455654 in do_call_trace (c_p=0x7f9c1bb003d8, I=0x7f9c1822f070, reg=0x7f9c1bfc4180, local=local <at> entry=1, ms=<optimised out>, tracer_pid=tracer_pid <at> entry=75) at beam/beam_bp.c:900
#16 0x0000000000459524 in erts_generic_breakpoint (c_p=0x7f9c1bb003d8, I=0x7f9c1822f070, reg=0x7f9c1bfc4180) at beam/beam_bp.c:626
#17 0x0000000000443f23 in process_main () at beam/beam_emu.c:4921
#18 0x00000000004d6415 in sched_thread_func (vesdp=0x7f9c1ae4bc40) at beam/erl_process.c:8021
#19 0x000000000062d0e3 in thr_wrapper (vtwd=0x7fff8a43d010) at pthread/ethread.c:114
#20 0x00007f9c1cb136aa in start_thread (arg=0x7f9c198fe700) at pthread_create.c:333
#21 0x00007f9c1c640eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

A minimal example:

c("test.erl"),
dbg:tracer(),
dbg:p(self(), [call]),
dbg:tpl(test, identity, [{'_',[],[{message,{process_dump}}]}]),
test:sum(<<0>>, 0).

test.erl:

-module(test).

-export([sum/2]).

sum(<<Int, Rest/binary>>, Acc) ->
    sum(Rest, Acc + identity(Int));
sum(<<>>, Acc) -> Acc.

identity(Int) ->
    Int.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Alex Hudich | 17 Jul 14:00 2015
Picon

bad certificate if trying to verify StartSsl certificate

I don’t know if it is an Erlang bug but still I don’t have any clue how to resolve this situation:


ubuntu 14.04 and OTP 18.0 # wget http://curl.haxx.se/ca/cacert.pem --2015-07-16 19:11:50-- http://curl.haxx.se/ca/cacert.pem Resolving curl.haxx.se (curl.haxx.se)... 2a00:1a28:1200:9::2, 80.67.6.50 Connecting to curl.haxx.se (curl.haxx.se)|2a00:1a28:1200:9::2|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 258424 (252K) Saving to: 'cacert.pem' 100%[=============================================================================================================================================================================================>] 258,424 1.62MB/s in 0.2s 2015-07-16 19:11:50 (1.62 MB/s) - 'cacert.pem' saved [258424/258424] # erl Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.0 (abort with ^G) 1> application:ensure_all_started(ssl). {ok,[crypto,asn1,public_key,ssl]} 2> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem"}] ). =ERROR REPORT==== 16-Jul-2015::19:12:18 === SSL: certify: ssl_handshake.erl:1476:Fatal error: bad certificate {error,{tls_alert,"bad certificate"}} 3> and Mac OS X and OTP 17.4 $ wget http://curl.haxx.se/ca/cacert.pem --2015-07-16 22:09:02-- http://curl.haxx.se/ca/cacert.pem Resolving curl.haxx.se... 80.67.6.50, 2a00:1a28:1200:9::2 Connecting to curl.haxx.se|80.67.6.50|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 258424 (252K) Saving to: 'cacert.pem' 100%[=============================================================================================================================================================================================>] 258,424 --.-K/s in 0.1s 2015-07-16 22:09:02 (1.92 MB/s) - 'cacert.pem' saved [258424/258424] $ erl Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] [dtrace] Eshell V6.3 (abort with ^G) 1> application:ensure_all_started(ssl). {ok,[crypto,asn1,public_key,ssl]} 2> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem"}] ). =ERROR REPORT==== 16-Jul-2015::22:09:23 === SSL: certify: ssl_handshake.erl:1389:Fatal error: bad certificate {error,{tls_alert,"bad certificate"}} 3>

Then Santiago Fernández reported that problem couldn’t be reproduced with OTP 17.5 and I tried it. Indeed connection was successful but I decided to dig it more and I found interesting things:

I prepared two files. cacert.pem.1 was just an empty file (with zero legth) and cacert.pem which I’d downloaded earlier. And there is an output of 17.5 which seems to me wrong. Line 2 and 3 is ok. Line 4 is ok. But why line 5 gave me no error?? Erlang/OTP 17 [erts-6.4] [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.4 (abort with ^G) 1> application:ensure_all_started(ssl). {ok,[crypto,asn1,public_key,ssl]} 2> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem.1"}] ). =ERROR REPORT==== 17-Jul-2015::13:26:45 === SSL: certify: ssl_handshake.erl:1401:Fatal error: unknown ca {error,{tls_alert,"unknown ca"}} 3> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem.1"}] ). =ERROR REPORT==== 17-Jul-2015::13:26:48 === SSL: certify: ssl_handshake.erl:1401:Fatal error: unknown ca {error,{tls_alert,"unknown ca"}} 4> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem"}] ). {ok,{sslsocket,{gen_tcp,#Port<0.1236>,tls_connection, undefined}, <0.53.0>}} 5> ssl:connect( "www.nicemine.ru", 443, [{verify,verify_peer},{server_name_indication,"www.nicemine.ru"},{depth,2},{cacertfile,"cacert.pem.1"}] ). {ok,{sslsocket,{gen_tcp,#Port<0.1243>,tls_connection, undefined}, <0.55.0>}}




_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Leo Liu | 15 Jul 05:59 2015
Picon

Typo on leex:file/2 options

The documentation in parsetools-2.1/doc/html/leex.html#file-2 says
returning: {error, Warnings, Errors}, but the code seems to suggest
{error, Errors, Warnings}.

Leo
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Dániel Szoboszlay | 13 Jul 11:30 2015
Picon

Emacs indentation problems

Hi,

I found a few issues with erlang.el's indentation. I'm not good enough with Emacs Lisp to write a fix, but it would be great if someone could do so. :)

The following code was auto-indented with Emacs:

%%% -*- mode: erlang; erlang-indent-level: 2 -*-
-module(foo).
-compile([export_all]).

-record(comma_first, { x
                     , y :: integer() % good indentation
                            , z       % bad indentation (caused by type spec)
                     }).

try_blocks() ->
  try ok,
       ok % bad indentation
  after
    ok
  end,

  try ok of
      X -> X % bad indentation: erlang-indent-level is 2!
  after
    ok
  end,

  try ok of
      Y -> % bad indentation
      Y    % looks terrible
  after
    ok
  end.

list_comprehensions() ->
  [ok
   || X <- [ 1
           , 2
           , 3] % comma-first indentation works here
        , X > 2 % but not here
  ].

In case email would screw the indentation, here's the same in a gist: https://gist.github.com/dszoboszlay/bf60b674dadc49c7d999

Cheers,
Daniel
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Aleksander Nycz | 10 Jul 16:10 2015
Picon

mnesia:dirty_update_counter doesn't work as expected in mnesia_frag context

Hello,

Please create frag table:

rd(testCounter, {key, value}).
testCounter

mnesia:create_table(tTest
                       , [{ram_copies, [node()]}
                         ,{type,set}
                         ,{attributes,record_info(fields, testCounter)}
                         ,{record_name, testCounter}
                         ,{frag_properties, [{n_fragments, 10}, {n_ram_copies, 1}, {node_pool, [node()]}]}])

and insert record using mnesia:write/3 func, that is called in mnesia_frag  access context:

mnesia:activity(sync_dirty, fun()-> mnesia:table_info(tTest, size) end, [], mnesia_frag).
0
mnesia:activity(sync_dirty, fun() -> mnesia:write(tTest, {testCounter, 100, 200}, write) end, [], mnesia_frag).
ok
mnesia:activity(sync_dirty, fun()-> mnesia:table_info(tTest, size) end, [], mnesia_frag).
1
[T || T <- ([tTest] ++ [list_to_atom("tTest_frag" ++ integer_to_list(N)) || N <- lists:seq(2, 10)]), mnesia:table_info(T, size) > 0].
[tTest_frag2]
ets:tab2list(tTest_frag2).
[#testCounter{key = 100,value = 200}]

We have 1 record in table in frag: tTest_frag2

Now please "insert" record using mnesia:dirty_update_counter/3:

[mnesia:clear_table(T) || T <- ([tTest] ++ [list_to_atom("tTest_frag" ++ integer_to_list(N)) || N <- lists:seq(2, 10)])].
[{atomic,ok},
 {atomic,ok},
 {atomic,ok},
 {atomic,ok},
 {atomic,ok},
 {atomic,ok},
 {atomic,ok},
 {atomic,ok},
 {atomic,ok},
 {atomic,ok}]
mnesia:activity(sync_dirty, fun()-> mnesia:table_info(tTest, size) end, [], mnesia_frag).
0
mnesia:activity(sync_dirty, fun() -> mnesia:dirty_update_counter(tTest, 100, 200) end, [], mnesia_frag).
200
mnesia:activity(sync_dirty, fun()-> mnesia:table_info(tTest, size) end, [], mnesia_frag).
1
[T || T <- ([tTest] ++ [list_to_atom("tTest_frag" ++ integer_to_list(N)) || N <- lists:seq(2, 10)]), mnesia:table_info(T, size) > 0].
[tTest]
ets:tab2list(tTest).
[#testCounter{key = 100,value = 200}]

Now record goes to 1st frag: tTest

So it looks, that dirty_update_counter doesn't handle frag table properly.

Best regards
Aleksander Nycz

Attachment (smime.p7s): application/pkcs7-signature, 6675 bytes
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Michael Truog | 10 Jul 03:53 2015
Picon

supervisor transient child error?

Hi,

I have noticed that when the supervisor has a child process with the childspec restart set to transient, and the process terminates in a way that is not abnormal, the childspec remains within the supervisor.  This appears to be an error based on old documentation: "When a temporary child dies for any reason or a transient child dies normally, the child is removed from the supervisor." (http://www.erlang.org/documentation/doc-4.8.2/lib/stdlib-1.6.1/doc/html/supervisor.html).  The new documentation states: "a transient child process will be restarted only if it terminates abnormally, i.e. with another exit reason than normal, shutdown or {shutdown,Term}" (http://www.erlang.org/doc/man/supervisor.html), and this statement is true with the current supervisor code.

Is it an error that transient processes that terminate in a way that is not abnormal do not get removed from the supervisor?  I think it is, but I am not sure if this was accepted legacy behavior that the documentation didn't want to contradict.  I have an example below with output:

-module(test).
-behaviour(supervisor).
-export([start_link/0, test_child/0, test/0, init/1]).
start_link() ->
    supervisor:start_link({local, ?MODULE}, ?MODULE, []).
test_child() ->
    {ok, erlang:spawn_link(fun() -> erlang:exit(normal) end)}.
test() ->
    ChildSpec = {test, {test, test_child, []}, transient, 2000, worker, []},
    supervisor:start_child(?MODULE, ChildSpec).
init([]) ->
    {ok, {{one_for_one, 5, 300}, []}}.


Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:10] [kernel-poll:false]

Eshell V7.0  (abort with ^G)
1> {ok, Sup} = test:start_link().
{ok,<0.35.0>}
2> erlang:unlink(Sup).
true
3> {ok, P} = test:test().
{ok,<0.38.0>}
4> erlang:is_process_alive(P).
false
5> supervisor:which_children(test).
[{test,undefined,worker,[]}]
6> test:test().
{error,already_present}

Isn't keeping the entry in the supervisor, after a termination that is not abnormal, an error?

Thanks,
Michael
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Garret Smith | 7 Jul 02:32 2015
Picon

Change in abstract format of user-specified -types in 18.0 (breaks PropEr)

This code:
-module(tt).

-type a() :: atom().
-type b() :: a().

has a different abstract syntax in 18.0 vs 17.5 as returned by
epp:parse_file("tt.erl", [])

in 18.0:
{ok,[{attribute,1,file,{"tt.erl",1}},
     {attribute,1,module,tt},
     {attribute,3,type,{a,{type,3,atom,[]},[]}},
     {attribute,4,type,{b,{user_type,4,a,[]},[]}},          <-- user_type
     {eof,6}]}

and in 17.0:
{ok,[{attribute,1,file,{"tt.erl",1}},
     {attribute,1,module,tt},
     {attribute,3,type,{a,{type,3,atom,[]},[]}},
     {attribute,4,type,{b,{type,4,a,[]},[]}},                   <-- type
     {eof,6}]}

When I use PropEr on a module containing module-defined types like 'b'
above, it fails with: Error: The typeserver encountered an error:
{unsupported_type,{user_type,45,point,[]}}.

The module I'm checking defines -type point() and uses it in other types.

Question: is this a bug, since 17.x included user_type in the abstract
format, but apparently never actually used it?

If this was an intended fix, I didn't read about it in the release
notes (only about improving the documentation of the abstract format).
Any other code, including parse transforms, that work with the
abstract format could be affected as well.

Thanks,
Garret
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Garret Smith | 7 Jul 02:25 2015
Picon

Change in abstract format of user-specified -types in 18.0 (breaks PropEr)

This code:
-module(tt).

-type a() :: atom().
-type b() :: a().

has a different abstract syntax in 18.0 vs 17.5 as returned by
epp:parse_file("tt.erl", [])

in 18.0:
{ok,[{attribute,1,file,{"tt.erl",1}},
     {attribute,1,module,tt},
     {attribute,3,type,{a,{type,3,atom,[]},[]}},
     {attribute,4,type,{b,{user_type,4,a,[]},[]}},          <-- user_type
     {eof,6}]}

and in 17.0:
{ok,[{attribute,1,file,{"tt.erl",1}},
     {attribute,1,module,tt},
     {attribute,3,type,{a,{type,3,atom,[]},[]}},
     {attribute,4,type,{b,{type,4,a,[]},[]}},                   <-- type
     {eof,6}]}

When I use PropEr on a module containing module-defined types like 'b'
above, it fails with: Error: The typeserver encountered an error:
{unsupported_type,{user_type,45,point,[]}}.

The module I'm checking defines -type point() and uses it in other types.

Question: is this a bug, since 17.x included user_type in the abstract
format, but apparently never actually used it?

If this was an intended fix, I didn't read about it in the release
notes (only about improving the documentation of the abstract format).
Any other code, including parse transforms, that work with the
abstract format could be affected as well.

Thanks,
Garret
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Adam Krupicka | 3 Jul 20:07 2015
Picon

SSH library does not conform to the RFC standard

Hi,

I recently tried to play with distributed CT (Common Tests); these require the ability to open a SSH connection to the target host to start the remote nodes. It was there that I found that Erlang is unable to open a SSH connection to an up-to-date, defautly-configured OpenSSH server. The SSH Erlang library only supports a single Kex (key-exchange algorithm): diffie-hellman-group1-sha1. The RFC[1], however, specifically requests that every SSH implementation must also support the diffie-hellman-group14-sha1 algorithm. The current version of OpenSSH (OpenSSH_6.8p1, OpenSSL 1.0.2c 12 Jun 2015) in its default configuration only accepts:
curve25519-sha256 <at> libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha1.
I've been told in #erlang on irc.freenode.net that the SSH library was probably only meant to access Erlang systems running SSH shells, however, the CT implementation depends on being able to connect to a real OpenSSH server; that is, on a correct implementation of the SSH standard.
I thought fixing this would be just a matter of implementing the correct Kex algorithm, but upon looking at the source I saw that the current implementation of the Kex algorithms seems to be a bit of a hack[2].

Can you please confirm that this is indeed a bug? I did also come across other people having what I consider to be the same issue[3].


Thanks,
A. K.



[1] https://tools.ietf.org/html/rfc4253#section-8.2
[2] https://github.com/erlang/otp/blob/74a95b3d511177a9b35c2b0272b9ca5511b6f750/lib/ssh/src/ssh_transport.erl#L367
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Knut Nesheim | 30 Jun 16:39 2015
Picon

Dirty schedulers and '-smp disable'

Dear list,

I ran into unexpected behaviour in the following situation:

 * OTP 18.0, compiled from the git tag with dirty schedulers enabled
 * NIF with the ERL_NIF_DIRTY_JOB_CPU_BOUND flag
 * Small machine with only one core (AWS t1.micro)
 * The first log line from startup with no explicit flags looks like
this: Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10]
[hipe] [kernel-poll:false]

When I call the NIF, the calling process hangs forever. When I call it
from the shell, I'm unable to interrupt the process (C-g, i 1 does
nothing useful).

If I explicitly use '-smp enable' as arguments to erl, the NIF runs
fine. In that case the first log line looks like this: Erlang/OTP 18
[erts-7.0] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:10]
[hipe] [kernel-poll:false]

This behaviour got me a bit confused, as there is no indication what
is happening except "something somewhere got stuck". It's not a common
case for me, as most machines have multiple cores except tiny cloud
instances or virtual machines.

Regards
Knut
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Rik Ribbers | 26 Jun 22:43 2015
Picon

ipv6 bug in inet:ntoa

Hello,

I've been playing around with ipv6 in erlang and came across at first strange behaviour in converting string to ipv6 and back

~ --> erl
Erlang/OTP 18 [erts-7.0] [source-4d83b58] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V7.0  (abort with ^G)
1>inet:parse_address("2a00:d78::147:94:198:152:68").
{ok,{10752,3448,0,327,148,408,338,104}}
2> inet:ntoa({10752,3448,0,327,148,408,338,104}).
"2A00:D78:0:147:94:198:152:68"

If you look closely you will see that there is an extra 0 introduced. This is actually correct. In IETF RFC5952 section 4.2.2 states that a single 0 must not be shortened. This however introduces however the question is the inet:parse_address is actually correct, however it is being friendly to its caller... 

The real issue is however that the addresses are displayed in uppercase which is simply wrong. As RFC5952 clearly states in section 4.3. There is even Errata on this issue that states it must be in lower case.

The RFC can be found here https://tools.ietf.org/html/rfc5952 

Kind regards,
Rik Ribbers

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Gmane