Louis-Philippe Gauthier | 25 Jul 17:49 2014

erl_lock_count segfault

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


LP
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
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> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Michael Truog | 22 Jul 00:55 2014
Picon

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?).

Thanks,
Michael

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

Tomas Abrahamsson | 20 Jul 03:27 2014
Picon

enif_make_int64 => -0 for INT64_MIN with gcc 4.9.1

Hi,

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]
[kernel-poll:false]

  -0

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.

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

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

Given the following code:

-module(foo).
-compile(export_all).

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

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> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Du Felix | 18 Jul 07:57 2014
Picon

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> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Louis-Philippe Gauthier | 18 Jul 06:46 2014

--enable-native-libs is broken

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

Linux:

% 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
make

% install

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

% test

erl
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).
{file,"/usr/local/lib/erlang/lib/stdlib-2.1/ebin/gen_server.beam"}
2> code:is_module_native(gen_server).
false


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 --enable-darwin-64bit --with-dynamic-trace=dtrace
make

% 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> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
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
https://github.com/erlang/otp/blob/maint-17/lib/ssl/src/ssl_handshake.erl#L1110
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
EFI
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

José Valim | 4 Jul 17:10 2014
Picon

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]).
{ok,<0.34.0>}
2> {ok, Bin} = file:read_line(F).
{ok,<<"héllo\n">>}
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> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Loïc Hoguin | 3 Jul 13:51 2014
Picon

Small oddities

Observing this on my Arch Linux install:

$ erl -man 6 ssl
ssl(7)                                                Erlang Application 
Definition                                                ssl(7)

$ erl -man 7 ssl
No manual entry for ssl in section 7

$ erl -man 6 common_test
common_test(3)                                           Erlang Module 
Definition                                          common_test(3)

Probably for others too.

So now I'm not sure if I should use 6 or 7 for the "application" man 
page. Any hint appreciated. :-)

--

-- 
Loïc Hoguin
http://ninenines.eu
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Knut Nesheim | 1 Jul 16:26 2014
Picon

Missing comma between maps results in merge

Hi,

I was recently bitten by a combination of my own mistakes and a unexpected syntax with maps. I'm not sure if this is a bug or intended behaviour.

1> #{foo => bar, foo => quux}.  
#{foo => quux}
2> #{foo => bar} #{foo => quux}.
#{foo => quux}

In the second case, two maps are merged due to missing a separating comma between them. I would expect it to fail with a syntax error.

Is this intended behaviour?

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

Gmane