January 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:111264] [Ruby master Feature#19197] Add Exception#root_cause
by AMomchilov (Alexander Momchilov) 02 Jun '23

02 Jun '23

Issue #19197 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Feature #19197: Add Exception#root_cause https://bugs.ruby-lang.org/issues/19197 * Author: AMomchilov (Alexander Momchilov) * Status: Open * Priority: Normal ---------------------------------------- ## Description I would like to add a `#root_cause` method to `Exception`. It returns the last exception in linked-list of causality chain, that is, the original exception (whose own `cause` is `nil`). ## Example ```ruby e = begin raise 'a' # This is the root cause rescue => a begin raise 'b' rescue => b begin raise 'c' # This is the outermost cause assigned to `e` rescue => c c end end end p(e) # => #<RuntimeError: c> p(e.cause) # => #<RuntimeError: b> p(e.cause.cause) # => #<RuntimeError: a> p(e.cause.cause.cause) # => nil p(e.root_cause) # => #<RuntimeError: a> p(e.root_cause.cause) # => nil ``` # Motivation There are some kinds of exceptions that can occur all over the place (and might be wrapped by arbitrarily many middlemen), but are attributable to a singular global cause. For example, a database outage could raise exceptions in almost every line of business logic of an app that uses ActiveRecord models. Fundamentally, you wouldn't want an error report for every one of these lines. You'd want to look at the root cause, and bucket all SQL-connection issues into a single report, regardless of where they surface. ### Implementation Draft PR: https://github.com/ruby/ruby/pull/6913 -- https://bugs.ruby-lang.org/

4 7

[ruby-core:112072] [Ruby master Bug#19386] `test_hmac.rb` of openssl is timeout on RHEL9
by hsbt (Hiroshi SHIBATA) 21 May '23

21 May '23

Issue #19386 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19386: `test_hmac.rb` of openssl is timeout on RHEL9 https://bugs.ruby-lang.org/issues/19386 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I prepared new test instance of RHEL9 for https://rubyci.org/. But it stuck with openssl tests. see http://rubyci.s3.amazonaws.com/rhel9/ruby-master/log/20230127T003004Z.fail.… I did bisect this issue. This issue caused by https://github.com/ruby/ruby/blob/master/test/openssl/test_hmac.rb#L23 ``` def test_dup h1 = OpenSSL::HMAC.new("KEY", "MD5") h1.update("DATA") h = h1.dup assert_equal(h1.digest, h.digest, "dup digest") end ``` Stuck is happened after running this test. /cc @vo.x @jaruga @rhenium -- https://bugs.ruby-lang.org/

7 13

[ruby-core:111566] [Ruby master Bug#19294] Enumerator.product works incorrectly with consuming enumerators
by zverok (Victor Shepelev) 14 May '23

14 May '23

Issue #19294 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #19294: Enumerator.product works incorrectly with consuming enumerators https://bugs.ruby-lang.org/issues/19294 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby s = StringIO.new('abc') Enumerator.product([1, 2, 3], s.each_char).to_a # Expected: => [[1, "a"], [1, "b"], [1, "c"], [2, "a"], [2, "b"], [2, "c"], [3, "a"], [3, "b"], [3, "c"]] # Actual: => [[1, "a"], [1, "b"], [1, "c"]] ``` The implementation consumes the non-first enumerator to produce the first combination. Somewhat related to the dilemma of consuming and non-consuming enumerators (#19061). PS: I noticed I don't understand why it is `Enumerator.product` and not `Enumerable#product`, but probably it is too late to raise the questions :( -- https://bugs.ruby-lang.org/

3 2

[ruby-core:111136] [Ruby master Bug#19168] "such file" is bad grammar
by masterleep2 (Bill Lipa) 12 May '23

12 May '23

Issue #19168 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #19168: "such file" is bad grammar https://bugs.ruby-lang.org/issues/19168 * Author: masterleep2 (Bill Lipa) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The error message for a missing required file has bad grammar: $ irb irb(main):001:0> require 'wuxx' <internal:/opt/local/lib/ruby3.1/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- wuxx (LoadError) The "such" should be removed. "cannot load file" reads more normally in English. -- https://bugs.ruby-lang.org/

7 6

[ruby-core:111792] [Ruby master Bug#19334] Defining many instance variables and accessing them is slow in Ruby 3.2.0
by mame (Yusuke Endoh) 10 May '23

10 May '23

Issue #19334 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #19334: Defining many instance variables and accessing them is slow in Ruby 3.2.0 https://bugs.ruby-lang.org/issues/19334 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal * Assignee: tenderlovemaking (Aaron Patterson) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` class C eval("def initialize; #{ (0..100000).map { "@x#{ _1 } = 0; " }.join } end") attr_reader :x50000 end p :start C.new.x50000 ``` This script takes less than one second in Ruby 3.1.3, and does more than ten second in Ruby 3.2.0. ``` $ time ruby -v test.rb ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] :start real 0m0.210s user 0m0.167s sys 0m0.044s ``` ``` $ time ruby -v test.rb ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] :start real 0m11.026s user 0m10.950s sys 0m0.040s ``` This problem is not critical, but is there any room for improvement? -- https://bugs.ruby-lang.org/

6 11

[ruby-core:111309] [Ruby master Bug#19238] URI.open fails for file path when second argument is a hash
by dkinzer (David Kinzer) 09 May '23

09 May '23

Issue #19238 has been reported by dkinzer (David Kinzer). ---------------------------------------- Bug #19238: URI.open fails for file path when second argument is a hash https://bugs.ruby-lang.org/issues/19238 * Author: dkinzer (David Kinzer) * Status: Open * Priority: Normal * ruby -v: 3.0, 3.1 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I upgraded one of my projects to ruby 3.1.3 and I found that `URI.open` now throws an error when passed a second argument when the first argument is a file path. When the first argument is a URL, then URI.open will work as expected. I was able to replicate this issue in all 3.x versions including the latest so it's an issue that was introduce with the release of 3.0 I found it convenient that `URI.open(uri, {})`, worked regardless of wether uri was a file path or a URL because it meant I did not have to add logic for varying cases. When the uri argument was a file path URI.open would simply open up the file and disregard the hash options params. But now I have to add that logic myself which is not as clean looking. Below is an example of the error. It's quite easy to reproduce on any version of ruby 3.x ``` URI.open("spec/fixtures/blogs.json", {}) /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/open-uri.rb:31:in `initialize': no implicit conversion of Hash into String (TypeError) from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/open-uri.rb:31:in `open' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/open-uri.rb:31:in `open' from (irb):9:in `<main>' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>' from /Users/dkinzer/.rbenv/versions/3.1.3/bin/irb:25:in `load' from /Users/dkinzer/.rbenv/versions/3.1.3/bin/irb:25:in `<top (required)>' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli/exec.rb:58:in `load' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli/exec.rb:58:in `kernel_load' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli/exec.rb:23:in `run' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli.rb:486:in `exec' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli.rb:31:in `dispatch' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli.rb:25:in `start' ... 5 levels... ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:111990] [Ruby master Bug#19371] Having Psych 5 installed raises an error during another gem's C-extension installation when parsing YAML
by tombruijn (Tom de Bruijn) 14 Apr '23

14 Apr '23

Issue #19371 has been reported by tombruijn (Tom de Bruijn). ---------------------------------------- Bug #19371: Having Psych 5 installed raises an error during another gem's C-extension installation when parsing YAML https://bugs.ruby-lang.org/issues/19371 * Author: tombruijn (Tom de Bruijn) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [aarch64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Summary There's an issue on Ruby versions with Psych 4 installed by default (Ruby 2.6 through 3.1) after installing the Psych gem version 5. This problem occurs when a Ruby gem has a C-extension installation script that parses a YAML string. I'm reporting it here and not with on the Psych gem repo, because it looks more like an issue with which Ruby C-extension is load during other gem's C-extension installation. ## Background I have a gem that parses a YAML string in the C-extension installation script, or it calls `Gem.configuration[:http_proxy]`, which parses the `.gemrc` file as YAML. This triggers the error mentioned below. This YAML parsing is done in the gem's `ext/extconf.rb` file. An example gem can be found in this repository: https://github.com/tombruijn/yaml-dummy-gem, see the [`ext/extconf.rb` file](https://github.com/tombruijn/yaml-dummy-gem/blob/main/ext/extconf.rb#…. ## The problem On Ruby 3.1.3 Psych version 4 is installed by default. When it parses the YAML file, it will use Psych 4. When Psych 5 is also installed on Ruby 3.1.3, it is no longer be able to parse the YAML file. The following error is raised: ``` $ bundle install Fetching https://github.com/tombruijn/yaml-dummy-gem.git Resolving dependencies... Using bundler 2.3.7 Using yaml-dummy-gem 1.0.0 from https://github.com/tombruijn/yaml-dummy-gem.git (at main@a48852d) Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /usr/local/bundle/bundler/gems/yaml-dummy-gem-a48852dac33d/ext /usr/local/bin/ruby -I /usr/local/lib/ruby/3.1.0 -r ./siteconf20230123-730-rmbnnl.rb extconf.rb /usr/local/lib/ruby/3.1.0/psych.rb:459:in `parse_stream': undefined method `parse' for #<Psych::Parser:0x0000ffff8078c7f8 @handler=#<Psych::Handlers::DocumentStream:0x0000ffff8078c910 @stack=[], @last=nil, @root=nil, @start_line=nil, @start_column=nil, @end_line=nil, @end_column=nil, @block=#<Proc:0x0000ffff8078c848 /usr/local/lib/ruby/3.1.0/psych.rb:399>>, @external_encoding=0> (NoMethodError) parser.parse yaml, filename ^^^^^^ from /usr/local/lib/ruby/3.1.0/psych.rb:399:in `parse' from extconf.rb:3:in `<main>' extconf failed, exit code 1 Gem files will remain installed in /usr/local/bundle/bundler/gems/yaml-dummy-gem-a48852dac33d for inspection. Results logged to /usr/local/bundle/bundler/gems/extensions/aarch64-linux/3.1.0/yaml-dummy-gem-a48852dac33d/gem_make.out /usr/local/lib/ruby/3.1.0/rubygems/ext/builder.rb:95:in `run' /usr/local/lib/ruby/3.1.0/rubygems/ext/ext_conf_builder.rb:47:in `block in build' /usr/local/lib/ruby/3.1.0/tempfile.rb:317:in `open' /usr/local/lib/ruby/3.1.0/rubygems/ext/ext_conf_builder.rb:26:in `build' /usr/local/lib/ruby/3.1.0/rubygems/ext/builder.rb:161:in `build_extension' /usr/local/lib/ruby/3.1.0/rubygems/ext/builder.rb:195:in `block in build_extensions' /usr/local/lib/ruby/3.1.0/rubygems/ext/builder.rb:192:in `each' /usr/local/lib/ruby/3.1.0/rubygems/ext/builder.rb:192:in `build_extensions' /usr/local/lib/ruby/3.1.0/rubygems/installer.rb:853:in `build_extensions' /usr/local/lib/ruby/3.1.0/bundler/rubygems_gem_installer.rb:71:in `build_extensions' /usr/local/lib/ruby/3.1.0/bundler/source/path/installer.rb:34:in `post_install' /usr/local/lib/ruby/3.1.0/bundler/source/path.rb:244:in `generate_bin' /usr/local/lib/ruby/3.1.0/bundler/source/git.rb:194:in `install' /usr/local/lib/ruby/3.1.0/bundler/installer/gem_installer.rb:54:in `install' /usr/local/lib/ruby/3.1.0/bundler/installer/gem_installer.rb:16:in `install_from_spec' /usr/local/lib/ruby/3.1.0/bundler/installer/parallel_installer.rb:186:in `do_install' /usr/local/lib/ruby/3.1.0/bundler/installer/parallel_installer.rb:177:in `block in worker_pool' /usr/local/lib/ruby/3.1.0/bundler/worker.rb:62:in `apply_func' /usr/local/lib/ruby/3.1.0/bundler/worker.rb:57:in `block in process_queue' /usr/local/lib/ruby/3.1.0/bundler/worker.rb:54:in `loop' /usr/local/lib/ruby/3.1.0/bundler/worker.rb:54:in `process_queue' /usr/local/lib/ruby/3.1.0/bundler/worker.rb:91:in `block (2 levels) in create_threads' An error occurred while installing yaml-dummy-gem (1.0.0), and Bundler cannot continue. In Gemfile: yaml-dummy-gem ``` ## Debugging results The error is raised because the `Psych::Parser#parse` method cannot be found. In Psych version 4, this method is [defined by the Psych C-extension](https://github.com/ruby/psych/blob/2c3708e0a483c6d44ebddaff0b5…. In Psych version 5 the `parse` method is [defined in the gem's Ruby code](https://github.com/ruby/psych/blob/1f23e6e7f0ab4a6efab598c1ee528bb52d…. This method calls a [C function registered as the private `_native_parse` method](https://github.com/ruby/psych/blob/1f23e6e7f0ab4a6efab598c1ee528bb5…, which is the renamed version of the `parse` C-function in Psych version 4. From what I can tell, the Psych version 4 C-extension is no longer loaded when Psych version 5 is installed in this scenario. There is a mix up in which Psych gem version's C-extension is loaded during my dummy gem's C-extension installation. It load the Psych 4 Ruby code, with the Psych 5 C-extension∂. I confirmed this by modifying the standard installed Psych gem's code on Ruby 3.1 (Docker image `ruby:3.1`), with the following the change, which prints `true` on error. This means the Psych 4 gem has the Psych 5 C-extension loaded where `_native_parse` is defined. ```diff diff --git lib/psych.rb lib/psych.rb index 42d79ef..1a690d2 100644 --- lib/psych.rb +++ lib/psych.rb @@ -452,6 +452,9 @@ def self.parser def self.parse_stream yaml, filename: nil, &block if block_given? parser = Psych::Parser.new(Handlers::DocumentStream.new(&block)) + # This returns `true`, but it should be `false`. The `_native_parse` + # method is defined in the Psych 5 C-extension, not Psych 4. + puts parser.respond_to? :_native_parse, true # => true parser.parse yaml, filename ``` This error only occurs during the gem's extension installation in `ext/extconf.rb`. If the gem parses YAML when a Ruby app is running, it will not produce the same error with Psych version 5 installed. This issue does not occur on Ruby 3.2, where Psych version 5 is installed by default. I have confirmed this error occurs on the latest patch releases of the following Ruby versions: 3.1, 3.0, 2.7 and 2.6. ``` $ gem list psych psych (5.0.2, default: 4.0.3) ``` ## Code to reproduce Here is a basic Ruby gem that only parses a YAML file during extension installation: https://github.com/tombruijn/yaml-dummy-gem Here is a small project that triggers the error: https://github.com/tombruijn/yaml-dummy-ruby-app A GitHub actions workflow shows the results for all affected Ruby versions: https://github.com/tombruijn/yaml-dummy-ruby-app/actions/runs/3969088933 The [example app repo](https://github.com/tombruijn/yaml-dummy-ruby-app) also has instructions to run the example app locally. Please follow the instructions in the README to see the error. -- https://bugs.ruby-lang.org/

5 4

[ruby-core:111780] [Ruby master Bug#19331] --enable-rpath results in incorrect RPATH in Ruby 3.1.3
by Kulikjak (Jakub Kulik) 12 Apr '23

12 Apr '23

Issue #19331 has been reported by Kulikjak (Jakub Kulik). ---------------------------------------- Bug #19331: --enable-rpath results in incorrect RPATH in Ruby 3.1.3 https://bugs.ruby-lang.org/issues/19331 * Author: Kulikjak (Jakub Kulik) * Status: Open * Priority: Normal * ruby -v: 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I just updated Ruby from 3.1.2 to 3.1.3 and found out that all .so libraries from the enc directory have wrong RPATH/RUNPATH (when building with `--enable-rpath`). I first hit this on Solaris, but my testing on Linux resulted in the same thing. It can be easily reproduced with the following: ``` wget http://cache.ruby-lang.org/pub/ruby/3.1/ruby-3.1.3.tar.gz tar xzf ruby-3.1.3.tar.gz cd ruby-3.1.3 ./configure --prefix=/usr/ruby/3.1 --mandir=/usr/ruby/3.1/share/man --bindir=/usr/ruby/3.1/bin --sbindir=/usr/ruby/3.1/sbin --libdir=/usr/ruby/3.1/lib/amd64 --with-rubylibprefix=/usr/ruby/3.1/lib/ruby --enable-shared --enable-rpath /usr/bin/make -j 16 -l 32 objdump -x ./.ext/x86_64-linux/enc/windows_31j.so | grep RPATH ``` While previously this resulted in the following output: `RPATH /usr/ruby/3.1/lib/amd64` in 3.1.3 it is wrongly set to the build directory: `RPATH /home/jkulik/rubytest/ruby-3.1.3` I tried looking for some obvious change but didn't find the core of this issue yet. All I found out is that generated `enc.mk` differs in `prefix` and `libdir` ``` -prefix = /usr/ruby/3.1 +prefix = /home/jkulik/rubytest/ruby-3.1.3 exec_prefix = $(prefix) -libdir = $(exec_prefix)/lib/amd64 +libdir = /home/jkulik/rubytest/ruby-3.1.3 ``` `rbconfig.rb` is similar in both versions, but when I print out `CONFIG` in `make_encmake.rb` right after `load File.expand_path("lib/mkmf.rb", dir)`, I can see the differences from above, so it's probably something in the `lib/mkmf.rb` file that changes that. I am seeing the same issue in the current latest ruby 3.1 branch cloned from github. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:111956] [Ruby master Bug#19363] Fix rb_transient_heap_mark: wrong header (T_STRUCT) segfault
by bkuhlmann (Brooke Kuhlmann) 10 Apr '23

10 Apr '23

Issue #19363 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Bug #19363: Fix rb_transient_heap_mark: wrong header (T_STRUCT) segfault https://bugs.ruby-lang.org/issues/19363 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Overview Hello. 👋 I'm hitting an issue where my build is constantly failing with a segfault. The following is a snippet taken from my local machine with YJIT enabled (see attachments for details): ``` /Users/bkuhlmann/.cache/frum/versions/3.2.0/lib/ruby/gems/3.2.0/gems/puma-6.0.2/lib/puma/runner.rb: [BUG] rb_transient_heap_mark: wrong header, T_STRUCT (0x0000000109ea98a0) ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0] ``` The closest issue I could find that might be related to this issue (but not sure) is this issue: #15358. ## Steps to Recreate You should be able to quickly recreate this issue via these steps: - Download/clone my [Hemo](https://github.com/bkuhlmann/hemo) project. - Run the setup steps. - Run the test suite by running `bin/rspec`. If you need an example of the same segfault (but not on my macOS machine), you can see the same segfault via my [Circle CI Build](https://app.circleci.com/pipelines/github/bkuhlmann/hemo/11/workflow…. My Circle CI build is using my [Docker Alpine Linux Ruby](https://www.alchemists.io/projects/docker-alpine-ruby) image which might be of interest as well. This Docker image is also built with YJIT enabled. Interestingly, is if you were to run the test suite with `bin/guard` instead of `bin/rspec` then the segfault doesn't occur. ## Environment ``` ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0] 1.43.0 (using Parser 3.2.0.0, rubocop-ast 1.24.1, running on ruby 3.2.0) [arm64-darwin22.2.0] - rubocop-performance 1.15.2 - rubocop-rake 0.6.0 - rubocop-rspec 2.18.1 - rubocop-sequel 0.3.4 - rubocop-thread_safety 0.4.4 ``` ---Files-------------------------------- segfault.txt (237 KB) ruby-2023-01-21-113841.ips (19.6 KB) -- https://bugs.ruby-lang.org/

6 8

[ruby-core:111332] [Ruby master Bug#19242] Circular cause by Marshal
by nobu (Nobuyoshi Nakada) 24 Mar '23

24 Mar '23

Issue #19242 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19242: Circular cause by Marshal https://bugs.ruby-lang.org/issues/19242 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED ---------------------------------------- Crafted marshaled data can creates an `Exception` object with circular `cause`. -- https://bugs.ruby-lang.org/

2 1