"require" behaves differently on ppc64el during certain conditions

[Sergio Durigan Junior]

I have verified that under specific circumstances, 'require' can behave differently between ppc64el and other architectures.

Simple reproducer:

$ cat > foo.rb << __EOF__
begin
  require 'bar'
rescue LoadError
  puts "Caught first LoadError. Continuing..."
end

puts require 'bar'
__EOF__
$ cat > bar.rb << __EOF__
require 'baz'
__EOF__
$ ruby3.0 -I . foo.rb

On ppc64el, you will see:

Caught first LoadError. Continuing...
false

On non-ppc64el, you will see:

Caught first LoadError. Continuing...
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:86:in `require': cannot load such file -- baz (LoadError)
Did you mean? bar
        from <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:86:in `require'
        from /home/ubuntu/bar.rb:1:in `<top (required)>'
        from <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:86:in `require'
        from <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:86:in `require'
        from foo.rb:7:in `<main>'

[Sergio Durigan Junior (sergiodj)]

I debugged this a little bit and found that the difference manifests on ruby3.0's load.c:require_internal, more specifically this part here:

1118 if (found) {
1119 if (!path || !(ftptr = load_lock(th->vm, RSTRING_PTR(path), warn))) {
1120 result = 0;
1121 }

On ppc64el, the call to "load_lock" fails for some reason. On non-ppc64el, the call succeeds and the function proceeds to successfully load "bar".

[Sergio Durigan Junior (sergiodj)]

This is impacting ruby-tilt, whose autopkgtest is failing on ppc64el right now. It's important to mention that Debian apparently isn't impacted by this, which probably means that the error might be happen somewhere else.

Note to self: glibc 2.34 doesn't ship with a separate libpthread anymore, and load_lock eventually calls uses rb_thread_shield_wait, which seems to make use of some pthread functions.