Issue #12666 has been updated by jaruga (Jun Aruga).


Let me explain more context about this backport requests.

Here is current `test/fiddle/helper.rb` file on ruby/ruby ruby_2_6 branch.

https://github.com/ruby/ruby/blob/02c341c9bc5879eae568ed2ba02cf227ed948199/test/fiddle/helper.rb#L23-L24

https://github.com/ruby/ruby/blob/02c341c9bc5879eae568ed2ba02cf227ed948199/test/fiddle/helper.rb#L102-L103

We have been using the file's 2nd logic to parse the libc_so, libm_so file paths from the output of `ldd /path/to/ruby` in RHEL 8 Ruby RPM (downstream) packages. However recently we found a ppc64le Power 9 build environment has the following ldd result.

The actually file paths are `/lib64/glibc-hwcaps/power9/libc-2.28.so` and `/lib64/glibc-hwcaps/power9/libm-2.28.so`. The logic by the regular expression failed to parse the paths. The paths are intentional, and due to [an optimized version of the libraries](https://sourceware.org/pipermail/libc-alpha/2020-May/113757.html).

```
$ uname -m
ppc64le

$ lscpu | grep -i model
Model:               2.2 (pvr 004e 1202)
Model name:          POWER9, altivec supported

$ ldd /usr/bin/ruby
	linux-vdso64.so.1 (0x00007fff8c650000)
	libruby.so.2.6 => /lib64/libruby.so.2.6 (0x00007fff8c220000)
	libpthread.so.0 => /lib64/glibc-hwcaps/power9/libpthread-2.28.so (0x00007fff8c1d0000)
	librt.so.1 => /lib64/glibc-hwcaps/power9/librt-2.28.so (0x00007fff8c1a0000)
	libgmp.so.10 => /lib64/libgmp.so.10 (0x00007fff8c0f0000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fff8c0c0000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fff8c070000)
	libm.so.6 => /lib64/glibc-hwcaps/power9/libm-2.28.so (0x00007fff8bf40000)
	libc.so.6 => /lib64/glibc-hwcaps/power9/libc-2.28.so (0x00007fff8bd20000)
	/lib64/ld64.so.2 (0x00007fff8c670000)
```

And I confirmed [the latest change](https://github.com/ruby/fiddle/pull/70) on the master branch works on this environment. While we apply the patch to our downstream Rubies, I would just like to see the patch is applied to Rubies.



----------------------------------------
Bug #12666: Fatal error: glibc detected an invalid stdio handle
https://bugs.ruby-lang.org/issues/12666#change-95832

* Author: vo.x (Vit Ondruch)
* Status: Closed
* Priority: Normal
* Assignee: tenderlovemaking (Aaron Patterson)
* ruby -v: ruby 2.3.1p112 (2016-04-26 revision 54768) [powerpc64-linux]
* Backport: 2.6: REQUIRED, 2.7: REQUIRED, 3.0: REQUIRED
----------------------------------------
During build of Ruby for Fedora on PPC64, there is reported following error:

```
Fiddle::TestImport#test_io = Fatal error: glibc detected an invalid stdio handle
uncommon.mk:612: recipe for target 'yes-test-almost' failed
make: *** [yes-test-almost] Aborted (core dumped)
```

and this is the analysis of one of glibc maintainers:

```
libio vtable verification fails because there are two copies of libc.so.6 in the process:

	0x00003fffb79413a8 - 0x00003fffb7941f78 is __libc_IO_vtables in /lib64/power8/libc.so.6
	0x00003fffb74213c0 - 0x00003fffb7421f90 is __libc_IO_vtables in /lib64/libc.so.6

IO.pipe refers to a vtable from a the first copy, but the fprintf called via libffi comes from the second copy.

The root cause is the Fiddle module loading libc.so.6 with an absolute path:

#0  __dlopen (file=0x20728280 "/lib64/libc.so.6", mode=257) at dlopen.c:75
#1  0x00003fffb748782c in rb_fiddle_handle_initialize (argc=<optimized out>, argv=<optimized out>, self=544821280) at handle.c:179

This comes from test/fiddle/helper.rb:

when /x86_64-linux/
  libc_so = "/lib64/libc.so.6"
  libm_so = "/lib64/libm.so.6"
when /linux/
  libdir = '/lib'
  case [0].pack('L!').size
  when 4
    # 32-bit ruby
    libdir = '/lib32' if File.directory? '/lib32'
  when 8
    # 64-bit ruby
    libdir = '/lib64' if File.directory? '/lib64'
  end
  libc_so = File.join(libdir, "libc.so.6")
  libm_so = File.join(libdir, "libm.so.6")

So the good news is that it's just a path.  I expect the fix looks like this:

when /linux/
  libc_so = "libc.so.6"
  libm_so = "libm.so.6"

(This replaces tehe x86_64-linux branch, too.)
```

Please also note that:

```
libio vtable verification is a new security hardening feature in Fedora 25.
```

To workaround this error, I am going to apply following patch to Fedora:

```
From 346e147ba6480839b87046e9a9efab0bf6ed3660 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?V=C3=ADt=20Ondruch?= <vondruch / redhat.com>
Date: Wed, 10 Aug 2016 17:35:48 +0200
Subject: [PATCH] Rely on ldd to detect glibc.

This is just workaround, since we know we are quite sure this will be successful
on Red Hat platforms.

This workaround rhbz#1361037
---
 test/fiddle/helper.rb | 92 ---------------------------------------------------
 1 file changed, 92 deletions(-)

diff --git a/test/fiddle/helper.rb b/test/fiddle/helper.rb
index 1da3d93..65148a1 100644
--- a/test/fiddle/helper.rb
+++ b/test/fiddle/helper.rb
@@ -6,98 +6,6 @@
 
 libc_so = libm_so = nil
 
-case RUBY_PLATFORM
-when /cygwin/
-  libc_so = "cygwin1.dll"
-  libm_so = "cygwin1.dll"
-when /x86_64-linux/
-  libc_so = "/lib64/libc.so.6"
-  libm_so = "/lib64/libm.so.6"
-when /linux/
-  libdir = '/lib'
-  case [0].pack('L!').size
-  when 4
-    # 32-bit ruby
-    libdir = '/lib32' if File.directory? '/lib32'
-  when 8
-    # 64-bit ruby
-    libdir = '/lib64' if File.directory? '/lib64'
-  end
-  libc_so = File.join(libdir, "libc.so.6")
-  libm_so = File.join(libdir, "libm.so.6")
-when /mingw/, /mswin/
-  require "rbconfig"
-  crtname = RbConfig::CONFIG["RUBY_SO_NAME"][/msvc\w+/] || 'ucrtbase'
-  libc_so = libm_so = "#{crtname}.dll"
-when /darwin/
-  libc_so = "/usr/lib/libc.dylib"
-  libm_so = "/usr/lib/libm.dylib"
-when /kfreebsd/
-  libc_so = "/lib/libc.so.0.1"
-  libm_so = "/lib/libm.so.1"
-when /gnu/	#GNU/Hurd
-  libc_so = "/lib/libc.so.0.3"
-  libm_so = "/lib/libm.so.6"
-when /mirbsd/
-  libc_so = "/usr/lib/libc.so.41.10"
-  libm_so = "/usr/lib/libm.so.7.0"
-when /freebsd/
-  libc_so = "/lib/libc.so.7"
-  libm_so = "/lib/libm.so.5"
-when /bsd|dragonfly/
-  libc_so = "/usr/lib/libc.so"
-  libm_so = "/usr/lib/libm.so"
-when /solaris/
-  libdir = '/lib'
-  case [0].pack('L!').size
-  when 4
-    # 32-bit ruby
-    libdir = '/lib' if File.directory? '/lib'
-  when 8
-    # 64-bit ruby
-    libdir = '/lib/64' if File.directory? '/lib/64'
-  end
-  libc_so = File.join(libdir, "libc.so")
-  libm_so = File.join(libdir, "libm.so")
-when /aix/
-  pwd=Dir.pwd
-  libc_so = libm_so = "#{pwd}/libaixdltest.so"
-  unless File.exist? libc_so
-    cobjs=%w!strcpy.o!
-    mobjs=%w!floats.o sin.o!
-    funcs=%w!sin sinf strcpy strncpy!
-    expfile='dltest.exp'
-    require 'tmpdir'
-    Dir.mktmpdir do |dir|
-      begin
-        Dir.chdir dir
-        %x!/usr/bin/ar x /usr/lib/libc.a #{cobjs.join(' ')}!
-        %x!/usr/bin/ar x /usr/lib/libm.a #{mobjs.join(' ')}!
-        %x!echo "#{funcs.join("\n")}\n" > #{expfile}!
-        require 'rbconfig'
-        if RbConfig::CONFIG["GCC"] = 'yes'
-          lflag='-Wl,'
-        else
-          lflag=''
-        end
-        flags="#{lflag}-bE:#{expfile} #{lflag}-bnoentry -lm"
-        %x!#{RbConfig::CONFIG["LDSHARED"]} -o #{libc_so} #{(cobjs+mobjs).join(' ')} #{flags}!
-      ensure
-        Dir.chdir pwd
-      end
-    end
-  end
-else
-  libc_so = ARGV[0] if ARGV[0] && ARGV[0][0] == ?/
-  libm_so = ARGV[1] if ARGV[1] && ARGV[1][0] == ?/
-  if( !(libc_so && libm_so) )
-    $stderr.puts("libc and libm not found: #{$0} <libc> <libm>")
-  end
-end
-
-libc_so = nil if !libc_so || (libc_so[0] == ?/ && !File.file?(libc_so))
-libm_so = nil if !libm_so || (libm_so[0] == ?/ && !File.file?(libm_so))
-
 if !libc_so || !libm_so
   ruby = EnvUtil.rubybin
   ldd = `ldd #{ruby}`
-- 
2.9.2
```

i.e. I am going to disable the custom code for detecting glibc on various platfors and rely just on ldd. My question is what should be the proper fix? Shouldn't be the ldd way the default behavior for Linux?

This issue was originally reported at:

https://bugzilla.redhat.com/show_bug.cgi?id=1361037




---Files--------------------------------
fiddle-path.diff (1.37 KB)
0001-Do-not-use-full-path-to-load-glibc.patch (947 Bytes)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>