From jose.valim@REDACTED Sat Feb 6 17:15:32 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Sat, 6 Feb 2016 17:15:32 +0100 Subject: [erlang-bugs] Internal consistency check failed (with binary matching and orself) Message-ID: Hello, We have run into a failed internal consistency check. Here I am reporting the bug as asked. :D https://gist.github.com/josevalim/77ba585445e2eccb5160 The code is a bit convoluted but that was done in order to provide a minimum test case. Thank you! *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Mon Feb 8 08:11:46 2016 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 8 Feb 2016 08:11:46 +0100 Subject: [erlang-bugs] Internal consistency check failed (with binary matching and orself) In-Reply-To: References: Message-ID: On Sat, Feb 6, 2016 at 5:15 PM, Jos? Valim wrote: > Hello, > > We have run into a failed internal consistency check. Here I am reporting > the bug as asked. :D > > https://gist.github.com/josevalim/77ba585445e2eccb5160 > > The code is a bit convoluted but that was done in order to provide a minim > test case. > > Thank you! > Thank you for the bug report! Here is a branch that corrects the bug: https://github.com/bjorng/otp/commits/bjorn/compiler/beam_bsm /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From daimon@REDACTED Wed Feb 17 07:08:24 2016 From: daimon@REDACTED (Masatake Daimon) Date: Wed, 17 Feb 2016 15:08:24 +0900 Subject: [erlang-bugs] Combination of erl flags "+B" and "-smp enable" renders producing crash dumps impossible Message-ID: <56C40E58.9060900@ymir.co.jp> Hello, I found a bug in OTP 18.2.1 on Linux. When the erl flag "+B" is given, and SMP is enabled, erts fails to produce a crash dump but instead kills itself with SIGUSR2: > $ erl -smp enable -noshell -eval 'erlang:halt("Hello").' > > Crash dump is being written to: erl_crash.dump...done > Hello > $ echo $? > 1 > $ erl -smp disable +B -noshell -eval 'erlang:halt("Hello").' > > Crash dump is being written to: erl_crash.dump...done > Hello > $ rm erl_crash.dump > $ erl -smp enable +B -noshell -eval 'erlang:halt("Hello").' > User defined signal 2 > $ echo $? > 140 > $ ls erl_crash.dump > ls: erl_crash.dump: No such file or directory The reason for this behavior is as follows: * When the +B flag is given, erl_start() (beam/erl_init.c:2133) skips calling init_break_handler(). * But init_break_handler() (sys/unix/sys.c:970) is the only function which registers a signal handler for SIGUSR2. * When a crash dump is being produced, erl_crash_dump_v() (beam/break.c:694) sends SIGUSR2 to each scheduler thread. * Since there is no handler for SIGUSR2, the whole process terminates. I'm posting the report to the ML instead of submitting a pull request because I'm not sure how to fix this properly. This is especially problematic for escripts because main() (etc/common/escript.c:459) automatically sets the +B flag. I hope someone familiar with these things can resolve the problem. Kind regards, Masatake Daimon -- ?? ?? From daimon@REDACTED Wed Feb 17 09:10:22 2016 From: daimon@REDACTED (Masatake Daimon) Date: Wed, 17 Feb 2016 17:10:22 +0900 Subject: [erlang-bugs] Combination of erl flags "+B" and "-smp enable" renders producing crash dumps impossible In-Reply-To: <56C40E58.9060900@ymir.co.jp> References: <56C40E58.9060900@ymir.co.jp> Message-ID: <56C42AEE.4090607@ymir.co.jp> I just found there was a public bug tracker so I created an issue there: http://bugs.erlang.org/browse/ERL-94 Sorry for the noise to ML. On 02/17/16 15:08, Masatake Daimon wrote: > Hello, > > I found a bug in OTP 18.2.1 on Linux. When the erl flag "+B" is given, > and SMP is enabled, erts fails to produce a crash dump but instead kills > itself with SIGUSR2: > >> $ erl -smp enable -noshell -eval 'erlang:halt("Hello").' >> >> Crash dump is being written to: erl_crash.dump...done >> Hello >> $ echo $? >> 1 >> $ erl -smp disable +B -noshell -eval 'erlang:halt("Hello").' >> >> Crash dump is being written to: erl_crash.dump...done >> Hello >> $ rm erl_crash.dump >> $ erl -smp enable +B -noshell -eval 'erlang:halt("Hello").' >> User defined signal 2 >> $ echo $? >> 140 >> $ ls erl_crash.dump >> ls: erl_crash.dump: No such file or directory > > The reason for this behavior is as follows: > * When the +B flag is given, erl_start() (beam/erl_init.c:2133) skips > calling init_break_handler(). > * But init_break_handler() (sys/unix/sys.c:970) is the only function > which registers a signal handler for SIGUSR2. > * When a crash dump is being produced, erl_crash_dump_v() > (beam/break.c:694) sends SIGUSR2 to each scheduler thread. > * Since there is no handler for SIGUSR2, the whole process terminates. > > I'm posting the report to the ML instead of submitting a pull request > because I'm not sure how to fix this properly. This is especially > problematic for escripts because main() (etc/common/escript.c:459) > automatically sets the +B flag. I hope someone familiar with these > things can resolve the problem. > > Kind regards, > Masatake Daimon -- ?? ?? From tony@REDACTED Thu Feb 18 10:43:36 2016 From: tony@REDACTED (Tony Wallace) Date: Thu, 18 Feb 2016 22:43:36 +1300 Subject: [erlang-bugs] io:get_chars no longer respecting Control-D (eof) in Erlang 18.1 Message-ID: <56C59248.3010900@tony.gen.nz> The task is to produce an escript that reads standard input. The code that used to work was: read_stdin() -> lists:flatten(read_stdin(io:get_chars(standard_io,"",8192))). read_stdin(eof) -> []; read_stdin(Data) -> [Data|read_stdin(io:get_chars(standard_io,"",8192))]. Now this code causes the program to hang. If I try the following command from the erlang prompt: 2> io:get_chars("",10). and then try to end the input with control-D the command does not return. It could be a problem with the shell intercepting the control-D or io:get_chars could be broken. Tony Wallace From tony@REDACTED Fri Feb 19 04:26:17 2016 From: tony@REDACTED (Tony Wallace) Date: Fri, 19 Feb 2016 16:26:17 +1300 Subject: [erlang-bugs] io:get_chars no longer respecting Control-D (eof) in Erlang 18.1 In-Reply-To: <56C59248.3010900@tony.gen.nz> References: <56C59248.3010900@tony.gen.nz> Message-ID: <56C68B59.3090605@tony.gen.nz> My apologies. Not sure why I had problems (yet) but it is not an erlang bug. Tony -------- Forwarded Message -------- Subject: io:get_chars no longer respecting Control-D (eof) in Erlang 18.1 Date: Thu, 18 Feb 2016 22:43:36 +1300 From: Tony Wallace To: erlang-bugs@REDACTED The task is to produce an escript that reads standard input. The code that used to work was: read_stdin() -> lists:flatten(read_stdin(io:get_chars(standard_io,"",8192))). read_stdin(eof) -> []; read_stdin(Data) -> [Data|read_stdin(io:get_chars(standard_io,"",8192))]. Now this code causes the program to hang. If I try the following command from the erlang prompt: 2> io:get_chars("",10). and then try to end the input with control-D the command does not return. It could be a problem with the shell intercepting the control-D or io:get_chars could be broken. Tony Wallace -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrzej.trawinski@REDACTED Wed Feb 24 23:18:02 2016 From: andrzej.trawinski@REDACTED (=?UTF-8?Q?Andrzej_Trawi=C5=84ski?=) Date: Wed, 24 Feb 2016 22:18:02 +0000 Subject: [erlang-bugs] Missing sockets stats for SCTP Message-ID: Hi! I've recently played with the SCTP connections and noticed that when I'm trying to get SCTP socket stats (using inet:getstat(Socket) function) I'm always receiving zero (0) values for sending side options. ... {ok,[{recv_oct,96}, {recv_cnt,7}, {recv_max,16}, {recv_avg,13}, {recv_dvi,2}, {send_oct,0}, {send_cnt,0}, {send_max,0}, {send_avg,0}, {send_pend,0}]}. .. This reproduces on both 17.5.6.8 and 18.2. It shows proper values for TCP sockets, but for SCTP most likely something is wrong with it. Any ideas on this? Thanks, Andrzej -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.feng.bao@REDACTED Thu Feb 25 03:47:56 2016 From: max.feng.bao@REDACTED (max_feng) Date: Thu, 25 Feb 2016 10:47:56 +0800 Subject: [erlang-bugs] Scheduler hang Message-ID: On Erlang 18.1, my application run several weeks, and I found one scheduler hanging for several hourse (But work fine on Erlang-17.5 fine for several months ! ), here is my experiment: 0) my application run several weeks 1) attach 2) run one process on each scheduler 5> [erlang:spawn(fun() -> erlang:process_flag(scheduler, I), io:format("Id: ~p~n", [I]) end) || I <- lists:seq(1, 24) ]. Id: 1 Id: 2 Id: 3 Id: 4 Id: 6 Id: 5 Id: 7 Id: 8 Id: 9 Id: 10 Id: 11 Id: 13 Id: 12 Id: 14 Id: 15 Id: 16 Id: 17 Id: 18 Id: 19 Id: 21 Id: 22 Id: 24 Id: 23 But scheduler-20 not responsed !. This is run queue length: 6> erlang:statistics(run_queues). {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0} The run queue length of scheduler-20 is 1, and increased by when I rerun [erlang:spawn(fun() -> erlang:process_flag(scheduler, I), io:format("Id: ~p~n", [I]) end) || I <- lists:seq(1, 24) ]. Here is the callstack of scheduler-20, and most schedulers's callstack are the same: #0 0x0000003895ee4049 in syscall () from /lib64/libc.so.6 #1 0x000000000060f71e in ethr_event_twait () #2 0x00000000004d9edc in scheduler_wait () #3 0x00000000004e5926 in schedule () #4 0x00000000004383c3 in process_main () #5 0x00000000004d431f in sched_thread_func () #6 0x000000000060ee12 in thr_wrapper () #7 0x0000003896207851 in start_thread () from /lib64/libpthread.so.0 #8 0x0000003895ee767d in clone () from /lib64/libc.so.6 But after several hours scheduler-20 resume again ! Max Feng -------------- next part -------------- An HTML attachment was scrubbed... URL: