From filip@REDACTED Wed Jan 20 18:42:28 2016 From: filip@REDACTED (Filip Andres) Date: Wed, 20 Jan 2016 18:42:28 +0100 Subject: [erlang-bugs] Troubles with ethr_dw_atomic_cmpxchg implementation on intel Atom? Message-ID: Hello, I have found out that on intel Atom processors the erlang:processes() crashes the VM. To me it seems like a glitch in the implementation of ethr_dw_atomic_cmpxchg on platforms lacking native support for double word compare-and-exchange (although I cannot claim I really understand all of erl_threads.h and atomic.h). GDB stacktrace: (gdb) bt #0 0x56798d70 in ethr_dw_atomic_cmpxchg () at ../include/internal/i386/atomic.h:177 #1 0x566103ce in ethr_dw_atomic_cmpxchg_nob (xchg=0xf4e0609c, new=0xf4e060a4, var=0x568688f0 ) at beam/erl_threads.h:1456 #2 erts_atomic64_inc_read_nob (var=0x568688f0 ) at beam/erl_threads.h:1646 #3 step_interval_nob (icp=0x568688f0 ) at beam/utils.c:4954 #4 erts_smp_step_interval_nob (icp=icp@REDACTED=0x568688f0 ) at beam/utils.c:5004 #5 0x5671572b in ptab_list_bif_engine (c_p=c_p@REDACTED=0xf6dc0218, res_accp=res_accp@REDACTED=0xf4e06178, mbp=mbp@REDACTED=0xf1f80a88) at beam/erl_ptab.c:927 #6 0x56716a5d in erts_ptab_list (c_p=c_p@REDACTED=0xf6dc0218, ptab=0x568688c0 ) at beam/erl_ptab.c:766 #7 0x5661be76 in processes_0 (A__p=0xf6dc0218, BIF__ARGS=0xf7483100) at beam/bif.c:3841 #8 0x5659978b in process_main () at beam/beam_emu.c:3690 #9 0x56638784 in sched_thread_func (vesdp=0xf6087dc0) at beam/erl_process.c:8021 #10 0x567a19cc in thr_wrapper (vtwd=0xffffd1b4) at pthread/ethread.c:114 #11 0xf7f164be in start_thread (arg=0xf4e06b40) at pthread_create.c:333 #12 0xf7e2a3fe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:114 Some more information in: https://bugzilla.redhat.com/show_bug.cgi?id=1221824 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.joseph.davis@REDACTED Thu Jan 21 06:26:33 2016 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Wed, 20 Jan 2016 23:26:33 -0600 Subject: [erlang-bugs] NIF segfault when using dirty schedulers Message-ID: Hey all, I've recently run into a segfault while working with dirty schedulers. I managed to make a fairly concise reproducing test case at [1]. I included a stack trace at [2] from when the segfault occurs. This is definitely a racey segfault as well. I sometimes have to run `rebar eunit` a handful of times to trigger it. I'm not hugely familiar with all of the VM internals so I'm at a bit of a loss on where to start looking further. I did try and get rid of the requirement for eunit but I couldn't reproduce without it. This reproduces on both 17.5.6.4 where I found it and 18.2.2. I haven't tried master or anything of that nature. Let me know if there's anything else I can do to help debug this. Thanks, Paul [1] https://gist.github.com/davisp/1e71ec7f2f7a70d1b79c [2] https://gist.github.com/davisp/1e71ec7f2f7a70d1b79c#file-gdb_backtrace-txt From vinoski@REDACTED Thu Jan 21 13:24:58 2016 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 21 Jan 2016 07:24:58 -0500 Subject: [erlang-bugs] NIF segfault when using dirty schedulers In-Reply-To: References: Message-ID: On Thu, Jan 21, 2016 at 12:26 AM, Paul Davis wrote: > Hey all, > > I've recently run into a segfault while working with dirty schedulers. > I managed to make a fairly concise reproducing test case at [1]. I > included a stack trace at [2] from when the segfault occurs. This is > definitely a racey segfault as well. I sometimes have to run `rebar > eunit` a handful of times to trigger it. > > I'm not hugely familiar with all of the VM internals so I'm at a bit > of a loss on where to start looking further. I did try and get rid of > the requirement for eunit but I couldn't reproduce without it. > > This reproduces on both 17.5.6.4 where I found it and 18.2.2. I > haven't tried master or anything of that nature. > > Let me know if there's anything else I can do to help debug this. > > Thanks, > Paul > > [1] https://gist.github.com/davisp/1e71ec7f2f7a70d1b79c > [2] > https://gist.github.com/davisp/1e71ec7f2f7a70d1b79c#file-gdb_backtrace-txt I'll have a look at your example, thanks for putting it together. Fro your backtrace I'm guessing the issue is already fixed by available patches which are not yet consolidated in any one branch or release. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From ram3a12@REDACTED Thu Jan 21 13:38:50 2016 From: ram3a12@REDACTED (Ingars) Date: Thu, 21 Jan 2016 14:38:50 +0200 Subject: [erlang-bugs] ASN.1. generation with erlc -bber works / erlc -bper - fails Message-ID: Hi, I have found an ASN.1 fragment that compiles well with erlc -bber flag but fails with erlc -bper. > iri@REDACTED:~/asn$ erlc -bber TEST.asn -> works well > iri@REDACTED:~/asn$ erlc -bper TEST.asn -> raises an error ------------------------------------------------ {{badmatch,1799999989}, [{asn1ct_imm,per_enc_constrained,4,[{file,"asn1ct_imm.erl"},{line,1139}]}, {asn1ct_imm,per_enc_integer_1,3,[{file,"asn1ct_imm.erl"},{line,1094}]}, {asn1ct_imm,'-per_enc_integer/4-lc$^0/1-0-',4, [{file,"asn1ct_imm.erl"},{line,248}]}, {asn1ct_imm,per_enc_integer,4,[{file,"asn1ct_imm.erl"},{line,248}]}, {asn1ct_gen_per,gen_encode_prim,3,[{file,"asn1ct_gen_per.erl"},{line,121}]}, {asn1ct_gen_per,gen_encode_user,2,[{file,"asn1ct_gen_per.erl"},{line,98}]}, {asn1ct_gen,pgen_types,5,[{file,"asn1ct_gen.erl"},{line,123}]}, {asn1ct_gen,pgen_typeorval,4,[{file,"asn1ct_gen.erl"},{line,105}]}]} ------------------------------------------------ With ASN.1 -> C compiler > asn1c -gen-PER TEST.asn -> also works well File TEST.asn: ------------------------ TEST DEFINITIONS IMPLICIT TAGS ::= BEGIN Longitude ::= INTEGER { oneMicrodegreeEast(10), oneMicrodegreeWest(-10), unavailable(1800000001) } (-1799999999..1800000001) END ------------------------ Thanks, Ingars ///// -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Thu Jan 21 16:18:40 2016 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 21 Jan 2016 16:18:40 +0100 Subject: [erlang-bugs] ASN.1. generation with erlc -bber works / erlc -bper - fails In-Reply-To: References: Message-ID: On Thu, Jan 21, 2016 at 1:38 PM, Ingars wrote: > Hi, > > I have found an ASN.1 fragment that compiles well with erlc -bber flag but > fails with erlc -bper. > Thanks for the bug report. Here is a branch that fixes the bug: https://github.com/bjorng/otp/tree/bjorn/asn1/fix-per-crash/OTP-13257 The fix will be included in OTP 18.3. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From mikpelinux@REDACTED Sat Jan 23 19:01:55 2016 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 23 Jan 2016 19:01:55 +0100 Subject: [erlang-bugs] Troubles with ethr_dw_atomic_cmpxchg implementation on intel Atom? In-Reply-To: References: Message-ID: <22179.49171.89654.972724@gargle.gargle.HOWL> Filip Andres writes: > Hello, > I have found out that on intel Atom processors the erlang:processes() > crashes the VM. > To me it seems like a glitch in the implementation of > ethr_dw_atomic_cmpxchg on platforms lacking native support for double word > compare-and-exchange (although I cannot claim I really understand all of > erl_threads.h and atomic.h). > > GDB stacktrace: > > (gdb) bt > #0 0x56798d70 in ethr_dw_atomic_cmpxchg () at > ../include/internal/i386/atomic.h:177 > #1 0x566103ce in ethr_dw_atomic_cmpxchg_nob (xchg=0xf4e0609c, > new=0xf4e060a4, var=0x568688f0 ) > at beam/erl_threads.h:1456 > #2 erts_atomic64_inc_read_nob (var=0x568688f0 ) at > beam/erl_threads.h:1646 > #3 step_interval_nob (icp=0x568688f0 ) at beam/utils.c:4954 > #4 erts_smp_step_interval_nob (icp=icp@REDACTED=0x568688f0 > ) at beam/utils.c:5004 > #5 0x5671572b in ptab_list_bif_engine (c_p=c_p@REDACTED=0xf6dc0218, > res_accp=res_accp@REDACTED=0xf4e06178, > mbp=mbp@REDACTED=0xf1f80a88) at beam/erl_ptab.c:927 > #6 0x56716a5d in erts_ptab_list (c_p=c_p@REDACTED=0xf6dc0218, > ptab=0x568688c0 ) at beam/erl_ptab.c:766 > #7 0x5661be76 in processes_0 (A__p=0xf6dc0218, BIF__ARGS=0xf7483100) > at beam/bif.c:3841 > #8 0x5659978b in process_main () at beam/beam_emu.c:3690 > #9 0x56638784 in sched_thread_func (vesdp=0xf6087dc0) at > beam/erl_process.c:8021 > #10 0x567a19cc in thr_wrapper (vtwd=0xffffd1b4) at pthread/ethread.c:114 > #11 0xf7f164be in start_thread (arg=0xf4e06b40) at pthread_create.c:333 > #12 0xf7e2a3fe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:114 > > Some more information in: > https://bugzilla.redhat.com/show_bug.cgi?id=1221824 I'm unable to reproduce this issue with Fedora 22 running on a Core-i7 CPU. I forced a 32-bit build with "setarch i386", and in that I further forced "-mtune=atom" into CFLAGS when building otp_src_18.2.1.tar.gz. The build succeeded and "erlang:processes()." didn't SEGV. Can you please add the following information: - all options passed to ./configure - what does "gcc -v" say in your build environment? - cat /proc/cpuinfo - in your GDB session, please do "info regs" and disassemble the function which faulted - do the binaries fault everywhere or only on those Atom processors? - does the build use libatomic_ops? if so, can you try without that