From raimo+erlang-bugs@REDACTED Mon Aug 1 12:17:00 2016 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 1 Aug 2016 12:17:00 +0200 Subject: [erlang-bugs] Missing sockets stats for SCTP In-Reply-To: References: Message-ID: <20160801101700.GA91067@erix.ericsson.se> Now fixed for the upcoming OTP-19.1: https://bugs.erlang.org/browse/ERL-102 On Wed, Feb 24, 2016 at 10:18:02PM +0000, Andrzej Trawi?ski wrote: > 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 > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From binarin@REDACTED Fri Aug 5 13:45:49 2016 From: binarin@REDACTED (Alexey Lebedeff) Date: Fri, 5 Aug 2016 14:45:49 +0300 Subject: [erlang-bugs] Strange stack-traces in crash reports Message-ID: Hi folks, In sasl logs I'm observing some stack-traces that I can't explain, on Erlang 18.1 + actively using HiPE compilation. Looks like those are stack-traces of 2 different processes somehow merged together. Here are some examples: ** {function_clause,[{gb_trees,delete_1,2,[]}, {gb_trees,delete,2,[]}, {mirrored_supervisor,init,1,[]}, {gen_server2,handle_msg,2,[]}, {mirrored_supervisor,init,1,[]}]} mirrored_supervisor:init/1 is https://github.com/rabbitmq/rabbitmq-common/blob/stable/src/mirrored_supervisor.erl#L276 But there is no way it can call: - itself recursively - gen_server2:handle_msg/2 - gb_trees:delete/1 ** {function_clause,[{rabbit_channel,handle_info,2,[]}, {gen_server2,handle_msg,2,[]}, {ssl_config,module_info,1,[]}]} And according to this trace, `ssl_config:module_info/1` somehow started process of message handling in generic server, which doesn't make any sense. And this `module_info` happens with a lot of different modules, both built-in and application specific. Is this something known? Can it be related to HiPE? I was not able to find anything related to stacktraces in release notes of every 18 and 19 release. Best, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed Aug 17 22:31:59 2016 From: erlang@REDACTED (Andreas Stenius) Date: Wed, 17 Aug 2016 20:31:59 +0000 Subject: [erlang-bugs] internal error in lint_module Message-ID: Hi, When compiling attached file, I get an internal error from the lint_module when using 19.0 (built from source, using kerl). Compiling the same file using OTP 17.3 and 18.0 works fine. $ ~/lib/erl/17.3/bin/erlc -v -Werror +debug_info +warn_export_vars +warn_shadow_vars +warn_obsolete_guard -o ebin/ -pa ebin/ -I include/ src/ecapnp.erl $ ~/lib/erl/17.3/bin/erlc -v -Werror +debug_info +warn_export_vars +warn_shadow_vars +warn_obsolete_guard -o ebin/ -pa ebin/ -I include/ src/c++_capnp.erl $ ~/lib/erl/18.0/bin/erlc -v -Werror +debug_info +warn_export_vars +warn_shadow_vars +warn_obsolete_guard -o ebin/ -pa ebin/ -I include/ src/c++_capnp.erl $ ~/lib/erl/19.0/bin/erlc -v -Werror +debug_info +warn_export_vars +warn_shadow_vars +warn_obsolete_guard -o ebin/ -pa ebin/ -I include/ src/c++_capnp.erl src/c++_capnp.erl: internal error in lint_module; crash reason: badarg in function erl_eval:line/1 (erl_eval.erl, line 1327) in call from erl_eval:partial_eval/1 (erl_eval.erl, line 1297) in call from erl_lint:check_type/3 (erl_lint.erl, line 2840) in call from lists:foldl/3 (lists.erl, line 1263) in call from erl_lint:check_type/2 (erl_lint.erl, line 2728) in call from lists:foldl/3 (lists.erl, line 1263) in call from erl_lint:forms/2 (erl_lint.erl, line 658) in call from erl_lint:module/3 (erl_lint.erl, line 506) Cheers, Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: c++_capnp.erl Type: application/octet-stream Size: 6074 bytes Desc: not available URL: From kostis@REDACTED Wed Aug 17 23:24:46 2016 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 17 Aug 2016 23:24:46 +0200 Subject: [erlang-bugs] internal error in lint_module In-Reply-To: References: Message-ID: On 08/17/2016 10:31 PM, Andreas Stenius wrote: > Hi, > > When compiling attached file, I get an internal error from the > lint_module when using 19.0 (built from source, using kerl). > Wild guess: Most likely this is due to the internal representation of typed records which has changed in 19.0. Looks like you generated this file with some older Erlang release and now you are trying to compile it with the 19.0 compiler and the linter does not like this. If you generate the file with a 19.x release, then most likely its subsequent compilation will work. Hope it helps, Kostis From erlang@REDACTED Thu Aug 18 22:17:12 2016 From: erlang@REDACTED (Andreas Stenius) Date: Thu, 18 Aug 2016 20:17:12 +0000 Subject: [erlang-bugs] internal error in lint_module In-Reply-To: References: Message-ID: Thanks Kostis, you were absolutely right. The records looks much cleaner now, too btw ;) //Andreas On Wed, Aug 17, 2016 at 11:21 PM Kostis Sagonas wrote: > On 08/17/2016 10:31 PM, Andreas Stenius wrote: > > Hi, > > > > When compiling attached file, I get an internal error from the > > lint_module when using 19.0 (built from source, using kerl). > > > > Wild guess: > > Most likely this is due to the internal representation of typed records > which has changed in 19.0. Looks like you generated this file with some > older Erlang release and now you are trying to compile it with the 19.0 > compiler and the linter does not like this. If you generate the file > with a 19.x release, then most likely its subsequent compilation will work. > > Hope it helps, > > Kostis > -------------- next part -------------- An HTML attachment was scrubbed... URL: