Description of problem: I am trying to build Ruby, but I constantly (ok it passes from time to time) observe one test failure: ~~~ 4) Error: test_str_crypt(TestM17NComb): Errno::EINVAL: Invalid argument - crypt /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/test_m17n_comb.rb:746:in `crypt' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/test_m17n_comb.rb:746:in `block in test_str_crypt' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:83:in `block in each' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:75:in `block in each_index' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:46:in `block in make_large_block' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:26:in `block (2 levels) in make_basic_block' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:21:in `times' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:21:in `block in make_basic_block' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:20:in `times' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:20:in `make_basic_block' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:45:in `make_large_block' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:71:in `each_index' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/allpairs.rb:82:in `each' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/test_m17n_comb.rb:60:in `combination' /builddir/build/BUILD/ruby-2.0.0-p648/test/ruby/test_m17n_comb.rb:738:in `test_str_crypt' ~~~ I was digging into and it seems to be due to glibc segfaulting when LD_PRELOAD is used: ~~~ $ LD_PRELOAD=/lib64/libruby.so.2.0.0 gdb /lib64/libc.so.6 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7 Copyright (C) 2013 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 "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/lib64/libc-2.17.so...Reading symbols from /usr/lib/debug/usr/lib64/libc-2.17.so.debug...done. done. (gdb) r Starting program: /lib64/libc.so.6 Program received signal SIGSEGV, Segmentation fault. strcmp () at ../sysdeps/x86_64/multiarch/strcmp.S:88 88 HAS_CPU_FEATURE (SSE4_2) (gdb) bt #0 strcmp () at ../sysdeps/x86_64/multiarch/strcmp.S:88 #1 0x00007ffff7de9288 in elf_machine_rela (reloc=0x7ffff799d0a8, reloc=0x7ffff799d0a8, skip_ifunc=<optimized out>, reloc_addr_arg=0x7ffff7db93f0, version=<optimized out>, sym=0x7ffff7983740, map=0x7ffff7ff7658) at ../sysdeps/x86_64/dl-machine.h:288 #2 elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=<optimized out>, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x7ffff7ff7658) at do-rel.h:137 #3 _dl_relocate_object (scope=<optimized out>, reloc_mode=<optimized out>, consider_profiling=<optimized out>, consider_profiling@entry=0) at dl-reloc.c:259 #4 0x00007ffff7de0792 in dl_main (phdr=<optimized out>, phdr@entry=0x555555554040, phnum=<optimized out>, phnum@entry=10, user_entry=user_entry@entry=0x7fffffffe588, auxv=<optimized out>) at rtld.c:2192 #5 0x00007ffff7df3e36 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7fffffffe640, dl_main=dl_main@entry=0x7ffff7dde820 <dl_main>) at ../elf/dl-sysdep.c:244 #6 0x00007ffff7de1a31 in _dl_start_final (arg=0x7fffffffe640) at rtld.c:318 #7 _dl_start (arg=0x7fffffffe640) at rtld.c:544 #8 0x00007ffff7dde1e8 in _start () from /lib64/ld-linux-x86-64.so.2 #9 0x0000000000000001 in ?? () #10 0x00007fffffffe862 in ?? () #11 0x0000000000000000 in ?? () ~~~ Version-Release number of selected component (if applicable): $ rpm -q glibc glibc-2.17-161.el7.x86_64 $ rpm -q glibc glibc-2.17-170.el7.x86_64 How reproducible: Steps to Reproduce: 1. Install ruby-libs 2. $ LD_PRELOAD=/lib64/libruby.so.2.0.0 /lib64/libc.so.6 Segmentation fault (core dumped) 3. Actual results: Segfault Expected results: Same as if the plain libc was executed, e.g.: ~~~ $ /lib64/libc.so.6 GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al. Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.8.5 20150623 (Red Hat 4.8.5-11). Compiled on a Linux 3.10.0 system on 2017-03-01. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. ~~~ Additional info: Please note that the LD_PRELOAD is the way how Ruby build setups the environment for the test suite execution.
I just tried it for the fun on my Fedora Rawhide and it fails the same way: $ rpm -q glibc glibc-2.24.90-29.fc26.x86_64 glibc-2.24.90-29.fc26.i686 $ rpm -q ruby-libs ruby-libs-2.4.0-77.fc26.x86_64
This is a known issue, also reported upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=20972#c4 I don't know why the Ruby build environment uses LD_PRELOAD instead of LD_LIBRARY_PATH to locate this library. libruby links against libpthread. Even if we fix the handling of the libc.so.6 special case in the dynamic linker, some programs will still fail because of indirect libpthread pre-loading, and the Ruby build system cannot know for certain that nothing it runs isn't in that category.
The think is that it used to work with glibc-2.17-106.el7_2.6.x86_64 while it does not work anymore. So from my point of view this is regression and should be fixed.
(In reply to Vít Ondruch from comment #4) > The think is that it used to work with glibc-2.17-106.el7_2.6.x86_64 while > it does not work anymore. So from my point of view this is regression and > should be fixed. The issue is unfortunately very difficult to address in a comprehensive manner. Changing the dependency sorting algorithm is hard (one bug in this area which has been stalled for long time is bug 1159809). A generic fix for IFUNC relocation issues (such as bug 1377895) is complicated, too.
(In reply to Florian Weimer from comment #6) > (In reply to Vít Ondruch from comment #4) > > The think is that it used to work with glibc-2.17-106.el7_2.6.x86_64 while > > it does not work anymore. So from my point of view this is regression and > > should be fixed. > > The issue is unfortunately very difficult to address in a comprehensive > manner. Changing the dependency sorting algorithm is hard (one bug in this > area which has been stalled for long time is bug 1159809). A generic fix > for IFUNC relocation issues (such as bug 1377895) is complicated, too. Ok, thx for explanation. It seems I should workaround the issues for the time being, otherwise I won't move forward. So feel free to close the issue.
Red Hat Enterprise Linux 7 is entering Maintenance Phase Support 1 this year and as such this issue will not be considered for fixing in RHEL 7 and is being closed. We still have bug bug 1159809 and bug 1377895 tracking the overall loader and IFUNC issues, but they are now being tracked for RHEL 8.
*** Bug 1887974 has been marked as a duplicate of this bug. ***