From mikpelinux@REDACTED Fri May 1 20:04:22 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Fri, 1 May 2015 20:04:22 +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: <20150427132903.GA6839@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> <20150427132903.GA6839@k2r.org> Message-ID: <21827.49190.650064.431723@gargle.gargle.HOWL> Kenji Rikitake writes: > Mikael: > > I managed to reduce the problem to a one-liner. > Executing > trunc(0.8 * (1 bsl 128)) > will generate the SIGFPE. I can reproduce the SIGFPE on Linux/x86_64 by compiling OTP-18-rc1 with clang-3.6.0. > > 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 kenji@REDACTED Sat May 2 05:44:55 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Sat, 2 May 2015 12:44:55 +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: <21827.49190.650064.431723@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> <20150427121614.GA6362@k2r.org> <20150427125344.GA6629@k2r.org> <20150427132903.GA6839@k2r.org> <21827.49190.650064.431723@gargle.gargle.HOWL> Message-ID: Thanks Mikael for the confirmation. So can I conclude this as a bug or FPE handling difference between gcc and clang? (I noticed on my OS X the *gcc-compiled* 18.0-rc1 didn't cause the problem either.) Regards, Kenji Rikitake On Sat, May 2, 2015 at 3:04 AM, Mikael Pettersson wrote: > Kenji Rikitake writes: > > Mikael: > > > > I managed to reduce the problem to a one-liner. > > Executing > > trunc(0.8 * (1 bsl 128)) > > will generate the SIGFPE. > > I can reproduce the SIGFPE on Linux/x86_64 by compiling OTP-18-rc1 with > clang-3.6.0. > > > > > > 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 > > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Sat May 2 16:16:36 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 2 May 2015 16:16:36 +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: 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> <20150427132903.GA6839@k2r.org> <21827.49190.650064.431723@gargle.gargle.HOWL> Message-ID: <21828.56388.900498.413647@gargle.gargle.HOWL> Kenji Rikitake writes: > Thanks Mikael for the confirmation. > > So can I conclude this as a bug or FPE handling > difference between gcc and clang? Yes. I have a reduced testcase in plain C99 which works with gcc but shows wrong behaviour when compiled by clang. It involves converting a double with value somewhere between INT64_MAX and UINT64_MAX to uint64_t: clang causes that to signal FP_INVALID. At the moment I'm trying to get confirmation about where the error lies: in the test case (i.e., the Erlang VM), or in clang. According to my reading of the C standard, clang is in error. For now, the workaround is to either compile with gcc, or to build with ./configure --disable-fp-exceptions. /Mikael > (I noticed on my OS X the *gcc-compiled* 18.0-rc1 > didn't cause the problem either.) > > Regards, > Kenji Rikitake > > On Sat, May 2, 2015 at 3:04 AM, Mikael Pettersson > wrote: > > > Kenji Rikitake writes: > > > Mikael: > > > > > > I managed to reduce the problem to a one-liner. > > > Executing > > > trunc(0.8 * (1 bsl 128)) > > > will generate the SIGFPE. > > > > I can reproduce the SIGFPE on Linux/x86_64 by compiling OTP-18-rc1 with > > clang-3.6.0. > > > > > > > > > > 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 essen@REDACTED Sat May 2 17:11:30 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 02 May 2015 18:11:30 +0300 Subject: [erlang-bugs] Crash on compile with deprecated functions (18-rc1) Message-ID: <5544E922.9090505@ninenines.eu> Hello, Some of my applications don't compile anymore because they have the ssl:negotiated_next_protocol instead of negotiated_protocol. Problem is there is a crash instead of a nice error: src/gun.erl: internal error in lint_module; crash reason: {case_clause,{deprecated,{ssl,negotiated_protocol}}} in function otp_internal:obsolete/3 (otp_internal.erl, line 33) in call from erl_lint:deprecated_function/5 (erl_lint.erl, line 3551) in call from erl_lint:check_remote_function/5 (erl_lint.erl, line 3527) in call from erl_lint:expr/3 (erl_lint.erl, line 2166) in call from erl_lint:expr/3 (erl_lint.erl, line 2111) in call from erl_lint:expr/3 (erl_lint.erl, line 2250) in call from erl_lint:exprs/3 (erl_lint.erl, line 2044) in call from erl_lint:icrt_clause/3 (erl_lint.erl, line 3029) When I sent the PR I just copied the code around this clause so I'm pretty sure this crash will happen on many more functions. Not sure what action to take about it. Cheers, -- Lo?c Hoguin http://ninenines.eu From mikpelinux@REDACTED Sat May 2 18:34:46 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 2 May 2015 18:34:46 +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: <21828.56388.900498.413647@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> <20150427121614.GA6362@k2r.org> <20150427125344.GA6629@k2r.org> <20150427132903.GA6839@k2r.org> <21827.49190.650064.431723@gargle.gargle.HOWL> <21828.56388.900498.413647@gargle.gargle.HOWL> Message-ID: <21828.64678.672168.468464@gargle.gargle.HOWL> Mikael Pettersson writes: > Kenji Rikitake writes: > > Thanks Mikael for the confirmation. > > > > So can I conclude this as a bug or FPE handling > > difference between gcc and clang? > > Yes. I have a reduced testcase in plain C99 which works with gcc > but shows wrong behaviour when compiled by clang. It involves > converting a double with value somewhere between INT64_MAX and > UINT64_MAX to uint64_t: clang causes that to signal FP_INVALID. > > At the moment I'm trying to get confirmation about where the > error lies: in the test case (i.e., the Erlang VM), or in clang. > According to my reading of the C standard, clang is in error. I've had a look in clang/llvm's bugzilla, and it's clear that clang/llvm does not support FP exceptions in any way -- both due to backend bugs and due to their middle-end being reckless. See e.g. PRs 17686, 22873, and 8100. I'll prepare a patch to force-disable FP exceptions if clang is detected. /Mikael > > For now, the workaround is to either compile with gcc, or to > build with ./configure --disable-fp-exceptions. > > /Mikael > > > (I noticed on my OS X the *gcc-compiled* 18.0-rc1 > > didn't cause the problem either.) > > > > Regards, > > Kenji Rikitake > > > > On Sat, May 2, 2015 at 3:04 AM, Mikael Pettersson > > wrote: > > > > > Kenji Rikitake writes: > > > > Mikael: > > > > > > > > I managed to reduce the problem to a one-liner. > > > > Executing > > > > trunc(0.8 * (1 bsl 128)) > > > > will generate the SIGFPE. > > > > > > I can reproduce the SIGFPE on Linux/x86_64 by compiling OTP-18-rc1 with > > > clang-3.6.0. > > > > > > > > > > > > > > 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 mikpelinux@REDACTED Sun May 3 13:25:12 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 3 May 2015 13:25:12 +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: <21828.64678.672168.468464@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> <20150427121614.GA6362@k2r.org> <20150427125344.GA6629@k2r.org> <20150427132903.GA6839@k2r.org> <21827.49190.650064.431723@gargle.gargle.HOWL> <21828.56388.900498.413647@gargle.gargle.HOWL> <21828.64678.672168.468464@gargle.gargle.HOWL> Message-ID: <21830.1432.431270.675293@gargle.gargle.HOWL> Mikael Pettersson writes: > Mikael Pettersson writes: > > Kenji Rikitake writes: > > > Thanks Mikael for the confirmation. > > > > > > So can I conclude this as a bug or FPE handling > > > difference between gcc and clang? > > > > Yes. I have a reduced testcase in plain C99 which works with gcc > > but shows wrong behaviour when compiled by clang. It involves > > converting a double with value somewhere between INT64_MAX and > > UINT64_MAX to uint64_t: clang causes that to signal FP_INVALID. > > > > At the moment I'm trying to get confirmation about where the > > error lies: in the test case (i.e., the Erlang VM), or in clang. > > According to my reading of the C standard, clang is in error. > > I've had a look in clang/llvm's bugzilla, and it's clear that clang/llvm > does not support FP exceptions in any way -- both due to backend bugs > and due to their middle-end being reckless. See e.g. PRs 17686, 22873, > and 8100. > > I'll prepare a patch to force-disable FP exceptions if clang is detected. > > /Mikael https://github.com/erlang/otp/pull/707 > > > > > For now, the workaround is to either compile with gcc, or to > > build with ./configure --disable-fp-exceptions. > > > > /Mikael > > > > > (I noticed on my OS X the *gcc-compiled* 18.0-rc1 > > > didn't cause the problem either.) > > > > > > Regards, > > > Kenji Rikitake > > > > > > On Sat, May 2, 2015 at 3:04 AM, Mikael Pettersson > > > wrote: > > > > > > > Kenji Rikitake writes: > > > > > Mikael: > > > > > > > > > > I managed to reduce the problem to a one-liner. > > > > > Executing > > > > > trunc(0.8 * (1 bsl 128)) > > > > > will generate the SIGFPE. > > > > > > > > I can reproduce the SIGFPE on Linux/x86_64 by compiling OTP-18-rc1 with > > > > clang-3.6.0. > > > > > > > > > > > > > > > > > > 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 eric.c.dahl@REDACTED Sun May 3 18:02:45 2015 From: eric.c.dahl@REDACTED (Eric Dahl) Date: Sun, 3 May 2015 09:02:45 -0700 Subject: [erlang-bugs] Crash when piping stdout to 'head'? Message-ID: I'm relatively new to erlang but ran across a weird issue which seems like a bug. When I redirect the output to 'head -20', it causes the VM to crash. Some other types of pipes are fine though. I've encountered this initially on FreeBSD 10.1 with Erlang/OTP 17 but also reproduced on Ubuntu 14.04 with Erlang R16B03 Minimal test case below: $ cat redirection_test.erl -module(redirection_test). -export([start/0]). f(0) -> 0; f(N) -> io:format("~p ~n", [N]), f(N-1). start() -> io:format("~p ~n", [f(100)]). $ erlc redirection_test.erl $ erl -noinput -s redirection_test -s init stop | head -20 100 99 ... 84 83 82 81 Crash dump was written to: erl_crash.dump init terminating in do_boot () $ uname -a Linux erlang-test 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ erl --version Erlang R16B03 (erts-5.10.4) [source] [64-bit] [async-threads:10] [kernel-poll:false] Eshell V5.10.4 (abort with ^G) Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Mon May 4 06:35:39 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Mon, 4 May 2015 06:35:39 +0200 Subject: [erlang-bugs] Crash when piping stdout to 'head'? In-Reply-To: References: Message-ID: <21830.63259.556549.538836@gargle.gargle.HOWL> Eric Dahl writes: > I'm relatively new to erlang but ran across a weird issue which seems like > a bug. When I redirect the output to 'head -20', it causes the VM to crash. > Some other types of pipes are fine though. > > I've encountered this initially on FreeBSD 10.1 with Erlang/OTP 17 but also > reproduced on Ubuntu 14.04 with Erlang R16B03 > > Minimal test case below: > > $ cat redirection_test.erl > -module(redirection_test). > -export([start/0]). > > f(0) -> 0; > f(N) -> io:format("~p ~n", [N]), f(N-1). > > start() -> io:format("~p ~n", [f(100)]). > $ erlc redirection_test.erl > $ erl -noinput -s redirection_test -s init stop | head -20 > 100 > 99 > ... > 84 > 83 > 82 > 81 > > Crash dump was written to: erl_crash.dump > init terminating in do_boot () > $ uname -a > Linux erlang-test 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC > 2014 x86_64 x86_64 x86_64 GNU/Linux > $ erl --version > Erlang R16B03 (erts-5.10.4) [source] [64-bit] [async-threads:10] > [kernel-poll:false] > > Eshell V5.10.4 (abort with ^G) > > > Thanks, > Eric I'm not so sure this is a bug. head -20 will close the pipe after consuming 20 lines from it. Standard Unix behaviour is to send a SIGPIPE signal to a process that writes to a closed pipe, and unless caught or ignored that kills the process. It looks like the Erlang VM ignores SIGPIPE, so the write will instead fail with EPIPE. Presumably something in the call chain considers that a fatal error and terminates the VM. Unless there is documentation to the effect that the VM is supposed to handle this use case, I don't think this is a bug. /Mikael From kenji@REDACTED Mon May 4 08:21:45 2015 From: kenji@REDACTED (Kenji Rikitake) Date: Mon, 4 May 2015 15:21:45 +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: <21830.1432.431270.675293@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> <20150427121614.GA6362@k2r.org> <20150427125344.GA6629@k2r.org> <20150427132903.GA6839@k2r.org> <21827.49190.650064.431723@gargle.gargle.HOWL> <21828.56388.900498.413647@gargle.gargle.HOWL> <21828.64678.672168.468464@gargle.gargle.HOWL> <21830.1432.431270.675293@gargle.gargle.HOWL> Message-ID: Mikael: Building Erlang with --disable-fp-exceptions on 18.0-rc1 solved the problem. Thanks for the pull request also. Regards, Kenji Rikitake On Sun, May 3, 2015 at 8:25 PM, Mikael Pettersson wrote: > Mikael Pettersson writes: > > Mikael Pettersson writes: > > > Kenji Rikitake writes: > > > > Thanks Mikael for the confirmation. > > > > > > > > So can I conclude this as a bug or FPE handling > > > > difference between gcc and clang? > > > > > > Yes. I have a reduced testcase in plain C99 which works with gcc > > > but shows wrong behaviour when compiled by clang. It involves > > > converting a double with value somewhere between INT64_MAX and > > > UINT64_MAX to uint64_t: clang causes that to signal FP_INVALID. > > > > > > At the moment I'm trying to get confirmation about where the > > > error lies: in the test case (i.e., the Erlang VM), or in clang. > > > According to my reading of the C standard, clang is in error. > > > > I've had a look in clang/llvm's bugzilla, and it's clear that clang/llvm > > does not support FP exceptions in any way -- both due to backend bugs > > and due to their middle-end being reckless. See e.g. PRs 17686, 22873, > > and 8100. > > > > I'll prepare a patch to force-disable FP exceptions if clang is > detected. > > > > /Mikael > > https://github.com/erlang/otp/pull/707 > > > > > > > > > > For now, the workaround is to either compile with gcc, or to > > > build with ./configure --disable-fp-exceptions. > > > > > > /Mikael > > > > > > > (I noticed on my OS X the *gcc-compiled* 18.0-rc1 > > > > didn't cause the problem either.) > > > > > > > > Regards, > > > > Kenji Rikitake > > > > > > > > On Sat, May 2, 2015 at 3:04 AM, Mikael Pettersson < > mikpelinux@REDACTED> > > > > wrote: > > > > > > > > > Kenji Rikitake writes: > > > > > > Mikael: > > > > > > > > > > > > I managed to reduce the problem to a one-liner. > > > > > > Executing > > > > > > trunc(0.8 * (1 bsl 128)) > > > > > > will generate the SIGFPE. > > > > > > > > > > I can reproduce the SIGFPE on Linux/x86_64 by compiling > OTP-18-rc1 with > > > > > clang-3.6.0. > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > -- > > > > > > > > > > > -- > > > > -- > > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon May 4 09:46:18 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 04 May 2015 10:46:18 +0300 Subject: [erlang-bugs] Crash when piping stdout to 'head'? In-Reply-To: <21830.63259.556549.538836@gargle.gargle.HOWL> References: <21830.63259.556549.538836@gargle.gargle.HOWL> Message-ID: <554723CA.2020505@ninenines.eu> On 05/04/2015 07:35 AM, Mikael Pettersson wrote: > Eric Dahl writes: > > I'm relatively new to erlang but ran across a weird issue which seems like > > a bug. When I redirect the output to 'head -20', it causes the VM to crash. > > Some other types of pipes are fine though. > > > > I've encountered this initially on FreeBSD 10.1 with Erlang/OTP 17 but also > > reproduced on Ubuntu 14.04 with Erlang R16B03 > > > > Minimal test case below: > > > > $ cat redirection_test.erl > > -module(redirection_test). > > -export([start/0]). > > > > f(0) -> 0; > > f(N) -> io:format("~p ~n", [N]), f(N-1). > > > > start() -> io:format("~p ~n", [f(100)]). > > $ erlc redirection_test.erl > > $ erl -noinput -s redirection_test -s init stop | head -20 > > 100 > > 99 > > ... > > 84 > > 83 > > 82 > > 81 > > > > Crash dump was written to: erl_crash.dump > > init terminating in do_boot () > > $ uname -a > > Linux erlang-test 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC > > 2014 x86_64 x86_64 x86_64 GNU/Linux > > $ erl --version > > Erlang R16B03 (erts-5.10.4) [source] [64-bit] [async-threads:10] > > [kernel-poll:false] > > > > Eshell V5.10.4 (abort with ^G) > > > > > > Thanks, > > Eric > > I'm not so sure this is a bug. > > head -20 will close the pipe after consuming 20 lines from it. Standard Unix > behaviour is to send a SIGPIPE signal to a process that writes to a closed pipe, > and unless caught or ignored that kills the process. It looks like the Erlang > VM ignores SIGPIPE, so the write will instead fail with EPIPE. Presumably > something in the call chain considers that a fatal error and terminates the VM. > > Unless there is documentation to the effect that the VM is supposed to handle > this use case, I don't think this is a bug. Make that a feature request then. It can be quite useful to have at times. Also add "less" usage to the list, never managed to make it work either. -- Lo?c Hoguin http://ninenines.eu From bjorn@REDACTED Mon May 4 12:38:03 2015 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 4 May 2015 12:38:03 +0200 Subject: [erlang-bugs] Crash on compile with deprecated functions (18-rc1) In-Reply-To: <5544E922.9090505@ninenines.eu> References: <5544E922.9090505@ninenines.eu> Message-ID: On Sat, May 2, 2015 at 5:11 PM, Lo?c Hoguin wrote: > Hello, > > Some of my applications don't compile anymore because they have the > ssl:negotiated_next_protocol instead of negotiated_protocol. > > Problem is there is a crash instead of a nice error: > > src/gun.erl: internal error in lint_module; > crash reason: {case_clause,{deprecated,{ssl,negotiated_protocol}}} This bug was introduced in https://github.com/erlang/otp/commit/7cf85926 > in function otp_internal:obsolete/3 (otp_internal.erl, line 33) > in call from erl_lint:deprecated_function/5 (erl_lint.erl, line 3551) > in call from erl_lint:check_remote_function/5 (erl_lint.erl, line 3527) > in call from erl_lint:expr/3 (erl_lint.erl, line 2166) > in call from erl_lint:expr/3 (erl_lint.erl, line 2111) > in call from erl_lint:expr/3 (erl_lint.erl, line 2250) > in call from erl_lint:exprs/3 (erl_lint.erl, line 2044) > in call from erl_lint:icrt_clause/3 (erl_lint.erl, line 3029) > > When I sent the PR I just copied the code around this clause so I'm pretty > sure this crash will happen on many more functions. Not sure what action to > take about it. No. All other functions are fine. They specify a replacement function as a complete {M,F,A} tuple. You left out the arity. The correction is here: https://github.com/erlang/otp/commit/85dbd5ff There is a test suite that can find similar bugs automatically. It is run like this: ts:run(system, otp_SUITE, [batch]). /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From essen@REDACTED Mon May 4 12:45:54 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 04 May 2015 13:45:54 +0300 Subject: [erlang-bugs] Crash on compile with deprecated functions (18-rc1) In-Reply-To: References: <5544E922.9090505@ninenines.eu> Message-ID: <55474DE2.20603@ninenines.eu> On 05/04/2015 01:38 PM, Bj?rn Gustavsson wrote: > No. All other functions are fine. They specify a > replacement function as a complete {M,F,A} > tuple. You left out the arity. Right, looks like I'm also blind. Cheers, -- Lo?c Hoguin http://ninenines.eu From erlang-bugs-mailing-list@REDACTED Tue May 5 16:36:05 2015 From: erlang-bugs-mailing-list@REDACTED (Luis Gerhorst) Date: Tue, 5 May 2015 16:36:05 +0200 Subject: [erlang-bugs] Common Test failed Message-ID: Hi, Here's some bug report Common Test gave me, if you need any additional information just ask. I'm not sure if it's a real bug anyway. https://gist.github.com/luisgerhorst/261f954a3e58cc428b86 Best regards, Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: From peppe@REDACTED Thu May 7 08:26:14 2015 From: peppe@REDACTED (Peter Andersson) Date: Thu, 7 May 2015 08:26:14 +0200 Subject: [erlang-bugs] Common Test failed In-Reply-To: References: Message-ID: <554B0586.4050504@erlang.org> Hi Luis, Thanks for the report. A fix for this error has been released with Patch Package OTP 17.5.3 (yesterday). Please let me know if this doesn't solve your problem. Best regards, Peter Ericsson AB, Erlang/OTP On 2015-05-05 16:36, Luis Gerhorst wrote: > Hi, > Here's some bug report Common Test gave me, if you need any additional > information just ask. I'm not sure if it's a real bug anyway. > > https://gist.github.com/luisgerhorst/261f954a3e58cc428b86 > > Best regards, > Luis > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From yannayl@REDACTED Sun May 10 08:06:19 2015 From: yannayl@REDACTED (yannay livneh) Date: Sun, 10 May 2015 09:06:19 +0300 Subject: [erlang-bugs] asn1ct: cant build asn files with names which does not agree with module name Message-ID: Hello, asn1ct can't build asn1 file which contain module with name that is not the basename of the file. Steps to reproduce: $ wget https://raw.githubusercontent.com/wireshark/wireshark/master/asn1/snmp/snmp.asn $ erlc snmp.asn result: snmp.erl:6: can't find include file "RFC1157-SNMP.hrl" The reason is confusion between 'erlang module' and 'asn1 module'. asn1ct generates a .erl and .hrl files with basenames same as the .asn file, but the code try to include the asn1module.hrl (which does not exist). The code which generates the -include line is in lib/asn1/src/asn1ct_gen.erl:gen_head Regards, yannay -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Sun May 10 12:00:19 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 10 May 2015 12:00:19 +0200 Subject: [erlang-bugs] Observer Crashdump Viewer bug? In-Reply-To: References: Message-ID: On Fri, Apr 24, 2015 at 10:35 PM, Tuncer Ayaz wrote: > 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. So, can nobody else reproduce this? From jargon@REDACTED Sun May 10 22:47:12 2015 From: jargon@REDACTED (Johannes =?utf-8?B?V2Vpw59s?=) Date: Sun, 10 May 2015 20:47:12 +0000 Subject: [erlang-bugs] ^G-q in remote shell quits erlang node Message-ID: <20150510204712.GA23581@molb.org> Hello, I experienced a very worrisome behavior: After connecting to an Erlang node with "-remsh", typing "^G-q" (JCL mode) quit the production node (!), not the maintenance shell: (node@REDACTED)2> User switch command --> q heart: Fri May 8 14:23:03 2015: Erlang has closed. Killed sh: echo: I/O error I could not reproduce that in an example, but it happened twice on a production node. Has anybody ever had this problem? Has anybody an idea how this can happen and where the bug could be located? The system is OTP 17.4 running on Debian Jessie. The node is started by a shell init script using "run_erl -daemon", /sbin/init is systemd. Regards, Johannes From bjorn@REDACTED Mon May 11 06:11:49 2015 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 11 May 2015 06:11:49 +0200 Subject: [erlang-bugs] asn1ct: cant build asn files with names which does not agree with module name In-Reply-To: References: Message-ID: On Sun, May 10, 2015 at 8:06 AM, yannay livneh wrote: > Hello, > > asn1ct can't build asn1 file which contain module with name that is not the > basename of the file. Yes. asn1ct assumes that the name of the ASN.1 spec and the basename of the file are the same. If there is an IMPORT statement in an ASN.1 spec, asn1ct will assume that the spec to be included is in a file whose basename is the same as the name of the spec. Therefore, it would not be trivial to lift the restriction that basename of the file and the of the ASN.1 spec must be the same. Therefore, you must rename your spec file to RFC1157-SNMP.asn. However, there is a way to force the name of the generated erlang module to be named 'snmp'. See the description of multi-file compilation in the User's Guide. Here is a direct link: http://www.erlang.org/doc/apps/asn1/asn1_ug.html#id62887 (This link works now but we still stop working when we release OTP 18.) /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From sdl.web@REDACTED Tue May 12 08:01:03 2015 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 12 May 2015 14:01:03 +0800 Subject: [erlang-bugs] make install-docs failed Message-ID: Something breaks `make install-docs' since 2015-04-27 my last successful build on Mac OSX Yosemite. make[6]: Nothing to be done for `release_docs_spec'. /Applications/Xcode.app/Contents/Developer/usr/bin/make RELEASE_PATH="/usr/local/unix/erlang/18.0/lib/erlang" release_docs_spec (cd ../../java_src;javadoc -sourcepath . -d ../doc/html/java \ -windowtitle 'Java-Erlang Interface Library' com.ericsson.otp.erlang) Loading source files for package com.ericsson.otp.erlang... Constructing Javadoc information... Standard Doclet version 1.8.0_31 Building tree for all the packages and classes... Generating ../doc/html/java/com/ericsson/otp/erlang/AbstractConnection.html... ./com/ericsson/otp/erlang/AbstractConnection.java:211: warning: no @param for e public abstract void deliver(Exception e); ^ ./com/ericsson/otp/erlang/AbstractConnection.java:216: warning: no @param for msg public abstract void deliver(OtpMsg msg); ^ ./com/ericsson/otp/erlang/AbstractConnection.java:230: warning: no @param for from protected void sendBuf(final OtpErlangPid from, final String dest, ^ ./com/ericsson/otp/erlang/AbstractConnection.java:275: warning: no @param for from protected void sendBuf(final OtpErlangPid from, final OtpErlangPid dest, ^ ./com/ericsson/otp/erlang/AbstractConnection.java:384: warning: no @param for from protected void sendLink(final OtpErlangPid from, final OtpErlangPid dest) ^ ./com/ericsson/otp/erlang/AbstractConnection.java:421: warning: no @param for from protected void sendUnlink(final OtpErlangPid from, final OtpErlangPid dest) ^ ./com/ericsson/otp/erlang/AbstractConnection.java:464: warning: no @param for from protected void sendExit2(final OtpErlangPid from, final OtpErlangPid dest, ^ ./com/ericsson/otp/erlang/AbstractConnection.java:41: warning: empty

tag *

^ ./com/ericsson/otp/erlang/AbstractConnection.java:177: warning: no @param for self protected AbstractConnection(final OtpLocalNode self, final OtpPeer other) ^ ./com/ericsson/otp/erlang/AbstractConnection.java:177: warning: no @param for other protected AbstractConnection(final OtpLocalNode self, final OtpPeer other) ^ ./com/ericsson/otp/erlang/AbstractConnection.java:137: warning: no @param for self protected AbstractConnection(final OtpLocalNode self, final OtpTransport s) ^ ./com/ericsson/otp/erlang/AbstractConnection.java:137: warning: no @param for s protected AbstractConnection(final OtpLocalNode self, final OtpTransport s) ^ Generating ../doc/html/java/com/ericsson/otp/erlang/AbstractNode.html... ./com/ericsson/otp/erlang/AbstractNode.java:272: warning: no @param for cookie public String setCookie(final String cookie) { ^ ./com/ericsson/otp/erlang/OtpTransportFactory.java:96: warning: no description for @throws * @throws IOException ^ ./com/ericsson/otp/erlang/OtpTransportFactory.java:109: warning: no description for @throws * @throws IOException ^ ./com/ericsson/otp/erlang/OtpTransportFactory.java:120: warning: no description for @throws * @throws IOException ^ ./com/ericsson/otp/erlang/AbstractNode.java:158: warning: no @param for node protected AbstractNode(final String node) { ^ ./com/ericsson/otp/erlang/AbstractNode.java:166: warning: no @param for node protected AbstractNode(final String node, ^ ./com/ericsson/otp/erlang/AbstractNode.java:166: warning: no @param for transportFactory protected AbstractNode(final String node, ^ ./com/ericsson/otp/erlang/AbstractNode.java:174: warning: no @param for name protected AbstractNode(final String name, final String cookie) { ^ ./com/ericsson/otp/erlang/AbstractNode.java:174: warning: no @param for cookie protected AbstractNode(final String name, final String cookie) { ^ ./com/ericsson/otp/erlang/AbstractNode.java:181: warning: no @param for name protected AbstractNode(final String name, final String cookie, ^ ./com/ericsson/otp/erlang/AbstractNode.java:181: warning: no @param for cookie protected AbstractNode(final String name, final String cookie, ^ ./com/ericsson/otp/erlang/AbstractNode.java:181: warning: no @param for transportFactory protected AbstractNode(final String name, final String cookie, ^ Generating ../doc/html/java/com/ericsson/otp/erlang/GenericQueue.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpAuthException.html... ./com/ericsson/otp/erlang/OtpAuthException.java:34: warning: no @param for s public OtpAuthException(final String s) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpConnection.html... ./com/ericsson/otp/erlang/OtpConnection.java:123: warning: no @return public int msgCount() { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpCookedConnection.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpEpmd.html... ./com/ericsson/otp/erlang/OtpEpmd.java:106: warning: no @param for port public static void useEpmdPort(final int port) { ^ ./com/ericsson/otp/erlang/OtpEpmd.java:119: warning: no @param for node public static int lookupPort(final AbstractNode node) throws IOException { ^ ./com/ericsson/otp/erlang/OtpEpmd.java:157: warning: no @param for node public static void unPublishPort(final OtpLocalNode node) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangAtom.html... ./com/ericsson/otp/erlang/OtpErlangObject.java:92: warning: no @param for public boolean match(final OtpErlangObject term, final T binds) { ^ ./com/ericsson/otp/erlang/OtpErlangObject.java:103: warning: no description for @throws * @throws OtpErlangException ^ ./com/ericsson/otp/erlang/OtpErlangObject.java:105: warning: no @param for public OtpErlangObject bind(final T binds) throws OtpErlangException { ^ ./com/ericsson/otp/erlang/OtpErlangAtom.java:76: warning: no @param for t public OtpErlangAtom(final boolean t) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangBinary.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangBitstr.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangBoolean.html... ./com/ericsson/otp/erlang/OtpErlangBoolean.java:49: warning: no @param for buf public OtpErlangBoolean(final OtpInputStream buf) ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangByte.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangChar.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangDecodeException.html... ./com/ericsson/otp/erlang/OtpErlangDecodeException.java:34: warning: no @param for msg public OtpErlangDecodeException(final String msg) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangDouble.html... ./com/ericsson/otp/erlang/OtpErlangDouble.java:36: warning: no @param for d public OtpErlangDouble(final double d) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangException.html... ./com/ericsson/otp/erlang/OtpErlangException.java:37: warning: no @param for msg public OtpErlangException(final String msg) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangExit.html... ./com/ericsson/otp/erlang/OtpErlangExit.java:102: warning: no @return public OtpErlangObject reason() { ^ ./com/ericsson/otp/erlang/OtpErlangExit.java:109: warning: no @return public OtpErlangPid pid() { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangExternalFun.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangFloat.html... ./com/ericsson/otp/erlang/OtpErlangFloat.java:31: warning: no @param for f public OtpErlangFloat(final float f) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangFun.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangInt.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangList.html... ./com/ericsson/otp/erlang/OtpErlangList.java:94: warning: no description for @param * @param lastTail ^ ./com/ericsson/otp/erlang/OtpErlangList.java:95: warning: no description for @throws * @throws OtpErlangException ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangList.SubList.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangLong.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangMap.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangObject.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangObject.Hash.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangPid.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangPort.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangRangeException.html... ./com/ericsson/otp/erlang/OtpErlangRangeException.java:39: warning: no @param for msg public OtpErlangRangeException(final String msg) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangRef.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangShort.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangString.html... ./com/ericsson/otp/erlang/OtpErlangString.java:188: warning: no @param for bytes public static String newString(final byte[] bytes) { ^ ./com/ericsson/otp/erlang/OtpErlangString.java:188: warning: no @return public static String newString(final byte[] bytes) { ^ ./com/ericsson/otp/erlang/OtpErlangString.java:48: warning: no @param for list public OtpErlangString(final OtpErlangList list) throws OtpErlangException { ^ ./com/ericsson/otp/erlang/OtpErlangString.java:35: warning: no @param for str public OtpErlangString(final String str) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangTuple.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangUInt.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangUShort.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpException.html... ./com/ericsson/otp/erlang/OtpException.java:37: warning: no @param for msg public OtpException(final String msg) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpExternal.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpInputStream.html... ./com/ericsson/otp/erlang/OtpInputStream.java:112: warning: no @param for abuf public int readN(final byte[] abuf) throws OtpErlangDecodeException { ^ ./com/ericsson/otp/erlang/OtpInputStream.java:125: warning: no @param for abuf public int readN(final byte[] abuf, final int off, final int len) ^ ./com/ericsson/otp/erlang/OtpInputStream.java:125: warning: no @param for off public int readN(final byte[] abuf, final int off, final int len) ^ ./com/ericsson/otp/erlang/OtpInputStream.java:125: warning: no @param for len public int readN(final byte[] abuf, final int off, final int len) ^ ./com/ericsson/otp/erlang/OtpInputStream.java:140: warning: no @return public int peek() throws OtpErlangDecodeException { ^ ./com/ericsson/otp/erlang/OtpInputStream.java:140: warning: no @throws for com.ericsson.otp.erlang.OtpErlangDecodeException public int peek() throws OtpErlangDecodeException { ^ ./com/ericsson/otp/erlang/OtpInputStream.java:40: warning: no description for @param * @param buf ^ ./com/ericsson/otp/erlang/OtpInputStream.java:49: warning: no description for @param * @param flags ^ ./com/ericsson/otp/erlang/OtpInputStream.java:51: warning: no @param for buf public OtpInputStream(final byte[] buf, final int flags) { ^ ./com/ericsson/otp/erlang/OtpInputStream.java:60: warning: no description for @param * @param flags ^ ./com/ericsson/otp/erlang/OtpInputStream.java:62: warning: no @param for buf public OtpInputStream(final byte[] buf, final int offset, final int length, ^ ./com/ericsson/otp/erlang/OtpInputStream.java:62: warning: no @param for offset public OtpInputStream(final byte[] buf, final int offset, final int length, ^ ./com/ericsson/otp/erlang/OtpInputStream.java:62: warning: no @param for length public OtpInputStream(final byte[] buf, final int offset, final int length, ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpLocalNode.html... ./com/ericsson/otp/erlang/OtpLocalNode.java:37: warning: no @param for node protected OtpLocalNode(final String node) { ^ ./com/ericsson/otp/erlang/OtpLocalNode.java:46: warning: no @param for node protected OtpLocalNode(final String node, ^ ./com/ericsson/otp/erlang/OtpLocalNode.java:46: warning: no @param for transportFactory protected OtpLocalNode(final String node, ^ ./com/ericsson/otp/erlang/OtpLocalNode.java:55: warning: no @param for node protected OtpLocalNode(final String node, final String cookie) { ^ ./com/ericsson/otp/erlang/OtpLocalNode.java:55: warning: no @param for cookie protected OtpLocalNode(final String node, final String cookie) { ^ ./com/ericsson/otp/erlang/OtpLocalNode.java:63: warning: no @param for node protected OtpLocalNode(final String node, final String cookie, ^ ./com/ericsson/otp/erlang/OtpLocalNode.java:63: warning: no @param for cookie protected OtpLocalNode(final String node, final String cookie, ^ ./com/ericsson/otp/erlang/OtpLocalNode.java:63: warning: no @param for transportFactory protected OtpLocalNode(final String node, final String cookie, ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpMbox.html... ./com/ericsson/otp/erlang/OtpMbox.java:427: warning: no @param for reason public void exit(final String reason) { ^ ./com/ericsson/otp/erlang/OtpMbox.java:458: warning: no @param for to public void exit(final OtpErlangPid to, final String reason) { ^ ./com/ericsson/otp/erlang/OtpMbox.java:458: warning: no @param for reason public void exit(final OtpErlangPid to, final String reason) { ^ ./com/ericsson/otp/erlang/OtpMbox.java:598: warning: no @return public boolean ping(final String node, final long timeout) { ^ ./com/ericsson/otp/erlang/OtpMbox.java:632: warning: no @param for aname public OtpErlangPid whereis(final String aname) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpMsg.html... ./com/ericsson/otp/erlang/OtpMsg.java:191: warning: no @return public int type() { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpNode.html... ./com/ericsson/otp/erlang/OtpNode.java:384: warning: no @param for name public OtpErlangPid whereis(final String name) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpNode.Acceptor.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpNode.Mailboxes.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpNodeStatus.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpOutputStream.html... ./com/ericsson/otp/erlang/OtpOutputStream.java:70: warning: no @param for size public OtpOutputStream(final int size) { ^ ./com/ericsson/otp/erlang/OtpOutputStream.java:77: warning: no @param for o public OtpOutputStream(final OtpErlangObject o) { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpPeer.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpSelf.html... ./com/ericsson/otp/erlang/OtpSelf.java:156: error: @param name not found * @param transportFactory ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpServer.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpServerSocketTransport.html... ./com/ericsson/otp/erlang/OtpServerTransport.java:35: warning: no @return int getLocalPort(); ^ ./com/ericsson/otp/erlang/OtpServerTransport.java:40: warning: no @return OtpTransport accept() throws IOException; ^ ./com/ericsson/otp/erlang/OtpServerTransport.java:40: warning: no @throws for java.io.IOException OtpTransport accept() throws IOException; ^ ./com/ericsson/otp/erlang/OtpServerTransport.java:45: warning: no @throws for java.io.IOException void close() throws IOException; ^ ./com/ericsson/otp/erlang/OtpServerSocketTransport.java:41: warning: no @param for port public OtpServerSocketTransport(final int port) throws IOException { ^ ./com/ericsson/otp/erlang/OtpServerSocketTransport.java:41: warning: no @throws for java.io.IOException public OtpServerSocketTransport(final int port) throws IOException { ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpServerTransport.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpSocketTransport.html... ./com/ericsson/otp/erlang/OtpTransport.java:37: warning: no @return public abstract InputStream getInputStream() throws IOException; ^ ./com/ericsson/otp/erlang/OtpTransport.java:37: warning: no @throws for java.io.IOException public abstract InputStream getInputStream() throws IOException; ^ ./com/ericsson/otp/erlang/OtpTransport.java:42: warning: no @return public abstract OutputStream getOutputStream() throws IOException; ^ ./com/ericsson/otp/erlang/OtpTransport.java:42: warning: no @throws for java.io.IOException public abstract OutputStream getOutputStream() throws IOException; ^ ./com/ericsson/otp/erlang/OtpTransport.java:47: warning: no @throws for java.io.IOException public abstract void close() throws IOException; ^ ./com/ericsson/otp/erlang/OtpSocketTransport.java:53: warning: no @param for addr public OtpSocketTransport(final InetAddress addr, final int port) ^ ./com/ericsson/otp/erlang/OtpSocketTransport.java:53: warning: no @param for port public OtpSocketTransport(final InetAddress addr, final int port) ^ ./com/ericsson/otp/erlang/OtpSocketTransport.java:53: warning: no @throws for java.net.UnknownHostException public OtpSocketTransport(final InetAddress addr, final int port) ^ ./com/ericsson/otp/erlang/OtpSocketTransport.java:53: warning: no @throws for java.io.IOException public OtpSocketTransport(final InetAddress addr, final int port) ^ ./com/ericsson/otp/erlang/OtpSocketTransport.java:44: warning: no @param for addr public OtpSocketTransport(final String addr, final int port) ^ ./com/ericsson/otp/erlang/OtpSocketTransport.java:44: warning: no @param for port public OtpSocketTransport(final String addr, final int port) ^ ./com/ericsson/otp/erlang/OtpSocketTransport.java:44: warning: no @throws for java.net.UnknownHostException public OtpSocketTransport(final String addr, final int port) ^ ./com/ericsson/otp/erlang/OtpSocketTransport.java:44: warning: no @throws for java.io.IOException public OtpSocketTransport(final String addr, final int port) ^ Generating ../doc/html/java/com/ericsson/otp/erlang/OtpSocketTransportFactory.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpTransport.html... Generating ../doc/html/java/com/ericsson/otp/erlang/OtpTransportFactory.html... Generating ../doc/html/java/com/ericsson/otp/erlang/package-frame.html... Generating ../doc/html/java/com/ericsson/otp/erlang/package-summary.html... Generating ../doc/html/java/com/ericsson/otp/erlang/package-tree.html... Generating ../doc/html/java/constant-values.html... Generating ../doc/html/java/serialized-form.html... Building index for all the packages and classes... Generating ../doc/html/java/overview-tree.html... Generating ../doc/html/java/index-all.html... Generating ../doc/html/java/deprecated-list.html... Building index for all classes... Generating ../doc/html/java/allclasses-frame.html... Generating ../doc/html/java/allclasses-noframe.html... Generating ../doc/html/java/index.html... Generating ../doc/html/java/help-doc.html... 1 error 97 warnings make[5]: *** [jdoc] Error 1 make[4]: *** [release_docs] Error 2 make[3]: *** [release_docs] Error 2 make[2]: *** [release_docs] Error 2 make[1]: *** [release_docs] Error 2 make: *** [install-docs] Error 2 From vladdu55@REDACTED Tue May 12 08:27:56 2015 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 12 May 2015 08:27:56 +0200 Subject: [erlang-bugs] make install-docs failed In-Reply-To: References: Message-ID: Hi, https://github.com/erlang/otp/pull/716 regards, Vlad On Tue, May 12, 2015 at 8:01 AM, Leo Liu wrote: > Something breaks `make install-docs' since 2015-04-27 my last successful > build on Mac OSX Yosemite. > > make[6]: Nothing to be done for `release_docs_spec'. > /Applications/Xcode.app/Contents/Developer/usr/bin/make > RELEASE_PATH="/usr/local/unix/erlang/18.0/lib/erlang" release_docs_spec > (cd ../../java_src;javadoc -sourcepath . -d ../doc/html/java \ > -windowtitle 'Java-Erlang Interface Library' > com.ericsson.otp.erlang) > Loading source files for package com.ericsson.otp.erlang... > Constructing Javadoc information... > Standard Doclet version 1.8.0_31 > Building tree for all the packages and classes... > Generating > ../doc/html/java/com/ericsson/otp/erlang/AbstractConnection.html... > ./com/ericsson/otp/erlang/AbstractConnection.java:211: warning: no @param > for e > public abstract void deliver(Exception e); > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:216: warning: no @param > for msg > public abstract void deliver(OtpMsg msg); > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:230: warning: no @param > for from > protected void sendBuf(final OtpErlangPid from, final String dest, > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:275: warning: no @param > for from > protected void sendBuf(final OtpErlangPid from, final OtpErlangPid > dest, > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:384: warning: no @param > for from > protected void sendLink(final OtpErlangPid from, final OtpErlangPid > dest) > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:421: warning: no @param > for from > protected void sendUnlink(final OtpErlangPid from, final OtpErlangPid > dest) > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:464: warning: no @param > for from > protected void sendExit2(final OtpErlangPid from, final OtpErlangPid > dest, > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:41: warning: empty

> tag > *

> ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:177: warning: no @param > for self > protected AbstractConnection(final OtpLocalNode self, final OtpPeer > other) > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:177: warning: no @param > for other > protected AbstractConnection(final OtpLocalNode self, final OtpPeer > other) > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:137: warning: no @param > for self > protected AbstractConnection(final OtpLocalNode self, final > OtpTransport s) > ^ > ./com/ericsson/otp/erlang/AbstractConnection.java:137: warning: no @param > for s > protected AbstractConnection(final OtpLocalNode self, final > OtpTransport s) > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/AbstractNode.html... > ./com/ericsson/otp/erlang/AbstractNode.java:272: warning: no @param for > cookie > public String setCookie(final String cookie) { > ^ > ./com/ericsson/otp/erlang/OtpTransportFactory.java:96: warning: no > description for @throws > * @throws IOException > ^ > ./com/ericsson/otp/erlang/OtpTransportFactory.java:109: warning: no > description for @throws > * @throws IOException > ^ > ./com/ericsson/otp/erlang/OtpTransportFactory.java:120: warning: no > description for @throws > * @throws IOException > ^ > ./com/ericsson/otp/erlang/AbstractNode.java:158: warning: no @param for > node > protected AbstractNode(final String node) { > ^ > ./com/ericsson/otp/erlang/AbstractNode.java:166: warning: no @param for > node > protected AbstractNode(final String node, > ^ > ./com/ericsson/otp/erlang/AbstractNode.java:166: warning: no @param for > transportFactory > protected AbstractNode(final String node, > ^ > ./com/ericsson/otp/erlang/AbstractNode.java:174: warning: no @param for > name > protected AbstractNode(final String name, final String cookie) { > ^ > ./com/ericsson/otp/erlang/AbstractNode.java:174: warning: no @param for > cookie > protected AbstractNode(final String name, final String cookie) { > ^ > ./com/ericsson/otp/erlang/AbstractNode.java:181: warning: no @param for > name > protected AbstractNode(final String name, final String cookie, > ^ > ./com/ericsson/otp/erlang/AbstractNode.java:181: warning: no @param for > cookie > protected AbstractNode(final String name, final String cookie, > ^ > ./com/ericsson/otp/erlang/AbstractNode.java:181: warning: no @param for > transportFactory > protected AbstractNode(final String name, final String cookie, > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/GenericQueue.html... > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpAuthException.html... > ./com/ericsson/otp/erlang/OtpAuthException.java:34: warning: no @param for > s > public OtpAuthException(final String s) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpConnection.html... > ./com/ericsson/otp/erlang/OtpConnection.java:123: warning: no @return > public int msgCount() { > ^ > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpCookedConnection.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpEpmd.html... > ./com/ericsson/otp/erlang/OtpEpmd.java:106: warning: no @param for port > public static void useEpmdPort(final int port) { > ^ > ./com/ericsson/otp/erlang/OtpEpmd.java:119: warning: no @param for node > public static int lookupPort(final AbstractNode node) throws > IOException { > ^ > ./com/ericsson/otp/erlang/OtpEpmd.java:157: warning: no @param for node > public static void unPublishPort(final OtpLocalNode node) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangAtom.html... > ./com/ericsson/otp/erlang/OtpErlangObject.java:92: warning: no @param for > > public boolean match(final OtpErlangObject term, final T binds) { > ^ > ./com/ericsson/otp/erlang/OtpErlangObject.java:103: warning: no > description for @throws > * @throws OtpErlangException > ^ > ./com/ericsson/otp/erlang/OtpErlangObject.java:105: warning: no @param for > > public OtpErlangObject bind(final T binds) throws > OtpErlangException { > ^ > ./com/ericsson/otp/erlang/OtpErlangAtom.java:76: warning: no @param for t > public OtpErlangAtom(final boolean t) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangBinary.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangBitstr.html... > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpErlangBoolean.html... > ./com/ericsson/otp/erlang/OtpErlangBoolean.java:49: warning: no @param for > buf > public OtpErlangBoolean(final OtpInputStream buf) > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangByte.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangChar.html... > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpErlangDecodeException.html... > ./com/ericsson/otp/erlang/OtpErlangDecodeException.java:34: warning: no > @param for msg > public OtpErlangDecodeException(final String msg) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangDouble.html... > ./com/ericsson/otp/erlang/OtpErlangDouble.java:36: warning: no @param for d > public OtpErlangDouble(final double d) { > ^ > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpErlangException.html... > ./com/ericsson/otp/erlang/OtpErlangException.java:37: warning: no @param > for msg > public OtpErlangException(final String msg) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangExit.html... > ./com/ericsson/otp/erlang/OtpErlangExit.java:102: warning: no @return > public OtpErlangObject reason() { > ^ > ./com/ericsson/otp/erlang/OtpErlangExit.java:109: warning: no @return > public OtpErlangPid pid() { > ^ > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpErlangExternalFun.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangFloat.html... > ./com/ericsson/otp/erlang/OtpErlangFloat.java:31: warning: no @param for f > public OtpErlangFloat(final float f) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangFun.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangInt.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangList.html... > ./com/ericsson/otp/erlang/OtpErlangList.java:94: warning: no description > for @param > * @param lastTail > ^ > ./com/ericsson/otp/erlang/OtpErlangList.java:95: warning: no description > for @throws > * @throws OtpErlangException > ^ > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpErlangList.SubList.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangLong.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangMap.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangObject.html... > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpErlangObject.Hash.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangPid.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangPort.html... > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpErlangRangeException.html... > ./com/ericsson/otp/erlang/OtpErlangRangeException.java:39: warning: no > @param for msg > public OtpErlangRangeException(final String msg) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangRef.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangShort.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangString.html... > ./com/ericsson/otp/erlang/OtpErlangString.java:188: warning: no @param for > bytes > public static String newString(final byte[] bytes) { > ^ > ./com/ericsson/otp/erlang/OtpErlangString.java:188: warning: no @return > public static String newString(final byte[] bytes) { > ^ > ./com/ericsson/otp/erlang/OtpErlangString.java:48: warning: no @param for > list > public OtpErlangString(final OtpErlangList list) throws > OtpErlangException { > ^ > ./com/ericsson/otp/erlang/OtpErlangString.java:35: warning: no @param for > str > public OtpErlangString(final String str) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangTuple.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangUInt.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpErlangUShort.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpException.html... > ./com/ericsson/otp/erlang/OtpException.java:37: warning: no @param for msg > public OtpException(final String msg) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpExternal.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpInputStream.html... > ./com/ericsson/otp/erlang/OtpInputStream.java:112: warning: no @param for > abuf > public int readN(final byte[] abuf) throws OtpErlangDecodeException { > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:125: warning: no @param for > abuf > public int readN(final byte[] abuf, final int off, final int len) > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:125: warning: no @param for > off > public int readN(final byte[] abuf, final int off, final int len) > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:125: warning: no @param for > len > public int readN(final byte[] abuf, final int off, final int len) > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:140: warning: no @return > public int peek() throws OtpErlangDecodeException { > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:140: warning: no @throws for > com.ericsson.otp.erlang.OtpErlangDecodeException > public int peek() throws OtpErlangDecodeException { > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:40: warning: no description > for @param > * @param buf > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:49: warning: no description > for @param > * @param flags > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:51: warning: no @param for > buf > public OtpInputStream(final byte[] buf, final int flags) { > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:60: warning: no description > for @param > * @param flags > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:62: warning: no @param for > buf > public OtpInputStream(final byte[] buf, final int offset, final int > length, > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:62: warning: no @param for > offset > public OtpInputStream(final byte[] buf, final int offset, final int > length, > ^ > ./com/ericsson/otp/erlang/OtpInputStream.java:62: warning: no @param for > length > public OtpInputStream(final byte[] buf, final int offset, final int > length, > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpLocalNode.html... > ./com/ericsson/otp/erlang/OtpLocalNode.java:37: warning: no @param for node > protected OtpLocalNode(final String node) { > ^ > ./com/ericsson/otp/erlang/OtpLocalNode.java:46: warning: no @param for node > protected OtpLocalNode(final String node, > ^ > ./com/ericsson/otp/erlang/OtpLocalNode.java:46: warning: no @param for > transportFactory > protected OtpLocalNode(final String node, > ^ > ./com/ericsson/otp/erlang/OtpLocalNode.java:55: warning: no @param for node > protected OtpLocalNode(final String node, final String cookie) { > ^ > ./com/ericsson/otp/erlang/OtpLocalNode.java:55: warning: no @param for > cookie > protected OtpLocalNode(final String node, final String cookie) { > ^ > ./com/ericsson/otp/erlang/OtpLocalNode.java:63: warning: no @param for node > protected OtpLocalNode(final String node, final String cookie, > ^ > ./com/ericsson/otp/erlang/OtpLocalNode.java:63: warning: no @param for > cookie > protected OtpLocalNode(final String node, final String cookie, > ^ > ./com/ericsson/otp/erlang/OtpLocalNode.java:63: warning: no @param for > transportFactory > protected OtpLocalNode(final String node, final String cookie, > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpMbox.html... > ./com/ericsson/otp/erlang/OtpMbox.java:427: warning: no @param for reason > public void exit(final String reason) { > ^ > ./com/ericsson/otp/erlang/OtpMbox.java:458: warning: no @param for to > public void exit(final OtpErlangPid to, final String reason) { > ^ > ./com/ericsson/otp/erlang/OtpMbox.java:458: warning: no @param for reason > public void exit(final OtpErlangPid to, final String reason) { > ^ > ./com/ericsson/otp/erlang/OtpMbox.java:598: warning: no @return > public boolean ping(final String node, final long timeout) { > ^ > ./com/ericsson/otp/erlang/OtpMbox.java:632: warning: no @param for aname > public OtpErlangPid whereis(final String aname) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpMsg.html... > ./com/ericsson/otp/erlang/OtpMsg.java:191: warning: no @return > public int type() { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpNode.html... > ./com/ericsson/otp/erlang/OtpNode.java:384: warning: no @param for name > public OtpErlangPid whereis(final String name) { > ^ > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpNode.Acceptor.html... > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpNode.Mailboxes.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpNodeStatus.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpOutputStream.html... > ./com/ericsson/otp/erlang/OtpOutputStream.java:70: warning: no @param for > size > public OtpOutputStream(final int size) { > ^ > ./com/ericsson/otp/erlang/OtpOutputStream.java:77: warning: no @param for o > public OtpOutputStream(final OtpErlangObject o) { > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpPeer.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpSelf.html... > ./com/ericsson/otp/erlang/OtpSelf.java:156: error: @param name not found > * @param transportFactory > ^ > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpServer.html... > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpServerSocketTransport.html... > ./com/ericsson/otp/erlang/OtpServerTransport.java:35: warning: no @return > int getLocalPort(); > ^ > ./com/ericsson/otp/erlang/OtpServerTransport.java:40: warning: no @return > OtpTransport accept() throws IOException; > ^ > ./com/ericsson/otp/erlang/OtpServerTransport.java:40: warning: no @throws > for java.io.IOException > OtpTransport accept() throws IOException; > ^ > ./com/ericsson/otp/erlang/OtpServerTransport.java:45: warning: no @throws > for java.io.IOException > void close() throws IOException; > ^ > ./com/ericsson/otp/erlang/OtpServerSocketTransport.java:41: warning: no > @param for port > public OtpServerSocketTransport(final int port) throws IOException { > ^ > ./com/ericsson/otp/erlang/OtpServerSocketTransport.java:41: warning: no > @throws for java.io.IOException > public OtpServerSocketTransport(final int port) throws IOException { > ^ > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpServerTransport.html... > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpSocketTransport.html... > ./com/ericsson/otp/erlang/OtpTransport.java:37: warning: no @return > public abstract InputStream getInputStream() throws IOException; > ^ > ./com/ericsson/otp/erlang/OtpTransport.java:37: warning: no @throws for > java.io.IOException > public abstract InputStream getInputStream() throws IOException; > ^ > ./com/ericsson/otp/erlang/OtpTransport.java:42: warning: no @return > public abstract OutputStream getOutputStream() throws IOException; > ^ > ./com/ericsson/otp/erlang/OtpTransport.java:42: warning: no @throws for > java.io.IOException > public abstract OutputStream getOutputStream() throws IOException; > ^ > ./com/ericsson/otp/erlang/OtpTransport.java:47: warning: no @throws for > java.io.IOException > public abstract void close() throws IOException; > ^ > ./com/ericsson/otp/erlang/OtpSocketTransport.java:53: warning: no @param > for addr > public OtpSocketTransport(final InetAddress addr, final int port) > ^ > ./com/ericsson/otp/erlang/OtpSocketTransport.java:53: warning: no @param > for port > public OtpSocketTransport(final InetAddress addr, final int port) > ^ > ./com/ericsson/otp/erlang/OtpSocketTransport.java:53: warning: no @throws > for java.net.UnknownHostException > public OtpSocketTransport(final InetAddress addr, final int port) > ^ > ./com/ericsson/otp/erlang/OtpSocketTransport.java:53: warning: no @throws > for java.io.IOException > public OtpSocketTransport(final InetAddress addr, final int port) > ^ > ./com/ericsson/otp/erlang/OtpSocketTransport.java:44: warning: no @param > for addr > public OtpSocketTransport(final String addr, final int port) > ^ > ./com/ericsson/otp/erlang/OtpSocketTransport.java:44: warning: no @param > for port > public OtpSocketTransport(final String addr, final int port) > ^ > ./com/ericsson/otp/erlang/OtpSocketTransport.java:44: warning: no @throws > for java.net.UnknownHostException > public OtpSocketTransport(final String addr, final int port) > ^ > ./com/ericsson/otp/erlang/OtpSocketTransport.java:44: warning: no @throws > for java.io.IOException > public OtpSocketTransport(final String addr, final int port) > ^ > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpSocketTransportFactory.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/OtpTransport.html... > Generating > ../doc/html/java/com/ericsson/otp/erlang/OtpTransportFactory.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/package-frame.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/package-summary.html... > Generating ../doc/html/java/com/ericsson/otp/erlang/package-tree.html... > Generating ../doc/html/java/constant-values.html... > Generating ../doc/html/java/serialized-form.html... > Building index for all the packages and classes... > Generating ../doc/html/java/overview-tree.html... > Generating ../doc/html/java/index-all.html... > Generating ../doc/html/java/deprecated-list.html... > Building index for all classes... > Generating ../doc/html/java/allclasses-frame.html... > Generating ../doc/html/java/allclasses-noframe.html... > Generating ../doc/html/java/index.html... > Generating ../doc/html/java/help-doc.html... > 1 error > 97 warnings > make[5]: *** [jdoc] Error 1 > make[4]: *** [release_docs] Error 2 > make[3]: *** [release_docs] Error 2 > make[2]: *** [release_docs] Error 2 > make[1]: *** [release_docs] Error 2 > make: *** [install-docs] Error 2 > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Wed May 13 22:40:56 2015 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 13 May 2015 22:40:56 +0200 Subject: [erlang-bugs] Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5) In-Reply-To: References: Message-ID: I have benchmarked with Erlang 18.0-rc2 and all the issues I have mentioned here have been resolved. Thanks OTP! *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer 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 > > 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 daniel.goertzen@REDACTED Thu May 14 18:17:33 2015 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Thu, 14 May 2015 11:17:33 -0500 Subject: [erlang-bugs] 18.0-rc2 erlc segfaults building hipe Message-ID: As the title says, rc2 fails to build. Error output below. Rc1 does not have a problem. When I build with libSegFault turned on, "erts_check_next_timeout_time" gets a mention. My build environment is a 32 bit Gentoo chroot living in 64 bit Kubuntu-15.04. Erlang is built as part of a larger make process. My configure line is: ./configure \ --prefix=/usr/local/ \ --enable-ethread-pre-pentium4-compatibility \ --without-javac \ --disable-hipe \ --enable-dynamic-ssl-lib \ --enable-dirty-schedulers \ === Entering application hipe make[4]: Entering directory '/device/otp/lib/hipe/misc' ERLC ../ebin/hipe_consttab.beam /bin/sh: line 1: 9875 Segmentation fault (core dumped) erlc -W +debug_info +warn_exported_vars +warn_missing_spec +warn_untyped_record -o../ebin hipe_consttab.erl /device/otp/make/i686-pc-linux-gnu/otp.mk:122: recipe for target '../ebin/hipe_consttab.beam' failed make[4]: *** [../ebin/hipe_consttab.beam] Error 139 make[4]: Leaving directory '/device/otp/lib/hipe/misc' /device/otp/make/otp_subdir.mk:28: recipe for target 'opt' failed make[3]: *** [opt] Error 2 make[3]: Leaving directory '/device/otp/lib/hipe' /device/otp/make/otp_subdir.mk:28: recipe for target 'opt' failed make[2]: *** [opt] Error 2 make[2]: Leaving directory '/device/otp/lib' Makefile:549: recipe for target 'secondary_bootstrap_build' failed make[1]: *** [secondary_bootstrap_build] Error 2 make[1]: Leaving directory '/device/otp' Makefile:224: recipe for target 'otp.stamp' failed make: *** [otp.stamp] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Thu May 14 18:21:43 2015 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Thu, 14 May 2015 11:21:43 -0500 Subject: [erlang-bugs] 18.0-rc2 erlc segfaults building hipe In-Reply-To: References: Message-ID: Never mind, I just saw the thread in erlang-questions about this. On Thu, May 14, 2015 at 11:17 AM, Daniel Goertzen wrote: > As the title says, rc2 fails to build. Error output below. Rc1 does not > have a problem. When I build with libSegFault turned on, > "erts_check_next_timeout_time" gets a mention. > > My build environment is a 32 bit Gentoo chroot living in 64 bit > Kubuntu-15.04. Erlang is built as part of a larger make process. My > configure line is: > > ./configure \ > --prefix=/usr/local/ \ > --enable-ethread-pre-pentium4-compatibility \ > --without-javac \ > --disable-hipe \ > --enable-dynamic-ssl-lib \ > --enable-dirty-schedulers \ > > > > === Entering application hipe > make[4]: Entering directory '/device/otp/lib/hipe/misc' > ERLC ../ebin/hipe_consttab.beam > /bin/sh: line 1: 9875 Segmentation fault (core dumped) erlc -W > +debug_info +warn_exported_vars +warn_missing_spec +warn_untyped_record > -o../ebin hipe_consttab.erl > /device/otp/make/i686-pc-linux-gnu/otp.mk:122: recipe for target > '../ebin/hipe_consttab.beam' failed > make[4]: *** [../ebin/hipe_consttab.beam] Error 139 > make[4]: Leaving directory '/device/otp/lib/hipe/misc' > /device/otp/make/otp_subdir.mk:28: recipe for target 'opt' failed > make[3]: *** [opt] Error 2 > make[3]: Leaving directory '/device/otp/lib/hipe' > /device/otp/make/otp_subdir.mk:28: recipe for target 'opt' failed > make[2]: *** [opt] Error 2 > make[2]: Leaving directory '/device/otp/lib' > Makefile:549: recipe for target 'secondary_bootstrap_build' failed > make[1]: *** [secondary_bootstrap_build] Error 2 > make[1]: Leaving directory '/device/otp' > Makefile:224: recipe for target 'otp.stamp' failed > make: *** [otp.stamp] Error 2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Fri May 15 14:18:49 2015 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 15 May 2015 14:18:49 +0200 Subject: [erlang-bugs] Segfault by purging native and reloading beam Message-ID: This one was a bit tricky to minimize: you have to load beam code, then remove it fully, then load native, remove it fully again, then reload the beam code. Repeatable every time on plain old R15B03-1 and about one in three times on 18.0. See example module. /Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.erl Type: application/octet-stream Size: 1296 bytes Desc: not available URL: From carlsson.richard@REDACTED Fri May 15 15:32:25 2015 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 15 May 2015 15:32:25 +0200 Subject: [erlang-bugs] Segfault by purging native and reloading beam In-Reply-To: References: Message-ID: cc:ing list. On Fri, May 15, 2015 at 3:19 PM, Jeremy Heater < jeremy.heater@REDACTED> wrote: > A useful observation maybe: in R16B01 it also always segfaults, and from > R16B02 onwards there is the behavior where it only segfaults from time to > time (it also happens in 17.1 and 17.4, what I had on hand to test). > > 2015-05-15 14:18 GMT+02:00 Richard Carlsson : > >> This one was a bit tricky to minimize: you have to load beam code, then >> remove it fully, then load native, remove it fully again, then reload the >> beam code. Repeatable every time on plain old R15B03-1 and about one in >> three times on 18.0. See example module. >> >> /Richard >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Fri May 15 15:32:51 2015 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 15 May 2015 15:32:51 +0200 Subject: [erlang-bugs] Segfault by purging native and reloading beam In-Reply-To: References: Message-ID: Forgot to include the crash information, but it looks like it's happening far away from where the corruption occurred, so not that much help: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fe8d2b33700 (LWP 18980)] process_main () at beam/beam_emu.c:2610 2610 result = (*bf)(c_p, reg, I); #0 process_main () at beam/beam_emu.c:2610 #1 0x00000000004a8548 in sched_thread_func (vesdp=0x7f5b3b250380) at beam/erl_process.c:5281 #2 0x00000000005be5d0 in thr_wrapper (vtwd=0x7fff4cdbf930) at pthread/ethread.c:106 #3 0x00007f5b3b8f7e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x00007f5b3b41c8bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x0000000000000000 in ?? () /Richard On Fri, May 15, 2015 at 2:18 PM, Richard Carlsson < carlsson.richard@REDACTED> wrote: > This one was a bit tricky to minimize: you have to load beam code, then > remove it fully, then load native, remove it fully again, then reload the > beam code. Repeatable every time on plain old R15B03-1 and about one in > three times on 18.0. See example module. > > /Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jargon@REDACTED Fri May 15 21:58:27 2015 From: jargon@REDACTED (Johannes =?utf-8?B?V2Vpw59s?=) Date: Fri, 15 May 2015 21:58:27 +0200 Subject: [erlang-bugs] ^G-q in remote shell quits erlang node In-Reply-To: <20150510204712.GA23581@molb.org> References: <20150510204712.GA23581@molb.org> Message-ID: <20150515195827.GA20161@molb.org> A short update: I ran "erl -remsh" in a screen session, maybe this has something to do with "^G-q" being transmitted to the production node. To mitigate the problem, I start the production node now with "+Bi" so that "^G-q" is forbidden there. Johannes On Sun, May 10, 2015 at 08:47PM +0000, Johannes Wei?l wrote: > Hello, > > I experienced a very worrisome behavior: After connecting to an Erlang > node with "-remsh", typing "^G-q" (JCL mode) quit the production node (!), > not the maintenance shell: > > (node@REDACTED)2> > User switch command > --> q > heart: Fri May 8 14:23:03 2015: Erlang has closed. > Killed > sh: echo: I/O error > > I could not reproduce that in an example, but it happened twice on a > production node. Has anybody ever had this problem? Has anybody an idea > how this can happen and where the bug could be located? > > The system is OTP 17.4 running on Debian Jessie. The node is started by > a shell init script using "run_erl -daemon", /sbin/init is systemd. > > Regards, > Johannes From rory@REDACTED Sun May 17 14:37:08 2015 From: rory@REDACTED (Rory Byrne) Date: Sun, 17 May 2015 13:37:08 +0100 Subject: [erlang-bugs] VM locking up 18.0-rc2 Message-ID: <20150517123708.GA9886@nybek.com> Hello, You can get example code showing this bug from: git clone https://gist.github.com/0b05a793f308044359ab.git Run the code as follows: 1> acceptor_pool:start_link(). Then connect to port 7777 on the local machine using any TCP client. For example, using curl: curl http://localhost:7777/ After the first connection, the VM will lock up and look like this: 1> acceptor_pool:start_link(). New acceptor started: <0.37.0> {ok,<0.36.0>} HERE 1 HERE 2 New acceptor started: <0.40.0> 2> I've tested this using the current master HEAD 9a81b28 (Wed May 13) on Linux on single and multi-processor machines (32 bit and 64 bit) and on FreeBSD. Notes: 1. The code works fine using the current maint branch (efbfe96): you can connect multiple times in succession with no problems. 2. The code works fine if you remove the following print statement from the bottom of acceptor_pool.erl: io:format("New acceptor started: ~p~n", [Pid]), 3. The code works fine if you change the following code in acceptor.erl: Self = self(), spawn(fun() -> acceptor_pool:create(AcceptorPool, Self) end), to: ok = acceptor_pool:create(AcceptorPool, self()), Let me know if you need anything further. Regards, Rory From rickard@REDACTED Wed May 20 23:37:49 2015 From: rickard@REDACTED (Rickard Green) Date: Wed, 20 May 2015 23:37:49 +0200 Subject: [erlang-bugs] VM locking up 18.0-rc2 In-Reply-To: <20150517123708.GA9886@nybek.com> References: <20150517123708.GA9886@nybek.com> Message-ID: > After the first connection, the VM will lock up and look like this: > > 1> acceptor_pool:start_link(). > New acceptor started: <0.37.0> > {ok,<0.36.0>} > HERE 1 > HERE 2 > New acceptor started: <0.40.0> > 2> > Thanks for the bug report! A fix for this will soon show up in the master branch. Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB From gomoripeti@REDACTED Thu May 21 16:13:00 2015 From: gomoripeti@REDACTED (=?UTF-8?B?UGV0aSBHw7Ztw7ZyaQ==?=) Date: Thu, 21 May 2015 16:13:00 +0200 Subject: [erlang-bugs] cover:analyse_to_file never returns Message-ID: Hi all, I faced the following issue when trying to analyse a coverdata collected earlier. The coverdata file contained a module which was removed (so source and beam not available any more) Imported the coverdata file and called cover:analyze_to_file(test, "/tmp/test.html", [html]) never returned and resulted in the following error report %% =ERROR REPORT==== 20-May-2015::16:13:47 === %% Error in process <0.578.0> with exit value: {undef,[{test,module_info,[compile],[]},{cover,find_source,2,[{file,"cover.erl"},{line,1996}]},{cover,do_parallel_analysis_to_file,6,[{file,"cover.erl"},{line,2139}]}]} I did not look at the source code of cover yet but this looks like a spawned process crashed and the main loop waiting for it indefinitely The issue is reproducible (with file attached) on both R16B03-1 and 18-rc1 /Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cover_issue.erl Type: application/octet-stream Size: 1171 bytes Desc: not available URL: From zachary.hueras@REDACTED Thu May 21 18:48:54 2015 From: zachary.hueras@REDACTED (Soup) Date: Thu, 21 May 2015 12:48:54 -0400 Subject: [erlang-bugs] Segmentation Fault in check_process_code / erts_garbage_collect Message-ID: This topic, or one very similar, appears to have been discussed before in the erlang-patches mailing list thread titled "erlang node crashes in erts_gc_after_bif_call" from October, 2012 ( http://erlang.org/pipermail/erlang-patches/2012-October/003072.html). No clear resolution was reached on this thread, and I am currently dealing with it in production systems, so I have decided to address this mailing list. Please see the bottom of the email for system specification, as I believe this to be largely unrelated (except possibly for multithreading). Please feel free to request any pertinent information I may have left out, or to make suggestions to improve future bug reports. I don't often submit bug reports, and am not at all familiar with Erlang/OTP's particular practices in this regard. *## Scenario and Error ##* The error is a segmentation fault arising out of the erts_garbage_collect and check_process_code functions. The scenario is as follows: 1) You must be hot-loading a module (in my case, this module is dynamically generated) periodically. 2) You must have non-suspended processes active in the module you are hot-loading while it is being loaded (though not necessarily *in* the code of the module; may be using terms from the module or having function references ot the module). 3) Purging of the *old* version of the module must be happening at the same time as garbage collection. (in my case, the garbage collection is explicit because of the use of large binary terms with relatively few reductions; that does not appear to be the case in the situation laid out in the previously mentioned thread). It appears, at least to my untrained eye, that garbage collection sweeps can occur at the same time as code purging, and that this seems to happen without multithreading protection. My reason for this suspicion is that in my production systems I began receiving one of two segmentation faults: one occuring in the function check_process_code (of erts/emulator/beam/beam_bif_load.c) and erts_garbage_collect (of erts/emulator/beam/erl_gc.c). Most of the time *in production*, the segmentation fault occured in the check_process_code function. Only sometimes did it appear to be coming from erts_garbage_collect. *## Reproducing the Error ##* It took a while, but I did ultimately manage to create an app which reliably produces this error (insofar as I can tell). Please see the app here: https://github.com/fauxsoup/erlang-sigsegv There are some apparent differences from what I was observing in production, but this could possibly be related to differences between my production environment and my testing environment (which are non-trivial), and potentially differences between my minimal test case and the production service. Please see the bottom of this email for pertinent details about both environments. For testing, and because my production deployment of Erlang does not include debug symbols, I recompiled Erlang/OTP 17.4 with the flags "-g -O2" to produce debug symbols and prevent aggressive optimizations which may distort the stacktrace. The primary difference between the *results* of the error in production versus testing is that the segmentation fault in testing *always *comes from erts_garbage_collect. I have not at all been able to produce a test result in which the segmentation fault occured in check_process_code using the minimal test case code. Another difference, which I believe to be caused by the inclusion of debug symbols, is that erts_garbage_collect appears earlier in the backtrace in testing, and that the actual segmentation fault appears to come from the function sweep_one_area (erl_gc.c again). My assumption is that the optimization and lack of debug symbols in the production system merely obfuscated the origin of the segmentation fault there. *## The Backtrace ##* Included here for your convenience (also available in test case README): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff3b3e700 (LWP 26743)] sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, src=src@REDACTED=0x7fffe9ec2028 "", src_size=src_size@REDACTED=600224) at beam/erl_gc.c:1816 1816 mb->base = binary_bytes(*origptr); (gdb) bt #0 sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, src=src@REDACTED=0x7fffe9ec2028 "", src_size=src_size@REDACTED=600224) at beam/erl_gc.c:1816 #1 0x0000000000527ea0 in do_minor (nobj=1, objv=0x7ffff3b3dd50, new_sz=121536, p=0x7ffff5c80800) at beam/erl_gc.c:1160 #2 minor_collection (recl=, nobj=1, objv=0x7ffff3b3dd50, need=0, p=0x7ffff5c80800) at beam/erl_gc.c:876 #3 erts_garbage_collect (p=0x7ffff5c80800, need=need@REDACTED=0, objv=objv@REDACTED=0x7ffff3b3dd50, nobj=nobj@REDACTED=1) at beam/erl_gc.c:450 #4 0x000000000052877b in erts_gc_after_bif_call (p=0x7ffff5c80800, result=140736302308346, regs=, arity=) at beam/erl_gc.c:370 #5 0x0000000000571951 in process_main () at beam/beam_emu.c:2787 #6 0x00000000004a9a70 in sched_thread_func (vesdp=0x7ffff51cc8c0) at beam/erl_process.c:7743 #7 0x00000000006056fb in thr_wrapper (vtwd=0x7fffffffd9a0) at pthread/ethread.c:106 #8 0x00007ffff704d374 in start_thread () from /usr/lib/libpthread.so.0 #9 0x00007ffff6b8327d in clone () from /usr/lib/libc.so.6 *## The Systems ##* *PRODUCTION*Erlang/OTP 17.4 (also observed on Erlang R15B01) Amazon EC2 c3.8xlarge (32 Virtual CPUs, ~64 GB Memory) Debian Wheezy uname -a: Linux rtb0.ec2.chitika.net 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2 x86_64 GNU/Linux *TESTING* Erlang/OTP 17.4 Intel Core i5 760 @ 2.80GHz (4 Logical CPUs, 2 cores IIRC), ~16GB Memory Arch Linux (up-to-date) uname -a: Linux diogenes 4.0.1-1-ARCH #1 SMP PREEMPT Wed Apr 29 12:00:26 CEST 2015 x86_64 GNU/Linux -------------- next part -------------- An HTML attachment was scrubbed... URL: From mu@REDACTED Fri May 22 00:42:03 2015 From: mu@REDACTED (Miroslav Urbanek) Date: Fri, 22 May 2015 00:42:03 +0200 Subject: [erlang-bugs] Freeze in re:run Message-ID: <20150521224203.GB9841@miroslavurbanek.com> Hi, I'm using Erlang 17.5 and I'm experiencing freezes in re:run that take tens of seconds. I've isolated the problematic part into the following code: ---- #!/usr/bin/env escript log(Term) -> {_ , {Hour, Minute, Second}} = calendar:now_to_universal_time(os:timestamp()), io:format("~2..0w:~2..0w:~2..0w ~p~n", [Hour, Minute, Second, Term]). test(Filename) -> {ok, IoDevice} = file:open(Filename, [binary, read]), {ok, Data} = file:read(IoDevice, 1048576), Regexp = "(?i)(?m)(?s)(?U)(?<=\n)--(?|.*^content-disposition:(?:(?!\n\\S).)*filename=\"[^\"]*\\.([^\".]*)\".*|.*^content-type:(?:(?!\n\\S).)*name=\"[^\"]*\\.([^\".]*)\").*\n\n", re:run(Data, Regexp, [report_errors]). main([Filename]) -> spawn_link(fun Fun() -> log(heartbeat), timer:sleep(1000), Fun() end), log(test(Filename)). ---- Processing the complex regexp above takes about 50 seconds for my test data. Sometimes, the whole Erlang VM freezes for several seconds. The output then looks like this: ---- $ ./test.erl test.eml 18:27:48 heartbeat 18:27:49 heartbeat 18:27:50 heartbeat 18:27:51 heartbeat 18:27:52 heartbeat 18:27:53 heartbeat 18:27:54 heartbeat 18:27:55 heartbeat 18:27:56 heartbeat 18:27:57 heartbeat 18:27:58 heartbeat 18:27:59 heartbeat 18:28:00 heartbeat 18:28:01 heartbeat 18:28:02 heartbeat 18:28:03 heartbeat 18:28:04 heartbeat 18:28:05 heartbeat 18:28:06 heartbeat 18:28:07 heartbeat 18:28:08 heartbeat 18:28:36 heartbeat 18:28:36 nomatch ---- The VM froze between 18:28:08 and 18:28:36. The manual page re(3) states that "re:run always give control back to the scheduler of Erlang processes at intervals that ensures the real time properties of the Erlang system". I believe this is a bug, because re:run clearly didn't give control back to the scheduler during the interval above. Why does it happen? Is there any option to limit the number of time VM spends in re:run? The program and the data file can be downloaded here: http://miroslavurbanek.com/re.tgz Thanks, Miro From eric.pailleau@REDACTED Fri May 22 17:43:18 2015 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Fri, 22 May 2015 17:43:18 +0200 Subject: [erlang-bugs] Freeze in re:run In-Reply-To: <20150521224203.GB9841@miroslavurbanek.com> Message-ID: <72f1310a-ca97-48da-a6d9-034aff99e913@email.android.com> Hi, Your regexp is compiled at each call. Your should compile it in your shell and set it in your code by a define. It is probably not your problem, but it should increase perfs... Regards Le?22 mai 2015 00:42, Miroslav Urbanek a ?crit?: > > Hi, > > I'm using Erlang 17.5 and I'm experiencing freezes in re:run that take > tens of seconds. I've isolated the problematic part into the following > code: > > ---- > #!/usr/bin/env escript > > log(Term) -> > ??? {_ , {Hour, Minute, Second}} = calendar:now_to_universal_time(os:timestamp()), > ??? io:format("~2..0w:~2..0w:~2..0w ~p~n", [Hour, Minute, Second, Term]). > > test(Filename) -> > ??? {ok, IoDevice} = file:open(Filename, [binary, read]), > ??? {ok, Data} = file:read(IoDevice, 1048576), > ??? Regexp = "(?i)(?m)(?s)(?U)(?<=\n)--(?|.*^content-disposition:(?:(?!\n\\S).)*filename=\"[^\"]*\\.([^\".]*)\".*|.*^content-type:(?:(?!\n\\S).)*name=\"[^\"]*\\.([^\".]*)\").*\n\n", > ??? re:run(Data, Regexp, [report_errors]). > > main([Filename]) -> > ??? spawn_link(fun Fun() -> > ?????????????????????? log(heartbeat), > ?????????????????????? timer:sleep(1000), > ?????????????????????? Fun() > ?????????????? end), > ??? log(test(Filename)). > ---- > > Processing the complex regexp above takes about 50 seconds for my test > data. Sometimes, the whole Erlang VM freezes for several seconds. The > output then looks like this: > > ---- > $ ./test.erl test.eml > 18:27:48 heartbeat > 18:27:49 heartbeat > 18:27:50 heartbeat > 18:27:51 heartbeat > 18:27:52 heartbeat > 18:27:53 heartbeat > 18:27:54 heartbeat > 18:27:55 heartbeat > 18:27:56 heartbeat > 18:27:57 heartbeat > 18:27:58 heartbeat > 18:27:59 heartbeat > 18:28:00 heartbeat > 18:28:01 heartbeat > 18:28:02 heartbeat > 18:28:03 heartbeat > 18:28:04 heartbeat > 18:28:05 heartbeat > 18:28:06 heartbeat > 18:28:07 heartbeat > 18:28:08 heartbeat > 18:28:36 heartbeat > 18:28:36 nomatch > ---- > > The VM froze between 18:28:08 and 18:28:36. The manual page re(3) > states that "re:run always give control back to the scheduler of > Erlang processes at intervals that ensures the real time properties of > the Erlang system". I believe this is a bug, because re:run clearly > didn't give control back to the scheduler during the interval above. > > Why does it happen? Is there any option to limit the number of time VM > spends in re:run? > > The program and the data file can be downloaded here: > > http://miroslavurbanek.com/re.tgz > > Thanks, > Miro > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From bobgus@REDACTED Fri May 22 20:54:07 2015 From: bobgus@REDACTED (Bob Gustafson) Date: Fri, 22 May 2015 13:54:07 -0500 Subject: [erlang-bugs] Segmentation Fault in check_process_code / erts_garbage_collect In-Reply-To: References: Message-ID: <555F7B4F.5020504@chidig.com> I am running 18.rc1 on a Macbook Air - I was able to duplicate your segv (although I haven't seen the dump) - I ran it for about 20 minutes total and it segv 3x in that time frame. While running, I used the Mac Activity Monitor to peek. It is using about 380% CPU, 19 Threads and seems to be only one OSX process. Memory jumps around a bit - roughly 360-420 MB initially and then it drops down - I saw 127 MB, and then it was gone - crashed. I will fish around for the crash dump. Have fun Bob G On 05/21/2015 11:48 AM, Soup wrote: > This topic, or one very similar, appears to have been discussed before > in the erlang-patches mailing list thread titled "erlang node crashes > in erts_gc_after_bif_call" from October, 2012 > (http://erlang.org/pipermail/erlang-patches/2012-October/003072.html). > No clear resolution was reached on this thread, and I am currently > dealing with it in production systems, so I have decided to address > this mailing list. > > Please see the bottom of the email for system specification, as I > believe this to be largely unrelated (except possibly for multithreading). > > Please feel free to request any pertinent information I may have left > out, or to make suggestions to improve future bug reports. I don't > often submit bug reports, and am not at all familiar with Erlang/OTP's > particular practices in this regard. > > *## Scenario and Error ## > * > The error is a segmentation fault arising out of the > erts_garbage_collect and check_process_code functions. > > The scenario is as follows: > 1) You must be hot-loading a module (in my case, this module is > dynamically generated) periodically. > 2) You must have non-suspended processes active in the module you are > hot-loading while it is being loaded (though not necessarily *in* the > code of the module; may be using terms from the module or having > function references ot the module). > 3) Purging of the *old* version of the module must be happening at the > same time as garbage collection. (in my case, the garbage collection > is explicit because of the use of large binary terms with relatively > few reductions; that does not appear to be the case in the situation > laid out in the previously mentioned thread). > > It appears, at least to my untrained eye, that garbage collection > sweeps can occur at the same time as code purging, and that this seems > to happen without multithreading protection. My reason for this > suspicion is that in my production systems I began receiving one of > two segmentation faults: one occuring in the function > check_process_code (of erts/emulator/beam/beam_bif_load.c) and > erts_garbage_collect (of erts/emulator/beam/erl_gc.c). Most of the > time *in production*, the segmentation fault occured in the > check_process_code function. Only sometimes did it appear to be coming > from erts_garbage_collect. > > *## Reproducing the Error ##* > > It took a while, but I did ultimately manage to create an app which > reliably produces this error (insofar as I can tell). Please see the > app here: https://github.com/fauxsoup/erlang-sigsegv > > There are some apparent differences from what I was observing in > production, but this could possibly be related to differences between > my production environment and my testing environment (which are > non-trivial), and potentially differences between my minimal test case > and the production service. Please see the bottom of this email for > pertinent details about both environments. > > For testing, and because my production deployment of Erlang does not > include debug symbols, I recompiled Erlang/OTP 17.4 with the flags "-g > -O2" to produce debug symbols and prevent aggressive optimizations > which may distort the stacktrace. > > The primary difference between the *results* of the error in > production versus testing is that the segmentation fault in testing > *always *comes from erts_garbage_collect. I have not at all been able > to produce a test result in which the segmentation fault occured in > check_process_code using the minimal test case code. > > Another difference, which I believe to be caused by the inclusion of > debug symbols, is that erts_garbage_collect appears earlier in the > backtrace in testing, and that the actual segmentation fault appears > to come from the function sweep_one_area (erl_gc.c again). My > assumption is that the optimization and lack of debug symbols in the > production system merely obfuscated the origin of the segmentation > fault there. > > *## The Backtrace ## > > * > Included here for your convenience (also available in test case README): > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff3b3e700 (LWP 26743)] > sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, > src=src@REDACTED=0x7fffe9ec2028 "", src_size=src_size@REDACTED=600224) at > beam/erl_gc.c:1816 > 1816mb->base = binary_bytes(*origptr); > (gdb) bt > #0 sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, > src=src@REDACTED=0x7fffe9ec2028 "", src_size=src_size@REDACTED=600224) at > beam/erl_gc.c:1816 > #1 0x0000000000527ea0 in do_minor (nobj=1, objv=0x7ffff3b3dd50, > new_sz=121536, p=0x7ffff5c80800) at beam/erl_gc.c:1160 > #2 minor_collection (recl=, nobj=1, > objv=0x7ffff3b3dd50, need=0, p=0x7ffff5c80800) at beam/erl_gc.c:876 > #3 erts_garbage_collect (p=0x7ffff5c80800, need=need@REDACTED=0, > objv=objv@REDACTED=0x7ffff3b3dd50, nobj=nobj@REDACTED=1) at beam/erl_gc.c:450 > #4 0x000000000052877b in erts_gc_after_bif_call (p=0x7ffff5c80800, > result=140736302308346, regs=, arity=) > at beam/erl_gc.c:370 > #5 0x0000000000571951 in process_main () at beam/beam_emu.c:2787 > #6 0x00000000004a9a70 in sched_thread_func (vesdp=0x7ffff51cc8c0) at > beam/erl_process.c:7743 > #7 0x00000000006056fb in thr_wrapper (vtwd=0x7fffffffd9a0) at > pthread/ethread.c:106 > #8 0x00007ffff704d374 in start_thread () from /usr/lib/libpthread.so.0 > #9 0x00007ffff6b8327d in clone () from /usr/lib/libc.so.6 > > *## The Systems ##* > > *PRODUCTION > *Erlang/OTP 17.4 (also observed on Erlang R15B01) > Amazon EC2 c3.8xlarge (32 Virtual CPUs, ~64 GB Memory) > Debian Wheezy > uname -a: Linux rtb0.ec2.chitika.net > 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2 > x86_64 GNU/Linux* > * > > *TESTING* > Erlang/OTP 17.4 > Intel Core i5 760 @ 2.80GHz (4 Logical CPUs, 2 cores IIRC), ~16GB Memory > Arch Linux (up-to-date) > uname -a: Linux diogenes 4.0.1-1-ARCH #1 SMP PREEMPT Wed Apr 29 > 12:00:26 CEST 2015 x86_64 GNU/Linux > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Fri May 22 21:32:52 2015 From: wallentin.dahlberg@REDACTED (=?UTF-8?Q?Bj=C3=B6rn=2DEgil_Dahlberg?=) Date: Fri, 22 May 2015 21:32:52 +0200 Subject: [erlang-bugs] Segmentation Fault in check_process_code / erts_garbage_collect In-Reply-To: <555F7B4F.5020504@chidig.com> References: <555F7B4F.5020504@chidig.com> Message-ID: I'll just mention that we have looked at this in the VM team at OTP and can confirm the results. We also have a reasonable idea of what's happening. It seems that a binary match state is not handled properly in garbage collect literals (gc when purging code and moving literals to the process heaps). I will look into it more on monday (or perhaps this weekend). // Bj?rn-Egil 2015-05-22 20:54 GMT+02:00 Bob Gustafson : > I am running 18.rc1 on a Macbook Air - I was able to duplicate your segv > (although I haven't seen the dump) - I ran it for about 20 minutes total > and it segv 3x in that time frame. > > While running, I used the Mac Activity Monitor to peek. > > It is using about 380% CPU, 19 Threads and seems to be only one OSX > process. > > Memory jumps around a bit - roughly 360-420 MB initially and then it drops > down - I saw 127 MB, and then it was gone - crashed. > > I will fish around for the crash dump. > > Have fun > > Bob G > > > On 05/21/2015 11:48 AM, Soup wrote: > > This topic, or one very similar, appears to have been discussed before > in the erlang-patches mailing list thread titled "erlang node crashes in > erts_gc_after_bif_call" from October, 2012 ( > http://erlang.org/pipermail/erlang-patches/2012-October/003072.html). No > clear resolution was reached on this thread, and I am currently dealing > with it in production systems, so I have decided to address this mailing > list. > > Please see the bottom of the email for system specification, as I believe > this to be largely unrelated (except possibly for multithreading). > > Please feel free to request any pertinent information I may have left out, > or to make suggestions to improve future bug reports. I don't often submit > bug reports, and am not at all familiar with Erlang/OTP's particular > practices in this regard. > > > *## Scenario and Error ## * > The error is a segmentation fault arising out of the erts_garbage_collect > and check_process_code functions. > > The scenario is as follows: > 1) You must be hot-loading a module (in my case, this module is > dynamically generated) periodically. > 2) You must have non-suspended processes active in the module you are > hot-loading while it is being loaded (though not necessarily *in* the code > of the module; may be using terms from the module or having function > references ot the module). > 3) Purging of the *old* version of the module must be happening at the > same time as garbage collection. (in my case, the garbage collection is > explicit because of the use of large binary terms with relatively few > reductions; that does not appear to be the case in the situation laid out > in the previously mentioned thread). > > It appears, at least to my untrained eye, that garbage collection sweeps > can occur at the same time as code purging, and that this seems to happen > without multithreading protection. My reason for this suspicion is that in > my production systems I began receiving one of two segmentation faults: one > occuring in the function check_process_code (of > erts/emulator/beam/beam_bif_load.c) and erts_garbage_collect (of > erts/emulator/beam/erl_gc.c). Most of the time *in production*, the > segmentation fault occured in the check_process_code function. Only > sometimes did it appear to be coming from erts_garbage_collect. > > *## Reproducing the Error ##* > > It took a while, but I did ultimately manage to create an app which > reliably produces this error (insofar as I can tell). Please see the app > here: https://github.com/fauxsoup/erlang-sigsegv > > There are some apparent differences from what I was observing in > production, but this could possibly be related to differences between my > production environment and my testing environment (which are non-trivial), > and potentially differences between my minimal test case and the production > service. Please see the bottom of this email for pertinent details about > both environments. > > For testing, and because my production deployment of Erlang does not > include debug symbols, I recompiled Erlang/OTP 17.4 with the flags "-g -O2" > to produce debug symbols and prevent aggressive optimizations which may > distort the stacktrace. > > The primary difference between the *results* of the error in production > versus testing is that the segmentation fault in testing *always *comes > from erts_garbage_collect. I have not at all been able to produce a test > result in which the segmentation fault occured in check_process_code using > the minimal test case code. > > Another difference, which I believe to be caused by the inclusion of debug > symbols, is that erts_garbage_collect appears earlier in the backtrace in > testing, and that the actual segmentation fault appears to come from the > function sweep_one_area (erl_gc.c again). My assumption is that the > optimization and lack of debug symbols in the production system merely > obfuscated the origin of the segmentation fault there. > > > > *## The Backtrace ## * > Included here for your convenience (also available in test case README): > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread > 0x7ffff3b3e700 (LWP 26743)] > sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, src=src@REDACTED=0x7fffe9ec2028 > "", src_size=src_size@REDACTED=600224) at beam/erl_gc.c:1816 > 1816 mb->base = binary_bytes(*origptr); > (gdb) bt > #0 sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, > src=src@REDACTED=0x7fffe9ec2028 "", src_size=src_size@REDACTED=600224) at > beam/erl_gc.c:1816 > #1 0x0000000000527ea0 in do_minor (nobj=1, objv=0x7ffff3b3dd50, > new_sz=121536, p=0x7ffff5c80800) at beam/erl_gc.c:1160 > #2 minor_collection (recl=, nobj=1, > objv=0x7ffff3b3dd50, need=0, p=0x7ffff5c80800) at beam/erl_gc.c:876 > #3 erts_garbage_collect (p=0x7ffff5c80800, need=need@REDACTED=0, > objv=objv@REDACTED=0x7ffff3b3dd50, nobj=nobj@REDACTED=1) at beam/erl_gc.c:450 > #4 0x000000000052877b in erts_gc_after_bif_call (p=0x7ffff5c80800, > result=140736302308346, regs=, arity=) at > beam/erl_gc.c:370 > #5 0x0000000000571951 in process_main () at beam/beam_emu.c:2787 > #6 0x00000000004a9a70 in sched_thread_func (vesdp=0x7ffff51cc8c0) at > beam/erl_process.c:7743 > #7 0x00000000006056fb in thr_wrapper (vtwd=0x7fffffffd9a0) at > pthread/ethread.c:106 > #8 0x00007ffff704d374 in start_thread () from /usr/lib/libpthread.so.0 > #9 0x00007ffff6b8327d in clone () from /usr/lib/libc.so.6 > > *## The Systems ##* > > > *PRODUCTION *Erlang/OTP 17.4 (also observed on Erlang R15B01) > Amazon EC2 c3.8xlarge (32 Virtual CPUs, ~64 GB Memory) > Debian Wheezy > uname -a: Linux rtb0.ec2.chitika.net 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2 > x86_64 GNU/Linux > > *TESTING* > Erlang/OTP 17.4 > Intel Core i5 760 @ 2.80GHz (4 Logical CPUs, 2 cores IIRC), ~16GB Memory > Arch Linux (up-to-date) > uname -a: Linux diogenes 4.0.1-1-ARCH #1 SMP PREEMPT Wed Apr 29 12:00:26 > CEST 2015 x86_64 GNU/Linux > > > _______________________________________________ > 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 wallentin.dahlberg@REDACTED Fri May 22 21:43:40 2015 From: wallentin.dahlberg@REDACTED (=?UTF-8?Q?Bj=C3=B6rn=2DEgil_Dahlberg?=) Date: Fri, 22 May 2015 21:43:40 +0200 Subject: [erlang-bugs] Segmentation Fault in check_process_code / erts_garbage_collect In-Reply-To: References: <555F7B4F.5020504@chidig.com> Message-ID: I would also like to add that your testcase for provoking this was very helpful. The crash will almost always show a random symptom and rarely the actual cause. The point of corruption has long since passed. Therefor a testcase showing the error is the most helpful in hunting down the problem. 2015-05-22 21:32 GMT+02:00 Bj?rn-Egil Dahlberg : > I'll just mention that we have looked at this in the VM team at OTP and > can confirm the results. We also have a reasonable idea of what's happening. > It seems that a binary match state is not handled properly in garbage > collect literals (gc when purging code and moving literals to the process > heaps). > > I will look into it more on monday (or perhaps this weekend). > > // Bj?rn-Egil > > 2015-05-22 20:54 GMT+02:00 Bob Gustafson : > >> I am running 18.rc1 on a Macbook Air - I was able to duplicate your segv >> (although I haven't seen the dump) - I ran it for about 20 minutes total >> and it segv 3x in that time frame. >> >> While running, I used the Mac Activity Monitor to peek. >> >> It is using about 380% CPU, 19 Threads and seems to be only one OSX >> process. >> >> Memory jumps around a bit - roughly 360-420 MB initially and then it >> drops down - I saw 127 MB, and then it was gone - crashed. >> >> I will fish around for the crash dump. >> >> Have fun >> >> Bob G >> >> >> On 05/21/2015 11:48 AM, Soup wrote: >> >> This topic, or one very similar, appears to have been discussed before >> in the erlang-patches mailing list thread titled "erlang node crashes in >> erts_gc_after_bif_call" from October, 2012 ( >> http://erlang.org/pipermail/erlang-patches/2012-October/003072.html). No >> clear resolution was reached on this thread, and I am currently dealing >> with it in production systems, so I have decided to address this mailing >> list. >> >> Please see the bottom of the email for system specification, as I believe >> this to be largely unrelated (except possibly for multithreading). >> >> Please feel free to request any pertinent information I may have left >> out, or to make suggestions to improve future bug reports. I don't often >> submit bug reports, and am not at all familiar with Erlang/OTP's particular >> practices in this regard. >> >> >> *## Scenario and Error ## * >> The error is a segmentation fault arising out of the erts_garbage_collect >> and check_process_code functions. >> >> The scenario is as follows: >> 1) You must be hot-loading a module (in my case, this module is >> dynamically generated) periodically. >> 2) You must have non-suspended processes active in the module you are >> hot-loading while it is being loaded (though not necessarily *in* the code >> of the module; may be using terms from the module or having function >> references ot the module). >> 3) Purging of the *old* version of the module must be happening at the >> same time as garbage collection. (in my case, the garbage collection is >> explicit because of the use of large binary terms with relatively few >> reductions; that does not appear to be the case in the situation laid out >> in the previously mentioned thread). >> >> It appears, at least to my untrained eye, that garbage collection sweeps >> can occur at the same time as code purging, and that this seems to happen >> without multithreading protection. My reason for this suspicion is that in >> my production systems I began receiving one of two segmentation faults: one >> occuring in the function check_process_code (of >> erts/emulator/beam/beam_bif_load.c) and erts_garbage_collect (of >> erts/emulator/beam/erl_gc.c). Most of the time *in production*, the >> segmentation fault occured in the check_process_code function. Only >> sometimes did it appear to be coming from erts_garbage_collect. >> >> *## Reproducing the Error ##* >> >> It took a while, but I did ultimately manage to create an app which >> reliably produces this error (insofar as I can tell). Please see the app >> here: https://github.com/fauxsoup/erlang-sigsegv >> >> There are some apparent differences from what I was observing in >> production, but this could possibly be related to differences between my >> production environment and my testing environment (which are non-trivial), >> and potentially differences between my minimal test case and the production >> service. Please see the bottom of this email for pertinent details about >> both environments. >> >> For testing, and because my production deployment of Erlang does not >> include debug symbols, I recompiled Erlang/OTP 17.4 with the flags "-g -O2" >> to produce debug symbols and prevent aggressive optimizations which may >> distort the stacktrace. >> >> The primary difference between the *results* of the error in production >> versus testing is that the segmentation fault in testing *always *comes >> from erts_garbage_collect. I have not at all been able to produce a test >> result in which the segmentation fault occured in check_process_code using >> the minimal test case code. >> >> Another difference, which I believe to be caused by the inclusion of >> debug symbols, is that erts_garbage_collect appears earlier in the >> backtrace in testing, and that the actual segmentation fault appears to >> come from the function sweep_one_area (erl_gc.c again). My assumption is >> that the optimization and lack of debug symbols in the production system >> merely obfuscated the origin of the segmentation fault there. >> >> >> >> *## The Backtrace ## * >> Included here for your convenience (also available in test case README): >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread >> 0x7ffff3b3e700 (LWP 26743)] >> sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, src=src@REDACTED=0x7fffe9ec2028 >> "", src_size=src_size@REDACTED=600224) at beam/erl_gc.c:1816 >> 1816 mb->base = binary_bytes(*origptr); >> (gdb) bt >> #0 sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, >> src=src@REDACTED=0x7fffe9ec2028 "", src_size=src_size@REDACTED=600224) at >> beam/erl_gc.c:1816 >> #1 0x0000000000527ea0 in do_minor (nobj=1, objv=0x7ffff3b3dd50, >> new_sz=121536, p=0x7ffff5c80800) at beam/erl_gc.c:1160 >> #2 minor_collection (recl=, nobj=1, >> objv=0x7ffff3b3dd50, need=0, p=0x7ffff5c80800) at beam/erl_gc.c:876 >> #3 erts_garbage_collect (p=0x7ffff5c80800, need=need@REDACTED=0, >> objv=objv@REDACTED=0x7ffff3b3dd50, nobj=nobj@REDACTED=1) at beam/erl_gc.c:450 >> #4 0x000000000052877b in erts_gc_after_bif_call (p=0x7ffff5c80800, >> result=140736302308346, regs=, arity=) at >> beam/erl_gc.c:370 >> #5 0x0000000000571951 in process_main () at beam/beam_emu.c:2787 >> #6 0x00000000004a9a70 in sched_thread_func (vesdp=0x7ffff51cc8c0) at >> beam/erl_process.c:7743 >> #7 0x00000000006056fb in thr_wrapper (vtwd=0x7fffffffd9a0) at >> pthread/ethread.c:106 >> #8 0x00007ffff704d374 in start_thread () from /usr/lib/libpthread.so.0 >> #9 0x00007ffff6b8327d in clone () from /usr/lib/libc.so.6 >> >> *## The Systems ##* >> >> >> *PRODUCTION *Erlang/OTP 17.4 (also observed on Erlang R15B01) >> Amazon EC2 c3.8xlarge (32 Virtual CPUs, ~64 GB Memory) >> Debian Wheezy >> uname -a: Linux rtb0.ec2.chitika.net 3.2.0-4-amd64 #1 SMP Debian >> 3.2.63-2 x86_64 GNU/Linux >> >> *TESTING* >> Erlang/OTP 17.4 >> Intel Core i5 760 @ 2.80GHz (4 Logical CPUs, 2 cores IIRC), ~16GB Memory >> Arch Linux (up-to-date) >> uname -a: Linux diogenes 4.0.1-1-ARCH #1 SMP PREEMPT Wed Apr 29 12:00:26 >> CEST 2015 x86_64 GNU/Linux >> >> >> _______________________________________________ >> 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 zachary.hueras@REDACTED Fri May 22 23:31:13 2015 From: zachary.hueras@REDACTED (Soup) Date: Fri, 22 May 2015 17:31:13 -0400 Subject: [erlang-bugs] Segmentation Fault in check_process_code / erts_garbage_collect In-Reply-To: References: <555F7B4F.5020504@chidig.com> Message-ID: I am only upset that I am not able to replicate the original stacktrace I saw in my production servers with this example. However, what little I was able to glean from the -g free stacktraces showed that both the garbage collection and check process code errors were happening when interacting with the "off heap" of the process. Not sure what would be in the off heap, but binaries sound like they would be (though I think there was something about function references to the old version of the module in the vicinity as well). Please let me know if I can provide any more information. ~Zac On Fri, May 22, 2015 at 3:43 PM, Bj?rn-Egil Dahlberg < wallentin.dahlberg@REDACTED> wrote: > I would also like to add that your testcase for provoking this was very > helpful. The crash will almost always show a random symptom and rarely the > actual cause. The point of corruption has long since passed. Therefor a > testcase showing the error is the most helpful in hunting down the problem. > > 2015-05-22 21:32 GMT+02:00 Bj?rn-Egil Dahlberg < > wallentin.dahlberg@REDACTED>: > >> I'll just mention that we have looked at this in the VM team at OTP and >> can confirm the results. We also have a reasonable idea of what's happening. >> It seems that a binary match state is not handled properly in garbage >> collect literals (gc when purging code and moving literals to the process >> heaps). >> >> I will look into it more on monday (or perhaps this weekend). >> >> // Bj?rn-Egil >> >> 2015-05-22 20:54 GMT+02:00 Bob Gustafson : >> >>> I am running 18.rc1 on a Macbook Air - I was able to duplicate your >>> segv (although I haven't seen the dump) - I ran it for about 20 minutes >>> total and it segv 3x in that time frame. >>> >>> While running, I used the Mac Activity Monitor to peek. >>> >>> It is using about 380% CPU, 19 Threads and seems to be only one OSX >>> process. >>> >>> Memory jumps around a bit - roughly 360-420 MB initially and then it >>> drops down - I saw 127 MB, and then it was gone - crashed. >>> >>> I will fish around for the crash dump. >>> >>> Have fun >>> >>> Bob G >>> >>> >>> On 05/21/2015 11:48 AM, Soup wrote: >>> >>> This topic, or one very similar, appears to have been discussed before >>> in the erlang-patches mailing list thread titled "erlang node crashes in >>> erts_gc_after_bif_call" from October, 2012 ( >>> http://erlang.org/pipermail/erlang-patches/2012-October/003072.html). >>> No clear resolution was reached on this thread, and I am currently dealing >>> with it in production systems, so I have decided to address this mailing >>> list. >>> >>> Please see the bottom of the email for system specification, as I >>> believe this to be largely unrelated (except possibly for multithreading). >>> >>> Please feel free to request any pertinent information I may have left >>> out, or to make suggestions to improve future bug reports. I don't often >>> submit bug reports, and am not at all familiar with Erlang/OTP's particular >>> practices in this regard. >>> >>> >>> *## Scenario and Error ## * >>> The error is a segmentation fault arising out of the >>> erts_garbage_collect and check_process_code functions. >>> >>> The scenario is as follows: >>> 1) You must be hot-loading a module (in my case, this module is >>> dynamically generated) periodically. >>> 2) You must have non-suspended processes active in the module you are >>> hot-loading while it is being loaded (though not necessarily *in* the code >>> of the module; may be using terms from the module or having function >>> references ot the module). >>> 3) Purging of the *old* version of the module must be happening at the >>> same time as garbage collection. (in my case, the garbage collection is >>> explicit because of the use of large binary terms with relatively few >>> reductions; that does not appear to be the case in the situation laid out >>> in the previously mentioned thread). >>> >>> It appears, at least to my untrained eye, that garbage collection sweeps >>> can occur at the same time as code purging, and that this seems to happen >>> without multithreading protection. My reason for this suspicion is that in >>> my production systems I began receiving one of two segmentation faults: one >>> occuring in the function check_process_code (of >>> erts/emulator/beam/beam_bif_load.c) and erts_garbage_collect (of >>> erts/emulator/beam/erl_gc.c). Most of the time *in production*, the >>> segmentation fault occured in the check_process_code function. Only >>> sometimes did it appear to be coming from erts_garbage_collect. >>> >>> *## Reproducing the Error ##* >>> >>> It took a while, but I did ultimately manage to create an app which >>> reliably produces this error (insofar as I can tell). Please see the app >>> here: https://github.com/fauxsoup/erlang-sigsegv >>> >>> There are some apparent differences from what I was observing in >>> production, but this could possibly be related to differences between my >>> production environment and my testing environment (which are non-trivial), >>> and potentially differences between my minimal test case and the production >>> service. Please see the bottom of this email for pertinent details about >>> both environments. >>> >>> For testing, and because my production deployment of Erlang does not >>> include debug symbols, I recompiled Erlang/OTP 17.4 with the flags "-g -O2" >>> to produce debug symbols and prevent aggressive optimizations which may >>> distort the stacktrace. >>> >>> The primary difference between the *results* of the error in production >>> versus testing is that the segmentation fault in testing *always *comes >>> from erts_garbage_collect. I have not at all been able to produce a test >>> result in which the segmentation fault occured in check_process_code using >>> the minimal test case code. >>> >>> Another difference, which I believe to be caused by the inclusion of >>> debug symbols, is that erts_garbage_collect appears earlier in the >>> backtrace in testing, and that the actual segmentation fault appears to >>> come from the function sweep_one_area (erl_gc.c again). My assumption is >>> that the optimization and lack of debug symbols in the production system >>> merely obfuscated the origin of the segmentation fault there. >>> >>> >>> >>> *## The Backtrace ## * >>> Included here for your convenience (also available in test case README): >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread >>> 0x7ffff3b3e700 (LWP 26743)] >>> sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, src=src@REDACTED=0x7fffe9ec2028 >>> "", src_size=src_size@REDACTED=600224) at beam/erl_gc.c:1816 >>> 1816 mb->base = binary_bytes(*origptr); >>> (gdb) bt >>> #0 sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, >>> src=src@REDACTED=0x7fffe9ec2028 "", src_size=src_size@REDACTED=600224) at >>> beam/erl_gc.c:1816 >>> #1 0x0000000000527ea0 in do_minor (nobj=1, objv=0x7ffff3b3dd50, >>> new_sz=121536, p=0x7ffff5c80800) at beam/erl_gc.c:1160 >>> #2 minor_collection (recl=, nobj=1, >>> objv=0x7ffff3b3dd50, need=0, p=0x7ffff5c80800) at beam/erl_gc.c:876 >>> #3 erts_garbage_collect (p=0x7ffff5c80800, need=need@REDACTED=0, >>> objv=objv@REDACTED=0x7ffff3b3dd50, nobj=nobj@REDACTED=1) at beam/erl_gc.c:450 >>> #4 0x000000000052877b in erts_gc_after_bif_call (p=0x7ffff5c80800, >>> result=140736302308346, regs=, arity=) at >>> beam/erl_gc.c:370 >>> #5 0x0000000000571951 in process_main () at beam/beam_emu.c:2787 >>> #6 0x00000000004a9a70 in sched_thread_func (vesdp=0x7ffff51cc8c0) at >>> beam/erl_process.c:7743 >>> #7 0x00000000006056fb in thr_wrapper (vtwd=0x7fffffffd9a0) at >>> pthread/ethread.c:106 >>> #8 0x00007ffff704d374 in start_thread () from /usr/lib/libpthread.so.0 >>> #9 0x00007ffff6b8327d in clone () from /usr/lib/libc.so.6 >>> >>> *## The Systems ##* >>> >>> >>> *PRODUCTION *Erlang/OTP 17.4 (also observed on Erlang R15B01) >>> Amazon EC2 c3.8xlarge (32 Virtual CPUs, ~64 GB Memory) >>> Debian Wheezy >>> uname -a: Linux rtb0.ec2.chitika.net 3.2.0-4-amd64 #1 SMP Debian >>> 3.2.63-2 x86_64 GNU/Linux >>> >>> *TESTING* >>> Erlang/OTP 17.4 >>> Intel Core i5 760 @ 2.80GHz (4 Logical CPUs, 2 cores IIRC), ~16GB Memory >>> Arch Linux (up-to-date) >>> uname -a: Linux diogenes 4.0.1-1-ARCH #1 SMP PREEMPT Wed Apr 29 12:00:26 >>> CEST 2015 x86_64 GNU/Linux >>> >>> >>> _______________________________________________ >>> 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 eric.pailleau@REDACTED Sat May 23 00:03:06 2015 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 23 May 2015 00:03:06 +0200 Subject: [erlang-bugs] Freeze in re:run In-Reply-To: <72f1310a-ca97-48da-a6d9-034aff99e913@email.android.com> References: <72f1310a-ca97-48da-a6d9-034aff99e913@email.android.com> Message-ID: <555FA79A.3040102@wanadoo.fr> Hello, Using your code, I got same behavior, ie. 22 secondes then freeze. Using a pre-compiled regexp , I got freeze only 2/3 secondes after start . -define(MP,{re_pattern,1,0,0,<<69,82,67,80,73,1,0,0,7,2,0,0,81,8,0,0,255,255,255,255,255,255,255,255,45,0,10,0,1,0,1,0,0,0,56,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,125,1,13,121,0,8,118,0,1,30,10,114,0,8,30,45,30,45,125,0,133,86,13,26,30,99,30,111,30,110,30,116,30,101,30,110,30,116,30,45,30,100,30,105,30,115,30,112,30,111,30,115,30,105,30,116,30,105,30,111,30,110,30,58,141,125,0,13,120,0,6,30,10,8,114,0,6,13,116,0,13,30,102,30,105,30,108,30,101,30,110,30,97,30,109,30,101,30,61,30,34,73,34,30,46,127,0,39,0,1,107,255,255,255,255,251,191,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,99,114,0,39,30,34,86,13,113,0,109,86,13,26,30,99,30,111,30,110,30,116,30,101,30,110,30,116,30,45,30,116,30,121,30,112,30,101,30,58,141,125,0,13,120,0,6,30,10,8,114,0,6,13,116,0,13,30,110,30,97,30,109,30,101,30,61,30,34,73,34,30,46,127,0,39,0,1,107,255,255,255,255,251,191,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255 ,255,255,255,255,255,255,99,114,0,39,30,34,114,0,242,86,13,30,10,30,10,114,1,13,0>>}). and re:run(Data, ?MP, [report_errors]). $ ./test2.erl test.eml 21:53:26 heartbeat 21:53:27 heartbeat 21:53:28 heartbeat 21:54:17 heartbeat 21:54:17 nomatch Using strace : _____________________________________________________ [...] sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 futex(0xb6840088, FUTEX_WAIT_PRIVATE, -1, NULL) = 0 rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 write(7, "\0", 1) = 1 select(0, NULL, NULL, NULL, NULL21:59:14 heartbeat 21:59:15 heartbeat 21:59:16 heartbeat 22:00:05 nomatch 22:00:05 heartbeat +++ exited with 0 +++ _____________________________________________________ sched_yield() is not called during the 50 secondes processing. Indeed strange. Regards Le 22/05/2015 17:43, ?ric Pailleau a ?crit : > Hi, > > Your regexp is compiled at each call. > Your should compile it in your shell and set it in your code by a define. > It is probably not your problem, but it should increase perfs... > Regards > > Le 22 mai 2015 00:42, Miroslav Urbanek a ?crit : >> >> Hi, >> >> I'm using Erlang 17.5 and I'm experiencing freezes in re:run that take >> tens of seconds. I've isolated the problematic part into the following >> code: >> >> ---- >> #!/usr/bin/env escript >> >> log(Term) -> >> {_ , {Hour, Minute, Second}} = calendar:now_to_universal_time(os:timestamp()), >> io:format("~2..0w:~2..0w:~2..0w ~p~n", [Hour, Minute, Second, Term]). >> >> test(Filename) -> >> {ok, IoDevice} = file:open(Filename, [binary, read]), >> {ok, Data} = file:read(IoDevice, 1048576), >> Regexp = "(?i)(?m)(?s)(?U)(?<=\n)--(?|.*^content-disposition:(?:(?!\n\\S).)*filename=\"[^\"]*\\.([^\".]*)\".*|.*^content-type:(?:(?!\n\\S).)*name=\"[^\"]*\\.([^\".]*)\").*\n\n", >> re:run(Data, Regexp, [report_errors]). >> >> main([Filename]) -> >> spawn_link(fun Fun() -> >> log(heartbeat), >> timer:sleep(1000), >> Fun() >> end), >> log(test(Filename)). >> ---- >> >> Processing the complex regexp above takes about 50 seconds for my test >> data. Sometimes, the whole Erlang VM freezes for several seconds. The >> output then looks like this: >> >> ---- >> $ ./test.erl test.eml >> 18:27:48 heartbeat >> 18:27:49 heartbeat >> 18:27:50 heartbeat >> 18:27:51 heartbeat >> 18:27:52 heartbeat >> 18:27:53 heartbeat >> 18:27:54 heartbeat >> 18:27:55 heartbeat >> 18:27:56 heartbeat >> 18:27:57 heartbeat >> 18:27:58 heartbeat >> 18:27:59 heartbeat >> 18:28:00 heartbeat >> 18:28:01 heartbeat >> 18:28:02 heartbeat >> 18:28:03 heartbeat >> 18:28:04 heartbeat >> 18:28:05 heartbeat >> 18:28:06 heartbeat >> 18:28:07 heartbeat >> 18:28:08 heartbeat >> 18:28:36 heartbeat >> 18:28:36 nomatch >> ---- >> >> The VM froze between 18:28:08 and 18:28:36. The manual page re(3) >> states that "re:run always give control back to the scheduler of >> Erlang processes at intervals that ensures the real time properties of >> the Erlang system". I believe this is a bug, because re:run clearly >> didn't give control back to the scheduler during the interval above. >> >> Why does it happen? Is there any option to limit the number of time VM >> spends in re:run? >> >> The program and the data file can be downloaded here: >> >> http://miroslavurbanek.com/re.tgz >> >> Thanks, >> Miro >> _______________________________________________ >> 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 > From eric.pailleau@REDACTED Sat May 23 00:24:51 2015 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 23 May 2015 00:24:51 +0200 Subject: [erlang-bugs] Freeze in re:run In-Reply-To: <555FA79A.3040102@wanadoo.fr> References: <72f1310a-ca97-48da-a6d9-034aff99e913@email.android.com> <555FA79A.3040102@wanadoo.fr> Message-ID: <555FACB3.9020509@wanadoo.fr> Hi again, interestingly, when starting observer before spawn_link, output is not anymore frozen. I get heartbeat messages every second until nomatch. I did this several time, and sometime observer is totally unresponsive (frozen), but hearbeat messages are still coming in the meantime. Regards. From wallentin.dahlberg@REDACTED Sat May 23 01:40:07 2015 From: wallentin.dahlberg@REDACTED (=?UTF-8?Q?Bj=C3=B6rn=2DEgil_Dahlberg?=) Date: Sat, 23 May 2015 01:40:07 +0200 Subject: [erlang-bugs] Segmentation Fault in check_process_code / erts_garbage_collect In-Reply-To: References: <555F7B4F.5020504@chidig.com> Message-ID: Could you see if the following solves the problem: git fetch https://github.com/psyeugenic/otp.git egil/fix-purge-literals That branch is based on OTP-17.5 https://github.com/psyeugenic/otp/compare/maint...psyeugenic:egil/fix-purge-literals Just keep in mind that this hasn't been rigorously tested, only ran erlang-sigsegv which is still going strong. // Bj?rn-Egil 2015-05-22 23:31 GMT+02:00 Soup : > I am only upset that I am not able to replicate the original stacktrace I > saw in my production servers with this example. > > However, what little I was able to glean from the -g free stacktraces > showed that both the garbage collection and check process code errors were > happening when interacting with the "off heap" of the process. Not sure > what would be in the off heap, but binaries sound like they would be > (though I think there was something about function references to the old > version of the module in the vicinity as well). > > Please let me know if I can provide any more information. > > ~Zac > > On Fri, May 22, 2015 at 3:43 PM, Bj?rn-Egil Dahlberg < > wallentin.dahlberg@REDACTED> wrote: > >> I would also like to add that your testcase for provoking this was very >> helpful. The crash will almost always show a random symptom and rarely the >> actual cause. The point of corruption has long since passed. Therefor a >> testcase showing the error is the most helpful in hunting down the problem. >> >> 2015-05-22 21:32 GMT+02:00 Bj?rn-Egil Dahlberg < >> wallentin.dahlberg@REDACTED>: >> >>> I'll just mention that we have looked at this in the VM team at OTP and >>> can confirm the results. We also have a reasonable idea of what's happening. >>> It seems that a binary match state is not handled properly in garbage >>> collect literals (gc when purging code and moving literals to the process >>> heaps). >>> >>> I will look into it more on monday (or perhaps this weekend). >>> >>> // Bj?rn-Egil >>> >>> 2015-05-22 20:54 GMT+02:00 Bob Gustafson : >>> >>>> I am running 18.rc1 on a Macbook Air - I was able to duplicate your >>>> segv (although I haven't seen the dump) - I ran it for about 20 minutes >>>> total and it segv 3x in that time frame. >>>> >>>> While running, I used the Mac Activity Monitor to peek. >>>> >>>> It is using about 380% CPU, 19 Threads and seems to be only one OSX >>>> process. >>>> >>>> Memory jumps around a bit - roughly 360-420 MB initially and then it >>>> drops down - I saw 127 MB, and then it was gone - crashed. >>>> >>>> I will fish around for the crash dump. >>>> >>>> Have fun >>>> >>>> Bob G >>>> >>>> >>>> On 05/21/2015 11:48 AM, Soup wrote: >>>> >>>> This topic, or one very similar, appears to have been discussed >>>> before in the erlang-patches mailing list thread titled "erlang node >>>> crashes in erts_gc_after_bif_call" from October, 2012 ( >>>> http://erlang.org/pipermail/erlang-patches/2012-October/003072.html). >>>> No clear resolution was reached on this thread, and I am currently dealing >>>> with it in production systems, so I have decided to address this mailing >>>> list. >>>> >>>> Please see the bottom of the email for system specification, as I >>>> believe this to be largely unrelated (except possibly for multithreading). >>>> >>>> Please feel free to request any pertinent information I may have left >>>> out, or to make suggestions to improve future bug reports. I don't often >>>> submit bug reports, and am not at all familiar with Erlang/OTP's particular >>>> practices in this regard. >>>> >>>> >>>> *## Scenario and Error ## * >>>> The error is a segmentation fault arising out of the >>>> erts_garbage_collect and check_process_code functions. >>>> >>>> The scenario is as follows: >>>> 1) You must be hot-loading a module (in my case, this module is >>>> dynamically generated) periodically. >>>> 2) You must have non-suspended processes active in the module you are >>>> hot-loading while it is being loaded (though not necessarily *in* the code >>>> of the module; may be using terms from the module or having function >>>> references ot the module). >>>> 3) Purging of the *old* version of the module must be happening at the >>>> same time as garbage collection. (in my case, the garbage collection is >>>> explicit because of the use of large binary terms with relatively few >>>> reductions; that does not appear to be the case in the situation laid out >>>> in the previously mentioned thread). >>>> >>>> It appears, at least to my untrained eye, that garbage collection >>>> sweeps can occur at the same time as code purging, and that this seems to >>>> happen without multithreading protection. My reason for this suspicion is >>>> that in my production systems I began receiving one of two segmentation >>>> faults: one occuring in the function check_process_code (of >>>> erts/emulator/beam/beam_bif_load.c) and erts_garbage_collect (of >>>> erts/emulator/beam/erl_gc.c). Most of the time *in production*, the >>>> segmentation fault occured in the check_process_code function. Only >>>> sometimes did it appear to be coming from erts_garbage_collect. >>>> >>>> *## Reproducing the Error ##* >>>> >>>> It took a while, but I did ultimately manage to create an app which >>>> reliably produces this error (insofar as I can tell). Please see the app >>>> here: https://github.com/fauxsoup/erlang-sigsegv >>>> >>>> There are some apparent differences from what I was observing in >>>> production, but this could possibly be related to differences between my >>>> production environment and my testing environment (which are non-trivial), >>>> and potentially differences between my minimal test case and the production >>>> service. Please see the bottom of this email for pertinent details about >>>> both environments. >>>> >>>> For testing, and because my production deployment of Erlang does not >>>> include debug symbols, I recompiled Erlang/OTP 17.4 with the flags "-g -O2" >>>> to produce debug symbols and prevent aggressive optimizations which may >>>> distort the stacktrace. >>>> >>>> The primary difference between the *results* of the error in production >>>> versus testing is that the segmentation fault in testing *always *comes >>>> from erts_garbage_collect. I have not at all been able to produce a test >>>> result in which the segmentation fault occured in check_process_code using >>>> the minimal test case code. >>>> >>>> Another difference, which I believe to be caused by the inclusion of >>>> debug symbols, is that erts_garbage_collect appears earlier in the >>>> backtrace in testing, and that the actual segmentation fault appears to >>>> come from the function sweep_one_area (erl_gc.c again). My assumption is >>>> that the optimization and lack of debug symbols in the production system >>>> merely obfuscated the origin of the segmentation fault there. >>>> >>>> >>>> >>>> *## The Backtrace ## * >>>> Included here for your convenience (also available in test case README): >>>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to >>>> Thread 0x7ffff3b3e700 (LWP 26743)] >>>> sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, >>>> src=src@REDACTED=0x7fffe9ec2028 "", src_size=src_size@REDACTED=600224) at >>>> beam/erl_gc.c:1816 >>>> 1816 mb->base = binary_bytes(*origptr); >>>> (gdb) bt >>>> #0 sweep_one_area (n_hp=0x7fffe8862028, n_htop=0x7fffe8862c48, >>>> src=src@REDACTED=0x7fffe9ec2028 "", src_size=src_size@REDACTED=600224) at >>>> beam/erl_gc.c:1816 >>>> #1 0x0000000000527ea0 in do_minor (nobj=1, objv=0x7ffff3b3dd50, >>>> new_sz=121536, p=0x7ffff5c80800) at beam/erl_gc.c:1160 >>>> #2 minor_collection (recl=, nobj=1, >>>> objv=0x7ffff3b3dd50, need=0, p=0x7ffff5c80800) at beam/erl_gc.c:876 >>>> #3 erts_garbage_collect (p=0x7ffff5c80800, need=need@REDACTED=0, >>>> objv=objv@REDACTED=0x7ffff3b3dd50, nobj=nobj@REDACTED=1) at beam/erl_gc.c:450 >>>> #4 0x000000000052877b in erts_gc_after_bif_call (p=0x7ffff5c80800, >>>> result=140736302308346, regs=, arity=) at >>>> beam/erl_gc.c:370 >>>> #5 0x0000000000571951 in process_main () at beam/beam_emu.c:2787 >>>> #6 0x00000000004a9a70 in sched_thread_func (vesdp=0x7ffff51cc8c0) at >>>> beam/erl_process.c:7743 >>>> #7 0x00000000006056fb in thr_wrapper (vtwd=0x7fffffffd9a0) at >>>> pthread/ethread.c:106 >>>> #8 0x00007ffff704d374 in start_thread () from /usr/lib/libpthread.so.0 >>>> #9 0x00007ffff6b8327d in clone () from /usr/lib/libc.so.6 >>>> >>>> *## The Systems ##* >>>> >>>> >>>> *PRODUCTION *Erlang/OTP 17.4 (also observed on Erlang R15B01) >>>> Amazon EC2 c3.8xlarge (32 Virtual CPUs, ~64 GB Memory) >>>> Debian Wheezy >>>> uname -a: Linux rtb0.ec2.chitika.net 3.2.0-4-amd64 #1 SMP Debian >>>> 3.2.63-2 x86_64 GNU/Linux >>>> >>>> *TESTING* >>>> Erlang/OTP 17.4 >>>> Intel Core i5 760 @ 2.80GHz (4 Logical CPUs, 2 cores IIRC), ~16GB Memory >>>> Arch Linux (up-to-date) >>>> uname -a: Linux diogenes 4.0.1-1-ARCH #1 SMP PREEMPT Wed Apr 29 >>>> 12:00:26 CEST 2015 x86_64 GNU/Linux >>>> >>>> >>>> _______________________________________________ >>>> 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 mu@REDACTED Sat May 23 04:54:12 2015 From: mu@REDACTED (Miroslav Urbanek) Date: Sat, 23 May 2015 04:54:12 +0200 Subject: [erlang-bugs] Freeze in re:run In-Reply-To: <555FACB3.9020509@wanadoo.fr> References: <72f1310a-ca97-48da-a6d9-034aff99e913@email.android.com> <555FA79A.3040102@wanadoo.fr> <555FACB3.9020509@wanadoo.fr> Message-ID: <20150523025412.GA3788@miroslavurbanek.com> Hi Eric, thanks for your investigation. One thing I tried before is to uncomment the line #define ERLANG_DEBUG 1 in erts/emulator/pcre/pcre_exec.c. I don't have the output anymore, but it clearly showed "heartbeat" message near "Loop limit break detected". I think PCRE library doesn't properly return control to the VM, but my understanding of Erlang and PCRE internals is rather limited to see why. Miro On Sat, May 23, 2015 at 12:24:51AM +0200, PAILLEAU Eric wrote: > Hi again, > > interestingly, when starting observer before spawn_link, output is > not anymore frozen. I get heartbeat messages every second until > nomatch. > > I did this several time, and sometime observer is totally > unresponsive (frozen), but hearbeat messages are still coming in the > meantime. > > Regards. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From rickard@REDACTED Mon May 25 09:34:30 2015 From: rickard@REDACTED (Rickard Green) Date: Mon, 25 May 2015 09:34:30 +0200 Subject: [erlang-bugs] VM locking up 18.0-rc2 In-Reply-To: References: <20150517123708.GA9886@nybek.com> Message-ID: On Wed, May 20, 2015 at 11:37 PM, Rickard Green wrote: >> After the first connection, the VM will lock up and look like this: >> >> 1> acceptor_pool:start_link(). >> New acceptor started: <0.37.0> >> {ok,<0.36.0>} >> HERE 1 >> HERE 2 >> New acceptor started: <0.40.0> >> 2> >> > > Thanks for the bug report! A fix for this will soon show up in the > master branch. > > Regards, > Rickard > -- > Rickard Green, Erlang/OTP, Ericsson AB There is now a fix (4619791) for this in the master branch. Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB From rory@REDACTED Mon May 25 11:19:21 2015 From: rory@REDACTED (Rory Byrne) Date: Mon, 25 May 2015 10:19:21 +0100 Subject: [erlang-bugs] VM locking up 18.0-rc2 In-Reply-To: References: <20150517123708.GA9886@nybek.com> Message-ID: <20150525091921.GA31106@nybek.com> On Mon, May 25, 2015 at 09:34:30AM +0200, Rickard Green wrote: > On Wed, May 20, 2015 at 11:37 PM, Rickard Green wrote: > > > > Thanks for the bug report! A fix for this will soon show up in the > > master branch. > > There is now a fix (4619791) for this in the master branch. Great stuff! Everything works fine now. Thank you. Rory From aronisstav@REDACTED Wed May 27 13:40:11 2015 From: aronisstav@REDACTED (Stavros Aronis) Date: Wed, 27 May 2015 13:40:11 +0200 Subject: [erlang-bugs] Call with a tuple as a module succeeds in Erlang 18 RC2 Message-ID: Hello! It seems that there are some leftovers from the parameterized modules support in the compiler for Erlang 18 RC2 (and also earlier Erlang versions). In the example below, even though the compiler emits warnings when a tuple is used as a module name, the code executes without error. Requesting HiPE compilation restores the 'correct' behaviour (an error is raised). Regards, Stavros --- $ cat tuple_as_module.erl -module(tuple_as_module). -export([test/0, action/2]). test() -> P = {?MODULE, [1,2,3]}, {P:action(head), P:action(tail)}. action(head, {?MODULE, List}) -> hd(List); action(tail, {?MODULE, List}) -> tl(List). $ erl Erlang/OTP 18 [RELEASE CANDIDATE 2] [erts-7.0] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.0 (abort with ^G) 1> c(tuple_as_module). tuple_as_module.erl:7: Warning: invalid module and/or function name; this call will always fail tuple_as_module.erl:8: Warning: invalid module and/or function name; this call will always fail {ok,tuple_as_module} 2> tuple_as_module:test(). {1,[2,3]} 3> c(tuple_as_module, [native]). tuple_as_module.erl:7: Warning: invalid module and/or function name; this call will always fail tuple_as_module.erl:8: Warning: invalid module and/or function name; this call will always fail {ok,tuple_as_module} 4> tuple_as_module:test(). ** exception error: bad argument -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed May 27 14:00:41 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 27 May 2015 14:00:41 +0200 Subject: [erlang-bugs] Call with a tuple as a module succeeds in Erlang 18 RC2 In-Reply-To: References: Message-ID: Le 27 mai 2015 ? 13:40, Stavros Aronis a ?crit : > Hello! > > It seems that there are some leftovers from the parameterized modules support in the compiler for Erlang 18 RC2 (and also earlier Erlang versions). In the example below, even though the compiler emits warnings when a tuple is used as a module name, the code executes without error. > > Requesting HiPE compilation restores the 'correct' behaviour (an error is raised). > > Regards, > > Stavros From what I know, the module-as-tuple feature is here to stay and HiPE is wrong to refuse to compile such code. From mononcqc@REDACTED Wed May 27 15:07:31 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 27 May 2015 09:07:31 -0400 Subject: [erlang-bugs] Call with a tuple as a module succeeds in Erlang 18 RC2 In-Reply-To: References: Message-ID: <20150527130730.GJ75968@ferdair.local> On 05/27, Anthony Ramine wrote: >From what I know, the module-as-tuple feature is here to stay and HiPE >is wrong to refuse to compile such code. > That is correct. See http://www.erlang.org/news/35, issue 4: >Issue 4 - What to do with unsupported feature 'parameterized modules'. > > [...] > >To allow for source code compatibility, the board decides to only >remove the syntactic support for parameterized modules. This means: > >* Apply with tuple modules will be retained, supported and properly >documented. > > [...] > >* The parser will accept the syntax for implementation of parameterized >modules, but if the parameterized modules are not handled by a >parse_transform, an error message will be generated at a later stage >(this concerns the implementation of the modules themselves only). > I kept the relevant sections of the announcement. From aronisstav@REDACTED Wed May 27 16:10:59 2015 From: aronisstav@REDACTED (Stavros Aronis) Date: Wed, 27 May 2015 16:10:59 +0200 Subject: [erlang-bugs] Call with a tuple as a module succeeds in Erlang 18 RC2 In-Reply-To: <20150527130730.GJ75968@ferdair.local> References: <20150527130730.GJ75968@ferdair.local> Message-ID: Thanks Anthony & Fred! As far as I can understand from http://www.erlang.org/news/35: * The compiler warnings are wrong. The calls will succeed, and are expected to do so, since tuples are supported. * There should be 'proper documentation' about this feature somewhere, but I have failed to find it. * HiPE is wrong in compiling this into something that returns a 'badarg' error. It seems, therefore, that this is still a bug report, right? Stavros On Wed, May 27, 2015 at 3:07 PM, Fred Hebert wrote: > On 05/27, Anthony Ramine wrote: > >> From what I know, the module-as-tuple feature is here to stay and HiPE is >> wrong to refuse to compile such code. >> >> > That is correct. See http://www.erlang.org/news/35, issue 4: > > Issue 4 - What to do with unsupported feature 'parameterized modules'. >> >> [...] >> >> To allow for source code compatibility, the board decides to only remove >> the syntactic support for parameterized modules. This means: >> >> * Apply with tuple modules will be retained, supported and properly >> documented. >> >> [...] >> >> * The parser will accept the syntax for implementation of parameterized >> modules, but if the parameterized modules are not handled by a >> parse_transform, an error message will be generated at a later stage (this >> concerns the implementation of the modules themselves only). >> >> > I kept the relevant sections of the announcement. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Fri May 29 17:33:38 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 29 May 2015 17:33:38 +0200 Subject: [erlang-bugs] Observer Crashdump Viewer bug? In-Reply-To: References: Message-ID: On Sun, May 10, 2015 at 12:00 PM, Tuncer Ayaz wrote: > On Fri, Apr 24, 2015 at 10:35 PM, Tuncer Ayaz wrote: >> 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. > > So, can nobody else reproduce this? Bump? From mikpelinux@REDACTED Sat May 30 18:33:01 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 30 May 2015 18:33:01 +0200 Subject: [erlang-bugs] mnesia can corrupt tables if the VM runs out of file descriptors Message-ID: <21865.58941.866765.916749@gargle.gargle.HOWL> An embedded and charset-unspecified text was scrubbed... Name: mnesia_corrupts_data.erl URL: -------------- next part -------------- If the Erlang VM is close to its file descriptor limit, and mnesia tries to open a disc_copies table's .DCL file, the open fails with {error, emfile} which mnesia_log:open_log/6 incorrectly interprets as a corrupt file, and it then DELETES the perfectly valid .DCL file. This is reproducible with (at least) OTP 18.0-rc2 and R15B03. (This is not a hypothetical problem, it hit us and corrupted three tables, though we managed to recover through luck and manual emergency procedures.) I'm attaching a standalone module which reproduces the corruption for me with OTP 18.0-rc2 on a Fedora 20 Linux / x86_64 desktop system. Here's a transcript from a run of that module (foo.DCL is the interesting file): Script started on Sat 30 May 2015 05:47:41 PM CEST _1_/tmp/otp/bin/erlc mnesia_corrupts_data.erl _2_/tmp/otp/bin/erl Erlang/OTP 18 [RELEASE CANDIDATE 2] [erts-7.0] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.0 (abort with ^G) 1> mnesia_corrupts_data:doit(). DCL created after 1024 records written =INFO REPORT==== 30-May-2015::17:48:23 === application: mnesia exited: stopped type: temporary Initial DB: total 152 -rw-r--r-- 1 mikpe mikpe 2715 May 30 17:48 LATEST.LOG -rw-r--r-- 1 mikpe mikpe 104101 May 30 17:48 PREVIOUS.LOG -rw-r--r-- 1 mikpe mikpe 8 May 30 17:48 foo.DCD -rw-r--r-- 1 mikpe mikpe 31039 May 30 17:48 foo.DCL -rw-r--r-- 1 mikpe mikpe 6750 May 30 17:48 schema.DAT managed to open 1014 files Mnesia(nonode@REDACTED): Data may be missing, Corrupt logfile deleted: "/tmp/Mnesia.nonode@REDACTED/foo.DCL", {file_error, "/tmp/Mnesia.nonode@REDACTED/foo.DCL", emfile} =ERROR REPORT==== 30-May-2015::17:48:25 === Mnesia(nonode@REDACTED): ** ERROR ** (could not write core file: emfile) ** FATAL ** Cannot open log file "/tmp/Mnesia.nonode@REDACTED/foo.DCL": {file_error, "/tmp/Mnesia.nonode@REDACTED/foo.DCL", emfile} =ERROR REPORT==== 30-May-2015::17:48:35 === ** Generic server mnesia_monitor terminating ** Last message in was {'EXIT',<0.95.0>,killed} ** When Server state == {state,<0.95.0>,[],[],true,[],undefined,[],[]} ** Reason for termination == ** killed =ERROR REPORT==== 30-May-2015::17:48:35 === ** Generic server mnesia_recover terminating ** Last message in was {'EXIT',<0.95.0>,killed} ** When Server state == {state,<0.95.0>,undefined,undefined,undefined,0,false, true,[]} ** Reason for termination == ** killed =INFO REPORT==== 30-May-2015::17:48:35 === application: mnesia exited: {killed,{mnesia_sup,start,[normal,[]]}} type: temporary ** exception exit: {badmatch,{error,{killed,{mnesia_sup,start,[normal,[]]}}}} in function mnesia_corrupts_data:check_db/1 (mnesia_corrupts_data.erl, line 39) 2> BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution ^C _3_ls -l Mnesia.nonode@REDACTED/ total 120 -rw-r--r-- 1 mikpe mikpe 2715 May 30 17:48 LATEST.LOG -rw-r--r-- 1 mikpe mikpe 104101 May 30 17:48 PREVIOUS.LOG -rw-r--r-- 1 mikpe mikpe 8 May 30 17:48 foo.DCD -rw-r--r-- 1 mikpe mikpe 6750 May 30 17:48 schema.DAT _4_ /Mikael From mikpelinux@REDACTED Sun May 31 12:06:30 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 31 May 2015 12:06:30 +0200 Subject: [erlang-bugs] mnesia can corrupt tables if the VM runs out of file descriptors In-Reply-To: <21865.58941.866765.916749@gargle.gargle.HOWL> References: <21865.58941.866765.916749@gargle.gargle.HOWL> Message-ID: <21866.56614.295851.58281@gargle.gargle.HOWL> Mikael Pettersson writes: > -module(mnesia_corrupts_data). > -compile(export_all). > > -record(foo, {key, data}). > > doit() -> > %% set up initial db with foo.DCD and foo.DCL, > %% foo contains records with keys [0,N[ > N = init_db(), > io:format("Initial DB:\n~s", [os:cmd("ls -l Mnesia.nonode@REDACTED")]), > FDs = open_all_available_fds(), > %% free enough FDs so mnesia can start, but not enough for it > %% to be able to open foo.DCL > close_some_fds(FDs), > check_db(N). > > init_db() -> > ok = mnesia:create_schema([node()]), > ok = mnesia:start(), > {atomic, ok} = mnesia:create_table(foo, > [{attributes, record_info(fields, foo)}, > {disc_copies, [node()]}]), > N = create_dcl(0), > stopped = mnesia:stop(), > N. > > create_dcl(N) -> > case prim_file:read_file_info("Mnesia.nonode@REDACTED/foo.DCL") of > {error, enoent} -> > {atomic, ok} = > mnesia:transaction(fun() -> mnesia:write(#foo{key = N, data = "bar"}) end), > create_dcl(N + 1); > {ok, _} -> > io:format("DCL created after ~p records written\n", [N]), > N > end. > > check_db(N) -> > ok = mnesia:start(), > ok = mnesia:wait_for_tables([foo], 5*1000), > check_foo(0, N). > > check_foo(I, N) when I < N -> > [{foo, I, "bar"}] = mnesia:dirty_read(foo, I), > check_foo(I + 1, N); > check_foo(I, N) when I >= N -> > ok. > > open_all_available_fds() -> > ok = file:write_file("dummy.txt", <<"whatever\n">>), > open_all_available_fds([], 0). > > open_all_available_fds(FDs, N) -> > case prim_file:open("dummy.txt", [read]) of > {ok, FD} -> > open_all_available_fds([FD | FDs], N + 1); > {error, emfile} -> > io:format("managed to open ~p files\n", [N]), > FDs > end. > > close_some_fds([FD1, FD2 | _]) -> > prim_file:close(FD1), > prim_file:close(FD2). > > ---------------------------------------------------------------------- > If the Erlang VM is close to its file descriptor limit, and mnesia tries > to open a disc_copies table's .DCL file, the open fails with {error, emfile} > which mnesia_log:open_log/6 incorrectly interprets as a corrupt file, and it > then DELETES the perfectly valid .DCL file. > > This is reproducible with (at least) OTP 18.0-rc2 and R15B03. > > (This is not a hypothetical problem, it hit us and corrupted three tables, > though we managed to recover through luck and manual emergency procedures.) > > I'm attaching a standalone module which reproduces the corruption for me > with OTP 18.0-rc2 on a Fedora 20 Linux / x86_64 desktop system. Here's a > transcript from a run of that module (foo.DCL is the interesting file): > > Script started on Sat 30 May 2015 05:47:41 PM CEST > _1_/tmp/otp/bin/erlc mnesia_corrupts_data.erl > _2_/tmp/otp/bin/erl > Erlang/OTP 18 [RELEASE CANDIDATE 2] [erts-7.0] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V7.0 (abort with ^G) > 1> mnesia_corrupts_data:doit(). > DCL created after 1024 records written > > =INFO REPORT==== 30-May-2015::17:48:23 === > application: mnesia > exited: stopped > type: temporary > Initial DB: > total 152 > -rw-r--r-- 1 mikpe mikpe 2715 May 30 17:48 LATEST.LOG > -rw-r--r-- 1 mikpe mikpe 104101 May 30 17:48 PREVIOUS.LOG > -rw-r--r-- 1 mikpe mikpe 8 May 30 17:48 foo.DCD > -rw-r--r-- 1 mikpe mikpe 31039 May 30 17:48 foo.DCL > -rw-r--r-- 1 mikpe mikpe 6750 May 30 17:48 schema.DAT > managed to open 1014 files > Mnesia(nonode@REDACTED): Data may be missing, Corrupt logfile deleted: "/tmp/Mnesia.nonode@REDACTED/foo.DCL", {file_error, > "/tmp/Mnesia.nonode@REDACTED/foo.DCL", > emfile} > > =ERROR REPORT==== 30-May-2015::17:48:25 === > Mnesia(nonode@REDACTED): ** ERROR ** (could not write core file: emfile) > ** FATAL ** Cannot open log file "/tmp/Mnesia.nonode@REDACTED/foo.DCL": {file_error, > "/tmp/Mnesia.nonode@REDACTED/foo.DCL", > emfile} > > =ERROR REPORT==== 30-May-2015::17:48:35 === > ** Generic server mnesia_monitor terminating > ** Last message in was {'EXIT',<0.95.0>,killed} > ** When Server state == {state,<0.95.0>,[],[],true,[],undefined,[],[]} > ** Reason for termination == > ** killed > > =ERROR REPORT==== 30-May-2015::17:48:35 === > ** Generic server mnesia_recover terminating > ** Last message in was {'EXIT',<0.95.0>,killed} > ** When Server state == {state,<0.95.0>,undefined,undefined,undefined,0,false, > true,[]} > ** Reason for termination == > ** killed > > =INFO REPORT==== 30-May-2015::17:48:35 === > application: mnesia > exited: {killed,{mnesia_sup,start,[normal,[]]}} > type: temporary > ** exception exit: {badmatch,{error,{killed,{mnesia_sup,start,[normal,[]]}}}} > in function mnesia_corrupts_data:check_db/1 (mnesia_corrupts_data.erl, line 39) > 2> > BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded > (v)ersion (k)ill (D)b-tables (d)istribution > ^C > _3_ls -l Mnesia.nonode@REDACTED/ > total 120 > -rw-r--r-- 1 mikpe mikpe 2715 May 30 17:48 LATEST.LOG > -rw-r--r-- 1 mikpe mikpe 104101 May 30 17:48 PREVIOUS.LOG > -rw-r--r-- 1 mikpe mikpe 8 May 30 17:48 foo.DCD > -rw-r--r-- 1 mikpe mikpe 6750 May 30 17:48 schema.DAT > _4_ > > /Mikael https://github.com/erlang/otp/pull/752 Tested with 18.0-rc2 and 17.5.3.