And extract all the gem versions into global version variables. This
allow to make the updste script a bit simpler by dropping multiple ways
of representing gem versions.
Tests fail with a LANG=C environment. A new investigation into the
failing tests on x86 revealed exact commits which introduced the issue
and the commits that fixed the situation. Fix is not yet present in Ruby
3.2, therefore the conditional disabling the tests was left in.
A new re-reported ticket replaced the old one. The new upstream ticket
includes better detailed description of the environment causing the
issue.
The tests pass in Rawhide mock (F40), as the LANG there is C.UTF-8
that does not suffer from the issue.
Upstream ticket: https://bugs.ruby-lang.org/issues/20045
libffi since NVR libffi-3.4.4-3.fc39 builds with static trampolines
enabled. This fixes the failures which were the reason for disabling
the tests.
Since it recently landed in Rawhide, we can re-enable the tests.
The rhbz#2043092 is not resolved. Nevertheless, the generation of
package notes should not break builds of rubygem- packages anymore.
Nevertheless, the additional linker options will keep making issues for
`gem install`ed gems. Nothing new here unfortunately.
Fiddle::Closure object is making use of FFI closure
from libffi. When such object is created (instantiated) in Ruby,
and then the process forks on an SELinux-enabled system, the memory
will become corrupted. That is usually not a problem until the
The garbage collector sweeps the object and tries to free it, in which case the
Ruby process will fail with signal SIGABRT.
Tests in test/fiddle/test_closure.rb, test/fiddle/test_func.rb,
and test/fiddle/test_function.rb use the `Fiddle::Closure` class
directly and fiddle/test_import.rb use the class indirectly through
`bind_function` method, therefore they are disabled to prevent
introducing the problematic object into the Ruby GC during test suite
execution instead of relying on that fork and subsequent
garbage collection will not happen.
If an FFI closure object is allocated in Ruby
and the `fork` function is used afterward, the memory
pointing to the closure gets corrupted, and if Ruby GC
tries to collect the object in that state, a SIGABRT
error occurs.
The minimal Ruby reproducer for the issue is the following:
~~~
$ cat fiddle_fork.rb
require 'fiddle/closure'
require 'fiddle/struct'
Fiddle::Closure.new(Fiddle::TYPE_VOID, [])
fork { }
GC.start
~~~
We allocate an unused Closure object,
so it is free for the GC to pick up. Before we call `GC.start`
we fork the process as that corrupts the memory.
Running this with ruby-3.1.2-167.fc37.x86_64 on SELinux enabled system:
~~~
$ ruby fiddle_fork.rb
Aborted (core dumped)
~~~
Such issues may appear at random (depending on the use of forking and GC)
in larger applications that use Fiddle::Closure but can be spotted by the
following functions appearing in the coredump backtrace:
~~~
0x00007f6284d3e5b3 in dlfree (mem=<optimized out>) at ../src/dlmalloc.c:4350
0x00007f6284d6d0b1 in dealloc () from /usr/lib64/ruby/fiddle.so
0x00007f6295e432ec in finalize_list () from /lib64/libruby.so.3.1
0x00007f6295e43420 in finalize_deferred.lto_priv () from /lib64/libruby.so.3.1
0x00007f6295e4ff1c in gc_start_internal.lto_priv () from /lib64/libruby.so.3.1
~~~
Possible solutions to prevent Ruby from crashing:
* Do not use Fiddle::Closure.
* Use the Fiddle::Closure object only in isolated subprocess that
will not fork further.
* Enable static trampolines in libffi as noted in bugzilla comment:
<https://bugzilla.redhat.com/show_bug.cgi?id=2040380#c9>
See related discussion on
<https://bugzilla.redhat.com/show_bug.cgi?id=2040380>
Ruby upstream ticket:
<https://bugs.ruby-lang.org/issues/18914>
Ruby Fiddle ticket:
<https://github.com/ruby/fiddle/issues/102>
