From nicolas.dudebout@REDACTED Wed Apr 1 02:58:25 2015 From: nicolas.dudebout@REDACTED (Nicolas Dudebout) Date: Tue, 31 Mar 2015 20:58:25 -0400 Subject: [erlang-bugs] Own Id and git commit Message-ID: I saw in the 18rc1 release notes a change of interest to me "Own Id: OTP-12448". I grepped through the git log and searched github issues for 12448 but have not found anything. Is there a system where the bugs are indexed by that number? What is the git commit corresponding to that number? Thanks in advance, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth@REDACTED Wed Apr 1 12:01:06 2015 From: kenneth@REDACTED (Kenneth Lundin) Date: Wed, 1 Apr 2015 12:01:06 +0200 Subject: [erlang-bugs] Own Id and git commit In-Reply-To: References: Message-ID: The "Own Id: OTP-xxxxx" is an Id for the issue in Ericssons internal "ticket system". We are trying to find a solution where we can have a public issue tracking system and hope to have that up and running during the year. You can find what OTP-12448 corresponds to by searching in the commit messages (all these "Own Ids" are mentioned in the corresponding commit messages) git log --grep=OTP-125448 /Kenneth, Erlang/OTP, Ericsson On Wed, Apr 1, 2015 at 2:58 AM, Nicolas Dudebout wrote: > I saw in the 18rc1 release notes a change of interest to me "Own Id: > OTP-12448". I grepped through the git log and searched github issues for > 12448 but have not found anything. > > Is there a system where the bugs are indexed by that number? > > What is the git commit corresponding to that number? > > Thanks in advance, > Nicolas > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Wed Apr 1 14:30:59 2015 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Wed, 1 Apr 2015 14:30:59 +0200 Subject: [erlang-bugs] Own Id and git commit In-Reply-To: References: Message-ID: <551BE503.4060701@ericsson.com> This ticket OTP-12448 (Improved error handling when memory allocation for HiPE code fails) seems to have been lost. It was never merged into OTP-17.5. It's mostly a code cleanup however and the only change in behavior is a nicer out-of-memory-crash. /Sverker, Erlang/OTP On 04/01/2015 02:58 AM, Nicolas Dudebout wrote: > > I saw in the 18rc1 release notes a change of interest to me "Own Id: > OTP-12448". I grepped through the git log and searched github issues > for 12448 but have not found anything. > > Is there a system where the bugs are indexed by that number? > > What is the git commit corresponding to that number? > > Thanks in advance, > Nicolas > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.dudebout@REDACTED Wed Apr 1 13:00:52 2015 From: nicolas.dudebout@REDACTED (Nicolas Dudebout) Date: Wed, 1 Apr 2015 07:00:52 -0400 Subject: [erlang-bugs] Own Id and git commit In-Reply-To: References: Message-ID: Thanks Kenneth. This is exactly the grep I did yesterday and it did not return anything. On Apr 1, 2015 6:01 AM, "Kenneth Lundin" wrote: > The "Own Id: OTP-xxxxx" is an Id for the issue in Ericssons internal > "ticket system". We are trying to find a solution where we can have a > public issue tracking system and hope to have that up and running during > the year. > > You can find what OTP-12448 corresponds to by searching in the commit > messages (all these "Own Ids" are mentioned in the corresponding commit > messages) > > git log --grep=OTP-125448 > > /Kenneth, Erlang/OTP, Ericsson > > > On Wed, Apr 1, 2015 at 2:58 AM, Nicolas Dudebout < > nicolas.dudebout@REDACTED> wrote: > >> I saw in the 18rc1 release notes a change of interest to me "Own Id: >> OTP-12448". I grepped through the git log and searched github issues for >> 12448 but have not found anything. >> >> Is there a system where the bugs are indexed by that number? >> >> What is the git commit corresponding to that number? >> >> Thanks in advance, >> Nicolas >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schoch@REDACTED Wed Apr 1 19:41:45 2015 From: schoch@REDACTED (Jesse Schoch) Date: Wed, 1 Apr 2015 13:41:45 -0400 Subject: [erlang-bugs] windows deduplication file system causes vm crash for duplicated files Message-ID: It appears that trying to access a file via file or filelib on a file that has been deduplcated via windows deduplication causes the VM to crash. more info about deduplication can be found below, it is supposed to be transparent to the applications using the file system but it appears erlang is making some assumptions about the filesystem or using interfaces that are not up to date. I was able to reproduce the error on 2 machines one running 17.3 and the other running 17.5. This was discovered using elixir, but can be reproduced on a system without elixir on it. Steps to recreate 1. setup volume with deduplicaiton 2. ensure duplicate files exist and dedup job has ran per windows documentation 3. open erl.exe 4. run> filelib:file_size(Filename) https://msdn.microsoft.com/en-us/library/hh769303%28v=vs.85%29.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From garret.smith@REDACTED Thu Apr 2 00:24:48 2015 From: garret.smith@REDACTED (Garret Smith) Date: Wed, 1 Apr 2015 15:24:48 -0700 Subject: [erlang-bugs] common_test fails when using longnames and previous log directories Message-ID: The bug was introduced in 4e61b. The new function does not handle the case where the node name contains '.' character(s). Since the sort is slightly different, I didn't just create a patch to use sort_all_runs, but maybe reversing the results of sort_all_runs would give the desired results? -Garret From henrik@REDACTED Thu Apr 2 08:09:44 2015 From: henrik@REDACTED (Henrik Nord) Date: Thu, 2 Apr 2015 08:09:44 +0200 Subject: [erlang-bugs] Own Id and git commit In-Reply-To: <551BE503.4060701@ericsson.com> References: <551BE503.4060701@ericsson.com> Message-ID: <551CDD28.2040901@erlang.org> You can find the merge commit here: https://github.com/erlang/otp/commit/3051ca1fa0d27adee5abbccce10351a07ab7daa1 Looks like the ticket ID was lost on that one. On 2015-04-01 14:30, Sverker Eriksson wrote: > This ticket OTP-12448 (Improved error handling when memory allocation > for HiPE code fails) > seems to have been lost. It was never merged into OTP-17.5. > > It's mostly a code cleanup however and the only change in behavior is > a nicer out-of-memory-crash. > > /Sverker, Erlang/OTP > > > On 04/01/2015 02:58 AM, Nicolas Dudebout wrote: >> >> I saw in the 18rc1 release notes a change of interest to me "Own Id: >> OTP-12448". I grepped through the git log and searched github issues >> for 12448 but have not found anything. >> >> Is there a system where the bugs are indexed by that number? >> >> What is the git commit corresponding to that number? >> >> Thanks in advance, >> Nicolas >> >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From peppe@REDACTED Thu Apr 2 09:52:31 2015 From: peppe@REDACTED (Peter Andersson) Date: Thu, 2 Apr 2015 09:52:31 +0200 Subject: [erlang-bugs] common_test fails when using longnames and previous log directories In-Reply-To: References: Message-ID: <551CF53F.6080303@erlang.org> Thanks a lot for the report Garret! We'll fix this asap. Best, Peter Ericsson AB, Erlang/OTP On 2015-04-02 00:24, Garret Smith wrote: > The bug was introduced in 4e61b. The new function does not handle the > case where the node name contains '.' character(s). Since the sort is > slightly different, I didn't just create a patch to use sort_all_runs, > but maybe reversing the results of sort_all_runs would give the > desired results? > > -Garret > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From jargon@REDACTED Thu Apr 2 10:20:02 2015 From: jargon@REDACTED (Johannes =?utf-8?B?V2Vpw59s?=) Date: Thu, 2 Apr 2015 10:20:02 +0200 Subject: [erlang-bugs] bug in HiPE for <<_/utf8,...>> In-Reply-To: <7A9C4EA7-5ECC-4BB3-B9CC-B605409D96F8@entelios.com> References: <7A9C4EA7-5ECC-4BB3-B9CC-B605409D96F8@entelios.com> Message-ID: <20150402082002.GA28276@molb.org> Hi, A short update: The reported HiPE bug is still present and reproducible in OTP 17.5 and 18.0-rc1. We had to modify the 'crash.erl' program a little bit after commits 5a7b211 and 7b10ff7 (this shows how fragile it is!), so I'm attaching the latest version: MD5 (crash.erl) = 41d0e4e8ed7039dc898a16135aa62bcb MD5 (crash_it.escript) = f7756e997d9ca28f6d523086e8c37f91 MD5 (data.jsn) = a0ee43e0e63aea6f3c89c41cc3b5d378 To reproduce the bug, save all three files in one directory, make 'crash_it.escript' executable and run it. It compiles 'crash.erl' with HiPE enabled, and produces a crash, which does not occur without HiPE. See also the 'Details' section below for more information about the bug. Regards, Johannes Wei?l and Sebastian Egner On Mon, Sep 09, 2013 at 02:20PM +0000, Sebastian Egner wrote: > Hi, > > There seems to be a Heisenbug in HiPE related to matching <<_/utf8,...>>. > > After a long and bloody fight, we have been able to isolate the problem to the degree > that it is sufficiently reproducible. See details below. > > We strongly suspect that the problem is a genuine bug related to the binary matching > and the garbage collector. Whether the bug is hit depends on the memory contents > of previously allocated heap-allocated binaries. > > Best regards, > Johannes Weissl and Sebastian Egner. > > -- > > Details: > - The program 'crash.erl' loads a JSON sample file. Then it parses the file again and again, > and after a wildly varying number of iterations (100-100000) the parser fails. > - To run the program, execute "crash_it" in a directory containing "crash.erl" and "data.jsn". > When the bug is hit, the program stops. This takes several seconds to minutes. > - The problem manifests itself when <<"0123...">> does not match <<_/utf8,_/binary>> > in the function crash:check_utf8_binary/1. (The program aborts with an exception exit.) > - Surprisingly, we have not been able to reduce the program even more. > In particular, when randomize_memory/0 is not called, the problem is much less frequent. > - The bug is present in R13B02, R14B04, R16B01, "maint" (2f28245) and master (45eaf81). > - The bug is present under MacOSX (10.8.4), Debian GNU/Linux and a Linux in an ARM emulator. > This indicates that the bug is not related to the operating system platform. > - We have run the program in Valgrind and found conditionals that depend on uninitialised > values. Refer to "valgrind.out" for details. > > Attachments: > MD5 (crash.erl) = 1f1507c8238e2136d9163314bcac0045 > MD5 (crash_it) = 4061276b89dfc822cbfc22002f202358 > MD5 (data.jsn) = c5b503cc61d76adc7dcb60832a123b99 > MD5 (valgrind.out) = 2e6f67bf06b3df66c6daf728444b9b66 -------------- next part -------------- -module(crash). %% The program loads a data file ("data.jsn") once and %% decodes it as json subset repeatedly and checks the %% strings to be UTF-8, which it is (even ASCII). %% After some number of iterations, the check crashes. %% Unfortunately, the behaviour does not reproduce well. %% The rate of crashes is very sensitive to the contents %% of the program. Also in some cases the process does not %% seem to crash at all; we start several parallel Erlang %% processes (instances) to increase the total probability %% of a crash. -export([start/1]). start(Instance) -> {ok,Data} = file:read_file("data.jsn"), erlang:garbage_collect(), loop_parse(1, Data, Instance). loop_parse(N, Data, Instance) -> try {ok,_} = parse(Data) catch {check_utf8_binary,Key} -> io:fwrite("; bug tripped in iteration ~p of instance ~p for Key = ~p.~n", [N, Instance, Key]), %% Use with "+Mim true" in crash_it.escript for further information %% io:fwrite("instrument:memory_data() ->~n ~p.~n", [instrument:memory_data()]), exit(1) end, case N rem 100 == 0 orelse N == 1 of true -> io:fwrite("; ~b iterations OK of instance ~p.~n", [N, Instance]); false -> ok end, loop_parse(N + 1, Data, Instance). %% -- stripped down code from our application -- parse(Data) -> Lines = binary:split(Data, <<"\n">>, [global, trim]), fold_list([], Lines). fold_list(List, [Utf8|Utf8s]) -> {ok,Json} = from_utf8(Utf8), fold_list([Json|List], Utf8s); fold_list(List, []) -> {ok,List}. from_utf8(Utf8) -> {ok,Toks} = toks(Utf8, []), {ok,Value,[]} = from_toks(Toks), {ok,Value}. from_toks([S|Toks]) when is_binary(S) -> {ok,S,Toks}; from_toks([lbrac|Toks]) -> array_from_toks(Toks, []); from_toks([lpar|Toks]) -> object_from_toks(Toks, []). array_from_toks(Toks, RevValues) -> case from_toks(Toks) of {ok,Value,[comma|Toks1]} -> array_from_toks(Toks1, [Value|RevValues]); {ok,Value,[rbrac|Toks1]} -> {ok,lists:reverse([Value|RevValues]),Toks1} end. object_from_toks([K,colon|Toks1], RevKVs) when is_binary(K) -> case from_toks(Toks1) of {ok,V,[comma|Toks2]} -> object_from_toks(Toks2, [{K,V}|RevKVs]); {ok,V,[rpar|Toks2]} -> {ok,obj([{K,V}|RevKVs]),Toks2} end. toks(<<"[",T/binary>>, Toks) -> toks(T, [lbrac|Toks]); toks(<<"]",T/binary>>, Toks) -> toks(T, [rbrac|Toks]); toks(<<"{",T/binary>>, Toks) -> toks(T, [lpar|Toks]); toks(<<"}",T/binary>>, Toks) -> toks(T, [rpar|Toks]); toks(<<",",T/binary>>, Toks) -> toks(T, [comma|Toks]); toks(<<":",T/binary>>, Toks) -> toks(T, [colon|Toks]); toks(<<"\"",T/binary>>, Toks) -> toks_string(<<>>, T, Toks); toks(<<>>, Toks) -> {ok,lists:reverse(Toks)}. toks_string(Acc, <<"\"",T/binary>>, Toks) -> toks(T, [Acc|Toks]); toks_string(Acc, <>, Toks) -> toks_string(<>, T, Toks). obj(KVs) when is_list(KVs) -> {obj,from_list([{to_atom(K),V} || {K,V} <- KVs])}. to_atom(Key) -> try ok = check_utf8_binary(Key) catch error:function_clause -> throw({check_utf8_binary,Key}) end, binary_to_atom(Key, utf8). check_codepoint(Cp) -> %% Not all cases required for crash! %% The cases are split in separate if-expressions so that they are %% not optimized away by the compiler (since 7b10ff7, OTP 18). ok = if Cp < 0; Cp >= 16#110000 -> {error,codepoint,Cp}; true -> ok end, ok = if 16#d800 =< Cp, Cp =< 16#dfff -> {error,codepoint,Cp}; true -> ok end, ok = if 16#fdd0 =< Cp, Cp =< 16#fdef -> {error,codepoint,Cp}; true -> ok end, ok = if Cp band 16#ffff >= 16#fffe -> {error,codepoint,Cp}; true -> ok end. check_utf8_binary(<>) -> % (*) ok = check_codepoint(Cp), check_utf8_binary(More); check_utf8_binary(<<>>) -> ok. %% -- from orddict.erl before 5a7b211 -- from_list(Pairs) -> lists:foldl(fun ({K,V}, D) -> store(K, V, D) end, [], Pairs). store(Key, New, [{K,_}=E|Dict]) when Key < K -> [{Key,New},E|Dict]; store(Key, New, [{K,_}=E|Dict]) when Key > K -> [E|store(Key, New, Dict)]; store(Key, New, [{_K,_Old}|Dict]) -> [{Key,New}|Dict]; store(Key, New, []) -> [{Key,New}]. -------------- next part -------------- #!/usr/bin/env escript %% The following enables memory tracing in the emulator: %%! +Mim true %% Run as: %% rm -f crash.beam && ./crash_it.escript [timeout_seconds] main(Args) -> make:all([native,{hipe,[verbose,o3]}]), % trips the bug %% make:all([]), % does not trip the bug process_args(Args), io:fwrite("OTP ~s.~n", [erlang:system_info(otp_release)]), %% Sometimes a process won't trip the bug, regardless how many iterations, %% so we start a number of parallel processes to increase the probability %% that one of them trips the bug. %% The bug seems to be related to a minor GC not yet executed. The GC %% settings below seem to increase the rate of tripping the bug. Instances = 10, lists:foreach( fun (Instance) -> erlang:spawn_opt(crash, start, [Instance], [link, {min_heap_size,1}, {min_bin_vheap_size,1}, {fullsweep_after,1000000000}]) end, lists:seq(1, Instances)), receive never -> ok end. process_args([]) -> ok; process_args([TimeoutStr]) -> Timeout = list_to_integer(TimeoutStr) * 1000, % [ms] spawn_link(fun() -> halt_after(Timeout) end), ok; process_args(_) -> io:fwrite(standard_error, "usage: crash_it.escript [timeout_seconds]~n", []), erlang:halt(2). halt_after(Timeout) -> timer:sleep(Timeout), Status = 3, io:fwrite("bug not tripped after ~w ms, exit with status ~w~n", [Timeout, Status]), erlang:halt(Status). -------------- next part -------------- ["012345601234",["012","","","","","","",""],{"01234":"","0123456":[{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""}],"0123456":["012","","","","","","",""],"0123456":""}] ["012345601234",["012","","","","","","",""],{"01234":"","0123456":[{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""}],"0123456":["012","","","","","","",""],"0123456":""}] ["012345601234",["012","","","","","","",""],{"01234":"","0123456":[{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":["01234560123456",""],"012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""},{"01234":"","012345":"","012345":"","0123456":"","0123456":["012","","","","","","",""],"0123":""}],"0123456":["012","","","","","","",""],"0123456":""}] From sverker.eriksson@REDACTED Thu Apr 2 13:24:29 2015 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 2 Apr 2015 13:24:29 +0200 Subject: [erlang-bugs] Own Id and git commit In-Reply-To: <551CDD28.2040901@erlang.org> References: <551BE503.4060701@ericsson.com> <551CDD28.2040901@erlang.org> Message-ID: <551D26ED.1090900@ericsson.com> That is the merge to master (OTP-18.0-rc1). On 04/02/2015 08:09 AM, Henrik Nord wrote: > You can find the merge commit here: > > https://github.com/erlang/otp/commit/3051ca1fa0d27adee5abbccce10351a07ab7daa1 > > Looks like the ticket ID was lost on that one. > > > On 2015-04-01 14:30, Sverker Eriksson wrote: >> This ticket OTP-12448 (Improved error handling when memory allocation >> for HiPE code fails) >> seems to have been lost. It was never merged into OTP-17.5. >> >> It's mostly a code cleanup however and the only change in behavior is >> a nicer out-of-memory-crash. >> >> /Sverker, Erlang/OTP >> >> >> On 04/01/2015 02:58 AM, Nicolas Dudebout wrote: >>> >>> I saw in the 18rc1 release notes a change of interest to me "Own Id: >>> OTP-12448". I grepped through the git log and searched github issues >>> for 12448 but have not found anything. >>> >>> Is there a system where the bugs are indexed by that number? >>> >>> What is the git commit corresponding to that number? >>> >>> Thanks in advance, >>> Nicolas >>> >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > -- > /Henrik Nord Erlang/OTP > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvirding@REDACTED Sat Apr 4 02:13:48 2015 From: rvirding@REDACTED (Robert Virding) Date: Sat, 4 Apr 2015 02:13:48 +0200 Subject: [erlang-bugs] Want improve document about Getting Started In-Reply-To: References: Message-ID: The input to the shell can also be a sequence of expressions separated by ',' in the same way as the body of a clause can be a sequence of expressions. The shell will process this sequence in the same as it is done in a clause body by evaluating the expressions sequentially in order. Robert On 29 March 2015 at 08:53, Netroby wrote: > By read the manual , we know how to compile and run module > > for example > > 3> c(helloworld). > {ok,helloworld} > 4> helloworld:start(). > Hello world > > ok, this work as normal. > > But we can put two step into one, compile and execute > > 9> c(helloworld),helloworld:start(). > > > if you want put more step in one single line input, you can split them > with comma , > > > > > > Appreciate your time. > ---------------------------- > Netroby > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang-bugs-mailing-list@REDACTED Sun Apr 5 18:32:01 2015 From: erlang-bugs-mailing-list@REDACTED (Luis Gerhorst) Date: Sun, 5 Apr 2015 18:32:01 +0200 Subject: [erlang-bugs] Emacs package: Local function named "get" highlighted like built-in functions In-Reply-To: References: <196D0071-B16E-45BB-BDA8-7949699D5E84@luisgerhorst.de> Message-ID: <11CA4AB5-488D-42A1-845F-D264760E9455@luisgerhorst.de> Is there a way to prevent these keyword from being highlighted as bifs if they refer to a function defined by another module or do I simply have to avoid using such function names? ~ Luis > On 15-W13-7, at 21:06, Steve Vinoski wrote: > > > > On Sun, Mar 29, 2015 at 2:02 PM, Jesper Louis Andersen > wrote: > > On Sun, Mar 29, 2015 at 5:47 PM, Luis Gerhorst > wrote: > I'm using solarized-theme (https://github.com/bbatsov/solarized-emacs ) and as you can see in the screenshot the local function "get" is highlighted the same way built in functions from the "erlang" module are highlighted. > > I have a guess as to why this happens. The get/1 function is defined in erlang:get/1. It is used to look up values in the process dictionary. The syntax highlighter doesn't understand that get/2 is defined locally in the current module, so it thinks your call to get is to the underlying 'erlang:get/1', not to ?MODULE:get/2. And all problems stems from there. > > Correct -- see lib/tools/emacs/erlang.el on the maint branch, line 759 (I would link to github but it's being ddos'ed right now so I can't get to it), where "get" is specified as part of an elisp variable holding erlang bif names. Erlang-mode highlights those names as symbols. > > --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Mon Apr 6 00:12:55 2015 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Sun, 5 Apr 2015 15:12:55 -0700 Subject: [erlang-bugs] Emacs package: Local function named "get" highlighted like built-in functions In-Reply-To: <11CA4AB5-488D-42A1-845F-D264760E9455@luisgerhorst.de> References: <196D0071-B16E-45BB-BDA8-7949699D5E84@luisgerhorst.de> <11CA4AB5-488D-42A1-845F-D264760E9455@luisgerhorst.de> Message-ID: If we can have colouring based on parsing information, I'd love to have exported functions names highlighted in a different way than non-exported ones! Cheers, -- Pierre Fenoll On 5 April 2015 at 09:32, Luis Gerhorst < erlang-bugs-mailing-list@REDACTED> wrote: > Is there a way to prevent these keyword from being highlighted as bifs if > they refer to a function defined by another module or do I simply have to > avoid using such function names? > > ~ Luis > > On 15-W13-7, at 21:06, Steve Vinoski wrote: > > > > On Sun, Mar 29, 2015 at 2:02 PM, Jesper Louis Andersen < > jesper.louis.andersen@REDACTED> wrote: > >> >> On Sun, Mar 29, 2015 at 5:47 PM, Luis Gerhorst < >> erlang-bugs-mailing-list@REDACTED> wrote: >> >>> I'm using solarized-theme (https://github.com/bbatsov/solarized-emacs >>> ) and as you can see in the >>> screenshot the local function "get" is highlighted the same way built in >>> functions from the "erlang" module are highlighted. >>> >> >> I have a guess as to why this happens. The get/1 function is defined in >> erlang:get/1. It is used to look up values in the process dictionary. The >> syntax highlighter doesn't understand that get/2 is defined locally in the >> current module, so it thinks your call to get is to the underlying >> 'erlang:get/1', not to ?MODULE:get/2. And all problems stems from there. >> > > Correct -- see lib/tools/emacs/erlang.el on the maint branch, line 759 (I > would link to github but it's being ddos'ed right now so I can't get to > it), where "get" is specified as part of an elisp variable holding erlang > bif names. Erlang-mode highlights those names as symbols. > > --steve > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Tue Apr 7 06:21:44 2015 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 07 Apr 2015 12:21:44 +0800 Subject: [erlang-bugs] Crash observer by clicking on non-local pid Message-ID: Hi there, I am able to crash observer in both erlang/otp 18.0-rc1 and 17.5 by clicking a non-local pid (e.g <7411.0.0>). Leo From magnus@REDACTED Tue Apr 7 12:26:04 2015 From: magnus@REDACTED (Magnus Henoch) Date: Tue, 07 Apr 2015 11:26:04 +0100 Subject: [erlang-bugs] Emacs package: Local function named "get" highlighted like built-in functions In-Reply-To: (Pierre Fenoll's message of "Sun, 5 Apr 2015 15:12:55 -0700") References: <196D0071-B16E-45BB-BDA8-7949699D5E84@luisgerhorst.de> <11CA4AB5-488D-42A1-845F-D264760E9455@luisgerhorst.de> Message-ID: Pierre Fenoll writes: > If we can have colouring based on parsing information, I'd love > to have exported functions names highlighted in a different way > than non-exported ones! That feature was added in R16B already :) By default, the two kinds of functions have the same colour, though, so you need to customize erlang-font-lock-exported-function-name-face to make it different. Regards, Magnus From system.out@REDACTED Tue Apr 7 14:31:11 2015 From: system.out@REDACTED (Heizenberg John) Date: Tue, 07 Apr 2015 18:31:11 +0600 Subject: [erlang-bugs] SNMP usm agent doesn't work properly in case of mask =/= null Message-ID: <5345771428409871@web11g.yandex.ru> I faced with this problem on snmp-4.25. Then I cloned otp commit 545890576542e4be630df8772654b99bd0306f62 Author: Erlang/OTP Date: ??Tue Mar 31 12:24:06 2015 +0200 and I still have the same trouble. The reason is the some optimisation code in snmpa_mib_data_tttn (ttln). In fact there are two reasons: Reason 1. -module(snmpa_mib_data_tttn). 811 ??next_node(D, {tree, Tree, {table_entry, _MibName}}, .... 819 ??case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar, MibView) of %%------------------------------------------------------------------------------------ -module(snmpa_acm). 346 is_definitely_not_in_mib_view(Oid, [{SubTree, Mask,?view_included}|T]) -> 347 case check_maybe_mask(Oid, SubTree, Mask) of 348 true -> false; 349 false -> is_definitely_not_in_mib_view(Oid, T) 350 end; %%------------------------------------------------------------------------------------ But as I saw while debugging the Mask variable is type of emask (the list of bytes, not the list of bits) and check_maybe_mask(Oid, SubTree, Mask) always return false. This cause that every Oid will be dropped as inapropriate: %%----------------------------------------------------------------- %% As check_mask, BUT if Oid < SubTree and sofar good, we %% return true. As Oid get larger we may decide. %%----------------------------------------------------------------- check_maybe_mask(_Oid, [], _Mask) -> true; check_maybe_mask([X | Xs], [X | Ys], [1 | Ms]) -> check_maybe_mask(Xs, Ys, Ms); check_maybe_mask([X | Xs], [X | Ys], []) -> check_maybe_mask(Xs, Ys, []); check_maybe_mask([_X | Xs], [_Y | Ys], [0 | Ms]) -> check_maybe_mask(Xs, Ys, Ms); check_maybe_mask([_X | _Xs], [_Y | _Ys], _) -> false; <-------------------------------------------------------------------------- we always fall here check_maybe_mask(_, _, _) -> true. %%------------------------------------------------------------------------------------ I have changed the line 347 to "case check_maybe_mask(Oid, SubTree, snmp_view_based_acm_mib:emask2imask(Mask)) of" and this problem was gone Reason 2. My vacm.conf: {vacmSecurityToGroup, usm, "domainSecurity", "domainGroup"}. {vacmAccess, "domainGroup", "", usm, authPriv, exact, "domainOwnerView", "domainOwnerView", "domainOwnerView"}. {vacmViewTreeFamily, "domainOwnerView", [1,3,6,1,4,1,,1,2,1,1,2], included, [1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1]}. %%------------------------------------------------------------------------------------ The oid of my table is [1,3,6,1,4,1,,1,2,1,1,2] But this code tries to optimize working with tables, and it always decide that my oid is shorter than oid of subtree specified in the vacm.conf. So oid of my table is dropped as inappropriate. -module(snmpa_mib_data_tttn). 811 next_node(D, {tree, Tree, {table_entry, _MibName}}, 812 Oid, RevOidSoFar, MibView) -> 813 ?vtrace("next_node(tree,table_entry) -> entry when" 814 "~n size(Tree): ~p" 815 "~n Oid: ~p" 816 "~n RevOidSoFar: ~p" 817 "~n MibView: ~p", [size(Tree), Oid, RevOidSoFar, MibView]), 818 OidSoFar = lists:reverse(RevOidSoFar), 819 case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar, MibView) of %%------------------------------------------------------------------------------------ So, this code always return false as OidSoFar is shorter than MibView. I have changed the code at line 818 to "OidSoFar = lists:reverse(RevOidSoFar) ++ Oid," and all works well. %%------------------------------------------------------------------------------------ Unfortunately I cannot know if this changes broke functionality somewhere else. Moreover I've tried to use mask with wildcard applied to table column like this [1,3,6,1,4,1,,1,2,1,1,2,] [1,1,1,1,1,1,1,1, 1,1,1,0,1,0,0,0] and it's is not working for my table. I have already sended patch on another problem related to masks: http://erlang.org/pipermail/erlang-patches/2015-April/004766.html. Did anybody tested this feature last years? It is totally not works) Best regards, Dmitry From jose.valim@REDACTED Wed Apr 8 00:44:18 2015 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 8 Apr 2015 00:44:18 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) Message-ID: I have first noticed this issue when compiling Elixir's grammar. Compiling yrl -> erl -> beam is about 20% slower in Erlang 18.0-rc1. The results are shown below: https://gist.github.com/josevalim/ab08341512ba875fb4a7 To further verify the performance issues, I have decided to run Elixir's test suite with 18.0 and 17.4. Elixir test suite defines a lot of modules dynamically when loading so that would be a good test. The results are here: https://gist.github.com/josevalim/895e2365d5ae517b1c8a It is interesting that the load/compile times are indeed higher in 18.0 but the test suite is also taking *longer*. This may imply it is not the compiler that is slower but Erlang itself. I have run the test suite of other projects in different Erlang versions (same Elixir version though) and seen similar slow down. About a 20% slow down on Erlang 18.0-rc1 overall. Unfortunately, I don't have any idea why this is happening. I have asked others to compile the same .yrl file and they have seen similar performance hit. It is easy to reproduce it. Download the elixir_parser.yrl file: https://github.com/elixir-lang/elixir/blob/v1.0/lib/elixir/src/elixir_parser.yrl And run both commands: $ time erlc +time elixir_parser.yrl $ time erlc +time elixir_parser.erl I hope by posting this report others can be alert to similar issues in their projects. Thoughts? *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Wed Apr 8 01:02:09 2015 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 07 Apr 2015 16:02:09 -0700 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: <552461F1.5060702@gmail.com> On 04/07/2015 03:44 PM, Jos? Valim wrote: > I have first noticed this issue when compiling Elixir's grammar. Compiling yrl -> erl -> beam is about 20% slower in Erlang 18.0-rc1. The results are shown below: > > https://gist.github.com/josevalim/ab08341512ba875fb4a7 > > To further verify the performance issues, I have decided to run Elixir's test suite with 18.0 and 17.4. Elixir test suite defines a lot of modules dynamically when loading so that would be a good test. The results are here: > > https://gist.github.com/josevalim/895e2365d5ae517b1c8a > > It is interesting that the load/compile times are indeed higher in 18.0 but the test suite is also taking *longer*. This may imply it is not the compiler that is slower but Erlang itself. I have run the test suite of other projects in different Erlang versions (same Elixir version though) and seen similar slow down. About a 20% slow down on Erlang 18.0-rc1 overall. > > Unfortunately, I don't have any idea why this is happening. I have asked others to compile the same .yrl file and they have seen similar performance hit. It is easy to reproduce it. Download the elixir_parser.yrl file: > > https://github.com/elixir-lang/elixir/blob/v1.0/lib/elixir/src/elixir_parser.yrl > > And run both commands: > > $ time erlc +time elixir_parser.yrl > $ time erlc +time elixir_parser.erl > > I hope by posting this report others can be alert to similar issues in their projects. > > Thoughts? > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs I have used rebar2 (using the tag "2.1.0-pre") to compile CloudI with 18.0-rc1 and have had a few builds go extremely slow, to the point I needed to kill the build and restart it (slow only during the rebar2 usage). This problem appears to be transient and I haven't been able to reproduce it consistently, but I assume it is related to how escript is running. I have other escripts that use "-mode(compile)." which don't have this problem. I haven't done enough runtime usage of 18.0-rc1 to really determine that this is or isn't related to the Erlang compilation, but it makes more sense to me that it is a transient slowness with the Erlang VM itself, for reasons unknown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Wed Apr 8 10:27:18 2015 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 8 Apr 2015 10:27:18 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: Answers inline below. On Wed, Apr 8, 2015 at 12:44 AM, Jos? Valim wrote: > I have first noticed this issue when compiling Elixir's grammar. Compiling > yrl -> erl -> beam is about 20% slower in Erlang 18.0-rc1. The results are > shown below: > > https://gist.github.com/josevalim/ab08341512ba875fb4a7 The BEAM compiler might very well have become slower. There are new optimizations in sys_core_fold thay may cause slowdowns. For example, sys_core_fold now keeps track of more type information than in OTP 17. > To further verify the performance issues, I have decided to run Elixir's > test suite with 18.0 and 17.4. Elixir test suite defines a lot of modules > dynamically when loading so that would be a good test. The results are here: > > https://gist.github.com/josevalim/895e2365d5ae517b1c8a > > It is interesting that the load/compile times are indeed higher in 18.0 but > the test suite is also taking *longer*. This may imply it is not the > compiler that is slower but Erlang itself. I have run the test suite of > other projects in different Erlang versions (same Elixir version though) and > seen similar slow down. About a 20% slow down on Erlang 18.0-rc1 overall. Just to be absolutely clear. How is the 20% slow down measured? Is it based on the total run-time for the test suites (including compilation times for dynamic modules)? Before we can reach the conclusion that the run-time system is slower, we will need measurements on a piece of Erlang source code that has not changed between OTP versions. > Unfortunately, I don't have any idea why this is happening. I have asked > others to compile the same .yrl file and they have seen similar performance > hit. It is easy to reproduce it. Download the elixir_parser.yrl file: > > https://github.com/elixir-lang/elixir/blob/v1.0/lib/elixir/src/elixir_parser.yrl > > And run both commands: > > $ time erlc +time elixir_parser.yrl > $ time erlc +time elixir_parser.erl > I will have look and see if there are any unnecessary slowdowns in the BEAM compiler in OTP 18. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From jose.valim@REDACTED Wed Apr 8 15:34:15 2015 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 8 Apr 2015 15:34:15 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: Answers inline. > Just to be absolutely clear. How is the 20% slow down measured? > Is it based on the total run-time for the test suites (including > compilation times for dynamic modules)? > In the reports you can see the total time for running the test suite, as well as the time taken only for loading, and then just running the tests. So we will have all three times. > Before we can reach the conclusion that the run-time system > is slower, we will need measurements on a piece of Erlang > source code that has not changed between OTP versions. > Yes, agreed. I plan to perform a couple more benchmarks this weekend, if anyone has any ideas about what to bench, feedback is welcome. > I will have look and see if there are any unnecessary slowdowns > in the BEAM compiler in OTP 18. > Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Apr 8 16:17:34 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 8 Apr 2015 16:17:34 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: On Wed, Apr 8, 2015 at 3:34 PM, Jos? Valim wrote: > In the reports you can see the total time for running the test suite, as > well as the time taken only for loading, and then just running the tests. It can be either the way the tests are constructed and run, the compiler producing worse code, or a slowdown in the runtime. I'd suggest investigating by measuring the behaviour of the system while it is executing the tests. Many things have changed, so it can be anything which causes such a slowdown. Also, confirmation from the OTP team that the build has no assertions in it would be nice. E.g., FreeBSD enables a lot of extra checking on their -CURRENT to catch problems early on. But as a benchmarking target, it is fairly bad :) To heed Brendan Gregg, use active benchmarking, the USE method[0] http://www.brendangregg.com/activebenchmarking.html -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From system.out@REDACTED Thu Apr 9 05:37:51 2015 From: system.out@REDACTED (Dmitry Davidenko) Date: Thu, 09 Apr 2015 09:37:51 +0600 Subject: [erlang-bugs] SNMP usm agent doesn't work properly in case of mask =/= null In-Reply-To: <5345771428409871@web11g.yandex.ru> References: <5345771428409871@web11g.yandex.ru> Message-ID: <2282961428550671@web28m.yandex.ru> I have already made pull request on github fixes this subj https://github.com/erlang/otp/pull/671 07.04.2015, 19:24, "Heizenberg John" : > I faced with this problem on snmp-4.25. Then I cloned otp commit 545890576542e4be630df8772654b99bd0306f62 Author: Erlang/OTP Date: ??Tue Mar 31 12:24:06 2015 +0200 and I still have the same trouble. > The reason is the some optimisation code in snmpa_mib_data_tttn (ttln). ?In fact there are two reasons: > > Reason 1. > > -module(snmpa_mib_data_tttn). > > 811 ??next_node(D, {tree, Tree, {table_entry, _MibName}}, > ????????.... > 819 ??case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar, MibView) of > > %%------------------------------------------------------------------------------------ > > -module(snmpa_acm). > > 346 ??is_definitely_not_in_mib_view(Oid, [{SubTree, Mask,?view_included}|T]) -> > 347 ??????case check_maybe_mask(Oid, SubTree, Mask) of > 348 ???true -> false; > 349 ???false -> is_definitely_not_in_mib_view(Oid, T) > 350 ??????end; > > %%------------------------------------------------------------------------------------ > > But as I saw while debugging the Mask variable is type of emask (the list of bytes, not the list of bits) and check_maybe_mask(Oid, SubTree, Mask) always return false. This cause that every Oid will be dropped as inapropriate: > > %%----------------------------------------------------------------- > %% As check_mask, BUT if Oid < SubTree and sofar good, we > %% return true. As Oid get larger we may decide. > %%----------------------------------------------------------------- > check_maybe_mask(_Oid, [], _Mask) -> true; > check_maybe_mask([X | Xs], [X | Ys], [1 | Ms]) -> > ????check_maybe_mask(Xs, Ys, Ms); > check_maybe_mask([X | Xs], [X | Ys], []) -> > ????check_maybe_mask(Xs, Ys, []); > check_maybe_mask([_X | Xs], [_Y | Ys], [0 | Ms]) -> > ????check_maybe_mask(Xs, Ys, Ms); > check_maybe_mask([_X | _Xs], [_Y | _Ys], _) -> > ????false; ??<-------------------------------------------------------------------------- we always fall here > check_maybe_mask(_, _, _) -> > ????true. > %%------------------------------------------------------------------------------------ > > I have changed the line 347 to "case check_maybe_mask(Oid, SubTree, snmp_view_based_acm_mib:emask2imask(Mask)) of" and this problem was gone > > Reason 2. > > My vacm.conf: > > {vacmSecurityToGroup, usm, "domainSecurity", "domainGroup"}. > {vacmAccess, "domainGroup", "", usm, authPriv, exact, "domainOwnerView", "domainOwnerView", "domainOwnerView"}. > {vacmViewTreeFamily, "domainOwnerView", [1,3,6,1,4,1,,1,2,1,1,2], included, [1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1]}. > %%------------------------------------------------------------------------------------ > > The oid of my table is [1,3,6,1,4,1,,1,2,1,1,2] > > But this code tries to optimize working with tables, and it always decide that my oid is shorter than oid of subtree specified in the vacm.conf. So oid of my table is dropped as inappropriate. > > -module(snmpa_mib_data_tttn). > > 811 ???next_node(D, {tree, Tree, {table_entry, _MibName}}, > 812 ?Oid, RevOidSoFar, MibView) -> > 813 ????vtrace("next_node(tree,table_entry) -> entry when" > 814 "~n ??size(Tree): ?~p" > 815 "~n ??Oid: ????????~p" > 816 "~n ??RevOidSoFar: ~p" > 817 "~n ??MibView: ????~p", [size(Tree), Oid, RevOidSoFar, MibView]), > 818 ???OidSoFar = lists:reverse(RevOidSoFar), > 819 ???case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar, MibView) of > %%------------------------------------------------------------------------------------ > > So, this code always return false as OidSoFar is shorter than MibView. I have changed the code at line 818 to "OidSoFar = lists:reverse(RevOidSoFar) ++ Oid," and all works well. > %%------------------------------------------------------------------------------------ > > Unfortunately I cannot know if this changes broke functionality somewhere else. Moreover I've tried to use mask with wildcard applied to table column like this [1,3,6,1,4,1,,1,2,1,1,2,] [1,1,1,1,1,1,1,1, 1,1,1,0,1,0,0,0] and it's is not working for my table. > > I have already sended patch on another problem related to masks: http://erlang.org/pipermail/erlang-patches/2015-April/004766.html. > Did anybody tested this feature last years? It is totally not works) > > Best regards, Dmitry > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From a.p.burkov@REDACTED Thu Apr 9 12:27:36 2015 From: a.p.burkov@REDACTED (Alexander Burkov) Date: Thu, 09 Apr 2015 10:27:36 +0000 Subject: [erlang-bugs] Cover transforms some binary comprehensions incorrectly In-Reply-To: References: Message-ID: In some cases cover transforms binary comprehensions into non-working ones. Please consider example below: ---cut--- -module(wrong_transform). -compile(export_all). good() -> << <<$,, X/binary>> || X <- [ <<"a">>, <<"b">> ]>>. bad() -> << <<",", X/binary>> || X <- [ <<"a">>, <<"b">> ]>>. ---cut--- With disabled cover, outputs of this functions are equal, `bad() =:= good()`. But if you do `cover:compile_beam/1` (see decompile.erl) it blows with `badarg` in `bad/0` function. Meanwhile `good/0` works well. I've patched a bit `cover.erl` to dump AST forms before and after `cover:compile_beam/1` and found that for some reason it surrounds terms inside of comprehension with `begin ... end` pattern. It is wrong in case of list (I can't explain why, but it throws badarg, so I guess it is definitely an issue :) Also I will appreciate if someone explain me why we do need this cover's trick with `begin .. end`. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrong_transform.after.erl Type: application/octet-stream Size: 455 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrong_transform.after.ast Type: application/octet-stream Size: 2478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrong_transform.before.ast Type: application/octet-stream Size: 1521 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cover.erl.patch Type: application/octet-stream Size: 690 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: decompile.erl Type: application/octet-stream Size: 552 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrong_transform.before.erl Type: application/octet-stream Size: 184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrong_transform.erl Type: application/octet-stream Size: 182 bytes Desc: not available URL: From jose.valim@REDACTED Mon Apr 13 18:44:29 2015 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Mon, 13 Apr 2015 18:44:29 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: Ok, I have run some more experiments. *1. The time to start and shutdown the erlang system is higher on 18.0* $ time erl -s erlang halt real 0m0.357s user 0m0.229s sys 0m0.102s Takes on average 0.35s on 18.0 but 0.25 on 17.3. *2. The time to start, write to stdio and shutdown the erlang system is higher on 18.0* $ time erl -eval "io:format(hello, []), halt()." real 0m0.512s user 0m0.383s sys 0m0.118s Takes on average 0.51s on 18.0 but 0.28s on 17.3. *3. The emulator in 18.0 takes considerably more memory than 17.3* After running observer:start() on both, 18.0 takes 55MB while 17.3 takes only 18MB. *4. Time required to compile modules is higher on 18.0* Given the sample code in this module: https://gist.github.com/josevalim/bd0e82d9bfaf37599b9c Then compile the module and run foo:start() in the shell after boot: $ erlc foo.erl $ erl erl> foo:start(). Time: 1136296. The timer:tc/2 result is on average 1.1s on 18.0 but 0.9s on 17.3. *5. Time to compile a module and write to stdout with -s is very high on 18.0* I have found this one by accident. If we invoke the gist above from the command line, sometimes it takes about 8s to compile all modules and print to terminal on 18.0. Just run the code above as: $ erlc foo.erl && erl -s foo erl> Time: 7803694. It takes on average 0.9s on 17.3 but often it takes 7.8s on 18.0. *Info* Using Mac OS X, both Erlang compiled with .kerl using the same options. Those results have been confirmed by other users running on different machines. I can continue running more of those experiments or I can try anything specific. Just let me know. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Apr 13 22:38:54 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 13 Apr 2015 22:38:54 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 6:44 PM, Jos? Valim wrote: > 2. The time to start, write to stdio and shutdown the erlang system is > higher on 18.0 I was interested in this one, because I think I've perceived startup times being less regular, and this is a good check. I did: [jlouis@REDACTED 2]$ for i in $(seq 1 100); do time erl -eval "io:format(hello, []), halt()." ; done > collected.txt 2>&1 grep real collected.txt | sed -e 's/^.*m//g' -e s/s$//g > data.txt To collect the necessary data. On a FreeBSD system, you might need the jot(1) command rather than the seq(1) command, but the idea is the same. In R: x <- read.csv('data.txt', header=FALSE) > summary(x) V1 Min. :0.1890 1st Qu.:0.1930 Median :0.1940 Mean :0.1948 3rd Qu.:0.1963 Max. :0.2050 In other words, my hunch was soundly destroyed by data. I've seen what I perceive to be longer boot times as well, and they seem to deviate more. But the human perception is so bad at precise measurements. Consider using the above script-idea together with R to obtain some more data and better numbers. The mean is usually only a good statistic if you have other data. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Mon Apr 13 23:12:23 2015 From: wallentin.dahlberg@REDACTED (=?UTF-8?Q?Bj=C3=B6rn=2DEgil_Dahlberg?=) Date: Mon, 13 Apr 2015 23:12:23 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: 2015-04-13 18:44 GMT+02:00 Jos? Valim : > *3. The emulator in 18.0 takes considerably more memory than 17.3* > > After running observer:start() on both, 18.0 takes 55MB while 17.3 takes > only 18MB. > This is most likely due to multiple timer wheels in 18. We now have one wheel per scheduler and a larger wheel to boot. I'm unsure to why it is so large though. Rickard? TIW 16x larger? You can see the size vary with +S switch. // Bj?rn-Egil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Apr 13 23:26:47 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 13 Apr 2015 23:26:47 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: Ok, and I spoke too soon and reported numbers for 17.5 :P I've collected 17.5 and 18.0-rc1-109-gb5f3973 by the same method as in my previous post. The summaries in R are: > r17 <- read.csv('data-17.5.txt', header=FALSE) > r18 <- read.csv('data_OTP-18.0-rc1-109-gb5f3973.txt', header=FALSE) > r17$version <- 17 > r18$version <- 18 > x <- rbind(r17, r18) > summary(r17) V1 version Min. :0.1900 Min. :17 1st Qu.:0.1930 1st Qu.:17 Median :0.1940 Median :17 Mean :0.1946 Mean :17 3rd Qu.:0.1960 3rd Qu.:17 Max. :0.2040 Max. :17 > summary(r18) V1 version Min. :0.2100 Min. :18 1st Qu.:0.2790 1st Qu.:18 Median :0.2840 Median :18 Mean :0.2968 Mean :18 3rd Qu.:0.3493 3rd Qu.:18 Max. :0.4050 Max. :18 This is more like it! They are vastly different, with the r18 version having a much much larger spread. How large? install.packages('ggplot2') m <- ggplot(x, aes(x = V1, colour=version, group=version) m + geom_density(fill=NA) The kernel density plot on imgur: http://imgur.com/9i8YE0U which clearly shows that bootup of 17.5 is consistent, whereas bootup of the 18.0-rc1++ version I run is highly erratic. Is this due to timer wheel bootup and the new time tracking code? On Mon, Apr 13, 2015 at 10:38 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Mon, Apr 13, 2015 at 6:44 PM, Jos? Valim < > jose.valim@REDACTED> wrote: > >> 2. The time to start, write to stdio and shutdown the erlang system is >> higher on 18.0 > > > I was interested in this one, because I think I've perceived startup times > being less regular, and this is a good check. I did: > > [jlouis@REDACTED 2]$ for i in $(seq 1 100); do time erl -eval > "io:format(hello, []), halt()." ; done > collected.txt 2>&1 > grep real collected.txt | sed -e 's/^.*m//g' -e s/s$//g > data.txt > > To collect the necessary data. On a FreeBSD system, you might need the > jot(1) command rather than the seq(1) command, but the idea is the same. > > In R: > > x <- read.csv('data.txt', header=FALSE) > > summary(x) > V1 > Min. :0.1890 > 1st Qu.:0.1930 > Median :0.1940 > Mean :0.1948 > 3rd Qu.:0.1963 > Max. :0.2050 > > In other words, my hunch was soundly destroyed by data. I've seen what I > perceive to be longer boot times as well, and they seem to deviate more. > But the human perception is so bad at precise measurements. Consider using > the above script-idea together with R to obtain some more data and better > numbers. The mean is usually only a good statistic if you have other data. > > -- > J. > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Tue Apr 14 07:55:32 2015 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Tue, 14 Apr 2015 07:55:32 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: > > This is most likely due to multiple timer wheels in 18. We now have one > wheel per scheduler and a larger wheel to boot. I'm unsure to why it is so > large though. Rickard? TIW 16x larger? > > You can see the size vary with +S switch. > Yup, it is the due to the timer wheel. +S 1 reduces it. I believe Lukas mentioned it would take around 1 word MB per scheduler. It is likely this higher memory usage is going to cause confusion for folks jumping into Erlang 18.0 if we don't provide proper disclaimers, even more for those in the embedded space as I often hear the memory footprint to be one of Erlang VM benefits. Maybe one solution is to ship with smaller wheels but allow the size to be configurable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Apr 14 13:07:02 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 14 Apr 2015 13:07:02 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: On Tue, Apr 14, 2015 at 7:55 AM, Jos? Valim wrote: > Yup, it is the due to the timer wheel. +S 1 reduces it. I believe Lukas > mentioned it would take around 1 word MB per scheduler. r18 +S1 is actually faster in the median it seems, but it does have some speed bumps higher up: http://imgur.com/xTZc4qn > summary(r17) V1 version Min. :0.1900 Length:100 1st Qu.:0.1930 Class :character Median :0.1940 Mode :character Mean :0.1946 3rd Qu.:0.1960 Max. :0.2040 > summary(r18s1) V1 version Min. :0.1880 Length:100 1st Qu.:0.1900 Class :character Median :0.1910 Mode :character Mean :0.1957 3rd Qu.:0.1940 Max. :0.3000 To recreate this, use ggplot2, but use strings for the version and then use those version strings as factors: p <- ggplot(x, aes(x = V1, colour=factor(version))) p + geom_density() png('out.png') p + geom_density() dev.off() -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Apr 14 13:21:14 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 14 Apr 2015 13:21:14 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: I'm an export at messing up data sets. Corrected plot: http://imgur.com/N3mvRnn On Tue, Apr 14, 2015 at 1:07 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > On Tue, Apr 14, 2015 at 7:55 AM, Jos? Valim < > jose.valim@REDACTED> wrote: > >> Yup, it is the due to the timer wheel. +S 1 reduces it. I believe Lukas >> mentioned it would take around 1 word MB per scheduler. > > > r18 +S1 is actually faster in the median it seems, but it does have some > speed bumps higher up: > > http://imgur.com/xTZc4qn > > > summary(r17) > V1 version > Min. :0.1900 Length:100 > 1st Qu.:0.1930 Class :character > Median :0.1940 Mode :character > Mean :0.1946 > 3rd Qu.:0.1960 > Max. :0.2040 > > summary(r18s1) > V1 version > Min. :0.1880 Length:100 > 1st Qu.:0.1900 Class :character > Median :0.1910 Mode :character > Mean :0.1957 > 3rd Qu.:0.1940 > Max. :0.3000 > > To recreate this, use ggplot2, but use strings for the version and then > use those version strings as factors: > > p <- ggplot(x, aes(x = V1, colour=factor(version))) > p + geom_density() > png('out.png') > p + geom_density() > dev.off() > > > > > > -- > J. > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Apr 16 11:45:25 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 16 Apr 2015 12:45:25 +0300 Subject: [erlang-bugs] gen_server:init/1 is optional (18+) Message-ID: <552F84B5.20406@ninenines.eu> Hello, gen_server:init/1 is an optional callback and should be marked as such in Erlang 18+ now that it has -optional_callbacks. It is optional because of enter_loop. It is currently not possible to use -behavior(gen_server) when you need to use enter_loop. Cheers, -- Lo?c Hoguin http://ninenines.eu From kenneth@REDACTED Fri Apr 17 12:31:52 2015 From: kenneth@REDACTED (Kenneth Lundin) Date: Fri, 17 Apr 2015 12:31:52 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: In 18 Rc1 the timer wheel size per scheduler is set to 1 Mwords = 8 Mbytes, this is too high. We plan to lower this to 64K words = 0.5 Mbytes per scheduler in the next 18 Rc. Note that in OTP 17 there is 1 timer wheel with size 64K words. /Kenneth Erlang/OTP Team, Ericsson On Tue, Apr 14, 2015 at 7:55 AM, Jos? Valim wrote: > This is most likely due to multiple timer wheels in 18. We now have one >> wheel per scheduler and a larger wheel to boot. I'm unsure to why it is so >> large though. Rickard? TIW 16x larger? >> >> You can see the size vary with +S switch. >> > > Yup, it is the due to the timer wheel. +S 1 reduces it. I believe Lukas > mentioned it would take around 1 word MB per scheduler. > > It is likely this higher memory usage is going to cause confusion for > folks jumping into Erlang 18.0 if we don't provide proper disclaimers, even > more for those in the embedded space as I often hear the memory footprint > to be one of Erlang VM benefits. > > Maybe one solution is to ship with smaller wheels but allow the size to be > configurable? > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Mon Apr 20 09:06:58 2015 From: sdl.web@REDACTED (Leo Liu) Date: Mon, 20 Apr 2015 15:06:58 +0800 Subject: [erlang-bugs] Make it possible to link to unixODBC on darwin Message-ID: Hi there, I thought Erlang is linked to unixODBC on my mac since `brew info erlang' prints: erlang: stable 17.5 (bottled), HEAD http://www.erlang.org /usr/local/Cellar/erlang/17.5 (7398 files, 283M) * Poured from bottle From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/erlang.rb ==> Dependencies Build: autoconf ?, automake ?, libtool ? Required: openssl ?, unixodbc ? Took me about 20 minutes to install mysql and mysql-connector-odbc, configure and connect to mysql using odbc (via isql). but the Erlang odbc app keeps failing: {error,"[iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded SQLSTATE IS: IM002 Connection to database failed."} So now I am investigating this iodbc and discovered erlang actually linked to /usr/lib/libiodbc.2.dylib which seems to be an awfully outdated lib that apple no longer maintains. Besides that file I have no idea what else are provided to work with iODBC. I think it makes a lot of sense to allow compiling erlang with another ODBC lib (unixODBC takes about 1.7 seconds to install on the mac). Thanks, Leo From sverker.eriksson@REDACTED Mon Apr 20 16:51:30 2015 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 20 Apr 2015 16:51:30 +0200 Subject: [erlang-bugs] bug in HiPE for <<_/utf8,...>> In-Reply-To: <20150402082002.GA28276@molb.org> References: <7A9C4EA7-5ECC-4BB3-B9CC-B605409D96F8@entelios.com> <20150402082002.GA28276@molb.org> Message-ID: <55351272.9020104@ericsson.com> Here is a pull request that i think solved this problem. https://github.com/erlang/otp/pull/690 It would be good if you could test it out. The fix is both in the hipe compiler and in the VM, which means you have to rebuild both and then your own code with the new compiler. /Sverker, Erlang/OTP On 04/02/2015 10:20 AM, Johannes Wei?l wrote: > Hi, > > A short update: The reported HiPE bug is still present and reproducible > in OTP 17.5 and 18.0-rc1. > > We had to modify the 'crash.erl' program a little bit after commits > 5a7b211 and 7b10ff7 (this shows how fragile it is!), so I'm attaching > the latest version: > > MD5 (crash.erl) = 41d0e4e8ed7039dc898a16135aa62bcb > MD5 (crash_it.escript) = f7756e997d9ca28f6d523086e8c37f91 > MD5 (data.jsn) = a0ee43e0e63aea6f3c89c41cc3b5d378 > > To reproduce the bug, save all three files in one directory, make > 'crash_it.escript' executable and run it. It compiles 'crash.erl' > with HiPE enabled, and produces a crash, which does not occur without > HiPE. See also the 'Details' section below for more information about > the bug. > > Regards, > Johannes Wei?l and Sebastian Egner > > On Mon, Sep 09, 2013 at 02:20PM +0000, Sebastian Egner wrote: >> Hi, >> >> There seems to be a Heisenbug in HiPE related to matching <<_/utf8,...>>. >> >> After a long and bloody fight, we have been able to isolate the problem to the degree >> that it is sufficiently reproducible. See details below. >> >> We strongly suspect that the problem is a genuine bug related to the binary matching >> and the garbage collector. Whether the bug is hit depends on the memory contents >> of previously allocated heap-allocated binaries. >> >> Best regards, >> Johannes Weissl and Sebastian Egner. >> >> -- >> >> Details: >> - The program 'crash.erl' loads a JSON sample file. Then it parses the file again and again, >> and after a wildly varying number of iterations (100-100000) the parser fails. >> - To run the program, execute "crash_it" in a directory containing "crash.erl" and "data.jsn". >> When the bug is hit, the program stops. This takes several seconds to minutes. >> - The problem manifests itself when <<"0123...">> does not match <<_/utf8,_/binary>> >> in the function crash:check_utf8_binary/1. (The program aborts with an exception exit.) >> - Surprisingly, we have not been able to reduce the program even more. >> In particular, when randomize_memory/0 is not called, the problem is much less frequent. >> - The bug is present in R13B02, R14B04, R16B01, "maint" (2f28245) and master (45eaf81). >> - The bug is present under MacOSX (10.8.4), Debian GNU/Linux and a Linux in an ARM emulator. >> This indicates that the bug is not related to the operating system platform. >> - We have run the program in Valgrind and found conditionals that depend on uninitialised >> values. Refer to "valgrind.out" for details. >> >> Attachments: >> MD5 (crash.erl) = 1f1507c8238e2136d9163314bcac0045 >> MD5 (crash_it) = 4061276b89dfc822cbfc22002f202358 >> MD5 (data.jsn) = c5b503cc61d76adc7dcb60832a123b99 >> MD5 (valgrind.out) = 2e6f67bf06b3df66c6daf728444b9b66 >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jargon@REDACTED Mon Apr 20 21:02:22 2015 From: jargon@REDACTED (Johannes =?utf-8?B?V2Vpw59s?=) Date: Mon, 20 Apr 2015 21:02:22 +0200 Subject: [erlang-bugs] bug in HiPE for <<_/utf8,...>> In-Reply-To: <55351272.9020104@ericsson.com> References: <7A9C4EA7-5ECC-4BB3-B9CC-B605409D96F8@entelios.com> <20150402082002.GA28276@molb.org> <55351272.9020104@ericsson.com> Message-ID: <20150420190222.GA12042@molb.org> Hello Sverker, Thanks a lot! The patch solves the bug in the 'crash.erl' program as well as in our application. Johannes On Mon, Apr 20, 2015 at 04:51PM +0200, Sverker Eriksson wrote: > Here is a pull request that i think solved this problem. > > https://github.com/erlang/otp/pull/690 > > It would be good if you could test it out. > The fix is both in the hipe compiler and in the VM, > which means you have to rebuild both > and then your own code with the new compiler. > > /Sverker, Erlang/OTP > > On 04/02/2015 10:20 AM, Johannes Wei?l wrote: > > Hi, > > > > A short update: The reported HiPE bug is still present and reproducible > > in OTP 17.5 and 18.0-rc1. > > > > We had to modify the 'crash.erl' program a little bit after commits > > 5a7b211 and 7b10ff7 (this shows how fragile it is!), so I'm attaching > > the latest version: > > > > MD5 (crash.erl) = 41d0e4e8ed7039dc898a16135aa62bcb > > MD5 (crash_it.escript) = f7756e997d9ca28f6d523086e8c37f91 > > MD5 (data.jsn) = a0ee43e0e63aea6f3c89c41cc3b5d378 > > > > To reproduce the bug, save all three files in one directory, make > > 'crash_it.escript' executable and run it. It compiles 'crash.erl' > > with HiPE enabled, and produces a crash, which does not occur without > > HiPE. See also the 'Details' section below for more information about > > the bug. > > > > Regards, > > Johannes Wei?l and Sebastian Egner > > > > On Mon, Sep 09, 2013 at 02:20PM +0000, Sebastian Egner wrote: > > > Hi, > > > > > > There seems to be a Heisenbug in HiPE related to matching <<_/utf8,...>>. > > > > > > After a long and bloody fight, we have been able to isolate the problem to the degree > > > that it is sufficiently reproducible. See details below. > > > > > > We strongly suspect that the problem is a genuine bug related to the binary matching > > > and the garbage collector. Whether the bug is hit depends on the memory contents > > > of previously allocated heap-allocated binaries. > > > > > > Best regards, > > > Johannes Weissl and Sebastian Egner. > > > > > > -- > > > > > > Details: > > > - The program 'crash.erl' loads a JSON sample file. Then it parses the file again and again, > > > and after a wildly varying number of iterations (100-100000) the parser fails. > > > - To run the program, execute "crash_it" in a directory containing "crash.erl" and "data.jsn". > > > When the bug is hit, the program stops. This takes several seconds to minutes. > > > - The problem manifests itself when <<"0123...">> does not match <<_/utf8,_/binary>> > > > in the function crash:check_utf8_binary/1. (The program aborts with an exception exit.) > > > - Surprisingly, we have not been able to reduce the program even more. > > > In particular, when randomize_memory/0 is not called, the problem is much less frequent. > > > - The bug is present in R13B02, R14B04, R16B01, "maint" (2f28245) and master (45eaf81). > > > - The bug is present under MacOSX (10.8.4), Debian GNU/Linux and a Linux in an ARM emulator. > > > This indicates that the bug is not related to the operating system platform. > > > - We have run the program in Valgrind and found conditionals that depend on uninitialised > > > values. Refer to "valgrind.out" for details. > > > > > > Attachments: > > > MD5 (crash.erl) = 1f1507c8238e2136d9163314bcac0045 > > > MD5 (crash_it) = 4061276b89dfc822cbfc22002f202358 > > > MD5 (data.jsn) = c5b503cc61d76adc7dcb60832a123b99 > > > MD5 (valgrind.out) = 2e6f67bf06b3df66c6daf728444b9b66 From roberto@REDACTED Wed Apr 22 16:34:19 2015 From: roberto@REDACTED (Roberto Ostinelli) Date: Wed, 22 Apr 2015 16:34:19 +0200 Subject: [erlang-bugs] Cannot run CT tests multiple times Message-ID: Dear list, When I run CT tests multiple times I encounter a bug. ======== erl -pa apps/*/ebin -pa deps/*/ebin \ -name myapp@REDACTED \ +K true \ +P 5000000 \ +Q 1000000 \ -env ERL_FULLSWEEP_AFTER 10 \ -config myapp \ -mnesia schema_location ram \ -noshell \ -eval 'ct_run:run_test([{dir, "apps/myapp/test"}, {logdir, "apps/myapp/logs"}]).' \ -s erlang halt ========= Running this the first 2/3 times will give: ========= Common Test starting (cwd is /Users/roberto/workspace/myapp) Common Test: Running make in test directories... CWD set to: "/Users/roberto/workspace/myapp/apps/myapp/logs/ct_run.myapp@REDACTED " TEST INFO: 1 test(s), 1 case(s) in 1 suite(s) Testing apps.myapp: Starting test, 1 test cases Testing apps.myapp: TEST COMPLETE, 1 ok, 0 failed of 1 test cases ========= After the 3rd time or so (this happens randomly), I get: ========= $ ./tests Common Test starting (cwd is /Users/roberto/workspace/myapp) =ERROR REPORT==== 22-Apr-2015::16:26:00 === Error in process <0.42.0> on node 'myapp@REDACTED' with exit value: {{badmatch,["ct_run","myapp@REDACTED ","0","0","1","2015-04-22_16","25","26"]},[{ct_logs,'-sort_ct_runs/1-fun-0-',2,[{file,"ct_logs.erl"},{line,1912}]},{lists,sort,2,[{file,"lists.erl"},{line,967}]},{ct_logs,make_all_suites_index,1,[{file,"ct_logs... ========= If I delete the directory where the CT logs are stored I can re-run the command, without issues. Any ideas? Best, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peppe@REDACTED Thu Apr 23 12:40:22 2015 From: peppe@REDACTED (Peter Andersson) Date: Thu, 23 Apr 2015 12:40:22 +0200 Subject: [erlang-bugs] Cannot run CT tests multiple times In-Reply-To: References: Message-ID: <5538CC16.50103@erlang.org> Hi Roberto, This problem looks very much like one previously reported, about CT not handling long node names correctly. There's a fix for it in the master branch: 8a23259. Are you running on an updated branch? Best regards, Peter Ericsson AB, Erlang/OTP On 2015-04-22 16:34, Roberto Ostinelli wrote: > Dear list, > When I run CT tests multiple times I encounter a bug. > > ======== > erl -pa apps/*/ebin -pa deps/*/ebin \ > -name myapp@REDACTED \ > +K true \ > +P 5000000 \ > +Q 1000000 \ > -env ERL_FULLSWEEP_AFTER 10 \ > -config myapp \ > -mnesia schema_location ram \ > -noshell \ > -eval 'ct_run:run_test([{dir, "apps/myapp/test"}, {logdir, > "apps/myapp/logs"}]).' \ > -s erlang halt > ========= > > > Running this the first 2/3 times will give: > > > ========= > Common Test starting (cwd is /Users/roberto/workspace/myapp) > > > Common Test: Running make in test directories... > > CWD set to: > "/Users/roberto/workspace/myapp/apps/myapp/logs/ct_run.myapp@REDACTED" > > TEST INFO: 1 test(s), 1 case(s) in 1 suite(s) > > Testing apps.myapp: Starting test, 1 test cases > Testing apps.myapp: TEST COMPLETE, 1 ok, 0 failed of 1 test cases > ========= > > > After the 3rd time or so (this happens randomly), I get: > > > ========= > $ ./tests > > Common Test starting (cwd is /Users/roberto/workspace/myapp) > > > =ERROR REPORT==== 22-Apr-2015::16:26:00 === > Error in process <0.42.0> on node 'myapp@REDACTED > ' with exit value: > {{badmatch,["ct_run","myapp@REDACTED","0","0","1","2015-04-22_16","25","26"]},[{ct_logs,'-sort_ct_runs/1-fun-0-',2,[{file,"ct_logs.erl"},{line,1912}]},{lists,sort,2,[{file,"lists.erl"},{line,967}]},{ct_logs,make_all_suites_index,1,[{file,"ct_logs... > ========= > > > If I delete the directory where the CT logs are stored I can re-run > the command, without issues. > > Any ideas? > > Best, > r. > > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From peppe@REDACTED Thu Apr 23 13:50:57 2015 From: peppe@REDACTED (Peter Andersson) Date: Thu, 23 Apr 2015 13:50:57 +0200 Subject: [erlang-bugs] Cannot run CT tests multiple times In-Reply-To: References: <5538CC16.50103@erlang.org> Message-ID: <5538DCA1.6070209@erlang.org> Hi Roberto, The bug was reported for 17.5 and fixed only a couple of weeks ago for OTP 18. It would be great if you could try it out and let me know if the fix solves your problem. Btw, if you *can* run your test on a short name node, try that also and see if it works. (You need to delete or move any previous ct_run-directories in logdir first though). Keep me posted. Best, Peter On 2015-04-23 13:28, Roberto Ostinelli wrote: > Hello Peter, > No I'm running the standard OTP 17.5. > > I've checked but could not find a previous report. I apologize if this > was reported previously. > > Best, > r. > > > On Thu, Apr 23, 2015 at 12:40 PM, Peter Andersson > wrote: > > Hi Roberto, > > This problem looks very much like one previously reported, about > CT not handling long node names correctly. There's a fix for it in > the master branch: 8a23259. Are you running on an updated branch? > > Best regards, > Peter > > Ericsson AB, Erlang/OTP > > > > On 2015-04-22 16:34, Roberto Ostinelli wrote: >> Dear list, >> When I run CT tests multiple times I encounter a bug. >> >> ======== >> erl -pa apps/*/ebin -pa deps/*/ebin \ >> -name myapp@REDACTED \ >> +K true \ >> +P 5000000 \ >> +Q 1000000 \ >> -env ERL_FULLSWEEP_AFTER 10 \ >> -config myapp \ >> -mnesia schema_location ram \ >> -noshell \ >> -eval 'ct_run:run_test([{dir, "apps/myapp/test"}, {logdir, >> "apps/myapp/logs"}]).' \ >> -s erlang halt >> ========= >> >> >> Running this the first 2/3 times will give: >> >> >> ========= >> Common Test starting (cwd is /Users/roberto/workspace/myapp) >> >> >> Common Test: Running make in test directories... >> >> CWD set to: >> "/Users/roberto/workspace/myapp/apps/myapp/logs/ct_run.myapp@REDACTED" >> >> >> TEST INFO: 1 test(s), 1 case(s) in 1 suite(s) >> >> Testing apps.myapp: Starting test, 1 test cases >> Testing apps.myapp: TEST COMPLETE, 1 ok, 0 failed of 1 test cases >> ========= >> >> >> After the 3rd time or so (this happens randomly), I get: >> >> >> ========= >> $ ./tests >> >> Common Test starting (cwd is /Users/roberto/workspace/myapp) >> >> >> =ERROR REPORT==== 22-Apr-2015::16:26:00 === >> Error in process <0.42.0> on node 'myapp@REDACTED >> ' with exit value: >> {{badmatch,["ct_run","myapp@REDACTED","0","0","1","2015-04-22_16","25","26"]},[{ct_logs,'-sort_ct_runs/1-fun-0-',2,[{file,"ct_logs.erl"},{line,1912}]},{lists,sort,2,[{file,"lists.erl"},{line,967}]},{ct_logs,make_all_suites_index,1,[{file,"ct_logs... >> ========= >> >> >> If I delete the directory where the CT logs are stored I can >> re-run the command, without issues. >> >> Any ideas? >> >> Best, >> r. >> >> >> >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Thu Apr 23 13:28:11 2015 From: roberto@REDACTED (Roberto Ostinelli) Date: Thu, 23 Apr 2015 13:28:11 +0200 Subject: [erlang-bugs] Cannot run CT tests multiple times In-Reply-To: <5538CC16.50103@erlang.org> References: <5538CC16.50103@erlang.org> Message-ID: Hello Peter, No I'm running the standard OTP 17.5. I've checked but could not find a previous report. I apologize if this was reported previously. Best, r. On Thu, Apr 23, 2015 at 12:40 PM, Peter Andersson wrote: > Hi Roberto, > > This problem looks very much like one previously reported, about CT not > handling long node names correctly. There's a fix for it in the master > branch: 8a23259. Are you running on an updated branch? > > Best regards, > Peter > > Ericsson AB, Erlang/OTP > > > > On 2015-04-22 16:34, Roberto Ostinelli wrote: > > Dear list, > When I run CT tests multiple times I encounter a bug. > > ======== > erl -pa apps/*/ebin -pa deps/*/ebin \ > -name myapp@REDACTED \ > +K true \ > +P 5000000 \ > +Q 1000000 \ > -env ERL_FULLSWEEP_AFTER 10 \ > -config myapp \ > -mnesia schema_location ram \ > -noshell \ > -eval 'ct_run:run_test([{dir, "apps/myapp/test"}, {logdir, > "apps/myapp/logs"}]).' \ > -s erlang halt > ========= > > > Running this the first 2/3 times will give: > > > ========= > Common Test starting (cwd is /Users/roberto/workspace/myapp) > > > Common Test: Running make in test directories... > > CWD set to: > "/Users/roberto/workspace/myapp/apps/myapp/logs/ct_run.myapp@REDACTED" > > > TEST INFO: 1 test(s), 1 case(s) in 1 suite(s) > > Testing apps.myapp: Starting test, 1 test cases > Testing apps.myapp: TEST COMPLETE, 1 ok, 0 failed of 1 test cases > ========= > > > After the 3rd time or so (this happens randomly), I get: > > > ========= > $ ./tests > > Common Test starting (cwd is /Users/roberto/workspace/myapp) > > > =ERROR REPORT==== 22-Apr-2015::16:26:00 === > Error in process <0.42.0> on node 'myapp@REDACTED' with exit value: > {{badmatch,["ct_run","myapp@REDACTED > ","0","0","1","2015-04-22_16","25","26"]},[{ct_logs,'-sort_ct_runs/1-fun-0-',2,[{file,"ct_logs.erl"},{line,1912}]},{lists,sort,2,[{file,"lists.erl"},{line,967}]},{ct_logs,make_all_suites_index,1,[{file,"ct_logs... > ========= > > > If I delete the directory where the CT logs are stored I can re-run the > command, without issues. > > Any ideas? > > Best, > r. > > > > > > _______________________________________________ > erlang-bugs mailing listerlang-bugs@REDACTED://erlang.org/mailman/listinfo/erlang-bugs > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Fri Apr 24 17:32:55 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 24 Apr 2015 17:32:55 +0200 Subject: [erlang-bugs] gcc 5.1 ubsan Message-ID: Just built yesterday's otp.git master with amd64 gcc-5.1, and here's the UBSan results. The previously reported int overflow with 4.9 are naturally also there, but the diagnostics have changed a little. Of course, this is just an excerpt, and the complete set of ubsan errors for, say, one invocation of erlc would be too much to post. If for some reason you don't have access to gcc-5.1, I've archived the full build log for reference. Ask me if you need it. ------ beam/erl_thr_progress.c:422:8: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' sys/common/erl_poll.c:391:23: runtime error: left shift of 1 by 63 places cannot be represented in type 'long int' common/ethr_mutex.c:3003:7: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' common/ethr_mutex.c:3055:10: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' common/ethr_mutex.c:3056:13: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' common/ethr_mutex.c:3021:11: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' common/ethr_mutex.c:3063:7: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' common/ethr_mutex.c:3064:13: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' common/ethr_mutex.c:2077:16: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' common/ethr_mutex.c:2109:10: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' beam/beam_load.c:5205:14: runtime error: left shift of 65535 by 16 places cannot be represented in type 'int' beam/external.c:3064:13: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' beam/erl_process.c:10912:20: runtime error: left shift of 268435455 by 4 places cannot be represented in type 'int' beam/erl_process.c:10916:23: runtime error: left shift of 268435455 by 4 places cannot be represented in type 'int' beam/erl_process.c:10749:33: runtime error: left shift of 268435455 by 4 places cannot be represented in type 'int' beam/erl_process.c:10782:39: runtime error: left shift of 268435455 by 4 places cannot be represented in type 'int' beam/erl_thr_progress.c:812:14: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' beam/erl_thr_progress.c:741:18: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' beam/erl_thr_progress.c:358:27: runtime error: left shift of 1 by 31 places cannot be represented in type 'in beam/erl_thr_progress.c:366:27: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' beam/erl_thr_progress.c:867:7: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' beam/beam_emu.c:5588:15: runtime error: member access within misaligned address 0x00000230676c for type 'struct StackTrace', which requires 8 byte alignment 0x00000230676c: note: pointer points here 22 72 91 25 00 00 00 00 00 00 00 00 00 00 [...] ^ sys/common/erl_check_io.c:1621:9: runtime error: left shift of 1 by 63 places cannot be represented in type 'long int' sys/common/erl_poll.c:2293:6: runtime error: left shift of 1 by 63 places cannot be represented in type 'long int' sys/common/erl_poll.c:2136:21: runtime error: left shift of 1 by 63 places cannot be represented in type 'long int' sys/common/erl_poll.c:2347:26: runtime error: left shift of 1 by 63 places cannot be represented in type 'long int' sys/common/erl_poll.c:2023:25: runtime error: left shift of 1 by 63 places cannot be represented in type 'long int' beam/erl_bits.c:164:19: runtime error: member access within misaligned address 0x000002306cbc for type 'struct ErlBinMatchState', which requires 8 byte alignment 0x000002306cbc: note: pointer points here d5 08 c2 01 c4 02 00 00 00 00 00 00 52 6c 30 [...] ^ beam/erl_bits.c:157:11: runtime error: member access within misaligned address 0x00000240095c for type 'struct ProcBin', which requires 8 byte alignment 0x00000240095c: note: pointer points here 74 00 00 00 24 01 00 00 09 00 00 00 2d 70 72 6f [...] ^ beam/beam_emu.c:6387:22: runtime error: member access within misaligned address 0x000002401a64 for type 'struct ErlFunThing', which requires 8 byte alignment 0x000002401a64: note: pointer points here d5 0a 40 02 00 00 00 00 00 00 00 00 00 00 00 00 [...] ^ beam/io.c:5942:6: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/bits/string3.h:53:10: runtime error: null pointer passed as argument 2, which is declared to never be null beam/erl_gc.c:2354:23: runtime error: member access within misaligned address 0x0000024013ec for type 'struct erl_off_heap_header', which requires 8 byte alignment 0x0000024013ec: note: pointer points here 03 02 00 00 d4 01 00 00 00 00 00 00 50 2e 49 0e [...] ^ beam/erl_thr_progress.c:763:18: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' beam/erl_thr_progress.c:779:13: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' beam/erl_thr_progress.c:816:25: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' beam/binary.c:97:20: runtime error: member access within misaligned address 0x00000240340c for type 'struct ProcBin', which requires 8 byte alignment 0x00000240340c: note: pointer points here 87 09 00 00 00 00 00 00 21 40 40 02 00 00 00 00 11 [...] ^ beam/erl_bif_op.c:256:10: runtime error: member access within misaligned address 0x00000240830c for type 'struct ErlFunThing', which requires 8 byte alignment 0x00000240830c: note: pointer points here f1 82 40 02 d4 01 00 00 0f 07 00 00 30 3a 65 0f 56 03 00 [...] ^ beam/external.c:3280:14: runtime error: left shift of 245 by 24 places cannot be represented in type 'int' beam/beam_emu.c:5654:13: runtime error: member access within misaligned address 0x00000241bafc for type 'struct StackTrace', which requires 8 byte alignment 0x00000241bafc: note: pointer points here e5 ba 41 02 88 05 00 00 50 07 00 00 fd ba 41 02 fb ff ff ff [...] ^ x86_64-unknown-linux-gnu/opt/smp/beam_cold.h:142:5: runtime error: member access within misaligned address 0x000002429b84 for type 'struct ErlBinMatchBuffer', which requires 8 byte alignment 0x000002429b84: note: pointer points here 00 00 00 00 fa 9a 42 02 00 00 00 00 b0 4e 4c 0f 56 03 00 [...] ^ From tuncer.ayaz@REDACTED Fri Apr 24 18:39:26 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 24 Apr 2015 18:39:26 +0200 Subject: [erlang-bugs] gcc 5.1 ubsan In-Reply-To: References: Message-ID: On Fri, Apr 24, 2015 at 5:32 PM, Tuncer Ayaz wrote: > Just built yesterday's otp.git master with amd64 gcc-5.1, and here's > the UBSan results. The previously reported int overflow with 4.9 are > naturally also there, but the diagnostics have changed a little. Forgot to say that I didn't check the ignored Valgrind warnings in otp.git. So best case scenario the new errors are already known and ignored. [snip] From tuncer.ayaz@REDACTED Fri Apr 24 22:35:22 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 24 Apr 2015 22:35:22 +0200 Subject: [erlang-bugs] Observer Crashdump Viewer bug? Message-ID: Can anyone else reproduce a responsive but blocked Observer gui following these steps? # install otp 18.0 from master # clone and build erlguten $ git clone https://github.com/richcarl/erlguten $ cd erlguten $ make $ ./erlguten test/test1.xml # start Observer use File->Examine Crash Dump to load the # erlguten crash dump $ erl 1> observer:start(). ok WARNING: Found unexpected tag:scheduler WARNING: Found unexpected tag:scheduler WARNING: Found unexpected line in general information: Calling Thread WARNING: Found unexpected line in ETS info: Chain Length Avg # now it stalls in the GUI at "Processing ets" This does not happen if you instead start crashdump_viewer:start/0. From kenji@REDACTED Sat Apr 25 02:59:09 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Sat, 25 Apr 2015 09:59:09 +0900 Subject: [erlang-bugs] ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE Message-ID: <20150425005909.GA36460@k2r.org> I've seen a massive numbers of error when running a common test on 18.0-rc1 with HiPE as: ERTS_FP_CHECK_INIT at 0x50e193: detected unhandled FPE at 0x4ad This didn't happen when HiPE is disabled (--disable-hipe). I have traced this in the source that this message is sent from erts_fp_check_init_error() in erts/emulator/sys/unix/sys_float.c, highly presumably from hipe_fclearerror_error() in erts/emulator/hipe/hipe_native_bif.c. The running environment is on FreeBSD amd64 10.1-STABLE #64 r281235, and the kerl compilation options: export CC=clang CXX=clang CFLAGS="-O3 -fstack-protector" LDFLAGS="-fstack-protector" MAKEFLAGS="-j8" KERL_CONFIGURE_OPTIONS="--disable-native-libs --enable-vm-probes --with-dynamic-trace=dtrace --with-ssl=/usr/local --with-javac --enable-hipe --enable-kernel-poll --with-wx-config=/usr/local/bin/wxgtk2u-2.8-config --without-odbc --enable-threads --enable-sctp --enable-smp-support --disable-silent-rules" You can check this out by: git clone https://github.com/jj1bdx/emprng/ cd emprng make tests Regards, Kenji Rikitake From kenji@REDACTED Sat Apr 25 03:13:04 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Sat, 25 Apr 2015 10:13:04 +0900 Subject: [erlang-bugs] A possibly-spurious warning message on 18.0-rc1 when enabling compile inline option Message-ID: <20150425011304.GA36564@k2r.org> A warning message, which does not make sense, is generated when compiling the following code on 18.0-rc1 (both on FreeBSD and OS X): erlc -Werror buftest.erl compile: warnings being treated as errors buftest.erl:15: a term is constructed, but never used This doesn't happen on 17.5, and this message is not generated when `-compile({inline, [loop/1]})` doesn't exist. buftest.erl source code: -module(buftest). -export([ loop/1 ]). -compile({inline, [loop/1]}). calc(H, H2) -> ok = io:format("H = ~p, H2 = ~p~n", [H, H2]), H2. loop({[H], RL}) -> NL = lists:reverse(RL), loop({[H|NL], []}); % <- this line generates the warning loop({L, RL}) -> [H|L2] = L, [H2|L3] = L2, NH2 = calc(H, H2), NL2 = [NH2|L3], NRL = [H|RL], {NL2, NRL}. From mikpelinux@REDACTED Sat Apr 25 12:57:42 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 25 Apr 2015 12:57:42 +0200 Subject: [erlang-bugs] ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE In-Reply-To: <20150425005909.GA36460@k2r.org> References: <20150425005909.GA36460@k2r.org> Message-ID: <21819.29478.231394.191336@gargle.gargle.HOWL> Kenji Rikitake writes: > I've seen a massive numbers of error when running a common test on > 18.0-rc1 with HiPE as: > > ERTS_FP_CHECK_INIT at 0x50e193: detected unhandled FPE at 0x4ad > > This didn't happen when HiPE is disabled (--disable-hipe). > > I have traced this in the source that this message is sent from > erts_fp_check_init_error() in erts/emulator/sys/unix/sys_float.c, > highly presumably from > hipe_fclearerror_error() in erts/emulator/hipe/hipe_native_bif.c. > > The running environment is on FreeBSD amd64 10.1-STABLE #64 r281235, > and the kerl compilation options: > > export CC=clang CXX=clang CFLAGS="-O3 -fstack-protector" LDFLAGS="-fstack-protector" MAKEFLAGS="-j8" > KERL_CONFIGURE_OPTIONS="--disable-native-libs --enable-vm-probes --with-dynamic-trace=dtrace --with-ssl=/usr/local --with-javac --enable-hipe --enable-kernel-poll --with-wx-config=/usr/local/bin/wxgtk2u-2.8-config --without-odbc --enable-threads --enable-sctp --enable-smp-support --disable-silent-rules" > > You can check this out by: > > git clone https://github.com/jj1bdx/emprng/ > cd emprng > make tests I'm not able to reproduce any unhandled FPE:s on Linux/x86_64 with 18.0-rc1 configured with --enable-hipe --enable-fp-exceptions. I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with --disable-hipe --enable-fp-exceptions and then repeat your tests? It would also be helpful if you attached a debugger to beam.smp, put a breakpoint in erts_fp_check_init_error(), and took a backtrace from the thread when that breakpoint it hit. (You can also try to map the PC value 0x50e193 reported above to the corresponding C function via beam.smp's symbol table.) Finally, I find the 0x4ad address suspiciously low. Is that address range even mapped in your beam.smp process? I don't know how to check that on FreeBSD, but on Linux I would look in /proc/${pid}/maps. /Mikael From kenji@REDACTED Sat Apr 25 15:19:34 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Sat, 25 Apr 2015 22:19:34 +0900 Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE In-Reply-To: <21819.29478.231394.191336@gargle.gargle.HOWL> References: <20150425005909.GA36460@k2r.org> <21819.29478.231394.191336@gargle.gargle.HOWL> Message-ID: <20150425131934.GA47376@k2r.org> Mikael: > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > --disable-hipe --enable-fp-exceptions and then repeat your tests? Executing emprng tests on 18.0 built with the above options generated the following error for many times: ERTS_FP_CHECK_INIT at 0x502ef3: detected unhandled FPE at 0x4a3 So this is not a HiPE but highly suspected to be a FreeBSD FPE issue. I'll try the further tests later. Kenji Rikitake ++> Mikael Pettersson [2015-04-25 12:57:42 +0200]: > Kenji Rikitake writes: > > I've seen a massive numbers of error when running a common test on > > 18.0-rc1 with HiPE as: > > > > ERTS_FP_CHECK_INIT at 0x50e193: detected unhandled FPE at 0x4ad > > > > This didn't happen when HiPE is disabled (--disable-hipe). > > > > I have traced this in the source that this message is sent from > > erts_fp_check_init_error() in erts/emulator/sys/unix/sys_float.c, > > highly presumably from > > hipe_fclearerror_error() in erts/emulator/hipe/hipe_native_bif.c. > > > > The running environment is on FreeBSD amd64 10.1-STABLE #64 r281235, > > and the kerl compilation options: > > > > export CC=clang CXX=clang CFLAGS="-O3 -fstack-protector" LDFLAGS="-fstack-protector" MAKEFLAGS="-j8" > > KERL_CONFIGURE_OPTIONS="--disable-native-libs --enable-vm-probes --with-dynamic-trace=dtrace --with-ssl=/usr/local --with-javac --enable-hipe --enable-kernel-poll --with-wx-config=/usr/local/bin/wxgtk2u-2.8-config --without-odbc --enable-threads --enable-sctp --enable-smp-support --disable-silent-rules" > > > > You can check this out by: > > > > git clone https://github.com/jj1bdx/emprng/ > > cd emprng > > make tests > > I'm not able to reproduce any unhandled FPE:s on Linux/x86_64 with 18.0-rc1 > configured with --enable-hipe --enable-fp-exceptions. > > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > --disable-hipe --enable-fp-exceptions and then repeat your tests? > > It would also be helpful if you attached a debugger to beam.smp, put a > breakpoint in erts_fp_check_init_error(), and took a backtrace from the > thread when that breakpoint it hit. (You can also try to map the PC > value 0x50e193 reported above to the corresponding C function via beam.smp's > symbol table.) > > Finally, I find the 0x4ad address suspiciously low. Is that address range > even mapped in your beam.smp process? I don't know how to check that on > FreeBSD, but on Linux I would look in /proc/${pid}/maps. > > /Mikael From kenji@REDACTED Sun Apr 26 03:25:46 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Sun, 26 Apr 2015 10:25:46 +0900 Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE In-Reply-To: <20150425131934.GA47376@k2r.org> References: <20150425005909.GA36460@k2r.org> <21819.29478.231394.191336@gargle.gargle.HOWL> <20150425131934.GA47376@k2r.org> Message-ID: <20150426012546.GA41591@k2r.org> Mikael: So far I can only reach to the following analysis: I suspect the FPE was raised when ERTS_FP_CHECK_INIT() was called from erts_mixed_plus() in erts/emulator/beam/erl_arith.c. (My experience with gdb especially with multi-threaded code is rather limited.) The command called: erl -pa ebin -pa test -s rand_SUITE test The error message repeated (and beam.smp crashed): ERTS_FP_CHECK_INIT at 0x502ef3: detected unhandled FPE at 0x4a3 gdb result with beam.smp.core: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `beam.smp'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/lib/libelf.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000801b7fb8a in thr_kill () from /lib/libc.so.7 [New Thread 80240b000 (LWP 101044/beam.smp)] [New Thread 80240ac00 (LWP 101042/beam.smp)] [New Thread 80240a800 (LWP 101040/beam.smp)] [New Thread 80240a400 (LWP 101036/beam.smp)] [New Thread 80240a000 (LWP 100892/beam.smp)] [New Thread 802409c00 (LWP 100803/beam.smp)] [New Thread 802409800 (LWP 100651/beam.smp)] [New Thread 802409400 (LWP 100522/beam.smp)] [New Thread 802409000 (LWP 100507/beam.smp)] [New Thread 802408c00 (LWP 100459/beam.smp)] [New Thread 802408800 (LWP 100415/beam.smp)] [New Thread 802408400 (LWP 100309/beam.smp)] [New Thread 802408000 (LWP 100268/beam.smp)] [New Thread 802407c00 (LWP 100254/beam.smp)] [New Thread 802407800 (LWP 100253/beam.smp)] [New Thread 802407400 (LWP 100248/beam.smp)] [New Thread 802407000 (LWP 100245/beam.smp)] [New Thread 802406800 (LWP 100238/beam.smp)] [New Thread 802406400 (LWP 100142/beam.smp)] (gdb) bt #0 0x0000000801b7fb8a in thr_kill () from /lib/libc.so.7 #1 0x0000000801b7faf6 in raise () from /lib/libc.so.7 #2 0x0000000801b7e2e9 in abort () from /lib/libc.so.7 #3 0x000000000049e7d7 in erl_exit_vv () #4 0x000000000049c813 in erl_exit () #5 0x000000000063c49b in erts_fp_check_init_error () #6 0x0000000000502ef3 in erts_gc_mixed_plus () #7 0x00000000004615e7 in process_main () #8 0x00000000004ece11 in sched_thread_func () #9 0x000000000069f6ac in thr_wrapper () #10 0x00000008016196d5 in pthread_create () from /lib/libthr.so.3 #11 0x0000000000000000 in ?? () (gdb) info symbol 0x502ef3 erts_gc_mixed_plus + 547 in section .text (gdb) q ++> Kenji Rikitake [2015-04-25 22:19:34 +0900]: > Date: Sat, 25 Apr 2015 22:19:34 +0900 > From: Kenji Rikitake > To: Mikael Pettersson > Cc: erlang-bugs@REDACTED > Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: > ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD > 10.1-STABLE > > Mikael: > > > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > > --disable-hipe --enable-fp-exceptions and then repeat your tests? > > Executing emprng tests on 18.0 built with the above options generated > the following error for many times: > > ERTS_FP_CHECK_INIT at 0x502ef3: detected unhandled FPE at 0x4a3 > > So this is not a HiPE but highly suspected to be a FreeBSD FPE issue. > > I'll try the further tests later. > > Kenji Rikitake > > ++> Mikael Pettersson [2015-04-25 12:57:42 +0200]: > > Kenji Rikitake writes: > > > I've seen a massive numbers of error when running a common test on > > > 18.0-rc1 with HiPE as: > > > > > > ERTS_FP_CHECK_INIT at 0x50e193: detected unhandled FPE at 0x4ad > > > > > > This didn't happen when HiPE is disabled (--disable-hipe). > > > > > > I have traced this in the source that this message is sent from > > > erts_fp_check_init_error() in erts/emulator/sys/unix/sys_float.c, > > > highly presumably from > > > hipe_fclearerror_error() in erts/emulator/hipe/hipe_native_bif.c. > > > > > > The running environment is on FreeBSD amd64 10.1-STABLE #64 r281235, > > > and the kerl compilation options: > > > > > > export CC=clang CXX=clang CFLAGS="-O3 -fstack-protector" LDFLAGS="-fstack-protector" MAKEFLAGS="-j8" > > > KERL_CONFIGURE_OPTIONS="--disable-native-libs --enable-vm-probes --with-dynamic-trace=dtrace --with-ssl=/usr/local --with-javac --enable-hipe --enable-kernel-poll --with-wx-config=/usr/local/bin/wxgtk2u-2.8-config --without-odbc --enable-threads --enable-sctp --enable-smp-support --disable-silent-rules" > > > > > > You can check this out by: > > > > > > git clone https://github.com/jj1bdx/emprng/ > > > cd emprng > > > make tests > > > > I'm not able to reproduce any unhandled FPE:s on Linux/x86_64 with 18.0-rc1 > > configured with --enable-hipe --enable-fp-exceptions. > > > > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > > --disable-hipe --enable-fp-exceptions and then repeat your tests? > > > > It would also be helpful if you attached a debugger to beam.smp, put a > > breakpoint in erts_fp_check_init_error(), and took a backtrace from the > > thread when that breakpoint it hit. (You can also try to map the PC > > value 0x50e193 reported above to the corresponding C function via beam.smp's > > symbol table.) > > > > Finally, I find the 0x4ad address suspiciously low. Is that address range > > even mapped in your beam.smp process? I don't know how to check that on > > FreeBSD, but on Linux I would look in /proc/${pid}/maps. > > > > /Mikael > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From bjorn@REDACTED Sun Apr 26 11:39:20 2015 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sun, 26 Apr 2015 11:39:20 +0200 Subject: [erlang-bugs] A possibly-spurious warning message on 18.0-rc1 when enabling compile inline option In-Reply-To: <20150425011304.GA36564@k2r.org> References: <20150425011304.GA36564@k2r.org> Message-ID: On Sat, Apr 25, 2015 at 3:13 AM, Kenji Rikitake wrote: > A warning message, which does not make sense, is generated when > compiling the following code on 18.0-rc1 (both on FreeBSD and OS X): > > erlc -Werror buftest.erl > compile: warnings being treated as errors > buftest.erl:15: a term is constructed, but never used > I have a correction for this spurious warning. It will probably be merged to master next week. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From mikpelinux@REDACTED Sun Apr 26 12:19:47 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 26 Apr 2015 12:19:47 +0200 Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE In-Reply-To: <20150426012546.GA41591@k2r.org> References: <20150425005909.GA36460@k2r.org> <21819.29478.231394.191336@gargle.gargle.HOWL> <20150425131934.GA47376@k2r.org> <20150426012546.GA41591@k2r.org> Message-ID: <21820.48067.941646.266557@gargle.gargle.HOWL> Kenji Rikitake writes: > Mikael: > > So far I can only reach to the following analysis: > > I suspect the FPE was raised when > ERTS_FP_CHECK_INIT() was called from > erts_mixed_plus() in > erts/emulator/beam/erl_arith.c. > > (My experience with gdb especially with multi-threaded code is > rather limited.) > > The command called: > > erl -pa ebin -pa test -s rand_SUITE test > > The error message repeated (and beam.smp crashed): > > ERTS_FP_CHECK_INIT at 0x502ef3: detected unhandled FPE at 0x4a3 > > gdb result with beam.smp.core: > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... > Core was generated by `beam.smp'. > Program terminated with signal 6, Aborted. > Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. > Loaded symbols for /lib/libutil.so.9 > Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /usr/lib/libelf.so.1...(no debugging symbols found)...done. > Loaded symbols for /usr/lib/libelf.so.1 > Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. > Loaded symbols for /lib/libncurses.so.8 > Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. > Loaded symbols for /lib/libz.so.6 > Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. > Loaded symbols for /lib/libthr.so.3 > Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. > Loaded symbols for /usr/lib/librt.so.1 > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x0000000801b7fb8a in thr_kill () from /lib/libc.so.7 > [New Thread 80240b000 (LWP 101044/beam.smp)] > [New Thread 80240ac00 (LWP 101042/beam.smp)] > [New Thread 80240a800 (LWP 101040/beam.smp)] > [New Thread 80240a400 (LWP 101036/beam.smp)] > [New Thread 80240a000 (LWP 100892/beam.smp)] > [New Thread 802409c00 (LWP 100803/beam.smp)] > [New Thread 802409800 (LWP 100651/beam.smp)] > [New Thread 802409400 (LWP 100522/beam.smp)] > [New Thread 802409000 (LWP 100507/beam.smp)] > [New Thread 802408c00 (LWP 100459/beam.smp)] > [New Thread 802408800 (LWP 100415/beam.smp)] > [New Thread 802408400 (LWP 100309/beam.smp)] > [New Thread 802408000 (LWP 100268/beam.smp)] > [New Thread 802407c00 (LWP 100254/beam.smp)] > [New Thread 802407800 (LWP 100253/beam.smp)] > [New Thread 802407400 (LWP 100248/beam.smp)] > [New Thread 802407000 (LWP 100245/beam.smp)] > [New Thread 802406800 (LWP 100238/beam.smp)] > [New Thread 802406400 (LWP 100142/beam.smp)] > (gdb) bt > #0 0x0000000801b7fb8a in thr_kill () from /lib/libc.so.7 > #1 0x0000000801b7faf6 in raise () from /lib/libc.so.7 > #2 0x0000000801b7e2e9 in abort () from /lib/libc.so.7 > #3 0x000000000049e7d7 in erl_exit_vv () > #4 0x000000000049c813 in erl_exit () > #5 0x000000000063c49b in erts_fp_check_init_error () > #6 0x0000000000502ef3 in erts_gc_mixed_plus () > #7 0x00000000004615e7 in process_main () > #8 0x00000000004ece11 in sched_thread_func () > #9 0x000000000069f6ac in thr_wrapper () > #10 0x00000008016196d5 in pthread_create () from /lib/libthr.so.3 > #11 0x0000000000000000 in ?? () > (gdb) info symbol 0x502ef3 > erts_gc_mixed_plus + 547 in section .text > (gdb) q Ok, so this is the ERTS_FP_CHECK_INIT() at the start of erts_gc_mixed_plus() which detects a pending FPE, which is not allowed at this point. There are really only three reasons why this might trigger: 1. We got an FP exception outside of checked code (between ERTS_FP_CHECK_INIT() and ERTS_FP_ERROR()). 2. A libc or libm function called matherr() outside of checked code. 3. A process' fp_exception field is uninitialized or clobbered. Please try the attached debugging patch for 18-rc1. It enables logging of FP exceptions and matherr(), which should tell us more about what's really going on. I'm still bothered about the suspiciously low PC address (0x4a3) reported. Can you check if that actually corresponds to an address in beam.smp or one of its dynamically linked libraries? /Mikael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: to-kenji URL: -------------- next part -------------- > > ++> Kenji Rikitake [2015-04-25 22:19:34 +0900]: > > Date: Sat, 25 Apr 2015 22:19:34 +0900 > > From: Kenji Rikitake > > To: Mikael Pettersson > > Cc: erlang-bugs@REDACTED > > Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: > > ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD > > 10.1-STABLE > > > > Mikael: > > > > > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > > > --disable-hipe --enable-fp-exceptions and then repeat your tests? > > > > Executing emprng tests on 18.0 built with the above options generated > > the following error for many times: > > > > ERTS_FP_CHECK_INIT at 0x502ef3: detected unhandled FPE at 0x4a3 > > > > So this is not a HiPE but highly suspected to be a FreeBSD FPE issue. > > > > I'll try the further tests later. > > > > Kenji Rikitake > > > > ++> Mikael Pettersson [2015-04-25 12:57:42 +0200]: > > > Kenji Rikitake writes: > > > > I've seen a massive numbers of error when running a common test on > > > > 18.0-rc1 with HiPE as: > > > > > > > > ERTS_FP_CHECK_INIT at 0x50e193: detected unhandled FPE at 0x4ad > > > > > > > > This didn't happen when HiPE is disabled (--disable-hipe). > > > > > > > > I have traced this in the source that this message is sent from > > > > erts_fp_check_init_error() in erts/emulator/sys/unix/sys_float.c, > > > > highly presumably from > > > > hipe_fclearerror_error() in erts/emulator/hipe/hipe_native_bif.c. > > > > > > > > The running environment is on FreeBSD amd64 10.1-STABLE #64 r281235, > > > > and the kerl compilation options: > > > > > > > > export CC=clang CXX=clang CFLAGS="-O3 -fstack-protector" LDFLAGS="-fstack-protector" MAKEFLAGS="-j8" > > > > KERL_CONFIGURE_OPTIONS="--disable-native-libs --enable-vm-probes --with-dynamic-trace=dtrace --with-ssl=/usr/local --with-javac --enable-hipe --enable-kernel-poll --with-wx-config=/usr/local/bin/wxgtk2u-2.8-config --without-odbc --enable-threads --enable-sctp --enable-smp-support --disable-silent-rules" > > > > > > > > You can check this out by: > > > > > > > > git clone https://github.com/jj1bdx/emprng/ > > > > cd emprng > > > > make tests > > > > > > I'm not able to reproduce any unhandled FPE:s on Linux/x86_64 with 18.0-rc1 > > > configured with --enable-hipe --enable-fp-exceptions. > > > > > > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > > > --disable-hipe --enable-fp-exceptions and then repeat your tests? > > > > > > It would also be helpful if you attached a debugger to beam.smp, put a > > > breakpoint in erts_fp_check_init_error(), and took a backtrace from the > > > thread when that breakpoint it hit. (You can also try to map the PC > > > value 0x50e193 reported above to the corresponding C function via beam.smp's > > > symbol table.) > > > > > > Finally, I find the 0x4ad address suspiciously low. Is that address range > > > even mapped in your beam.smp process? I don't know how to check that on > > > FreeBSD, but on Linux I would look in /proc/${pid}/maps. > > > > > > /Mikael > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs -- From essen@REDACTED Sun Apr 26 14:30:03 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 26 Apr 2015 15:30:03 +0300 Subject: [erlang-bugs] proc_lib man page unclear Message-ID: <553CDA4B.3020709@ninenines.eu> I am not sure by what is meant in the proc_lib man page: Using the spawn option monitor is currently not allowed, but will cause the function to fail with reason badarg. If the option is not allowed then surely one would expect it to fail with badarg? Why "but"? -- Lo?c Hoguin http://ninenines.eu From tuncer.ayaz@REDACTED Sun Apr 26 18:10:47 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 26 Apr 2015 18:10:47 +0200 Subject: [erlang-bugs] proc_lib man page unclear In-Reply-To: <553CDA4B.3020709@ninenines.eu> References: <553CDA4B.3020709@ninenines.eu> Message-ID: On Sun, Apr 26, 2015 at 2:30 PM, Loic Hoguin wrote: > I am not sure by what is meant in the proc_lib man page: > > Using the spawn option monitor is currently not allowed, but will cause the > function to fail with reason badarg. > > If the option is not allowed then surely one would expect it to fail with > badarg? Why "but"? Perhaps it was meant to say "and", or it's missing something like "instead" at the end. From carlsson.richard@REDACTED Sun Apr 26 20:10:46 2015 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sun, 26 Apr 2015 20:10:46 +0200 Subject: [erlang-bugs] Suicide by module_info Message-ID: Here's a fun one! Erlang/OTP 18 [RELEASE CANDIDATE 1] [erts-7.0] [source-7ff8f81] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.0 (abort with ^G) 1> c(foo). {ok,foo} 2> erlang:get_module_info(foo). [{module,foo}, ...] 3> code:delete(foo). true 4> erlang:get_module_info(foo). Segmentation fault (core dumped) https://github.com/erlang/otp/pull/696 /Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Sun Apr 26 22:19:22 2015 From: vinoski@REDACTED (Steve Vinoski) Date: Sun, 26 Apr 2015 16:19:22 -0400 Subject: [erlang-bugs] Suicide by module_info In-Reply-To: References: Message-ID: On Sun, Apr 26, 2015 at 2:10 PM, Richard Carlsson < carlsson.richard@REDACTED> wrote: > Here's a fun one! > > Erlang/OTP 18 [RELEASE CANDIDATE 1] [erts-7.0] [source-7ff8f81] [64-bit] > [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V7.0 (abort with ^G) > 1> c(foo). > {ok,foo} > 2> erlang:get_module_info(foo). > [{module,foo}, > ...] > 3> code:delete(foo). > true > 4> erlang:get_module_info(foo). > Segmentation fault (core dumped) > Interestingly, the segv occurs as far back as R12B-5, which is the oldest release I have handy. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Sun Apr 26 22:40:29 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 26 Apr 2015 22:40:29 +0200 Subject: [erlang-bugs] Suicide by module_info In-Reply-To: References: Message-ID: On Sun, Apr 26, 2015 at 10:19 PM, Steve Vinoski wrote: > > > On Sun, Apr 26, 2015 at 2:10 PM, Richard Carlsson > wrote: > > > > Here's a fun one! > > > > Erlang/OTP 18 [RELEASE CANDIDATE 1] [erts-7.0] [source-7ff8f81] > > [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] > > > > Eshell V7.0 (abort with ^G) > > 1> c(foo). > > {ok,foo} > > 2> erlang:get_module_info(foo). > > [{module,foo}, > > ...] > > 3> code:delete(foo). > > true > > 4> erlang:get_module_info(foo). > > Segmentation fault (core dumped) > > > Interestingly, the segv occurs as far back as R12B-5, which is the > oldest release I have handy. Could it be that erlang:get_module_info/1 is undocumented and therefore underused? I don't think I ever called get_module_info/1 and I suspect everyone just uses foo:module_info/0,1, which interestingly works after a successful code:delete(foo) call. The crash is a bug, but this might explain how it went unnoticed. Do you think the following is the right behavior? > c(foo). {ok,foo} > code:delete(foo). true > foo:module_info(). [{module,foo}, ...] I mean, I would expect fully qualified calls to foo:module_infi/0 to fail once code:delete(foo) succeeds. Or is this how it's supposed to behave? From carlsson.richard@REDACTED Sun Apr 26 22:43:58 2015 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sun, 26 Apr 2015 22:43:58 +0200 Subject: [erlang-bugs] Suicide by module_info In-Reply-To: References: Message-ID: Yes, I think it goes back to when erlang:module_info() was added (which I was also involved in). Before that, the only way to get to the module info was to call the autogenerated function in the module itself, foo:module_info(), and then the code for the module obviously had to exist (or would be loaded on the fly). /Richard On Sun, Apr 26, 2015 at 10:19 PM, Steve Vinoski wrote: > > > On Sun, Apr 26, 2015 at 2:10 PM, Richard Carlsson < > carlsson.richard@REDACTED> wrote: > >> Here's a fun one! >> >> Erlang/OTP 18 [RELEASE CANDIDATE 1] [erts-7.0] [source-7ff8f81] [64-bit] >> [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V7.0 (abort with ^G) >> 1> c(foo). >> {ok,foo} >> 2> erlang:get_module_info(foo). >> [{module,foo}, >> ...] >> 3> code:delete(foo). >> true >> 4> erlang:get_module_info(foo). >> Segmentation fault (core dumped) >> > > Interestingly, the segv occurs as far back as R12B-5, which is the oldest > release I have handy. > > --steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Sun Apr 26 22:46:54 2015 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sun, 26 Apr 2015 22:46:54 +0200 Subject: [erlang-bugs] Suicide by module_info In-Reply-To: References: Message-ID: On Sun, Apr 26, 2015 at 10:40 PM, Tuncer Ayaz wrote: > Could it be that erlang:get_module_info/1 is undocumented and > therefore underused? I don't think I ever called get_module_info/1 and > I suspect everyone just uses foo:module_info/0,1, which interestingly > works after a successful code:delete(foo) call. > > The crash is a bug, but this might explain how it went unnoticed. > > Do you think the following is the right behavior? > > > c(foo). > {ok,foo} > > code:delete(foo). > true > > foo:module_info(). > [{module,foo}, > ...] > > I mean, I would expect fully qualified calls to foo:module_infi/0 to > fail once code:delete(foo) succeeds. Or is this how it's supposed to > behave? > That's how things are supposed to work. If the foo is deleted when you call foo:module_info(), it will simply get reloaded and then called, just as if foo had not been previously loaded at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Sun Apr 26 22:53:58 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 26 Apr 2015 22:53:58 +0200 Subject: [erlang-bugs] Suicide by module_info In-Reply-To: References: Message-ID: On Sun, Apr 26, 2015 at 10:46 PM, Richard Carlsson wrote: > On Sun, Apr 26, 2015 at 10:40 PM, Tuncer Ayaz wrote: > > > > Could it be that erlang:get_module_info/1 is undocumented and > > therefore underused? I don't think I ever called get_module_info/1 > > and I suspect everyone just uses foo:module_info/0,1, which > > interestingly works after a successful code:delete(foo) call. > > > > The crash is a bug, but this might explain how it went unnoticed. > > > > Do you think the following is the right behavior? > > > > > c(foo). > > {ok,foo} > > > code:delete(foo). > > true > > > foo:module_info(). > > [{module,foo}, > > ...] > > > > I mean, I would expect fully qualified calls to foo:module_infi/0 to > > fail once code:delete(foo) succeeds. Or is this how it's supposed to > > behave? > > > That's how things are supposed to work. If the foo is deleted when > you call foo:module_info(), it will simply get reloaded and then > called, just as if foo had not been previously loaded at all. Of course error_handler:undefined_function/3 takes care of that. Stupid thinko on my part to be blamed on posting late at night, making me look like someone who never tried to write a module named error_handler just to notice the interesting effects :). From kenji@REDACTED Mon Apr 27 03:29:33 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Mon, 27 Apr 2015 10:29:33 +0900 Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE In-Reply-To: <21820.48067.941646.266557@gargle.gargle.HOWL> References: <20150425005909.GA36460@k2r.org> <21819.29478.231394.191336@gargle.gargle.HOWL> <20150425131934.GA47376@k2r.org> <20150426012546.GA41591@k2r.org> <21820.48067.941646.266557@gargle.gargle.HOWL> Message-ID: <20150427012933.GA4523@k2r.org> Mikael: The patch is applied and tested. The patch is at: https://github.com/jj1bdx/otp/commit/71bfef44f99a01a2b3679bebbc41df1716ea00e5 And it's available as https://github.com/jj1bdx/otp/commits/18.0-FPE-patch (18.0-rc1 plus the patch). The following is a brief result of the test. In each case the error message was repeated 100000 to 150000 times (depending on the BEAM code) during the execution of test "interval_int" in rand_SUITE.erl, at https://github.com/jj1bdx/emprng/blob/38142e3d0c02b979723082e610f3850d1814afe8/test/rand_SUITE.erl#L179 In the build (with CFLAGS = "-O3 -fstack-protector"): Note: the value of 0x4a28a7 and 0x4a2 in the following abbreviated log are common in the first three digits. I also observed this on another build with difference address values. So my guess is that 0x4a2 is a truncated value of 0x4a28a7. fpe_sig_action: FPE at 0x4a28a7 ERTS_FP_CHECK_INIT at 0x502153: detected unhandled FPE at 0x4a2 in erts/emulator/beam/erl_arith.c (gdb) info symbol 0x502153 erts_gc_mixed_plus + 547 in section .text in erts/emulator/beam/erl_bif_guard.c (gdb) info symbol 0x4a28a7 erts_gc_trunc_1 + 407 in section .text In another debug build (with CFLAGS = "-g -fstack-protector", without -O3): Note: see the similarity of values 0x4cc0b5 and 0x4cc. fpe_sig_action: FPE at 0x4cc0b5 ERTS_FP_CHECK_INIT at 0x571e60: detected unhandled FPE at 0x4cc in erts/emulator/sys/unix/erl_unix_sys.h (gdb) info symbol 0x571e60 __ERTS_FP_CHECK_INIT + 64 in section .text in erts/emulator/beam/erl_bif_guard.c (gdb) info symbol 0x4cc0b5 gc_double_to_integer + 501 in section .text I still cannot conclude what is the real reason, but so far this is all I've got right now. Kenji Rikitake ++> Mikael Pettersson [2015-04-26 12:19:47 +0200]: > Date: Sun, 26 Apr 2015 12:19:47 +0200 > From: Mikael Pettersson > To: Kenji Rikitake > Cc: Mikael Pettersson , erlang-bugs@REDACTED > Subject: Re: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: > ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD > 10.1-STABLE > > Kenji Rikitake writes: > > Mikael: > > > > So far I can only reach to the following analysis: > > > > I suspect the FPE was raised when > > ERTS_FP_CHECK_INIT() was called from > > erts_mixed_plus() in > > erts/emulator/beam/erl_arith.c. > > > > (My experience with gdb especially with multi-threaded code is > > rather limited.) > > > > The command called: > > > > erl -pa ebin -pa test -s rand_SUITE test > > > > The error message repeated (and beam.smp crashed): > > > > ERTS_FP_CHECK_INIT at 0x502ef3: detected unhandled FPE at 0x4a3 > > > > gdb result with beam.smp.core: > > > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... > > Core was generated by `beam.smp'. > > Program terminated with signal 6, Aborted. > > Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. > > Loaded symbols for /lib/libutil.so.9 > > Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. > > Loaded symbols for /lib/libm.so.5 > > Reading symbols from /usr/lib/libelf.so.1...(no debugging symbols found)...done. > > Loaded symbols for /usr/lib/libelf.so.1 > > Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. > > Loaded symbols for /lib/libncurses.so.8 > > Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. > > Loaded symbols for /lib/libz.so.6 > > Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. > > Loaded symbols for /lib/libthr.so.3 > > Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. > > Loaded symbols for /usr/lib/librt.so.1 > > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > > Loaded symbols for /lib/libc.so.7 > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. > > Loaded symbols for /libexec/ld-elf.so.1 > > #0 0x0000000801b7fb8a in thr_kill () from /lib/libc.so.7 > > [New Thread 80240b000 (LWP 101044/beam.smp)] > > [New Thread 80240ac00 (LWP 101042/beam.smp)] > > [New Thread 80240a800 (LWP 101040/beam.smp)] > > [New Thread 80240a400 (LWP 101036/beam.smp)] > > [New Thread 80240a000 (LWP 100892/beam.smp)] > > [New Thread 802409c00 (LWP 100803/beam.smp)] > > [New Thread 802409800 (LWP 100651/beam.smp)] > > [New Thread 802409400 (LWP 100522/beam.smp)] > > [New Thread 802409000 (LWP 100507/beam.smp)] > > [New Thread 802408c00 (LWP 100459/beam.smp)] > > [New Thread 802408800 (LWP 100415/beam.smp)] > > [New Thread 802408400 (LWP 100309/beam.smp)] > > [New Thread 802408000 (LWP 100268/beam.smp)] > > [New Thread 802407c00 (LWP 100254/beam.smp)] > > [New Thread 802407800 (LWP 100253/beam.smp)] > > [New Thread 802407400 (LWP 100248/beam.smp)] > > [New Thread 802407000 (LWP 100245/beam.smp)] > > [New Thread 802406800 (LWP 100238/beam.smp)] > > [New Thread 802406400 (LWP 100142/beam.smp)] > > (gdb) bt > > #0 0x0000000801b7fb8a in thr_kill () from /lib/libc.so.7 > > #1 0x0000000801b7faf6 in raise () from /lib/libc.so.7 > > #2 0x0000000801b7e2e9 in abort () from /lib/libc.so.7 > > #3 0x000000000049e7d7 in erl_exit_vv () > > #4 0x000000000049c813 in erl_exit () > > #5 0x000000000063c49b in erts_fp_check_init_error () > > #6 0x0000000000502ef3 in erts_gc_mixed_plus () > > #7 0x00000000004615e7 in process_main () > > #8 0x00000000004ece11 in sched_thread_func () > > #9 0x000000000069f6ac in thr_wrapper () > > #10 0x00000008016196d5 in pthread_create () from /lib/libthr.so.3 > > #11 0x0000000000000000 in ?? () > > (gdb) info symbol 0x502ef3 > > erts_gc_mixed_plus + 547 in section .text > > (gdb) q > > Ok, so this is the ERTS_FP_CHECK_INIT() at the start of erts_gc_mixed_plus() > which detects a pending FPE, which is not allowed at this point. > > There are really only three reasons why this might trigger: > 1. We got an FP exception outside of checked code (between > ERTS_FP_CHECK_INIT() and ERTS_FP_ERROR()). > 2. A libc or libm function called matherr() outside of checked code. > 3. A process' fp_exception field is uninitialized or clobbered. > > Please try the attached debugging patch for 18-rc1. It enables > logging of FP exceptions and matherr(), which should tell us more > about what's really going on. > > I'm still bothered about the suspiciously low PC address (0x4a3) > reported. Can you check if that actually corresponds to an address > in beam.smp or one of its dynamically linked libraries? > > /Mikael > > diff --git a/erts/emulator/sys/unix/sys_float.c b/erts/emulator/sys/unix/sys_float.c > index 2ffa649..d35bf4b 100644 > --- a/erts/emulator/sys/unix/sys_float.c > +++ b/erts/emulator/sys/unix/sys_float.c > @@ -638,7 +638,7 @@ static void fpe_sig_action(int sig, siginfo_t *si, void *puc) > fpstate->mxcsr = 0x1F80; > fpstate->sw &= ~0xFF; > #endif > -#if 0 > +#if 1 > { > char buf[64]; > snprintf(buf, sizeof buf, "%s: FPE at %p\r\n", __FUNCTION__, (void*)pc); > @@ -839,6 +839,12 @@ matherr(struct exception *exc) > { > #if !defined(NO_FPE_SIGNALS) > volatile unsigned long *fpexnp = erts_get_current_fp_exception(); > +#if 1 > + char buf[128]; > + snprintf(buf, sizeof buf, "sys_float.c:matherr() type %d from %s at %p\r\n", > + exc->type, exc->name, (void*)__builtin_return_address(0)); > + write(2, buf, strlen(buf)); > +#endif > if (fpexnp != NULL) > *fpexnp = (unsigned long)__builtin_return_address(0); > #endif > > > > > ++> Kenji Rikitake [2015-04-25 22:19:34 +0900]: > > > Date: Sat, 25 Apr 2015 22:19:34 +0900 > > > From: Kenji Rikitake > > > To: Mikael Pettersson > > > Cc: erlang-bugs@REDACTED > > > Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: > > > ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD > > > 10.1-STABLE > > > > > > Mikael: > > > > > > > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > > > > --disable-hipe --enable-fp-exceptions and then repeat your tests? > > > > > > Executing emprng tests on 18.0 built with the above options generated > > > the following error for many times: > > > > > > ERTS_FP_CHECK_INIT at 0x502ef3: detected unhandled FPE at 0x4a3 > > > > > > So this is not a HiPE but highly suspected to be a FreeBSD FPE issue. > > > > > > I'll try the further tests later. > > > > > > Kenji Rikitake > > > > > > ++> Mikael Pettersson [2015-04-25 12:57:42 +0200]: > > > > Kenji Rikitake writes: > > > > > I've seen a massive numbers of error when running a common test on > > > > > 18.0-rc1 with HiPE as: > > > > > > > > > > ERTS_FP_CHECK_INIT at 0x50e193: detected unhandled FPE at 0x4ad > > > > > > > > > > This didn't happen when HiPE is disabled (--disable-hipe). > > > > > > > > > > I have traced this in the source that this message is sent from > > > > > erts_fp_check_init_error() in erts/emulator/sys/unix/sys_float.c, > > > > > highly presumably from > > > > > hipe_fclearerror_error() in erts/emulator/hipe/hipe_native_bif.c. > > > > > > > > > > The running environment is on FreeBSD amd64 10.1-STABLE #64 r281235, > > > > > and the kerl compilation options: > > > > > > > > > > export CC=clang CXX=clang CFLAGS="-O3 -fstack-protector" LDFLAGS="-fstack-protector" MAKEFLAGS="-j8" > > > > > KERL_CONFIGURE_OPTIONS="--disable-native-libs --enable-vm-probes --with-dynamic-trace=dtrace --with-ssl=/usr/local --with-javac --enable-hipe --enable-kernel-poll --with-wx-config=/usr/local/bin/wxgtk2u-2.8-config --without-odbc --enable-threads --enable-sctp --enable-smp-support --disable-silent-rules" > > > > > > > > > > You can check this out by: > > > > > > > > > > git clone https://github.com/jj1bdx/emprng/ > > > > > cd emprng > > > > > make tests > > > > > > > > I'm not able to reproduce any unhandled FPE:s on Linux/x86_64 with 18.0-rc1 > > > > configured with --enable-hipe --enable-fp-exceptions. > > > > > > > > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > > > > --disable-hipe --enable-fp-exceptions and then repeat your tests? > > > > > > > > It would also be helpful if you attached a debugger to beam.smp, put a > > > > breakpoint in erts_fp_check_init_error(), and took a backtrace from the > > > > thread when that breakpoint it hit. (You can also try to map the PC > > > > value 0x50e193 reported above to the corresponding C function via beam.smp's > > > > symbol table.) > > > > > > > > Finally, I find the 0x4ad address suspiciously low. Is that address range > > > > even mapped in your beam.smp process? I don't know how to check that on > > > > FreeBSD, but on Linux I would look in /proc/${pid}/maps. > > > > > > > > /Mikael > > > _______________________________________________ > > > erlang-bugs mailing list > > > erlang-bugs@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-bugs > > -- From mikpelinux@REDACTED Mon Apr 27 10:15:47 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Mon, 27 Apr 2015 10:15:47 +0200 Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE In-Reply-To: <20150427012933.GA4523@k2r.org> References: <20150425005909.GA36460@k2r.org> <21819.29478.231394.191336@gargle.gargle.HOWL> <20150425131934.GA47376@k2r.org> <20150426012546.GA41591@k2r.org> <21820.48067.941646.266557@gargle.gargle.HOWL> <20150427012933.GA4523@k2r.org> Message-ID: <21821.61491.795529.404781@gargle.gargle.HOWL> Kenji Rikitake writes: > Mikael: > > The patch is applied and tested. > The patch is at: > https://github.com/jj1bdx/otp/commit/71bfef44f99a01a2b3679bebbc41df1716ea00e5 > And it's available as > https://github.com/jj1bdx/otp/commits/18.0-FPE-patch > (18.0-rc1 plus the patch). > > The following is a brief result of the test. > > In each case the error message was repeated 100000 to 150000 times > (depending on the BEAM code) during the execution of test "interval_int" in > rand_SUITE.erl, at > https://github.com/jj1bdx/emprng/blob/38142e3d0c02b979723082e610f3850d1814afe8/test/rand_SUITE.erl#L179 > > In the build (with CFLAGS = "-O3 -fstack-protector"): > > Note: the value of 0x4a28a7 and 0x4a2 in the following abbreviated log are > common in the first three digits. I also observed this on another build with > difference address values. So my guess is that 0x4a2 is a truncated value of > 0x4a28a7. Yes, the buffer in erts_fp_check_init_error() is too small. I'll bump it to 128. > > fpe_sig_action: FPE at 0x4a28a7 > ERTS_FP_CHECK_INIT at 0x502153: detected unhandled FPE at 0x4a2 > > in erts/emulator/beam/erl_arith.c > (gdb) info symbol 0x502153 > erts_gc_mixed_plus + 547 in section .text > > in erts/emulator/beam/erl_bif_guard.c > (gdb) info symbol 0x4a28a7 > erts_gc_trunc_1 + 407 in section .text Can you provide a disassembly of erts_gc_trunc_1 from this build? > > In another debug build (with CFLAGS = "-g -fstack-protector", without -O3): > > Note: see the similarity of values 0x4cc0b5 and 0x4cc. > > fpe_sig_action: FPE at 0x4cc0b5 > ERTS_FP_CHECK_INIT at 0x571e60: detected unhandled FPE at 0x4cc > > in erts/emulator/sys/unix/erl_unix_sys.h > (gdb) info symbol 0x571e60 > __ERTS_FP_CHECK_INIT + 64 in section .text > > in erts/emulator/beam/erl_bif_guard.c > (gdb) info symbol 0x4cc0b5 > gc_double_to_integer + 501 in section .text Can you provide a disassembly of gc_double_to_integer from this build? Thanks, /Mikael > > I still cannot conclude what is the real reason, but so far this is all > I've got right now. > > Kenji Rikitake > > > ++> Mikael Pettersson [2015-04-26 12:19:47 +0200]: > > Date: Sun, 26 Apr 2015 12:19:47 +0200 > > From: Mikael Pettersson > > To: Kenji Rikitake > > Cc: Mikael Pettersson , erlang-bugs@REDACTED > > Subject: Re: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: > > ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD > > 10.1-STABLE > > > > Kenji Rikitake writes: > > > Mikael: > > > > > > So far I can only reach to the following analysis: > > > > > > I suspect the FPE was raised when > > > ERTS_FP_CHECK_INIT() was called from > > > erts_mixed_plus() in > > > erts/emulator/beam/erl_arith.c. > > > > > > (My experience with gdb especially with multi-threaded code is > > > rather limited.) > > > > > > The command called: > > > > > > erl -pa ebin -pa test -s rand_SUITE test > > > > > > The error message repeated (and beam.smp crashed): > > > > > > ERTS_FP_CHECK_INIT at 0x502ef3: detected unhandled FPE at 0x4a3 > > > > > > gdb result with beam.smp.core: > > > > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and you are > > > welcome to change it and/or distribute copies of it under certain conditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... > > > Core was generated by `beam.smp'. > > > Program terminated with signal 6, Aborted. > > > Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. > > > Loaded symbols for /lib/libutil.so.9 > > > Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. > > > Loaded symbols for /lib/libm.so.5 > > > Reading symbols from /usr/lib/libelf.so.1...(no debugging symbols found)...done. > > > Loaded symbols for /usr/lib/libelf.so.1 > > > Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. > > > Loaded symbols for /lib/libncurses.so.8 > > > Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. > > > Loaded symbols for /lib/libz.so.6 > > > Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. > > > Loaded symbols for /lib/libthr.so.3 > > > Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. > > > Loaded symbols for /usr/lib/librt.so.1 > > > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > > > Loaded symbols for /lib/libc.so.7 > > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. > > > Loaded symbols for /libexec/ld-elf.so.1 > > > #0 0x0000000801b7fb8a in thr_kill () from /lib/libc.so.7 > > > [New Thread 80240b000 (LWP 101044/beam.smp)] > > > [New Thread 80240ac00 (LWP 101042/beam.smp)] > > > [New Thread 80240a800 (LWP 101040/beam.smp)] > > > [New Thread 80240a400 (LWP 101036/beam.smp)] > > > [New Thread 80240a000 (LWP 100892/beam.smp)] > > > [New Thread 802409c00 (LWP 100803/beam.smp)] > > > [New Thread 802409800 (LWP 100651/beam.smp)] > > > [New Thread 802409400 (LWP 100522/beam.smp)] > > > [New Thread 802409000 (LWP 100507/beam.smp)] > > > [New Thread 802408c00 (LWP 100459/beam.smp)] > > > [New Thread 802408800 (LWP 100415/beam.smp)] > > > [New Thread 802408400 (LWP 100309/beam.smp)] > > > [New Thread 802408000 (LWP 100268/beam.smp)] > > > [New Thread 802407c00 (LWP 100254/beam.smp)] > > > [New Thread 802407800 (LWP 100253/beam.smp)] > > > [New Thread 802407400 (LWP 100248/beam.smp)] > > > [New Thread 802407000 (LWP 100245/beam.smp)] > > > [New Thread 802406800 (LWP 100238/beam.smp)] > > > [New Thread 802406400 (LWP 100142/beam.smp)] > > > (gdb) bt > > > #0 0x0000000801b7fb8a in thr_kill () from /lib/libc.so.7 > > > #1 0x0000000801b7faf6 in raise () from /lib/libc.so.7 > > > #2 0x0000000801b7e2e9 in abort () from /lib/libc.so.7 > > > #3 0x000000000049e7d7 in erl_exit_vv () > > > #4 0x000000000049c813 in erl_exit () > > > #5 0x000000000063c49b in erts_fp_check_init_error () > > > #6 0x0000000000502ef3 in erts_gc_mixed_plus () > > > #7 0x00000000004615e7 in process_main () > > > #8 0x00000000004ece11 in sched_thread_func () > > > #9 0x000000000069f6ac in thr_wrapper () > > > #10 0x00000008016196d5 in pthread_create () from /lib/libthr.so.3 > > > #11 0x0000000000000000 in ?? () > > > (gdb) info symbol 0x502ef3 > > > erts_gc_mixed_plus + 547 in section .text > > > (gdb) q > > > > Ok, so this is the ERTS_FP_CHECK_INIT() at the start of erts_gc_mixed_plus() > > which detects a pending FPE, which is not allowed at this point. > > > > There are really only three reasons why this might trigger: > > 1. We got an FP exception outside of checked code (between > > ERTS_FP_CHECK_INIT() and ERTS_FP_ERROR()). > > 2. A libc or libm function called matherr() outside of checked code. > > 3. A process' fp_exception field is uninitialized or clobbered. > > > > Please try the attached debugging patch for 18-rc1. It enables > > logging of FP exceptions and matherr(), which should tell us more > > about what's really going on. > > > > I'm still bothered about the suspiciously low PC address (0x4a3) > > reported. Can you check if that actually corresponds to an address > > in beam.smp or one of its dynamically linked libraries? > > > > /Mikael > > > > > diff --git a/erts/emulator/sys/unix/sys_float.c b/erts/emulator/sys/unix/sys_float.c > > index 2ffa649..d35bf4b 100644 > > --- a/erts/emulator/sys/unix/sys_float.c > > +++ b/erts/emulator/sys/unix/sys_float.c > > @@ -638,7 +638,7 @@ static void fpe_sig_action(int sig, siginfo_t *si, void *puc) > > fpstate->mxcsr = 0x1F80; > > fpstate->sw &= ~0xFF; > > #endif > > -#if 0 > > +#if 1 > > { > > char buf[64]; > > snprintf(buf, sizeof buf, "%s: FPE at %p\r\n", __FUNCTION__, (void*)pc); > > @@ -839,6 +839,12 @@ matherr(struct exception *exc) > > { > > #if !defined(NO_FPE_SIGNALS) > > volatile unsigned long *fpexnp = erts_get_current_fp_exception(); > > +#if 1 > > + char buf[128]; > > + snprintf(buf, sizeof buf, "sys_float.c:matherr() type %d from %s at %p\r\n", > > + exc->type, exc->name, (void*)__builtin_return_address(0)); > > + write(2, buf, strlen(buf)); > > +#endif > > if (fpexnp != NULL) > > *fpexnp = (unsigned long)__builtin_return_address(0); > > #endif > > > > > > > > > ++> Kenji Rikitake [2015-04-25 22:19:34 +0900]: > > > > Date: Sat, 25 Apr 2015 22:19:34 +0900 > > > > From: Kenji Rikitake > > > > To: Mikael Pettersson > > > > Cc: erlang-bugs@REDACTED > > > > Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: > > > > ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD > > > > 10.1-STABLE > > > > > > > > Mikael: > > > > > > > > > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > > > > > --disable-hipe --enable-fp-exceptions and then repeat your tests? > > > > > > > > Executing emprng tests on 18.0 built with the above options generated > > > > the following error for many times: > > > > > > > > ERTS_FP_CHECK_INIT at 0x502ef3: detected unhandled FPE at 0x4a3 > > > > > > > > So this is not a HiPE but highly suspected to be a FreeBSD FPE issue. > > > > > > > > I'll try the further tests later. > > > > > > > > Kenji Rikitake > > > > > > > > ++> Mikael Pettersson [2015-04-25 12:57:42 +0200]: > > > > > Kenji Rikitake writes: > > > > > > I've seen a massive numbers of error when running a common test on > > > > > > 18.0-rc1 with HiPE as: > > > > > > > > > > > > ERTS_FP_CHECK_INIT at 0x50e193: detected unhandled FPE at 0x4ad > > > > > > > > > > > > This didn't happen when HiPE is disabled (--disable-hipe). > > > > > > > > > > > > I have traced this in the source that this message is sent from > > > > > > erts_fp_check_init_error() in erts/emulator/sys/unix/sys_float.c, > > > > > > highly presumably from > > > > > > hipe_fclearerror_error() in erts/emulator/hipe/hipe_native_bif.c. > > > > > > > > > > > > The running environment is on FreeBSD amd64 10.1-STABLE #64 r281235, > > > > > > and the kerl compilation options: > > > > > > > > > > > > export CC=clang CXX=clang CFLAGS="-O3 -fstack-protector" LDFLAGS="-fstack-protector" MAKEFLAGS="-j8" > > > > > > KERL_CONFIGURE_OPTIONS="--disable-native-libs --enable-vm-probes --with-dynamic-trace=dtrace --with-ssl=/usr/local --with-javac --enable-hipe --enable-kernel-poll --with-wx-config=/usr/local/bin/wxgtk2u-2.8-config --without-odbc --enable-threads --enable-sctp --enable-smp-support --disable-silent-rules" > > > > > > > > > > > > You can check this out by: > > > > > > > > > > > > git clone https://github.com/jj1bdx/emprng/ > > > > > > cd emprng > > > > > > make tests > > > > > > > > > > I'm not able to reproduce any unhandled FPE:s on Linux/x86_64 with 18.0-rc1 > > > > > configured with --enable-hipe --enable-fp-exceptions. > > > > > > > > > > I strongly suspect a FreeBSD issue wrt FPE:s. Can you rebuild OTP with > > > > > --disable-hipe --enable-fp-exceptions and then repeat your tests? > > > > > > > > > > It would also be helpful if you attached a debugger to beam.smp, put a > > > > > breakpoint in erts_fp_check_init_error(), and took a backtrace from the > > > > > thread when that breakpoint it hit. (You can also try to map the PC > > > > > value 0x50e193 reported above to the corresponding C function via beam.smp's > > > > > symbol table.) > > > > > > > > > > Finally, I find the 0x4ad address suspiciously low. Is that address range > > > > > even mapped in your beam.smp process? I don't know how to check that on > > > > > FreeBSD, but on Linux I would look in /proc/${pid}/maps. > > > > > > > > > > /Mikael > > > > _______________________________________________ > > > > erlang-bugs mailing list > > > > erlang-bugs@REDACTED > > > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > -- -- From kenji@REDACTED Mon Apr 27 14:16:14 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Mon, 27 Apr 2015 21:16:14 +0900 Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE In-Reply-To: <21821.61491.795529.404781@gargle.gargle.HOWL> References: <20150425005909.GA36460@k2r.org> <21819.29478.231394.191336@gargle.gargle.HOWL> <20150425131934.GA47376@k2r.org> <20150426012546.GA41591@k2r.org> <21820.48067.941646.266557@gargle.gargle.HOWL> <20150427012933.GA4523@k2r.org> <21821.61491.795529.404781@gargle.gargle.HOWL> Message-ID: <20150427121614.GA6362@k2r.org> ++> Mikael Pettersson [2015-04-27 10:15:47 +0200]: > Yes, the buffer in erts_fp_check_init_error() is too small. I'll bump it to 128. Appreciated. > Can you provide a disassembly of erts_gc_trunc_1 from this build? > Can you provide a disassembly of gc_double_to_integer from this build? I will send you personally (not on the list). List viewers: thanks for your patience. Kenji Rikitake From kenji@REDACTED Mon Apr 27 14:53:44 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Mon, 27 Apr 2015 21:53:44 +0900 Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE In-Reply-To: <20150427121614.GA6362@k2r.org> References: <20150425005909.GA36460@k2r.org> <21819.29478.231394.191336@gargle.gargle.HOWL> <20150425131934.GA47376@k2r.org> <20150426012546.GA41591@k2r.org> <21820.48067.941646.266557@gargle.gargle.HOWL> <20150427012933.GA4523@k2r.org> <21821.61491.795529.404781@gargle.gargle.HOWL> <20150427121614.GA6362@k2r.org> Message-ID: <20150427125344.GA6629@k2r.org> FYI: A reference on a similar issue on OS X: http://erlang.org/pipermail/erlang-bugs/2011-May/002383.html The instruction caused the exception was "cvttsd2siq". Kenji Rikitake ++> Kenji Rikitake [2015-04-27 21:16:14 +0900]: > > Can you provide a disassembly of erts_gc_trunc_1 from this build? > > > Can you provide a disassembly of gc_double_to_integer from this build? > > I will send you personally (not on the list). From kenji@REDACTED Mon Apr 27 15:29:03 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Mon, 27 Apr 2015 22:29:03 +0900 Subject: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE In-Reply-To: <20150427125344.GA6629@k2r.org> References: <20150425005909.GA36460@k2r.org> <21819.29478.231394.191336@gargle.gargle.HOWL> <20150425131934.GA47376@k2r.org> <20150426012546.GA41591@k2r.org> <21820.48067.941646.266557@gargle.gargle.HOWL> <20150427012933.GA4523@k2r.org> <21821.61491.795529.404781@gargle.gargle.HOWL> <20150427121614.GA6362@k2r.org> <20150427125344.GA6629@k2r.org> Message-ID: <20150427132903.GA6839@k2r.org> Mikael: I managed to reduce the problem to a one-liner. Executing trunc(0.8 * (1 bsl 128)) will generate the SIGFPE. I attached the gdb of FreeBSD 10.1-STABLE to the Erlang beam.smp and generated the following output. Regards, Kenji Rikitake --- Erlang shell output: Erlang/OTP 18 [RELEASE CANDIDATE 1] [erts-7.0] [source-71bfef4] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false] [dtrace] Eshell V7.0 (abort with ^G) 1> trunc(0.8 * (1 bsl 128)). %%% here FPE is issued and the gdb shows the value... fpe_sig_action: FPE at 0x4ca1b7 272225893536750785882272431128279252992 2> trunc(0.8 * (1 bsl 128)). ERTS_FP_CHECK_INIT at 0x571e60: detected unhandled FPE at 0x4cafpe_sig_action: FPE at 0x4ca1b7 272225893536750785882272431128279252992 3> q() ok --- output of attached gdb: Continuing. Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 80240a000 (LWP 101243/beam.smp)] double_to_integer (p=0x8031c0398, x=1.4757395258967642e+19) at beam/erl_bif_guard.c:302 302 d = x; /* trunc */ Current language: auto; currently minimal (gdb) print $mxcsr $1 = 6401 (gdb) disassemble double_to_integer Dump of assembler code for function double_to_integer: [...] 0x00000000004ca1b7 : cvttsd2siq %xmm1,%rcx [...] End of assembler dump. (gdb) print $mxcsr $3 = 6401 (gdb) print $xmm1 $4 = {f = {-1.58818684e-23, 467.199982, 0, 0}} (gdb) print $rcx $5 = -9223372036854775808 [End of log] ++> Kenji Rikitake [2015-04-27 21:53:44 +0900]: > Date: Mon, 27 Apr 2015 21:53:44 +0900 > From: Kenji Rikitake > To: Mikael Pettersson > Cc: erlang-bugs@REDACTED > Subject: Re: [erlang-bugs] FreeBSD FPE issue on ERTS_FP_CHECK_INIT Re: > ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD > 10.1-STABLE > > FYI: > A reference on a similar issue on OS X: > http://erlang.org/pipermail/erlang-bugs/2011-May/002383.html > > The instruction caused the exception was "cvttsd2siq". > > Kenji Rikitake > > ++> Kenji Rikitake [2015-04-27 21:16:14 +0900]: > > > Can you provide a disassembly of erts_gc_trunc_1 from this build? > > > > > Can you provide a disassembly of gc_double_to_integer from this build? > > > > I will send you personally (not on the list). > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From sdl.web@REDACTED Tue Apr 28 07:33:44 2015 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 28 Apr 2015 13:33:44 +0800 Subject: [erlang-bugs] [PATCH] Fix argument to gui_enable_updown in dbg_wx_trace:init/6 Message-ID: A non-text attachment was scrubbed... Name: 0001-Fix-argument-to-gui_enable_updown-in-dbg_wx_trace-in.patch Type: text/x-patch Size: 1470 bytes Desc: 0001-Fix-argument-to-gui_enable_updown-in-dbg_wx_trace-in.patch URL: From zl9d97p02@REDACTED Tue Apr 28 16:08:08 2015 From: zl9d97p02@REDACTED (Simon Cornish) Date: Tue, 28 Apr 2015 07:08:08 -0700 Subject: [erlang-bugs] Bugs in ssh regnotiation Message-ID: <25644-1430230089-174087@sneakemail.com> Hi, There are two bugs surrounding the OTP ssh implementation of key rengotiation. The first is the handling of the sent data statistics. The port stats are not accumulated so that once rekey_limit bytes (by default, 1GB) have been transmitted the connection will be rekeyed every minute, not after the next 1GB. The attached patch, rekey_limit.diff, provides a simple solution. In the second bug, ssh_connection_handler processes channel data requests from either the application or the network during renegotiation. This is in violation of the RFC and causes the peer to disconnect (observed with sshd on Solaris 10 and SLES 11). The solution is to queue those events for processing until after renegotiation is complete. The second attached patch is in that direction. It's not particularly complete hence the reason this is an email to erlang-bugs and not a pull request. This gist can recreate the fault fairly dependably by ensuring a constant flow of data. https://gist.github.com/dotsimon/ef41296db307561d8f94 /Simon -------------- next part -------------- diff --git a/lib/ssh/src/ssh_connection_handler.erl b/lib/ssh/src/ssh_connection_handler.erl index b7ccb02..59e80e6 100644 --- a/lib/ssh/src/ssh_connection_handler.erl +++ b/lib/ssh/src/ssh_connection_handler.erl @@ -68,6 +68,7 @@ undecoded_packet_length, % integer() key_exchange_init_msg, % #ssh_msg_kexinit{} renegotiate = false, % boolean() + last_size_rekey = 0, connection_queue, address, port, @@ -596,7 +597,8 @@ handle_event(renegotiate, StateName, State) -> %% Rekey due to sent data limit reached? handle_event(data_size, connected, #state{ssh_params = Ssh0} = State) -> - {ok, [{send_oct,Sent}]} = inet:getstat(State#state.socket, [send_oct]), + {ok, [{send_oct,Sent0}]} = inet:getstat(State#state.socket, [send_oct]), + Sent = Sent0 - State#state.last_size_rekey, MaxSent = proplists:get_value(rekey_limit, State#state.opts, 1024000000), timer:apply_after(?REKEY_DATA_TIMOUT, gen_fsm, send_all_state_event, [self(), data_size]), case Sent >= MaxSent of @@ -606,7 +608,8 @@ handle_event(data_size, connected, #state{ssh_params = Ssh0} = State) -> {next_state, kexinit, next_packet(State#state{ssh_params = Ssh, key_exchange_init_msg = KeyInitMsg, - renegotiate = true})}; + renegotiate = true, + last_size_rekey = Sent0})}; _ -> {next_state, connected, next_packet(State)} end; -------------- next part -------------- A non-text attachment was scrubbed... Name: queue_data.patch Type: application/octet-stream Size: 4269 bytes Desc: not available URL: From zl9d97p02@REDACTED Wed Apr 29 15:56:29 2015 From: zl9d97p02@REDACTED (Simon Cornish) Date: Wed, 29 Apr 2015 06:56:29 -0700 Subject: [erlang-bugs] Bugs in ssh regnotiation In-Reply-To: References: <25644-1430230089-174087@sneakemail.com> Message-ID: <28668-1430315789-510207@sneakemail.com> Hi Hans, The queue_data patch was more a proof-of-concept. There are a number of potential problems because I wasn't particularly careful which events are queued, nor what the condition is (eg. StateName == kexinit or #state.renegotiate == true or both). I was hoping there was someone on your side who was familiar with both the code and the protocol who could take that up. If not, I could put some more work into it but I can't guarantee the timeframe of that. Regarding testing, the gist is highly likely to provoke the fault but not certain. A better test would be manipulate ssh_connection_handler directly with the "Internal application API" - send/5, renegotiate/1, etc. Is this allowed for the OTP test suites since it uses knowledge of the underlying code? /Simon On 29 April 2015 at 06:19, Hans Nilsson R hans.r.nilsson-at-ericsson.com |erlang-mail/gmail| wrote: > Thanks for the reports and the diffs! > > I have put the rekey_limit diff into the nightly builds so if it is ok (which I think) it will come in next OTP release (18). > > Do you plan to make a pull request of the queue_data patch? > > /Hans > ________________________________________ > From: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] on behalf of Simon Cornish [zl9d97p02@REDACTED] > Sent: Tuesday, 28 April 2015 16:08 > To: erlang-bugs@REDACTED > Subject: [erlang-bugs] Bugs in ssh regnotiation > > Hi, > There are two bugs surrounding the OTP ssh implementation of key rengotiation. > > The first is the handling of the sent data statistics. The port stats > are not accumulated so that once rekey_limit bytes (by default, 1GB) > have been transmitted the connection will be rekeyed every minute, not > after the next 1GB. > > The attached patch, rekey_limit.diff, provides a simple solution. > > In the second bug, ssh_connection_handler processes channel data > requests from either the application or the network during > renegotiation. This is in violation of the RFC and causes the peer to > disconnect (observed with sshd on Solaris 10 and SLES 11). > > The solution is to queue those events for processing until after > renegotiation is complete. The second attached patch is in that > direction. It's not particularly complete hence the reason this is an > email to erlang-bugs and not a pull request. > > This gist can recreate the fault fairly dependably by ensuring a > constant flow of data. > > https://gist.github.com/dotsimon/ef41296db307561d8f94 > > /Simon