Mattias Jansson | 25 Nov 14:25 2015

HiPe compiler FP inlining crashing


I am having a problem with a crashing HiPe compiler.

It has been tested on Erlang OTP 18.1 (64-bit) on OSX 10.11.1, and also on Fedora Linux 22 with OTP versions
18.0 and 17.5 (64-bit).
It crashes on Linux as well as OSX, but it does not crash in OTP 17.5. This has only been seen in 18.*

The following code has been shrunk to remain syntactically correct and still show the error when compiling
(you’d be surprised by how much of this code is actually necessary to reproduce this).



eat() ->
    eat_what(1.0, #{}).

eat_what(Factor, #{rat_type := LT} = Rat) ->
    #{ cheese := Cheese } = Rat,
    UnitCheese = Cheese / 2,
    RetA = case eat() of
               {full, RetA1} ->
                   CheeseB2 = min(RetA1, UnitCheese) * Factor,
                   case eat() of
                       full ->
                           {win, RetA1};
                       hungry ->
                           {partial, RetA1 - CheeseB2}
(Continue reading)

Albin Stigö | 26 Oct 11:14 2015

erl -make returns 0 on failure.


I'm pretty new to Erlang and I guess this is an old discussion. But why do

erl -make

return 0 even on error? It makes it harder to do:

erl -make && erl -pa ebin/ test/ -noshell -s r1_tests test -s init stop

I have found some previous posts about it through google but they
normally boil down to "write a wrapper".

erlang-bugs mailing list
erlang-bugs <at>

Suraj N. Kurapati | 21 Oct 23:48 2015

leex extended regexp {m,n} quantifiers


I'm using Erlang/OTP 18.1 ([erts-7.1] [source] [64-bit] [smp:24:24]
[async-threads:10] [hipe] [kernel-poll:false]) where I find that leex
does not honor extended regexp numerical repetition quantifiers [1].

For example, I'm trying to recognize exactly 11, 10, or 7 uppercase
alphanumeric characters as a product_id in a leex rule, as follows:

           : {token, {product_id, TokenLine, TokenChars}}.

However, that didn't work, so I tried using AWK syntax [2] exactly:

           : {token, {product_id, TokenLine, TokenChars}}.

However, that didn't work either, so I was forced to expand it out:

           : {token, {product_id, TokenLine, TokenChars}}.

This is a giant step backwards in terms of regexp readability and
maintainability, so please make leex honor the extended regexp
numerical repetition quantifiers [1] since AWK supports them [2].

Furthermore, it seems that this work had already been started [3]
but, for reasons unknown to me, was commented-out in the code [4].

Thanks for your consideration.
(Continue reading)

Magnus Henoch | 19 Oct 20:04 2015

Race condition in TLS distribution

Hi all,

I'm trying to use Erlang distribution over TLS ("-proto_dist 
inet_tls"), and I've stumbled upon an interesting race condition.

The kernel supervisor starts the distribution subsystem before it 
starts the code server.  Therefore, it's possible for another node 
to establish a connection to the distribution port while the code 
server is not yet running.  (Apologies for not providing a recipe 
for reproducing this; I could work on that if that would be 

In that case, the TLS distribution module eventually calls 
ssl:ssl_accept/2 on the connection socket.  This in turn will 
eventually call crypto:supports/0.  That's when I got this error:

(Continue reading)

Loïc Hoguin | 9 Oct 21:13 2015

Re: [erlang-questions] Strange behaviour of exit(kill)

On 10/09/2015 10:35 AM, Roland Karlsson wrote:
> Woa!
> Thanx for explaining it so well!
> This seems so wrong that I am ashamed being an Erlang evangelist.
> I just want to lay down, curl together and cry.
> I have always assumed exit/1 just was implemented as
> exit(Reason) -> exit(self(),Reason).
> Or, at least, that they had the same semantics.
> Looking in the manual, I see that exit/1 and exit/2 are
> correctly described, and I do understand the need
> for both (maybe) as exit/1 is synchronous.
> Personally I think exit/2 shall be
> deprecated and renamed to send_exit_signal/2 or maybe kill/2.

Considering it is called an "exit signal", the name makes sense, 
although it is confusing.

Another clue is that exit/2 does not have error/2 or throw/2 equivalents.

Perhaps kill/2 would be better (and would also match the kill command on 
unix) but I don't see it improve things much. You still have the kill 
special case with all attached problems.

On the other hand, if you had exit/2 (or kill/2) just sending an exit 
signal (even if reason is kill), and kill/1 sending a kill signal, then 
(Continue reading)

Leo Liu | 9 Oct 03:59 2015

[PATCH] Prefer details in cdv_ets_cb:init_gen_page/2


When viewing the details page of an ETS table in crashdump_viewer, it
always shows the `data structure' as `hash'. Could someone see if this
is an oversight and the following patch is intended? Thanks.


erlang-bugs mailing list
erlang-bugs <at>
Robert Virding | 7 Oct 03:00 2015

Strange behaviour of exit(kill)

I am giving an Erlang course and we are looking at the error handling. When showing examples I found a very strange behaviour (to me) of doing exit(kill). The linked process gets the 'kill' but it is trappable. However, if I use exit(P, kill) to send the kill signal it is, as it should be, not trappable.

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

Eshell V7.0  (abort with ^G)
1> process_flag(trap_exit, true).
2> spawn_link(fun () -> exit(normal) end).
3> flush().                              
Shell got {'EXIT',<0.36.0>,normal}
4> spawn_link(fun () -> exit(die) end).  
5> flush().                           
Shell got {'EXIT',<0.39.0>,die}
6> S = self().
7> spawn_link(fun () -> exit(S, die) end).
8> flush().                              
Shell got {'EXIT',<0.43.0>,die}
Shell got {'EXIT',<0.43.0>,normal}
9> spawn_link(fun () -> exit(kill) end). 
10> flush().                              
Shell got {'EXIT',<0.46.0>,kill}
11> spawn_link(fun () -> exit(S, kill) end).
** exception exit: killed

The shell evaluator process traps exits and then spawn_links a number of processes which exit/1 and exit/2 with different reasons. Everything behaves normally until 9> where I spawn_link a process which does an exit(kill). I get the 'kill' signal, but it is a trappable 'kill' signal! If I send the 'kill' signal with exit/2 it is not trappable, as it shouldn't be.

What gives? So just receiving a 'kill' signal is not what kills me but it has to be sent in a certain way. So the process receiving a signal knows how the signal was sent. This is really inconsistent! It should be the signal itself which determines what the receiving process does. I would definitely class this as a bug.


erlang-bugs mailing list
erlang-bugs <at>
Leo Liu | 6 Oct 21:22 2015

[PATCH] Correct field name in cdv_ets_cb:info_fields/0

erlang-bugs mailing list
erlang-bugs <at>
Leo Liu | 5 Oct 17:15 2015

dbg:dhandler1/3 missing newline?


I am seeing dbg trace outputs looking like this:

(<0.6690.1>) returned from observer_html_lib:expandable_term/3 -> [["<HTML>\n",
[snipped 22 lines]
                                                                        ["<TR ",
                                                                         [["<TD ",

Is this a bug? I wonder if it looks better with the following tweak.

--- dbg.erl
+++ #<buffer dbg.erl>
 <at>  <at>  -1006,7 +1006,7  <at>  <at> 
 	return_from ->
 	    MFA = element(4, Trace),
 	    Ret = element(5, Trace),
-	    io:format(Out, "(~p) returned from ~s -> ~p~n", [From,ffunc(MFA),Ret]);
+	    io:format(Out, "(~p) returned from ~s ->~n  ~p~n", [From,ffunc(MFA),Ret]);
 	return_to ->
 	    MFA = element(4, Trace),
 	    io:format(Out, "(~p) returning to ~s~n", [From,ffunc(MFA)]);

Diff finished.  Mon Oct  5 23:02:46 2015

erlang-bugs mailing list
erlang-bugs <at>

Nico Kruber | 16 Sep 17:11 2015

the error_logger does not clean up its file_io_server instances anymore (gen_event related?)

In the current master (ddd1acec5100f5bcc96b29f09b80edd717746edf) the following 
code does not seem to properly remove the file_io_server processes. In 
error_logger_file_h [1] however, the terminate/2 function seems to clean up by 
closing the file.

So I guess, either file:close/1 does not clean up or 
gen_event:delete_handler/3 (called by error_logger:logfile(close)[2]) does not 
call Module:terminate/2 anymore(?)

error_logger:logfile({open, "test1"}).
error_logger:logfile({open, "test2"}).
[{X, file:pid2name(X)} || X <- processes(),
  Data <- [process_info(X, [current_function, initial_call, 
  Data =/= undefined,
  element(1, element(2, lists:keyfind(current_function, 1, Data))) =:= 

erlang-bugs mailing list
erlang-bugs <at>
Jens Páll | 8 Sep 23:09 2015

file:sendfile broken on FreeBSD?


I've been doing some tests using file:sendfile on FreeBSD 10 and it seems to be broken. It's unable to send files that are larger than the OS send buffer.

For example, if the buffer is 32KB, then only 48.996 bytes are sent to the client but from time to time it sends 130.708 bytes. It's always those numbers of bytes sent, 48.996 being the more popular one.

I discovered this when using Cowboy. I contacted Luic and we have been discussing some options, like the server could be closing the socket too soon. I created a simple test server to try things out where I for example delayed the closing of the socket well beyond the time it took the client to receive a full buffer. It had no effect, that is, the client just received its one and a half buffer and then waited until the server got to closing the socket. I tried both versions of sendfile.

If I use gen_tcp:send instead, the data is sent without any problems so I know the server works correctly.

Luic is planning on testing this in a few days but since I'm pretty sure (I can't rule out the possibility that I could be doing something wrong) the problem lies with Erlang itself I decided to post this here to get some further feedback.

I have a test server and client on github if someone cares to take a look:


Jens Páll

erlang-bugs mailing list
erlang-bugs <at>