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:
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):
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
gcc-ar crashes with core dump and next make command fails with error:
undefined reference to `toku_do_assert_fail`
compiles the same as on F20
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`
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.
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).
Created attachment 952539 [details]
tarball containing problematic o files
I've added tarball containing problematic o files.
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 ?
(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 ?
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
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:
(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
it seems to be ok with binutils-2.24-29.fc21.
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:
Thank you. binutils-18.104.22.168.1-26.fc20 solved our problems.
I think I just filed the same bug:
"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
(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.
Author: Nick Clifton <email@example.com>
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.
Author: H.J. Lu <firstname.lastname@example.org>
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
@@ -1,3 +1,8 @@
+2012-06-04 H.J. Lu <email@example.com>
+ * plugin.c (add_symbols): Set tdata.plugin_data before calling
diff --git a/bfd/plugin.c b/bfd/plugin.c
index ef356f1..1e6d82b 100644
@@ -275,12 +275,13 @@ add_symbols (void * handle,
plugin_data->nsyms = nsyms;
plugin_data->syms = syms;
+ abfd->tdata.plugin_data = plugin_data;
if ((nsyms + plugin_data->object_only_nsyms) != 0)
abfd->flags |= HAS_SYMS;
- abfd->tdata.plugin_data = plugin_data;
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:
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.
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
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.
> 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:
and let me know if you still have problems with it.
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'
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
Thank you for reporting this bug and we are sorry it could not be fixed.
# rpm -q binutils
# rpm -q gcc
# gcc-ar cr libtokuportability_static_conv.a ar/*.o