PAILLEAU Eric | 28 Jul 23:56 2014

17.0 : dialyzer issue on boolean type in record.

please considere below minimal module :


-record(test, { bool   = 'true' :: boolean()} ).

test() -> test(#test{}).

test(R) -> case R#test.bool of
                 true  -> ok ;
                 false -> ok
dialyzer raise an error :

test.erl:11: The pattern 'false' can never match the type 'true'.

Looks like dialyzer considere #test.bool to be of type 'true' while it 
is of type boolean() and default value to 'true'.

Documentation says :
"In the presence of initial values for fields, the type must be declared 
after the initialization as in the following:

   -record(rec, {field1 = [] :: Type1, field2, field3 = 42 :: Type3}).

Naturally, the initial values for fields should be compatible with (i.e. 
(Continue reading)

Mikael Pettersson | 28 Jul 16:27 2014

r15b03-1 SEGV in erts_port_task_schedule()

This is a followup to my previous report in
but it's for a different function in erl_port_task.c.

We've gotten a new SEGV with r15b03-1.  This time we managed to
capture a truncated core dump (just threads list and registers,
no thread stacks or heap memory):

Program terminated with signal 11, Segmentation fault.
#0  enqueue_task (ptp=<optimized out>, 
    ptqp=<error reading variable: Cannot access memory at address 0x7f8f02a95d08>)
    at beam/erl_port_task.c:327
327         ptp->prev = ptqp->last;
(gdb) bt
#0  enqueue_task (ptp=<optimized out>, 
    ptqp=<error reading variable: Cannot access memory at address 0x7f8f02a95d08>)
    at beam/erl_port_task.c:327
#1  erts_port_task_schedule (id=<optimized out>, 
    id <at> entry=<error reading variable: Cannot access memory at address 0x7f8efdeb8318>, 
    pthp=<error reading variable: Cannot access memory at address 0x7f8efdeb82c0>, 
    type=<error reading variable: Cannot access memory at address 0x7f8efdeb82cc>, 
    event=<error reading variable: Cannot access memory at address 0x7f8efdeb82d0>, 
    event_data=<error reading variable: Cannot access memory at address 0x7f8efdeb82d8>)
    at beam/erl_port_task.c:615

The code that faulted is

   0x00000000004b8203 <+419>:   mov    0x10(%r15),%rax
   0x00000000004b8207 <+423>:   mov    0x10(%rsp),%rbx
(Continue reading)

Louis-Philippe Gauthier | 25 Jul 17:49 2014

erl_lock_count segfault

Looks like in some certain conditions I get a segfault when starting the VM when compiled with lock counter.

erlang-bugs mailing list
erlang-bugs <at>
o鸡蛋黄o | 24 Jul 05:03 2014

erlang vm crash/coredump

Jul 23 19:11:31 imtestserver kernel: [27024.541714] TCP: TCP: Possible SYN flooding on port 5222. Sending cookies.  Check SNMP counters.
Jul 23 19:12:14 imtestserver kernel: [27067.574868] beam.smp[7347]: segfault at 20 ip 00000000005342d4 sp 00007f343baf5d00 error 4 in beam.smp[400000+267000]
Jul 23 19:14:22 imtestserver kernel: [27196.203390] TCP: TCP: Possible SYN flooding on port 5222. Sending cookies.  Check SNMP counters.
Jul 23 19:15:01 imtestserver CRON[7894]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jul 23 19:19:32 imtestserver kernel: [27505.432769] beam.smp[7643]: segfault at 20 ip 00000000005342d4 sp 00007f2d98f76d00 error 4 in beam.smp[400000+267000]

erlang-bugs mailing list
erlang-bugs <at>
Michael Truog | 22 Jul 00:55 2014

Dialyzer Bugs

There are two dialyzer bugs that I ran into recently:
1) In 17.1 passing a symbolic link to the --plt option doesn't work as it once did (it is still ok to have
~/.dialyzer_plt as a symbolic link)

2) -Wrace_conditions causes the dialyzer execution time to vary with the possibility that dialyzer
execution will not finish.  The memory of dialyzer can also grow to much larger sizes >1GB while this
occurs.  I had this occur awhile ago with R16B03-1 while leaving dialyzer to run and it refused to finish
after roughly 40 minutes when a normal run takes 1 minute (roughly).  I recently talked to a person on IRC
(freenode in the #erlang room) which had the same problem where the person's dev machine was affected but
the CI server never had any problem completing the dialyzer runs.  It seems like this appears only when a
sufficiently large amount of Erlang source code is used for the dialyzer run.  The person suspected that a
corrupt file might have caused the problem to appear, but I doubted
  that -Wrace_conditions would be modifying any state on disk (it wouldn't be changing a PLT file, right?).


erlang-bugs mailing list
erlang-bugs <at>

Tomas Abrahamsson | 20 Jul 03:27 2014

enif_make_int64 => -0 for INT64_MIN with gcc 4.9.1


I upgraded gcc from version 4.8.1 to 4.9.1, recompiled Erlang/OTP-17.1.1
and my nif, and now enif_make_int64 creates -0 for INT64_MIN.

  % make test
  erl -s int64nif go -s erlang halt
  Erlang/OTP 17 [erts-6.1.1] [source] [smp:4:4] [async-threads:10]


When Erlang was compiled with gcc-4.8.1, it printed -9223372036854775808,
I've attached the test programs, here are the important lines:

    go() ->
        io:format("~p~n", [int64_from_nif()]).

The NIF C-code contains:

    static ERL_NIF_TERM
    int64_from_nif(ErlNifEnv *env, int argc, const ERL_NIF_TERM argv[])
        return enif_make_int64(env, INT64_MIN);

System information:

  OS: linux, 32-bit core i5, 3.14-1-686-pae (debian unstable)
  Erlang/OTP: built from scratch (both times) from the OTP-17.1.1 git tag.
  gcc: initially: gcc (Debian 4.8.1-10) 4.8.1
       with this one, it prints -9223372036854775808
  gcc: after upgrade: gcc (Debian 4.9.1-1) 4.9.1
       with this one, it prints -0

The only change I did was apt-get install gcc and then rebuilding Erlang.

Attachment (int64nif.tar.gz): application/x-gzip, 1150 bytes
erlang-bugs mailing list
erlang-bugs <at>
José Valim | 19 Jul 18:11 2014

Warning shows the wrong operator when useless operator is inside a useless contruction

Given the following code:


bar() ->
  [{foo, hello:world() == bar}],

When compiled, it reports:

foo.erl:5: Warning: a term is constructed, but never used
foo.erl:5: Warning: use of operator '=:=' has no effect

The second warning is wrong. It must be refer to the operator '==' and not '=:='.

José Valim
Skype: jv.ptec
Founder and Lead Developer
erlang-bugs mailing list
erlang-bugs <at>
Du Felix | 18 Jul 07:57 2014

Syntax error: word unexpected (expecting ")" ) when cross compiling

Hi everyone.
      I did a cross compiling with the command:
      ./configure --host=arm-linux-gnueabif
      Duiring compilation, I got such error:

 === Entering application hipe
make[3]: Entering directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc'
 ERLC ../ebin/hipe_consttab.beam
/home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: 1:
/home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: Syntax error: word
unexpected (expecting ")")
make[3]: *** [../ebin/hipe_consttab.beam] Error 2
make[3]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc'
make[2]: *** [opt] Error 2
make[2]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe'
make[1]: *** [opt] Error 2
make[1]: Leaving directory `/home/dmy/App/otp_src_17.0/lib'
make: *** [secondary_bootstrap_build] Error 2

    When I went to /home/dmy/App/otp_src_17.0/lib/hipe/ebin, I didn't
find hipe_consttab.beam.

    I could successfully compiled a x86 erlang on my linux mint, but
got that error while cross compling.
erlang-bugs mailing list
erlang-bugs <at>

Louis-Philippe Gauthier | 18 Jul 06:46 2014

--enable-native-libs is broken

I've been trying to compile 17.1 with native libs... without any success. I get different errors on Linux and OSX.


% build

tar -xzf otp_src_17.1.tar.gz && cd otp_src_17.1/
./configure --enable-smp-support --enable-threads --enable-kernel-poll --enable-hipe --enable-native-libs

% install

sudo su
rm -rf /usr/local/lib/erlang/
make install

% test

Erlang/OTP 17 [erts-6.1] [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V6.1  (abort with ^G)
1> code:is_loaded(gen_server).
2> code:is_module_native(gen_server).


% build

tar -xzf otp_src_17.1.tar.gz && cd otp_src_17.1/
./configure --enable-smp-support --enable-threads --enable-kernel-poll --enable-hipe --enable-native-libs --enable-darwin-64bit --with-dynamic-trace=dtrace

% error

=== Entering application hipe
 ERLC ../ebin/hipe_rtl.beam
hipe_rtl.erl: internal error in native_compile;
crash reason: undef

erlang-bugs mailing list
erlang-bugs <at>
Peter Cooper | 11 Jul 16:42 2014

SSL Client Certificate Request types with EC certificates

It's entirely possible (even likely) I'm misunderstanding something about how these SSL ciphers are
supposed to work, but the behavior I'm seeing looks like an Erlang issue to me. I'm trying to use RabbitMQ on
Erlang 17.1 on 64-bit Windows 7, requiring a connection using SSL with a client certificate. All the
certificates are using elliptic curve (secp256k1) keys. However, my client (in Java) isn't sending its
client certificate because the CertificateRequest message from the RabbitMQ/Erlang server is saying
that it's requesting an RSA certificate, whereas all I have is an EC certificate. I'm trying to use cipher
suite {ecdhe_ecdsa, aes_128_cbc, sha256} which I think is the correct one, but the place that specifies
what types of certificates to request (ssl_handshake's certificate_types fu
 nction) at
doesn't seem to handle this case correctly and always asks for just RSA rather than ECDSA certificate.

When I connect to the server using the same keys with "openssl s_client", the connection is established and
the certificate gets sent fine, which leads me to think that openssl isn't checking for the type in the
CertificateRequest message and is just sending the certificate I specify. So it looks like Erlang's SSL
module can handle the certificate just fine if the client ignores the list of requested types.

Thanks for any help you could provide.


Peter Cooper Jr.
Sr. Software Engineer
erlang-bugs mailing list
erlang-bugs <at>

José Valim | 4 Jul 17:10 2014

Misleading docs or implementation of file:read/2 and friends

Hello everyone,

I have found the documentation or implementation file:read/2 to be misleading when working with unicode devices in binary mode. I will use file:read_line/1 in the examples below but the issue applies to file:read/2, file:pread/1 and etc.

$ echo "héllo" > foo
$ erl
1> {ok, F} = file:open("foo", [binary, unicode]).
2> {ok, Bin} = file:read_line(F).
3> <<Bin/binary, 0>>.
<<104,233,108,108,111,10, 0>>

Not the result is not the one desired because I expected a binary containing <<"héllo\n"/utf8>>, or more explicitly, I expected it to contain the bytes <<195, 169>> instead of <<233>>. In other words, I got latin1 as result. With char lists, we would get "héllo\n" but the function will fail for any codepoint > 255.

Note this behaviour also happens if I use file:read_line/1 on any other IO device set to unicode (like standard_io).

The trouble I have with the function is that it is aimed to byte-oriented but it only really works for latin1 files. If you have a unicode file, the behaviour seems to be broken for binaries, and it only works for a limited range of codepoints when using char lists.

It is interesting to notice those functions use the old {get_line, Prompt} messages which, according to the I/O protocol guide, should not exist beyond R15B (section 1.3). The same section above suggests to translate {get_line, Prompt} to {get_line, latin1, Prompt} which seems to be the root cause of the issues above: those functions were never meant to work with unicode devices.

Unless I am terribly wrong, I can think of some ways to fix those functions:

1. Keep its dual aspect of returning bytes and/or characters but fix the bug when working with unicode. This means the {get_line, Prompt} should rather translate to {get_line, EncodingOfTheIODevice, Prompt}

2. Make them crash if the encoding of the device is not latin1. This means we translate {get_line, Prompt} to {get_line, latin1, Prompt} only if the encoding of the device is latin1.

3. Make it always work at the byte level, regardless of the encoding of the IO device. This would require assigning new meaning to the {get_line, Prompt} message, so I believe it is not going to happen (although it would be a useful feature in my opinion).

Given that the original IO messages were never meant to work with unicode, maybe 2) is the best way to go here. Both 1) and 2) would require a small amendment to the current I/O protocol advice but I would argue it is necessary to fix the current limitations/bugs when working with unicode.

José Valim
Skype: jv.ptec
Founder and Lead Developer
erlang-bugs mailing list
erlang-bugs <at>