September 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:123350] [Ruby Bug#21618] Allow to use the build-in prism version to parse code
by Earlopain (Earlopain _) 29 Oct '25

29 Oct '25

Issue #21618 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21618: Allow to use the build-in prism version to parse code https://bugs.ruby-lang.org/issues/21618 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism is a multi-version parser, which is a great feature. If one calls `Prism.parse("foo")`, it will always use the latest version prism knows about. This may or may not be the version that is currently executing. This is problematic when one wants to introspect code the same way that the currently running ruby version would. Consider that some syntax will be disallowed in the next ruby version. I would have to specify the ruby version I want to parse as in order to not run into syntax errors: `Prism.parse("foo", version: RUBY_VERSION)`. But doing so is not feasable because `prism` is distributed out of sync with ruby itself. If the user already has prism in their lockfile, the user may run a prism version that doesn't yet know about lets say ruby 4.0 and thus raise. Similarly, it may parse as an older patch version that has subtle behaviour differences. `ripper` does not have this issue because it is always tied to the ruby version and it is not distributed as a gem, so what the user has will always be exactly what ruby shipped with. I wish for a similar API that utilizes the prism version bundled with ruby itself. Libraries like `rails` have moved from ripper to prism because of its superior developer experience but it risks breaking in unexpected ways with new `prism` versions that know about more recent syntax. `error_highlight` for example also suffers from the same defect. It seems like prism currently has 34 methods that optionally take a version (per the rbi file). Many of these are trivial helper methods like `Prism.parse_success?` (does the parse result have any errors?). I would be happy with supporting only the minimal functions like `Prism.parse` and `Prism.parse_file`. Currently I don't have a use-case for any of the other methods. Pretty much just functions to mirror `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.compile`. It would be optimal if I would be able to transparently call `Prism.parse("foo", version: "current")` (or maybe even have an unspecified version mean the build-in prism version) but I am not sure how feasable that is since I'm pretty sure logic for this would have to live in ruby itself. @kddnewton does this feature request make sense? Do you have any other ideas/inputs? -- https://bugs.ruby-lang.org/

4 14

[ruby-core:123279] [Ruby Misc#21609] Propose Stan Lo (@st0012) as a core committer
by tekknolagi (Maxwell Bernstein) 28 Oct '25

28 Oct '25

Issue #21609 has been reported by tekknolagi (Maxwell Bernstein). ---------------------------------------- Misc #21609: Propose Stan Lo (@st0012) as a core committer https://bugs.ruby-lang.org/issues/21609 * Author: tekknolagi (Maxwell Bernstein) * Status: Open ---------------------------------------- ## Proposal I'd like to propose Stan Lo (@st0012) as a committer. He's been doing excellent work on ZJIT for the past couple of months, making sure we're compatible with the test suite, analyzing benchmark data, and optimizing the generated code. Especially since he has been contributing to Ruby for years now and knows the community, I think he should be able to merge his own changes. Here is Stan's message: ## Stan Lo's message I have been contributing to Ruby and core Ruby tools since 2021\. My main contributions have been: ### ZJIT Contributions ([60+ PRs](https://github.com/ruby/ruby/pulls?q=is%3Apr+author%3Ast0012+ZJIT+is%3…) - Made ZJIT work with TracePoint ([\#14407](https://github.com/ruby/ruby/pull/14407), [\#14420](https://github.com/ruby/ruby/pull/14420)) - Built infrastructure for annotating builtin functions ([\#14078](https://github.com/ruby/ruby/pull/14078)) - Implemented invalidation for method redefinition ([\#13875](https://github.com/ruby/ruby/pull/13875)), stable constants ([\#13998](https://github.com/ruby/ruby/pull/13998)), single Ractor mode ([\#14121](https://github.com/ruby/ruby/pull/14121)) - Supported compiling instructions: `concatstrings` ([\#14154](https://github.com/ruby/ruby/pull/14154)), `opt_and`/`opt_or` ([\#13830](https://github.com/ruby/ruby/pull/13830)), `invokeblock` ([\#14496](https://github.com/ruby/ruby/pull/14496)), `opt_case_dispatch` ([\#14433](https://github.com/ruby/ruby/pull/14433)) - Expanded test infrastructure to run against all Ruby tests ([\#13950](https://github.com/ruby/ruby/pull/13950)) ### Core Ruby Tools - **IRB** \- [All-time \#1 contributor](https://github.com/ruby/irb/graphs/contributors) and maintainer since 2022 - Implemented major features across Ruby 3.2-3.4: `cd` command, `edit` command, `show_cmds`, pager support, integration with `ruby/debug`…etc. - **RDoc** \- Maintainer since 2024 - Redesigned the default theme for Ruby 3.4+ ([\#1191](https://github.com/ruby/rdoc/pull/1191), [\#1157](https://github.com/ruby/rdoc/pull/1157)) - Created docs.ruby-lang.org with new homepage ([\#12227](https://github.com/ruby/ruby/pull/12227)) and greatly improved standard library page ([\#12404](https://github.com/ruby/ruby/pull/12404)) - **Debug** \- [\#2 contributor with 400+ commits](https://github.com/ruby/debug/graphs/contributors) - IRB integration ([\#1024](https://github.com/ruby/debug/pull/1024)) - `outline` command ([\#173](https://github.com/ruby/debug/pull/173)) - Backtrace filtering ([\#138](https://github.com/ruby/debug/pull/138)) I would like to continue contributing to ZJIT, IRB, RDoc, and other parts of Ruby. Being a committer would make it easier to maintain these critical tools and contribute to ZJIT's ongoing development. -- https://bugs.ruby-lang.org/

10 11

[ruby-core:122883] [Ruby Bug#21522] Accessing outer locals via eval in a Ractor returns false
by tenderlovemaking (Aaron Patterson) 24 Oct '25

24 Oct '25

Issue #21522 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21522: Accessing outer locals via eval in a Ractor returns false https://bugs.ruby-lang.org/issues/21522 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Assignee: ractor * ruby -v: ruby 3.5.0dev (2025-07-28T22:17:45Z master f1acf47ca2) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Normally, if you try to access a local that's been defined outside the scope of the Ractor block, it'll raise an ArgumentError. However, if you try to access the local via `eval` it will return the value `false`. ```ruby foo = Object.new begin Ractor.new { p foo }.value rescue ArgumentError end Ractor.new { p eval("foo") # => false }.value ``` I'm not sure how we fix this, since my guess is that we zero the environment when copying, but I wanted to file the issue so we can track it. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123241] [Ruby Feature#21572] Make illegal variable in alternation pattern a syntax error
by kddnewton (Kevin Newton) 23 Oct '25

23 Oct '25

Issue #21572 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21572: Make illegal variable in alternation pattern a syntax error https://bugs.ruby-lang.org/issues/21572 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- Currently when you have an illegal variable in an alternation pattern, you get a compile error, but no syntax error. ```ruby case foo in {a: } | Array "matched: #{a}" end ``` yields ``` $ ruby -cv test.rb ruby 3.5.0dev (2025-04-10T10:21:51Z master 756479324f) +PRISM [x86_64-linux] Syntax OK ``` but ``` $ ruby test.rb test.rb:2: illegal variable in alternative pattern (a) test.rb: compile error (SyntaxError) ``` Looking at the compiler, since illegal jumps (like break, next, etc.) are now syntax errors, the only other actual compiler errors are related to builtins. I think this should be a proper syntax error, so that editors and other tools can report on it and users can find it in development sooner. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:123319] [Ruby Feature#21615] Introduce `Array#values`
by matheusrich (Matheus Richard) 23 Oct '25

23 Oct '25

Issue #21615 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #21615: Introduce `Array#values` https://bugs.ruby-lang.org/issues/21615 * Author: matheusrich (Matheus Richard) * Status: Open ---------------------------------------- ## Motivation In Ruby code, it's common to accept arrays and hashes and treat them uniformly as collections of values. `Hash` exposes `#values`, but `Array` does not, which pushes developers toward `is_a?`/`respond_to?` branching. Following the **Principle of Least Surprise**, users may reasonably expect `Array#values` to exist because: * Both `Array` **and** `Hash` already implement `#values_at`. * `Hash` implements `#values` but `Array` does not. ### Example Today: ```ruby def normalize_records(input) items = input.respond_to?(:values) ? input.values : input items.each do |item| do_stuff_with_item(item) end end ``` With `Array#values`: ```ruby def normalize_records(input) input.values.each do |item| do_stuff_with_item(item) end end ``` ## Proposal Add `Array#values`, returning `self`. Implementation could simply alias to `itself`: ```ruby class Array alias_method :values, :itself end ``` This yields a uniform interface for `Array` and `Hash` values without type checks. ### Alternatives considered * `Enumerable#values`: defaulting to `to_a`, but I found it too broad of a change. * `Array#each_value`: redundant as `Array#each` already covers iteration. Patch: https://github.com/ruby/ruby/pull/14641 -- https://bugs.ruby-lang.org/

6 8

[ruby-core:118243] [Ruby master Feature#20564] Switch default parser to Prism
by kddnewton (Kevin Newton) 22 Oct '25

22 Oct '25

Issue #20564 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #20564: Switch default parser to Prism https://bugs.ruby-lang.org/issues/20564 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- This issue is to propose switching the default parser for Ruby to Prism on the master branch. The main goal is to get this default into both master and the next preview so that the community has plenty of time to test before the eventual 3.4 release. Matz has indicated that the final decision about the default parser for Ruby 3.4 will be made later in the year. Decisions about the default parser for Ruby 3.5+ and the relationship between Prism, lrama, parse.y, etc. will also be made at a later time. ## Background For some background on the Prism project itself, here are a couple of links in chronological order that you can read: * https://bugs.ruby-lang.org/issues/19741 * https://railsatscale.com/2023-06-12-rewriting-the-ruby-parser/ * https://kddnewton.com/2024/01/23/prism.html * https://railsatscale.com/2024-04-16-prism-in-2024/ ## Status Prism now passes all Ruby tests and specs. Internally at Shopify, it also passes our Core monolith's CI, which is a large and complex Rails application. We are confident that it is ready for production use. External to CRuby, Prism has already been adopted extensively around the ecosystem, including but not limited to: * [JRuby](https://github.com/jruby/jruby/pull/8103) (via Java) * [TruffleRuby](https://github.com/oracle/truffleruby/issues/3117) (via Java) * [Natalie](https://github.com/natalie-lang/natalie/pull/1213) (via C++ and Ruby) * [Opal](https://github.com/opal/opal/pull/2642) (via Ruby and WASM) * [repl_type_completor](https://github.com/ruby/repl_type_completor) * [rubocop](https://docs.rubocop.org/rubocop/configuration.html#setting-the-pa… (via parser translator) * [ruby-lsp](https://github.com/Shopify/ruby-lsp) * [packwerk](https://github.com/Shopify/packwerk/pull/388) (via parser translator) Fortunately with the community adoption, we have been able to find many edge cases and bugs that have been fixed. Thank you so much to everyone who has tried, used, reported problems with, and improved Prism in the last couple of years. We would not have hit this milestone without this community involvement. ## Caveats While Prism correctly accepts and parses all valid Ruby syntax, there are still a number of cases where it does not reject invalid syntax as it should. We are currently working on these cases, and we are confident that we can eliminate them before the next preview release. You can find them listed here: https://github.com/ruby/prism/issues?q=is%3Aopen+is%3Aissue+label%3Ainvalid…. This is our top priority right now, and I anticipate these being resolved quickly. The other caveat is unknown unknowns: bugs or syntax issues that we have yet to discover. At Shopify we are currently taking numerous steps to mitigate this risk, including: * Prism currently passes all Ruby tests and specs, and will continue to going forward. The tests and specs are extensive, and we are confident this gets us almost all of the way there. * Grammar-based fuzzing to ensure we handle all possible syntax variations (both valid and invalid). As an example, that recently led to the discovery that the current compiler was segfaulting on safe navigation in for loops (https://bugs.ruby-lang.org/issues/20468) It has also found several memory leaks that have been fixed. * Mutation testing of existing source files (by adding and deleting random bytes) to find additional edge cases. Our goal is 100% compatibility, and we believe this is achievable through the above techniques and others. The goal of this proposal is to allow more companies to test their codebase against Prism, and to make this easier. We believe that we can sort out the remaining problems much more quickly in that manner. ## Implementation The implementation will be relatively straightforward, as there is already the `--parser` flag that can be used to switch between the current parser and Prism. We will change the default to be `"prism"` instead of `"parse.y"`. There is no plan to remove or change any code related to `parse.y`, `lrama`, or `compile.c` at this time, as we want to create the minimal amount of change possible to ensure stability. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:123257] [Ruby Misc#21606] DevMeeting-2025-10-23
by mame (Yusuke Endoh) 22 Oct '25

22 Oct '25

Issue #21606 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21606: DevMeeting-2025-10-23 https://bugs.ruby-lang.org/issues/21606 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/10/23 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/10/20. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

7 8

[ruby-core:111742] [Ruby master Feature#19326] Please add a better API for passing a Proc to a Ractor
by sdwolfz 18 Oct '25

18 Oct '25

Issue #19326 has been reported by sdwolfz (Codruț Gușoi). ---------------------------------------- Feature #19326: Please add a better API for passing a Proc to a Ractor https://bugs.ruby-lang.org/issues/19326 * Author: sdwolfz (Codruț Gușoi) * Status: Open * Priority: Normal ---------------------------------------- Example 1: ```ruby class Worker def initialize(&block) @block = block end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:271:in `new': allocator undefined for Proc (TypeError) from scripts/run.rb:9:in `run' from scripts/run.rb:14:in `<main>' ``` Example 2: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00007f00394c38b8 scripts/run.rb:13> (Ractor::IsolationError) from scripts/run.rb:5:in `initialize' from scripts/run.rb:13:in `new' from scripts/run.rb:13:in `<main>' ``` Example 3: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Ractor.current.instance_eval { Worker.new { 1 } } puts worker.run.take ``` Works, but having `Ractor.current.instance_eval` as a wrapper around the block is not ideal, as Ractor is supposed to be only an implementation detail in Worker. I know about https://bugs.ruby-lang.org/issues/18243 and the discussion around `proc.bind(nil)`. That would actually be ideal, as for the purposes if why I want this functionality I don't care what `self` is in a block, and the less it has access to the better. The general idea is to have a Ractor be able to lazily execute an arbitrary proc. And all the bindings it would need would be passed explicitly, either through `args` in the constructor or through `send`/`receive`, so `self` would really not matter. The benefit: this would make it so concurrent code can be more easily be implemented with Ractors as currently you can execute an arbitrary proc by passing it to a Thread (but you don't get the nice data isolation). -- https://bugs.ruby-lang.org/

6 12

[ruby-core:123207] [Ruby Bug#21568] Requiring core libraries when already requiring mutliple user defined libraries with the same name can error
by alexalexgriffith (Alex Griffith) 11 Oct '25

11 Oct '25

Issue #21568 has been reported by alexalexgriffith (Alex Griffith). ---------------------------------------- Bug #21568: Requiring core libraries when already requiring mutliple user defined libraries with the same name can error https://bugs.ruby-lang.org/issues/21568 * Author: alexalexgriffith (Alex Griffith) * Status: Open * ruby -v: ruby 3.1.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The simplest way to understand this error is that after requiring 2 or more files with the same name as some core libraries, any subsequent calls to require the core library will fail, ie ```ruby require '/Users/alex/foo/fiber' require '/Users/alex/bar/fiber' require 'fiber' ``` raises ``` cannot load such file -- fiber ``` More detailed instructions to repro this can be found in the code snippet below. Noting that I am on a Mac, OS 15.6. This is reproducible across my team on a few different OS versions, all Mac. The same underlying issue can also be seen in some other issues like: https://github.com/newrelic/newrelic-ruby-agent/issues/2001 The context this error is discovered in is that some gems may require their own libraries with the same name as core libraries, often wrapping the implementations of those core libraries to extend functionality, like the New Relic ruby agent does with fiber, for example (https://github.com/newrelic/newrelic-ruby-agent/tree/dev/lib/new_relic/agen…) Then, if 2 or more gems do something like that, and any other gem has `require 'fiber'` in it to support old ruby versions where this was necessary, the error occurs. **Full Steps to Reproduce:** ``` ruby # Setup # ===== # 1. Set this base_dir variable to be an absolute path to a dir # or something that can be found in your $LOAD_PATH. base_dir = # ex: "/Users/<you>/ruby_require_test" # 2. Within that base directory create 2 directories named `foo` and `bar` # 3. Within both `foo` and `bar` touch new files named # - complex.rb # - enumerator.rb # - fiber.rb # - rational.rb # - ruby2_keywords.rb # - set.rb # - thread.rb # Note - this list was generated by running: # `ruby -ve 'p $LOADED_FEATURES.reject { |feature| %r|/| =~ feature }'` # which returns: `["enumerator.so", "thread.rb", "fiber.so", "rational.so", "complex.so", "ruby2_keywords.rb"]` # Reproducing the error: # After requiring 2 (or more) user defined files with the same name as part of # the ruby core library that is required as a bare filename, requiring that part of # the core library will error, ex: `cannot load such file -- fiber`. # The erroring require statements are all .so files begin require "#{base_dir}/foo/complex" require "#{base_dir}/bar/complex" require 'complex' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/enumerator" require "#{base_dir}/bar/enumerator" require 'enumerator' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/fiber" require "#{base_dir}/bar/fiber" require 'fiber' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/rational" require "#{base_dir}/bar/rational" require 'rational' rescue LoadError => e puts e.message end # The following examples do not error. # The difference seems to be that the core lib files are defined as .rb not .so begin require "#{base_dir}/foo/ruby2_keywords" require "#{base_dir}/bar/ruby2_keywords" require 'ruby2_keywords' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/set" require "#{base_dir}/bar/set" require 'set' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/thread" require "#{base_dir}/bar/thread" require 'thread' rescue LoadError => e puts e.message end ``` -- https://bugs.ruby-lang.org/

5 8

[ruby-core:123318] [Ruby Bug#21614] thread_sched_wait_events race with timer_thread_wakeup
by luke-gru (Luke Gruber) 09 Oct '25

09 Oct '25

Issue #21614 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21614: thread_sched_wait_events race with timer_thread_wakeup https://bugs.ruby-lang.org/issues/21614 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `thread_sched_wait_events` checks th->sched.waiting_reason.flags under thread_sched_lock but not under timer_thread.waiting_lock. The timer thread sets it under the timer_thread.waiting_lock only. This race results in the assertion failure: `../ruby/thread_pthread.c:909: Assertion Failed: thread_sched_to_running_common:sched->running != th` Reproduction script (run it many times): ```ruby require "timeout" def invoke_ruby(args, stdin_data = "", capture_stdout = false, capture_stderr = false, encoding: nil, timeout: 10, reprieve: 1, timeout_error: Timeout::Error, stdout_filter: nil, stderr_filter: nil, ios: nil, signal: :TERM, rubybin: "ruby", precommand: nil, **opt) timeout = 60 in_c, in_p = IO.pipe out_p, out_c = IO.pipe if capture_stdout err_p, err_c = IO.pipe if capture_stderr && capture_stderr != :merge_to_stdout opt[:in] = in_c opt[:out] = out_c if capture_stdout opt[:err] = capture_stderr == :merge_to_stdout ? out_c : err_c if capture_stderr if encoding out_p.set_encoding(encoding) if out_p err_p.set_encoding(encoding) if err_p end ios.each {|i, o = i|opt[i] = o} if ios c = "C" child_env = {} if Array === args and Hash === args.first child_env.update(args.shift) end args = [args] if args.kind_of?(String) # use the same parser as current ruby if args.none? { |arg| arg.start_with?("--parser=") } args = ["--parser=prism"] + args end pid = spawn(child_env, *precommand, rubybin, *args, opt) in_c.close out_c&.close out_c = nil err_c&.close err_c = nil if block_given? return yield in_p, out_p, err_p, pid else th_stdout = Thread.new { out_p.read } if capture_stdout th_stderr = Thread.new { err_p.read } if capture_stderr && capture_stderr != :merge_to_stdout in_p.write stdin_data.to_str unless stdin_data.empty? in_p.close if (!th_stdout || th_stdout.join(timeout)) && (!th_stderr || th_stderr.join(timeout)) timeout_error = nil else $stderr.puts "Error: timed out" status = terminate(pid, signal, opt[:pgroup]) terminated = Time.now end stdout = th_stdout.value if capture_stdout stderr = th_stderr.value if capture_stderr && capture_stderr != :merge_to_stdout out_p.close if capture_stdout err_p.close if capture_stderr && capture_stderr != :merge_to_stdout status ||= Process.wait2(pid)[1] stdout = stdout_filter.call(stdout) if stdout_filter stderr = stderr_filter.call(stderr) if stderr_filter if timeout_error bt = caller_locations msg = "execution of #{bt.shift.label} expired timeout (#{timeout} sec)" raise timeout_error, msg, bt.map(&:to_s) end return stdout, stderr, status end ensure [th_stdout, th_stderr].each do |th| th.kill if th end [in_c, in_p, out_c, out_p, err_c, err_p].each do |io| io&.close end [th_stdout, th_stderr].each do |th| th.join if th end end def terminate(pid, signal = :TERM, pgroup = nil) case pgroup when 0, true pgroup = -pid when nil, false pgroup = pid end begin Process.kill signal, pgroup rescue Errno::EINVAL rescue Errno::ESRCH end $? end rs = [] 100.times do rs << Ractor.new do script = '$stdout.sync=true; def rec; print "."; rec; end; Fiber.new{rec}.resume' invoke_ruby([{}, '-e', script], "", true, true) end end rs.each(&:join) ``` This script is just taken directly from a failed test in the test suite that was run under multiple ractors at once (`test_vm_stack_size`). -- https://bugs.ruby-lang.org/

2 1