Latest upstream release: 17.5 Current version/release in rawhide: 17.4-2.fc23 URL: http://www.erlang.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.
Created attachment 1025627 [details] [patch] Update to 17.5 (#1221824)
Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9742977
Latest upstream release: 18.0 Current version/release in rawhide: 17.4-3.fc23 URL: http://www.erlang.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.
Created attachment 1042755 [details] [patch] Update to 18.0 (#1221824)
Scratch build failed http://koji.fedoraproject.org/koji/taskinfo?taskID=10197769
Latest upstream release: 18.1 Current version/release in rawhide: 17.4-5.fc24 URL: http://www.erlang.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.
Failed to kick off scratch build. cmd: sha256sum /var/tmp/thn-Ey_tJO/100.0% return code: 1 stdout: stderr: sha256sum: /var/tmp/thn-Ey_tJO/100.0%: No such file or directory
Latest upstream release: 18.2 Current version/release in rawhide: 17.4-5.fc24 URL: http://www.erlang.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.
Created attachment 1106948 [details] [patch] Update to 18.2 (#1221824)
Scratch build failed http://koji.fedoraproject.org/koji/taskinfo?taskID=12227928
Latest upstream release: 18.2.1 Current version/release in rawhide: 17.4-5.fc24 URL: http://www.erlang.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.
Created attachment 1107111 [details] [patch] Update to 18.2.1 (#1221824)
Scratch build failed http://koji.fedoraproject.org/koji/taskinfo?taskID=12236550
Created attachment 1110687 [details] Erlang 18.2.1 spec Update for Erlang 18.2.1, the package builds and works at least for x86_64 and i686 (even the bug with erlang:processes() dumping core has been corrected by this). Below is the output from rpmlint, all the warnings have been present before, no new warnings or errors introduced: erlang.src: W: spelling-error Summary(en_US) runtime -> run time, run-time, rudiment erlang.src: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment erlang.src: W: invalid-url URL: http://www.erlang.org HTTP Error 500: Internal Server Error erlang.src: W: strange-permission otp-get-patches.sh 775 erlang.src:414: W: unversioned-explicit-obsoletes erlang-appmon erlang.src:415: W: unversioned-explicit-obsoletes erlang-docbuilder erlang.src:416: W: unversioned-explicit-obsoletes erlang-inviso erlang.src:417: W: unversioned-explicit-obsoletes erlang-pman erlang.src:418: W: unversioned-explicit-obsoletes erlang-toolbar erlang.src:419: W: unversioned-explicit-obsoletes erlang-tv erlang.src:1489: W: macro-in-comment %dir erlang.src:1489: W: macro-in-comment %{_javadir} erlang.src:1489: W: macro-in-comment %{name} erlang.src:1521: W: macro-in-comment %dir erlang.src:1521: W: macro-in-comment %{_javadir} erlang.src:1521: W: macro-in-comment %{name} 1 packages and 0 specfiles checked; 0 errors, 16 warnings.
Scratch build succeeded: http://koji.fedoraproject.org/koji/taskinfo?taskID=12353990
(In reply to Filip Andres from comment #15) > Scratch build succeeded: > http://koji.fedoraproject.org/koji/taskinfo?taskID=12353990 Thanks for that! I'll upgrade Erlang shortly.
*** Bug 1188678 has been marked as a duplicate of this bug. ***
(In reply to Peter Lemenkov from comment #16) > (In reply to Filip Andres from comment #15) > > Scratch build succeeded: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=12353990 > > Thanks for that! I'll upgrade Erlang shortly. Great news Peter! Thank you for that. Please let me know if there is anything I could help you with.
Ok, I've made a build for Rawhide. Unfortunately it's not that easy to upgrade Erlang in F22/F23 because this is a API/ABI-incompatible upgrade, and user has to rebuild all his/her NIFs and driver libraries.
Hi Peter, the new version seems to be plagued by the same error as the old one -- erlang:processes() coredumping on i686: [fila@gatonegro erlang (master)]$ mock -r fedora-rawhide-i386 --no-clean --shell INFO: mock.py version 1.2.14 starting (python version = 3.4.2)... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Start: chroot init INFO: calling preinit hooks INFO: enabled root cache INFO: enabled dnf cache Start: cleaning dnf metadata Finish: cleaning dnf metadata INFO: enabled ccache Finish: chroot init Start: shell <mock-chroot>sh-4.3# rpm -q erlang erlang-18.2.2-1.fc24.i686 <mock-chroot>sh-4.3# erl Erlang/OTP 18 [erts-7.2.1] [source] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.2.1 (abort with ^G) 1> erlang:processes(). Segmentation fault (core dumped)
peter++! Fedora 24's Erlang support is going to be sweet.
(In reply to Filip Andres from comment #20) > Hi Peter, > the new version seems to be plagued by the same error as the old one -- > erlang:processes() coredumping on i686: > > [fila@gatonegro erlang (master)]$ mock -r fedora-rawhide-i386 --no-clean > --shell > INFO: mock.py version 1.2.14 starting (python version = 3.4.2)... > Start: init plugins > INFO: selinux enabled > Finish: init plugins > Start: run > Start: chroot init > INFO: calling preinit hooks > INFO: enabled root cache > INFO: enabled dnf cache > Start: cleaning dnf metadata > Finish: cleaning dnf metadata > INFO: enabled ccache > Finish: chroot init > Start: shell > <mock-chroot>sh-4.3# rpm -q erlang > erlang-18.2.2-1.fc24.i686 > <mock-chroot>sh-4.3# erl > Erlang/OTP 18 [erts-7.2.1] [source] [smp:4:4] [async-threads:10] [hipe] > [kernel-poll:false] > > Eshell V7.2.1 (abort with ^G) > 1> erlang:processes(). > Segmentation fault (core dumped) Wow! A working reproducer! See bug 1240487.
Hi, not sure what to look for in gdb, this is my session: [fila@gatonegro ~]$ mock -r fedora-rawhide-i386 --no-clean --shell INFO: mock.py version 1.2.14 starting (python version = 3.4.2)... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run INFO: Installed packages: Start: shell sh-4.3# export ROOTDIR=/usr/lib/erlang/; export BINDIR=/usr/lib/erlang/erts-7.2.1/bin/; export EMU=beam; export PROGNAME=erl sh-4.3# gdb /usr/lib/erlang/erts-7.2.1/bin/erlexec GNU gdb (GDB) Fedora 7.10.50.20160106-42.fc24 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/erlang/erts-7.2.1/bin/erlexec...Reading symbols from /usr/lib/debug/usr/lib/erlang/erts-7.2.1/bin/erlexec.debug...done. done. (gdb) r Starting program: /usr/lib/erlang/erts-7.2.1/bin/erlexec process 18058 is executing new program: /usr/lib/erlang/erts-7.2.1/bin/beam.smp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". [New Thread 0xf6cbfb40 (LWP 18062)] [New Thread 0xf5e7fb40 (LWP 18063)] [New Thread 0xf62beb40 (LWP 18064)] [New Thread 0xf62adb40 (LWP 18065)] [New Thread 0xf629cb40 (LWP 18066)] [New Thread 0xf567eb40 (LWP 18067)] [New Thread 0xf566db40 (LWP 18068)] [New Thread 0xf565cb40 (LWP 18069)] [New Thread 0xf564bb40 (LWP 18070)] [New Thread 0xf563ab40 (LWP 18071)] [New Thread 0xf5629b40 (LWP 18072)] [New Thread 0xf5618b40 (LWP 18073)] [New Thread 0xf7fd2b40 (LWP 18074)] [New Thread 0xf5607b40 (LWP 18075)] [New Thread 0xf4e06b40 (LWP 18076)] [New Thread 0xf4605b40 (LWP 18077)] [New Thread 0xf3e04b40 (LWP 18078)] [New Thread 0xf34ffb40 (LWP 18079)] Detaching after vfork from child process 18080. Erlang/OTP 18 [erts-7.2.1] [source] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.2.1 (abort with ^G) 1> erlang:processes(). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf4605b40 (LWP 18077)] 0x56798dae in ethr_dw_atomic_cmpxchg () at ../include/internal/i386/atomic.h:177 177 return var->counter; (gdb) bt #0 0x56798dae in ethr_dw_atomic_cmpxchg () at ../include/internal/i386/atomic.h:177 #1 0x568688f0 in erts_proc () (gdb)
Created attachment 1116279 [details] Strace output of i686 mock run with crash Strace output doesn't seem very helpful as the VM crashes in userspace.
A better 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 <erts_proc+48>) at beam/erl_threads.h:1456 #2 erts_atomic64_inc_read_nob (var=0x568688f0 <erts_proc+48>) at beam/erl_threads.h:1646 #3 step_interval_nob (icp=0x568688f0 <erts_proc+48>) at beam/utils.c:4954 #4 erts_smp_step_interval_nob (icp=icp@entry=0x568688f0 <erts_proc+48>) at beam/utils.c:5004 #5 0x5671572b in ptab_list_bif_engine (c_p=c_p@entry=0xf6dc0218, res_accp=res_accp@entry=0xf4e06178, mbp=mbp@entry=0xf1f80a88) at beam/erl_ptab.c:927 #6 0x56716a5d in erts_ptab_list (c_p=c_p@entry=0xf6dc0218, ptab=0x568688c0 <erts_proc>) 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
I can reproduce this as well following comment 23. Something is going horribly wrong and destroying the stack. (gdb) t a a bt Thread 19 (Thread 0xf3614b40 (LWP 24996)): #0 0xf7fd6ba0 in ?? () Thread 18 (Thread 0xf3e15b40 (LWP 24995)): #0 0xf7fd6ba0 in ?? () Thread 17 (Thread 0xf4616b40 (LWP 24994)): #0 0xf7fd6ba0 in ?? () Thread 16 (Thread 0xf4e17b40 (LWP 24993)): #0 0x56798dae in ethr_dw_atomic_cmpxchg () at ../include/internal/i386/atomic.h:177 #1 0x568688f0 in erts_proc () Thread 15 (Thread 0xf5618b40 (LWP 24992)): #0 0xf7fd6ba0 in ?? () Thread 14 (Thread 0xf628bb40 (LWP 24991)): #0 0xf7fd6ba0 in ?? () Backtrace stopped: Cannot access memory at address 0x7 Thread 13 (Thread 0xf5629b40 (LWP 24990)): #0 0xf7fd6ba0 in ?? () Thread 12 (Thread 0xf563ab40 (LWP 24989)): #0 0xf7fd6ba0 in ?? () Thread 11 (Thread 0xf564bb40 (LWP 24988)): #0 0xf7fd6ba0 in ?? () Thread 10 (Thread 0xf565cb40 (LWP 24987)): #0 0xf7fd6ba0 in ?? () Thread 9 (Thread 0xf566db40 (LWP 24986)): #0 0xf7fd6ba0 in ?? () Thread 8 (Thread 0xf567eb40 (LWP 24985)): #0 0xf7fd6ba0 in ?? () Thread 7 (Thread 0xf629cb40 (LWP 24984)): #0 0xf7fd6ba0 in ?? () Thread 6 (Thread 0xf62adb40 (LWP 24983)): #0 0xf7fd6ba0 in ?? () Thread 5 (Thread 0xf62beb40 (LWP 24982)): #0 0xf7fd6ba0 in ?? () Thread 4 (Thread 0xf6d13b40 (LWP 24981)): #0 0xf7fd6ba0 in ?? () Thread 3 (Thread 0xf5e7fb40 (LWP 24980)): #0 0xf7fd6ba0 in ?? () Backtrace stopped: Cannot access memory at address 0x7 Thread 2 (Thread 0xf6cbfb40 (LWP 24979)): #0 0xf7fd6ba0 in ?? () #1 0xc0000000 in ?? () #2 0xaef6cc00 in ?? () #3 0xc556797e in ?? () #4 0x88567a24 in ?? () #5 0x00f6cc00 in ?? () #6 0x00000000 in ?? () Thread 1 (Thread 0xf7d31700 (LWP 24975)): #0 0xf7fd6ba0 in ?? () #1 0xf7db19b9 in strstr () from /lib/libc.so.6 #2 0x00000000 in ?? () The current thread is 16: (gdb) bt #0 0x56798dae in ethr_dw_atomic_cmpxchg () at ../include/internal/i386/atomic.h:177 #1 0x568688f0 in erts_proc () Note that erts_proc isn't even a function, it's a variable, and ebp points somewhere in the middle of it: (gdb) p &erts_proc $5 = (ErtsPTab *) 0x568688c0 <erts_proc> (gdb) p sizeof erts_proc $6 = 320 (gdb) i r ebp ebp 0x568688f0 0x568688f0 <erts_proc+48>
My current hypotheses: * It's either a build problem or an upstream problem. * A build problem sounds a bit more probable to me as I would expect somebody else to hit the problem ahead of us. * If it's an upstream problem then I found the following: As per ethr_atomics.c in the OTP source code there are two implementations of some functions -- one for architectures with native support, the other for architecture without it: /* * This file maps native atomic implementations to ethread * API atomics. If no native atomic implementation * is available, a less efficient fallback is used instead. * The API consists of 32-bit size, word size (pointer size), * and double word size atomics. ... Given the fact that packages built on my newish i7 processor work for me and packages built in koji don't, hypothesis is that there may be something fishy in the fallback branch of the code. I've noticed that the build servers used by Koji use Atom processors (or at least the compiler for i686 builds is run with the -mtune=atom switch). Is it possible that the the processors lacks double word atomics, thus the fallback branch is run and there is an error there? Is it possible to force a i686 build on a standard Intel processor not an Atom one?
I have built new packages using the following flags in the RPM spec: %ifarch %{ix86} %global optflags -mtune=generic %endif Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=12621253 Now the erlang:processes() command executes successfully: $ mock -r fedora-rawhide-i386 --no-clean --shell INFO: mock.py version 1.2.14 starting (python version = 3.4.2)... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Start: chroot init INFO: calling preinit hooks INFO: enabled root cache INFO: enabled dnf cache Start: cleaning dnf metadata Finish: cleaning dnf metadata INFO: enabled ccache Finish: chroot init Start: shell <mock-chroot>sh-4.3# erl Erlang/OTP 18 [erts-7.2.1] [source] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.2.1 (abort with ^G) 1> erlang:processes(). [<0.0.0>,<0.3.0>,<0.6.0>,<0.7.0>,<0.9.0>,<0.10.0>,<0.11.0>, <0.12.0>,<0.14.0>,<0.15.0>,<0.16.0>,<0.17.0>,<0.18.0>, <0.20.0>,<0.21.0>,<0.22.0>,<0.23.0>,<0.24.0>,<0.25.0>, <0.26.0>,<0.27.0>,<0.28.0>,<0.29.0>,<0.30.0>,<0.34.0>] 2> Resume: There seem to be an error in the fallback implementation of ethr_dw_atomic_cmpxchg. I'm not sure whether these binaries would run on an Atom processor though (and I don't have means to test it). I guess I may ask in the erlang-bugs mailing list but I would let it to you to decide if building for generic processor (instead of Atom) is a viable workaround or not.
(In reply to Filip Andres from comment #28) > I have built new packages using the following flags in the RPM spec: > > %ifarch %{ix86} > %global optflags -mtune=generic > %endif > > Build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=12621253 > > Now the erlang:processes() command executes successfully: > > $ mock -r fedora-rawhide-i386 --no-clean --shell > INFO: mock.py version 1.2.14 starting (python version = 3.4.2)... > Start: init plugins > INFO: selinux enabled > Finish: init plugins > Start: run > Start: chroot init > INFO: calling preinit hooks > INFO: enabled root cache > INFO: enabled dnf cache > Start: cleaning dnf metadata > Finish: cleaning dnf metadata > INFO: enabled ccache > Finish: chroot init > Start: shell > <mock-chroot>sh-4.3# erl > Erlang/OTP 18 [erts-7.2.1] [source] [smp:4:4] [async-threads:10] [hipe] > [kernel-poll:false] > > Eshell V7.2.1 (abort with ^G) > 1> erlang:processes(). > [<0.0.0>,<0.3.0>,<0.6.0>,<0.7.0>,<0.9.0>,<0.10.0>,<0.11.0>, > <0.12.0>,<0.14.0>,<0.15.0>,<0.16.0>,<0.17.0>,<0.18.0>, > <0.20.0>,<0.21.0>,<0.22.0>,<0.23.0>,<0.24.0>,<0.25.0>, > <0.26.0>,<0.27.0>,<0.28.0>,<0.29.0>,<0.30.0>,<0.34.0>] > 2> > > Resume: > There seem to be an error in the fallback implementation of > ethr_dw_atomic_cmpxchg. I'm not sure whether these binaries would run on an > Atom processor though (and I don't have means to test it). > I guess I may ask in the erlang-bugs mailing list but I would let it to you > to decide if building for generic processor (instead of Atom) is a viable > workaround or not. I've just rebuilt Erlang with -mtune=generic on ix86. However it didn't change anything on my machine. Could you please test if it works for you or not? I'm talking about 18.2.2-3 version.