Created attachment 944219 [details] core dump of ar Description of problem: When I try to build mariadb with tokudb support on F21, we get error: /bin/gcc-ar cr libtokuportability_static_conv.a CMakeFiles/tokuportability_static_conv.dir/huge_page_detection.cc.o CMakeFiles/tokuportability_static_conv.dir/file.cc.o CMakeFiles/tokuportability_static_conv.dir/memory.cc.o CMakeFiles/tokuportability_static_conv.dir/os_malloc.cc.o CMakeFiles/tokuportability_static_conv.dir/portability.cc.o CMakeFiles/tokuportability_static_conv.dir/toku_assert.cc.o CMakeFiles/tokuportability_static_conv.dir/toku_crash.cc.o CMakeFiles/tokuportability_static_conv.dir/toku_path.cc.o CMakeFiles/tokuportability_static_conv.dir/toku_pthread.cc.o CMakeFiles/tokuportability_static_conv.dir/toku_time.cc.o /bin/ar terminated with signal 11 [Segmentation fault], core dumped with gcc-4.9.1 in F21. When I run make the second time, I get undefined reference to `toku_do_assert_fail` error, but that's probably because of crash of gcc-ar previously. When trying to build the same source in F20 with gcc-4.8.3, there is no such issue. Upstream report on mariadb is here: https://mariadb.atlassian.net/browse/MDEV-6449 They claim it compiles correctly with gcc-4.9.1 on Debian, so it seems to be problem in Fedora gcc-4.9.1. Version-Release number of selected component (if applicable): gcc-4.9.1-11.fc21 How reproducible: every-time Steps to Reproduce: 1. use SRPM from https://hhorak.fedorapeople.org/mariadb-10.0.14-4.fc21.src.rpm which has tokudb plugin enabled and changed SVID_SOURCE to _DEFAULT_SOURCE in the spec file (otherwise is same as what is in F21 koji right now) 2. build the attached SRPM Actual results: gcc-ar crashes with core dump and next make command fails with error: undefined reference to `toku_do_assert_fail` Expected results: compiles the same as on F20 Additional info: See attached core dump or generate own by rebuilding the srpm above.
The crash is in ar (therefore binutils).
(In reply to Jakub Jelinek from comment #1) > The crash is in ar (therefore binutils). Really? I don't think so. AFAIK, gcc ships (and mariadb uses) own versions of ar called gcc-ar: # rpm -qf `which gcc-ar` gcc-4.9.1-11.fc21.x86_64 Or do I understand it wrong?
/bin/ar terminated with signal 11 [Segmentation fault], core dumped ^^^^^^^ gcc-ar is just a wrapper program that executes ar.
(In reply to Jakub Jelinek from comment #3) > gcc-ar is just a wrapper program that executes ar. Ah, sorry, anyone have one pair of spare glasses? :) I'll probably need some.
Hi Honza, Please could you upload a tarball of those .o files so that I can try to reproduce the ar failure locally ? (I have been trying to build the rpm but having all kinds of problems doing so). Cheers Nick
Created attachment 952539 [details] tarball containing problematic o files I've added tarball containing problematic o files.
Hi Matej, Thanks for the tarball. Unfortunately I cannot reproduce the problem. That is when I run the ar command shown in the description of the problem, the library is created and there is no seg-fault. Which version of the binutils rpm are you using ? I was using binutils-2.24-28.fc21.x86_64.rpm. If you have not tried that version, please could you give it a go and see if the problem has been fixed ? Cheers Nick
(In reply to Nick Clifton from comment #7) > Hi Matej, > > Thanks for the tarball. Unfortunately I cannot reproduce the problem. > That is when I run the ar command shown in the description of the problem, > the library is created and there is no seg-fault. > > Which version of the binutils rpm are you using ? I was using > binutils-2.24-28.fc21.x86_64.rpm. If you have not tried that version, > please could you give it a go and see if the problem has been fixed ? > > Cheers > Nick Hi Nick, I've tried it with binutils-2.24-21.fc21.x86_64 and with binutils-2.24-28.fc21.x86_64. In both cases ar ended with sigsegv. When I run ar with --plugin option (like gcc-ar does) it crashes with sigsegv: (ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/liblto_plugin.so -cr out.a some-o-file.o) however when I run it without --plugin option it ends successfully: (ar -cr out.a some-o-file.o) Version of gcc is also important: gcc-4.9.2-1.fc21.x86_64
Hi Matej, The plugin was the thing that I was missing. Once I enabled that I could reproduce the bug. Please try out this binutils rpm, which should fix the problem: binutils-2.24-29.fc21 Cheers Nick
(In reply to Nick Clifton from comment #9) > Hi Matej, > > The plugin was the thing that I was missing. Once I enabled that I could > reproduce the bug. Please try out this binutils rpm, which should fix the > problem: > > binutils-2.24-29.fc21 > > Cheers > Nick Hi Nick, it seems to be ok with binutils-2.24-29.fc21. Cheers Matej
I think we have the same problems with binutils. But where can i find binutils-2.24-29.fc21? I find only a fc22 version. Will fc20 also be fixed?
(In reply to habicht from comment #11) > But where can i find binutils-2.24-29.fc21? I find only a fc22 version. FC21 is currently frozen. But once the freeze is off the rpm should be available. > Will fc20 also be fixed? Yes. I was waiting for confirmation that the patch works. I have now taken the patch and added it to the FC20 rpm. You should be able to find it in: binutils-2.23.88.0.1-26.fc20 Cheers Nick
Thank you. binutils-2.23.88.0.1-26.fc20 solved our problems.
I think I just filed the same bug: https://bugzilla.redhat.com/show_bug.cgi?id=1174065 "Bug 1174065 - ar with lto plugin segfaults while creating archive"
I upgraded to binutils-2.24-29.fc21 and now 64-bit bit build works, but creating archive from 32-bit object still crashes. The *.o are in a tgz in https://bugzilla.redhat.com/attachment.cgi?id=969589 (attached to https://bugzilla.redhat.com/show_bug.cgi?id=1174065) I just did "gcc-ar cr libtre.a *.o" manually and it still crashes with a core dump.
I can't find any reference/discussion on it, but apparently the crush happens in a fedora-specific patch that is quite large and been carried for some years. binutils-2.23.2-kernel-ld-r.patch commit d43b72113c5879ddde546867dfe23baaccf35c1f Author: Nick Clifton <nickc> Date: Fri May 17 08:42:58 2013 +0100 Import H.J.'s patch to add support for kernel ld -r modules.
Okay, I found that the segfault fix in binutils-2.24-29.fc21 is in fact known upstream since two years ago... the fix just bring bfd/plugin.c up to become identical with git://git.kernel.org/pub/scm/linux/kernel/git/hjl/binutils.git hjl/lto/master+error:bfd/plugin.c , This still leaves my 32-bit archive segfault on 64-bit host problem unsolved. commit d7f8c5c183adcaa3c313150486e15ea703a65576 Author: H.J. Lu <hjl.tools> Date: Mon Jun 4 06:44:34 2012 -0700 Set tdata.plugin_data first diff --git a/bfd/ChangeLog.lto-mixed b/bfd/ChangeLog.lto-mixed index 013ea23..f6d53a8 100644 --- a/bfd/ChangeLog.lto-mixed +++ b/bfd/ChangeLog.lto-mixed @@ -1,3 +1,8 @@ +2012-06-04 H.J. Lu <hongjiu.lu> + + * plugin.c (add_symbols): Set tdata.plugin_data before calling + bfd_plugin_get_symbols_in_object_only. + diff --git a/bfd/plugin.c b/bfd/plugin.c index ef356f1..1e6d82b 100644 --- a/bfd/plugin.c +++ b/bfd/plugin.c @@ -275,12 +275,13 @@ add_symbols (void * handle, plugin_data->nsyms = nsyms; plugin_data->syms = syms; + abfd->tdata.plugin_data = plugin_data; + bfd_plugin_get_symbols_in_object_only (abfd); if ((nsyms + plugin_data->object_only_nsyms) != 0) abfd->flags |= HAS_SYMS; - abfd->tdata.plugin_data = plugin_data; return LDPS_OK; }
Armed with the simplier command line with nm against a single 32-bit object (https://bugzilla.redhat.com/show_bug.cgi?id=1174065#c6) which works 64-bit object compiled with fto but segfault on 32-bit objects, I used gdb to single step through nm around those routines (https://bugzilla.redhat.com/show_bug.cgi?id=1174065#c4) against both the 64-bit object and 32-bit objects, and try to see where the logic diverges, and looking at the source code. In the end, I found the section of code where they diverge, which is at bfd/format.c between from line 337 - 382. So I was staring at the comment: /* If this is the default target, accept it, even if other targets might match. People who want those other targets have to set the GNUTARGET variable. */ which indeed gives me the answer I needed. gcc-nm/gcc-ar needs to have GNUTARGET=elf32-i386 set in the environment (or have "--target elf32-i386" specified) when building 32-bit archives on 64-bit platform, otherwise it would segfault. Still I would rather it would do that automatically, but at least this is a workaround... I 'll change the summary in my bug (https://bugzilla.redhat.com/show_bug.cgi?id=1174065) accordingly.
MariaDB is still failing with these builds (with tokudb enabled) in F21/F22: binutils-2.24-21.fc21.x86_64 binutils-2.25-2.fc22.x86_64 But it buidls fine with binutils-2.24-30.fc21, which is unfortunately still not in updates. So, please, could you submit a bodhi update for binutils-2.24-30.fc21 and apply the fix also in rawhide?
binutils-2.24-30.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/binutils-2.24-30.fc21
binutils-2.24-30.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 986581 [details] tarball containing problematic o files and core dump of ar Hi, there are still problems with ar. mariadb fails to build with binutils-2.25-4.fc22, however with binutils-2.24-30.fc21 it works ok. During the build (with binutils-2.25-4.fc22) ar receives SIGSEGV. In attachment you can find problematic o-files, core dump of ar and the COMMAND ar was started with. ar was started with plugin (/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/liblto_plugin.so) so version of gcc (4.9.2-5.fc22) is important too.
Hi Matej, > tarball containing problematic o files and core dump of ar Thanks very much - that tarball helped me find and fix the problem. Please try out: binutils-2.25-5.fc22 and let me know if you still have problems with it. Cheers Nick
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
# rpm -q binutils binutils-2.26.1-1.fc25.x86_64 # rpm -q gcc gcc-6.3.1-1.fc25.x86_64 # gcc-ar cr libtokuportability_static_conv.a ar/*.o works.