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

[ruby-core:126651] [Ruby Feature#13677] Add more details to error "Name or service not known (SocketError)"
by akr (Akira Tanaka) 11 Sep '26

11 Sep '26

Issue #13677 has been updated by akr (Akira Tanaka). The current patch, which adds 'rb_str_catf(msg, " %+"PRIsVALUE, host);' is fine. ---------------------------------------- Feature #13677: Add more details to error "Name or service not known (SocketError)" https://bugs.ruby-lang.org/issues/13677#change-118909 * Author: dsbonev (Dimitar Bonev) * Status: Open ---------------------------------------- ruby version: `ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]` ruby script: ~~~ ruby require 'socket' TCPSocket.new 'nonexistent.example.com', 80 ~~~ Result: `getaddrinfo: Name or service not known (SocketError)` Expected: `getaddrinfo: Name or service not known for nonexistent.example.com (SocketError)` Why: This will make it easier to resolve errors of this kind by just looking at the logged messages. It is common for production and non-production (development, test) code to connect to different hosts which can produce errors due to wrong configuration. This change will make the ruby stdlib code more consistent as other methods already provide useful error information. Some examples: ~~~ ruby host = 'nonexistent.example.com'; port = 80 Resolv.getaddress host # => Resolv::ResolvError: no address for nonexistent.example.com Socket.getservbyname host # => SocketError: no such service nonexistent.example.com/tcp Net::HTTP.get Struct.new(:hostname, :port, :scheme).new(host, port, 'http') # => SocketError: Failed to open TCP connection to nonexistent.example.com:80 (getaddrinfo: Name or service not known) ~~~ If this issue will be resolved, please add any useful information to the error message in addition to the host. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126625] [Ruby Bug#22302] Prism and parse.y disagree on the `:line` event for a bare `nil` method body
by Eregon (Benoit Daloze) 10 Sep '26

10 Sep '26

Issue #22302 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22302: Prism and parse.y disagree on the `:line` event for a bare `nil` method body https://bugs.ruby-lang.org/issues/22302 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary The Prism compiler and the parse.y compiler produce a different set of `:line` trace points (line events) for a bare `nil` literal that is the value-producing body of a method. Prism emits a line event on the `nil`'s own line; parse.y does not. ```ruby def m nil end ``` - With `--parser=prism`, executing `m` (or setting a `TracePoint(:line)` / coverage / a debugger breakpoint) reports a line event on **line 2**. - With `--parser=parse.y`, there is **no** line event on line 2. ## Reproduction ### Compile-time line events ```ruby def line_events(iseq) events = iseq.trace_points.select { |_, event| event == :line }.map(&:first) iseq.each_child { |child| events.concat(line_events(child)) } events.sort end p line_events(RubyVM::InstructionSequence.compile("def m\n nil\nend\n")) ``` ``` $ ruby --parser=prism repro.rb [1, 2] $ ruby --parser=parse.y repro.rb [1] ``` ### Runtime `:line` events ```ruby seen = [] TracePoint.new(:line) { |tp| seen << tp.lineno if tp.path.end_with?("body.rb") }.enable do File.write("body.rb", "def m\n nil\nend\nm\n") load "./body.rb" end p seen.sort ``` ``` $ ruby --parser=prism rt.rb [1, 2, 4] $ ruby --parser=parse.y rt.rb [1, 4] ``` Under Prism a line event fires on line 2 (the `nil`) when `m` is called; under parse.y it does not. ## Instruction sequences The method body iseq differs only in the line attributed to the `putnil`, and whether it carries the line event (`[Li]`): ``` # --parser=parse.y 0000 putnil ( 1)[Ca] 0001 leave ( 3)[Re] # --parser=prism 0000 putnil ( 2)[LiCa] 0001 leave ( 3)[Re] ``` parse.y attributes the method's implicit-`nil` `putnil` to the definition line (1) with only the `RUBY_EVENT_CALL` flag, so no line event is emitted for line 2. Prism attributes the `putnil` to the `nil`'s own line (2) and emits a line event there. ## Scope of the difference The difference is specific to a bare `nil` in method (`def`/`defs`) tail position. Other cases behave the same under both parsers: - Other literals in the same position emit a line event under both parsers (`def m; true; end`, `def m; 1; end`, `def m; :a; end`, `def m; "s"; end`). - A bare `nil` at the top level, or as the body of a block or lambda, emits a line event under both parsers. - The failing shape also occurs when the tail `nil` is reached through the branch of a conditional, e.g. a method whose body is `if cond; nil; elsif ...; end`. The behavior is consistent across Ruby versions: parse.y has never emitted the line event for this case (checked back to 2.3), and Prism has emitted it since its compiler could be selected. This is a standing difference between the two compilers rather than a recent change; it only became visible by default when Prism became the default parser. ## Note on the cause This difference stems from void-expression elimination: parse.y treats the trailing `nil` as the method's implicit `nil` return and elides it (compiling a synthetic `putnil` with no line event), whereas Prism keeps it as an explicit value expression that carries a line event. It is not ideal that whether a `:line` event is emitted depends on whether an expression is eliminated as void, but that coupling is already the established behavior in both compilers — an unused bare literal in non-tail statement position (e.g. `1` or `:a` followed by another statement) likewise loses its line event under both parsers — so this is not unique to the case here, only the one place the two happen to disagree. ## Question Which behavior is intended — should a bare `nil` in method tail position emit a `:line` event or not? Currently the two parsers disagree, which affects `TracePoint(:line)`, line coverage, and debuggers depending on which parser compiled the code. ## Environment ``` ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] ``` Also reproduced on ruby 3.4.0 with `--parser=prism` / `--parser=parse.y`. (found in https://github.com/ruby/prism/pull/4223) -- https://bugs.ruby-lang.org/

1 3

[ruby-core:126506] [Ruby Feature#22266] Stop warning for duplicate keywords in splatted literal hashes
by jeremyevans0 (Jeremy Evans) 10 Sep '26

10 Sep '26

Issue #22266 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #22266: Stop warning for duplicate keywords in splatted literal hashes https://bugs.ruby-lang.org/issues/22266 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- Ruby warns for duplicate keywords in the same literal hash: ```shellsession $ ruby -we '{h: 1, h: 1}' -e:1: warning: key :h is duplicated and overwritten on line 1 ``` Ruby does not warn for duplicate keywords in splatted hashes: ```shellsession $ ruby -we 'h = {h:}; {h:, **h}' $ ruby -we 'h = {h:}; {**h, h:}' $ ruby -we 'h = {h:}; {**h, h:, **h}' $ ruby -we 'h = {h:}; {**h, **h}' ``` However, Ruby warns for for duplicate keywords in splatted literal hashes: ```shellsession $ ruby -we '{h: 1, **{h: 1}}' -e:1: warning: key :h is duplicated and overwritten on line 1 $ ruby -we '{**{h: 1}, h: 1}' -e:1: warning: key :h is duplicated and overwritten on line 1 $ ruby -we '{**{h: 1}, h: 1, **{h: 1}}' -e:1: warning: key :h is duplicated and overwritten on line 1 -e:1: warning: key :h is duplicated and overwritten on line 1 $ ruby -we '{**{h: 1}, **{h: 1}}' -e:1: warning: key :h is duplicated and overwritten on line 1 ``` I think Ruby should stop warning in the splatted literal hash case, for two reasons: * Treatment of splatted literal hashes is inconsistent with treatment of splatted non-literal hashes. Even if the compiler optimizes the splatted literal hash to the same bytecode as a direct keyword, it should not emit the same warning, because fundamentally the duplicate keyword is in a different hash, not in the same hash. * Warnings are designed to be helpful to the programmer, but unlike the warning for duplicate keywords in the same hash (a common mistake), no Ruby programmer is going to write splatted literal hashes. I can see an automated program generating splatted literal hashes, but in that case, the warnings are likely to be undesirable, just as warning for duplicate keywords in splatted non-literal hashes would be undesirable. Consider a hypothetical future Ruby compiler that could optimize the `h = {h:}; {h:, **h}` to the same bytecode as `{h: nil, **{h: nil}}`. Would we still want to emit the same warning? If accepted, I'm happy to work on a patch to implement this. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126600] [Ruby Bug#22301] Writing to the contents of a frozen IO::Buffer does not raise FrozenError
by himura467 (Akito Shitara) 10 Sep '26

10 Sep '26

Issue #22301 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22301: Writing to the contents of a frozen IO::Buffer does not raise FrozenError https://bugs.ruby-lang.org/issues/22301 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Writing to the contents of a frozen `IO::Buffer` does not raise `FrozenError`: ```ruby buffer = IO::Buffer.new(8) buffer.freeze buffer.set_string("x", 0) # no FrozenError buffer.get_string # => "x\x00\x00\x00\x00\x00\x00\x00" ``` `io_buffer_validate_for_writing()` rejects a buffer whose `RB_IO_BUFFER_READONLY` flag is set, or whose source is frozen, so it already treats frozen as not writable. But it takes a `struct rb_io_buffer *`, so the receiver never reaches it and the buffer's own frozen state goes unchecked. Reachable from `#set_string`, `#copy`, `#clear`, `#set_value`, `#set_values`, `#and!`, `#or!`, `#xor!`, `#not!`, `#read` and `#pread`. `#free`, `#resize` and `#transfer` already raise as of [Bug #22219]. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126458] [Ruby Feature#22255] Add `timeout:` to Ractor::Port#receive, Ractor.receive and Ractor.select
by ko1 (Koichi Sasada) 10 Sep '26

10 Sep '26

Issue #22255 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22255: Add `timeout:` to Ractor::Port#receive, Ractor.receive and Ractor.select https://bugs.ruby-lang.org/issues/22255 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- ## Abstract Add a `timeout:` keyword to the three ways a Ractor waits for a message: ```ruby Ractor::Port#receive(timeout: nil) # -> msg or nil Ractor.receive(timeout: nil) # -> msg or nil Ractor.select(*ports, timeout: nil) # -> [port, msg] or nil ``` They return `nil` once the timeout passes. `timeout: 0` never blocks: it takes a message if one is already there and returns `nil` otherwise. ## Background Today a Ractor wait cannot be bounded. Once a Ractor calls `receive`, it waits until a message arrives, so there is no way to write * a worker that gives up and reports progress if nothing arrives for a while, * a shutdown that stops waiting after a grace period, * a non-blocking "is there anything for me?" check. The usual workarounds are worse than a timeout: a watchdog Ractor that sends a dummy message, or a helper thread that closes the port. Both add a Ractor or a thread per wait and change the shape of the program. Every other blocking wait in Ruby already has this: `Thread::Queue#pop(timeout:)`, `ConditionVariable#wait(mutex, timeout)`, `Thread#join(limit)`, `IO#wait(timeout)`, `Mutex#sleep(timeout)`. ## Specification | call | result | |---|---| | `port.receive` | blocks until a message arrives (unchanged) | | `port.receive(timeout: 1.5)` | the message, or `nil` after 1.5 seconds | | `port.receive(timeout: 0)` | the message if one is already queued, else `nil`, without blocking | | `port.receive(timeout: -1)` | `ArgumentError` | | `Ractor.select(a, b, timeout: 1.5)` | `[port, msg]`, or `nil` after 1.5 seconds | The timeout behaves as it does elsewhere in Ruby: `nil` when it passes, and `timeout: 0` polls without blocking, as in `Thread::Queue#pop(timeout:)`, `IO.select` and `IO#wait`. * `timeout` accepts what `sleep` accepts (Integer, Float, Rational); a non-numeric value raises `TypeError`. * A negative timeout raises `ArgumentError`, as `IO.select` does. Note that `Thread::Queue#pop(timeout: -1)` instead returns `nil` right away, so the two existing APIs already disagree here; this follows `IO.select`. * `timeout: nil` (the default) means no timeout, i.e. today's behaviour. * A closed port still raises `Ractor::ClosedError`, timeout or not. * The timeout bounds how long the call blocks; it does not cut delivery off. A message that arrives while the timeout is being reported is still returned. Nothing is lost either way: a message only leaves the queue when it is returned. ### Why `nil` `nil` on timeout is what `Thread::Queue#pop(timeout:)`, `IO.select`, `IO#wait` and `Thread#join` all return. It is ambiguous when `nil` itself is a valid message, which is the same ambiguity `Queue#pop` has. The alternatives are a new exception class (`Ractor::TimeoutError`) or a sentinel object; both were judged heavier than the ambiguity is worth, but this is worth confirming. ### Why `timeout: 0` rather than a separate `try_receive` `timeout: 0` covers the non-blocking case with no new method name, and it is a genuine fast path in the implementation: it converts nothing, reads no clock and never parks. It costs about what a `receive` of an already-waiting message costs (~70ns vs ~150ns in a micro benchmark), against ~1.7us for a `receive(timeout: 10)` that has to compute a deadline. ## Implementation The wait stays where it is. `rb_ractor_sched_wait()` keeps parking the thread in the thread scheduler, so **an M:N thread still hands its native thread back** instead of becoming a dedicated one. Measured with 50 Ractors waiting at once, a timed `receive` uses the same 18 native threads an untimed one does. How the deadline is taken depends on the thread: * A **dedicated native thread** parks on its own condvar, so it takes the deadline there, the way `native_cond_sleep()` does. The condvar it waits on is the one a send already signals, so nothing else is involved. * An **M:N thread** has no condvar of its own, so its deadline is armed on the timer thread as a timeout-only wheel entry. The timer thread then wakes it through `thread_sched_to_ready_common()`, which is exactly how a send wakes it. That gives an M:N waiter two wakers, so the send path takes an armed timeout back before waking, skips a thread a fired timeout already made runnable, and bumps the scheduler event serial so a timeout that has not fired cannot wake it twice. Both kinds of wait exist on every pthread platform, including builds without the timer wheel (`USE_MN_THREADS == 0`, e.g. s390x-linux), where every thread is dedicated. On win32 the wait is already a condvar wait, which takes the timeout directly. Timer resolution follows the thread kind, exactly as `sleep` already does on the same thread: a dedicated thread gets the condvar's resolution, an M:N thread gets the timer wheel's 1ms tick. Measured, `receive(timeout: 0.0002)` and `sleep(0.0002)` return in 0.275ms on the main thread and 1.15ms inside a Ractor. ## Verification Besides `test/ruby/test_ractor.rb` additions: an attack suite of 13 scenarios (timeout racing with send, `Port#close`, `Thread#kill`, `Thread#raise`, Ractor termination, GC and compaction, `fork`, 64 waiters expiring in the same instant, all-Ractors-waiting deadlock detection) and a sweep that injects a trap, `SIGINT`, `Thread#kill` and `Thread#raise` at four points of the wait, including the instant the timer fires. Run against a release build, a `VM_CHECK_MODE` build and a `USE_MN_THREADS=0` build, with `RUBY_MN_THREADS=0` and `=1`. Of ~120,000 interrupt injections, ~78,000 landed while the thread was parked: no missed wakeup, no wait cut short by a trap, no assertion. 2,000,000 arm/disarm cycles showed no timer-wheel growth. ## Open questions 1. `nil` on timeout, or a `Ractor::TimeoutError`? 1a. A negative timeout: `ArgumentError` as in `IO.select`, or `nil` as in `Thread::Queue#pop`? 2. Should `Ractor.select` return something other than `nil`, given it already returns an Array? ## Patch https://github.com/ruby/ruby/pull/18418 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125247] [Ruby Bug#21995] mkmf generates a non-deterministic log file
by gemmaro (Gemma Kosaka) 10 Sep '26

10 Sep '26

Issue #21995 has been reported by gemmaro (Gemma Kosaka). ---------------------------------------- Bug #21995: mkmf generates a non-deterministic log file https://bugs.ruby-lang.org/issues/21995 * Author: gemmaro (Gemma Kosaka) * Status: Open * ruby -v: ruby 4.1.0dev (2026-04-12T14:25:33Z master 6593cc52d6) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, When compiling Ruby's C extensions with mkmf, it can generate a `mkmf.log` file with non-deterministic content, especially at the line below: ```txt ld: /tmp/rubytest.h8pay9/cc3fbuGm.o: in function `t': ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This can be problematic on some distributions/package-managers, since the `mkmf.log` file is included in the files generated by `gem install`. {{collapse(example flow) Note about an example flow where randomized filenames occur: 1. `extconf.rb` has calls to `have_func` 2. `gem install` is run by the user 3. It invokes mkmf to process the `extconf.rb` file 4. The checks fail and print intermediate randomized filenames, which are recorded in `mkmf.log` file 5. `gem install` includes `mkmf.log` in the packaged files 6. When the gem is built/packaged multiple times, a reproducibility problem occurs }} {{collapse(background) As a background, the previously reported/related issues are: * ##15304 * This mentions temporary filenames in the generated Makefile, and they are not reproducible. * The necessity/value of including `Makefile`, `gem_make.out`, and `mkmf.log` files are questioned. * So the [pull request](https://github.com/ruby/rubygems/pull/2481) was created to omit these files when installing gems. * However, deleting these files might break compatibility, so the pull request was closed. * Note: There is an [entry](https://github.com/ruby/rubygems/blob/3e3addb8d222d23ac46ca3b1959b29… about `mkmf.log` in the RubyGems' changelog: > ## 2.2.2 / 2014-02-05 > > ### Bug fixes: > > * [...] > * The `mkmf.log` is now placed next to `gem_make.out` when building extensions. * ##19329 * This points out that `gem install` installs `mkmf.log` file. * It was [transferred](https://github.com/ruby/rubygems/issues/6259) at RubyGems GitHub repository. * There are some issues related to this topic on the GNU Guix channel * For example, when I was packaging Ruby 4.0 for Guix, this reproducibility problem [occured](https://codeberg.org/guix/guix/pulls/5166). * There should be other workarounds in the Nix community, apparently. }} To wrap up, I think the followings are desirable: * Conventional file locations should be kept as is on the RubyGems side. * Just deleting these files breaks compatibilities. * These might be helpful when users report issues to gem owners with detailed information. * It is helpful if generated file contents are as reproducible as possible. * In some contexts where reproducibility matters, this issue makes packaging Ruby gems a bit harder. * Luckily, workarounds are possible in distribution package recipes such as deleting these files. * -> the component that generates `mkmf.log` is mkmf, so it might be resolvable by modifying mkmf itself. Thank you, gemmaro. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:126293] [Ruby Feature#22232] Deprecate `RHASH_TBL` and associated APIs
by byroot (Jean Boussier) 10 Sep '26

10 Sep '26

Issue #22232 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22232: Deprecate `RHASH_TBL` and associated APIs https://bugs.ruby-lang.org/issues/22232 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- I would like to deprecate `RHASH_TBL` and `RHASH_TBL_RAW`. ### Problem These API take a `RHash` instance and return its associated `st_table *`. If the Hash isn't backed by an `st_table` it will force convert it. I think it's a bad API because: - It allows to mutate the hash without triggering write barriers (dangerous). - Using it on a Hash backed by an `ar_table` blow memory usage. - It restrict evolution of RHash, as we must always be able to convert a Hash into a public `st_table`. There are various optimizations that would make sense for `RHash` but that would break the public `ruby/st.h` API, as such, in the future we may want to essentially fork `ruby/st.h` to have a distinct internal version dedicated to `RHash`. Just to give an example, `st_table.type` is very wasteful for RHash, as it's a full length 8B pointer that has only 2 possible values. It would be way more efficient to pass it as an argument every time, and get rid of some pointer chasing. With the possible future introduction of arbitrary length allocation in the GC, we might also want RHash to allocate its bins and entries with the GC rather than malloc. Both those ideas aren't possible to implement (or much harder) if we need to support `RHASH_TBL`. ### Impact I need to figure out how to use the gem search server, but a preliminary search on GitHub didn't show a lot of usage, it's a relatively rare API and if there are use cases that currently necessitate using `st_*` functions on RHash we should define equivalent `rb_hash_` functions to replace them. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126507] [Ruby Bug#22267] Active Support tests started failing on ruby master (bisected to #18194)
by yahonda (Yasuo Honda) 10 Sep '26

10 Sep '26

Issue #22267 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22267: Active Support tests started failing on ruby master (bisected to #18194) https://bugs.ruby-lang.org/issues/22267 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-26T07:05:32Z master 346b261abe) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- On ruby-head, the Active Support (Rails) test suite fails with two Ractor-related errors (rails-nightly build 4651, https://buildkite.com/rails/rails-nightly/builds/4651#01a016ac-eada-492d-95…) Rails CI failure. To reproduce on the Rails side, build ruby master, then in a rails/rails checkout run the two tests from activesupport/: ``` $ ruby -v ruby 4.1.0dev (2026-08-26T07:05:32Z master 346b261abe) +PRISM [x86_64-linux] $ bundle exec ruby -Ilib:test test/time_zone_test.rb -n test_formatted_offset_in_ractor #<Thread:...> terminated with exception (report_on_exception is true): lib/active_support/time_with_zone.rb:78:in 'ActiveSupport::TimeWithZone#period': undefined method 'period_for_utc' for nil (NoMethodError) from lib/active_support/time_with_zone.rb:139:in 'ActiveSupport::TimeWithZone#zone' from lib/active_support/time_with_zone.rb:59:in 'ActiveSupport::TimeWithZone#initialize' from lib/active_support/time_with_zone.rb:535:in 'ActiveSupport::TimeWithZone#marshal_load' 1) Error: TimeZoneTest#test_formatted_offset_in_ractor: Ractor::RemoteError: thrown by remote Ractor. lib/active_support/testing/ractors_assertions.rb:15:in 'Ractor#join' lib/active_support/testing/ractors_assertions.rb:15:in 'ActiveSupport::Testing::RactorsAssertions#on_ractor' test/time_zone_test.rb:895:in 'TimeZoneTest#test_formatted_offset_in_ractor' $ bundle exec ruby -Ilib:test test/notifications_test.rb -n test_record_and_set_subscriptions_when_using_a_regexp 1) Error: Notifications::NotificationSubscriptionTest#test_record_and_set_subscriptions_when_using_a_regexp: Ractor::Error: can not copy Hash object. lib/active_support/ractors.rb:117:in 'Ractor.make_shareable' lib/active_support/ractors.rb:117:in 'ActiveSupport::Ractors.make_shareable' lib/active_support/ractors.rb:79:in 'ActiveSupport::Ractors.try_make_shareable' lib/active_support/notifications.rb:359:in 'ActiveSupport::Notifications.record_subscriptions' lib/active_support/notifications.rb:314:in 'ActiveSupport::Notifications.subscribe' test/notifications_test.rb:604:in 'block in <class:NotificationSubscriptionTest>' ``` git bisect points at #18194 (Per-Ractor GC). Both reduce to Ractor copy and reproduce without Rails. Steps to reproduce (pure Ruby). (1) mirrors TimeZoneTest#test_formatted_offset_in_ractor — an object with a Time ivar (which now forces a Marshal fallback) whose marshal_load reconstructs from state only reachable in the main Ractor: ``` class Registry @zones = { "z" => Object.new } def self.find(name) = @zones.fetch(name) # reads a class-level ivar end class Wrapper def initialize(name) = (@name = name; @time = Time.now; @zone = Registry.find(name)) def marshal_dump = @name def marshal_load(name) = (@name = name; @time = Time.now; @zone = Registry.find(name)) end port = Ractor::Port.new Ractor.new(port, Wrapper.new("z")) { |p, o| p.send :ok }.join p port.receive ``` (2) mirrors Notifications...test_record_and_set_subscriptions_when_using_a_regexp — a Hash holding a Set and a shareable Proc: ``` require "set" Ractor.make_shareable({ s: Set.new([1, 2]), p: Ractor.shareable_proc {} }, copy: true) ``` Expected behavior. On Ruby 4.0.6 and before #18194 (50745e3e48): - (1) copies natively, marshal_load is not called, and prints :ok. - (2) succeeds. Actual behavior. On current master (346b261abe) and since #18194 (4f6c34eea6): (1): ``` #<Thread:...> terminated with exception (report_on_exception is true): -:3:in 'Registry.find': can not get unshareable values from instance variables of classes/modules from non-main Ractors (@zones from Registry) (Ractor::IsolationError) from -:8:in 'Wrapper#marshal_load' -:11:in 'Ractor#join': thrown by remote Ractor. (Ractor::RemoteError) from -:11:in '<main>' ``` marshal_load now runs in the receiver Ractor, where the object cannot reach main-Ractor state. In Active Support the same happens in TimeWithZone#marshal_load; there Time.find_zone rescues this and returns nil, so the Rails trace shows period_for_utc for nil instead. (2): ``` -:2:in 'Ractor.make_shareable': can not copy Hash object. (Ractor::Error) from -:2:in '<main>' -:2:in 'Ractor.make_shareable': no _dump_data is defined for class Proc (TypeError) from -:2:in '<main>' ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:122943] [Ruby Bug#21537] rb_ractor_sched_barrier_start() hangs on Windows
by rhenium (Kazuki Yamaguchi) 09 Sep '26

09 Sep '26

Issue #21537 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #21537: rb_ractor_sched_barrier_start() hangs on Windows https://bugs.ruby-lang.org/issues/21537 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * ruby -v: ruby 3.5.0dev (2025-08-09T11:32:53Z master 2a6345e957) +PRISM [x64-mswin64_140] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following script hangs at `GC.start` indefinitely. Pressing Ctrl+C on the terminal interrupts the `sleep` and it appears to resume and prints "in_ractor". ```ruby Ractor.new { sleep 1 GC.start puts "in_ractor" } sleep ``` I also reproduced this with Ruby 3.0.7 from RubyInstaller2. Here is the stack trace with master: ``` 0:006> ~*k 0 Id: 1e88.36c4 Suspend: 1 Teb: 000000c6`92478000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`929fef18 00007ffa`9e4edf43 ntdll!NtWaitForMultipleObjects+0x14 01 000000c6`929fef20 00007ffa`9e4ede11 KERNELBASE!WaitForMultipleObjectsEx+0x123 02 000000c6`929ff210 00007ff6`756b8164 KERNELBASE!WaitForMultipleObjects+0x11 03 000000c6`929ff250 00007ff6`756b13af miniruby!w32_wait_events+0x108 [C:\w\ruby\thread_win32.c @ 239] 04 000000c6`929ff2d0 00007ff6`756b62a2 miniruby!native_sleep+0xc3 [C:\w\ruby\thread_win32.c @ 360] 05 000000c6`929ff310 00007ff6`75646353 miniruby!sleep_forever+0x82 [C:\w\ruby\thread.c @ 1374] 06 000000c6`929ff350 00007ff6`756e5f4b miniruby!rb_f_sleep+0x53 [C:\w\ruby\process.c @ 4975] 07 000000c6`929ff380 00007ff6`756e5df9 miniruby!vm_call_cfunc_with_frame_+0x14b [C:\w\ruby\vm_insnhelper.c @ 3850] 08 000000c6`929ff460 00007ff6`756e5dbb miniruby!vm_call_cfunc_with_frame+0x29 [C:\w\ruby\vm_insnhelper.c @ 3895] 09 000000c6`929ff4a0 00007ff6`756e5ab7 miniruby!vm_call_cfunc_other+0xc7 [C:\w\ruby\vm_insnhelper.c @ 3922] 0a 000000c6`929ff4e0 00007ff6`756e8363 miniruby!vm_call_cfunc+0x10b [C:\w\ruby\vm_insnhelper.c @ 4003] 0b 000000c6`929ff510 00007ff6`756e7cfe miniruby!vm_call_method_each_type+0x637 [C:\w\ruby\vm_insnhelper.c @ 4827] 0c 000000c6`929ff610 00007ff6`756f39b4 miniruby!vm_call_method+0x152 [C:\w\ruby\vm_insnhelper.c @ 4991] 0d 000000c6`929ff680 00007ff6`756ee003 miniruby!vm_sendish+0x1f4 [C:\w\ruby\vm_insnhelper.c @ 6065] 0e 000000c6`929ff700 00007ff6`756e0f27 miniruby!vm_exec_core+0x25cb [C:\w\ruby\insns.def @ 900] 0f (Inline Function) --------`-------- miniruby!vm_exec_loop+0x8 [C:\w\ruby\vm.c @ 2653] 10 000000c6`929ff860 00007ff6`755b896f miniruby!rb_vm_exec+0x10b [C:\w\ruby\vm.c @ 2624] 11 000000c6`929ff9d0 00007ff6`755baf47 miniruby!rb_ec_exec_node+0x10f [C:\w\ruby\eval.c @ 284] 12 000000c6`929ffb50 00007ff6`75531069 miniruby!ruby_run_node+0x43 [C:\w\ruby\eval.c @ 320] 13 (Inline Function) --------`-------- miniruby!rb_main+0x25 [C:\w\ruby\main.c @ 42] 14 (Inline Function) --------`-------- miniruby!w32_main+0x5f [C:\w\ruby\main.c @ 62] 15 000000c6`929ffb80 00007ff6`7575e3ec miniruby!wmain+0x69 [C:\w\ruby\main.c @ 48] 16 (Inline Function) --------`-------- miniruby!invoke_main+0x22 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 90] 17 000000c6`929ffbb0 00007ffa`a03de8d7 miniruby!__scrt_common_main_seh+0x10c [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 18 000000c6`929ffbf0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 19 000000c6`929ffc20 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 1 Id: 1e88.1468 Suspend: 1 Teb: 000000c6`9247a000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`92dff618 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`92dff620 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`92dff980 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`92dff9b0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 2 Id: 1e88.1058 Suspend: 1 Teb: 000000c6`9247c000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`931ff6a8 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`931ff6b0 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`931ffa10 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`931ffa40 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 3 Id: 1e88.158c Suspend: 1 Teb: 000000c6`9247e000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`935ff998 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`935ff9a0 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`935ffd00 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`935ffd30 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 4 Id: 1e88.3acc Suspend: 1 Teb: 000000c6`92480000 Unfrozen "ruby-timer-thread" # Child-SP RetAddr Call Site 00 000000c6`936ffbc8 00007ffa`9e4ecbbf ntdll!NtWaitForSingleObject+0x14 01 000000c6`936ffbd0 00007ff6`756b7e9d KERNELBASE!WaitForSingleObjectEx+0xaf 02 000000c6`936ffc70 00007ffa`9e0d37b0 miniruby!timer_thread_func+0x45 [C:\w\ruby\thread_win32.c @ 777] 03 000000c6`936ffca0 00007ffa`a03de8d7 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x30 04 000000c6`936ffcd0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 05 000000c6`936ffd00 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 5 Id: 1e88.2934 Suspend: 1 Teb: 000000c6`92482000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`937ff4f8 00007ffa`9e4ecbbf ntdll!NtWaitForSingleObject+0x14 01 000000c6`937ff500 00007ff6`756b1276 KERNELBASE!WaitForSingleObjectEx+0xaf 02 000000c6`937ff5a0 00007ff6`756f7f47 miniruby!native_cond_timedwait_ms+0x62 [C:\w\ruby\thread_win32.c @ 483] 03 (Inline Function) --------`-------- miniruby!vm_cond_wait+0x28 [C:\w\ruby\vm_sync.c @ 211] 04 000000c6`937ff5f0 00007ff6`756b2c83 miniruby!rb_vm_cond_wait+0x37 [C:\w\ruby\vm_sync.c @ 220] 05 000000c6`937ff620 00007ff6`756f7f02 miniruby!rb_ractor_sched_barrier_start+0x67 [C:\w\ruby\thread_win32.c @ 956] 06 000000c6`937ff650 00007ff6`755c7a78 miniruby!rb_vm_barrier+0x1e [C:\w\ruby\vm_sync.c @ 265] 07 (Inline Function) --------`-------- miniruby!rb_gc_vm_barrier+0x5 [C:\w\ruby\gc.c @ 179] 08 (Inline Function) --------`-------- miniruby!gc_enter+0x25 [C:\w\ruby\gc\default\default.c @ 6609] 09 000000c6`937ff680 00007ff6`755c442e miniruby!gc_start+0xc0 [C:\w\ruby\gc\default\default.c @ 6334] 0a 000000c6`937ff6e0 00007ff6`755cdd0f miniruby!garbage_collect+0x42 [C:\w\ruby\gc\default\default.c @ 6316] 0b 000000c6`937ff710 00007ff6`755c2cc3 miniruby!rb_gc_impl_start+0x4b [C:\w\ruby\gc\default\default.c @ 6767] 0c 000000c6`937ff740 00007ff6`756d5c7b miniruby!gc_start_internal+0x4f [C:\w\ruby\gc.c @ 3447] 0d 000000c6`937ff780 00007ff6`756ee237 miniruby!builtin_invoker4+0x23 [C:\w\ruby\vm_insnhelper.c @ 7373] 0e (Inline Function) --------`-------- miniruby!invoke_bf+0x32 [C:\w\ruby\vm_insnhelper.c @ 7485] 0f (Inline Function) --------`-------- miniruby!vm_invoke_builtin+0x32 [C:\w\ruby\vm_insnhelper.c @ 7493] 10 000000c6`937ff7c0 00007ff6`756e0f27 miniruby!vm_exec_core+0x27ff [C:\w\ruby\build-debug\vm.inc @ 4621] 11 (Inline Function) --------`-------- miniruby!vm_exec_loop+0x8 [C:\w\ruby\vm.c @ 2653] 12 000000c6`937ff920 00007ff6`756f08b0 miniruby!rb_vm_exec+0x10b [C:\w\ruby\vm.c @ 2624] 13 (Inline Function) --------`-------- miniruby!invoke_iseq_block_from_c+0x1e3 [C:\w\ruby\vm.c @ 1651] 14 (Inline Function) --------`-------- miniruby!invoke_block_from_c_proc+0x2f2 [C:\w\ruby\vm.c @ 1745] 15 000000c6`937ffa90 00007ff6`756b6bf9 miniruby!vm_invoke_proc+0x324 [C:\w\ruby\vm.c @ 1775] 16 000000c6`937ffbd0 00007ff6`756b7987 miniruby!thread_do_start_proc+0x131 [C:\w\ruby\thread.c @ 584] 17 (Inline Function) --------`-------- miniruby!thread_do_start+0x37 [C:\w\ruby\thread.c @ 626] 18 000000c6`937ffc40 00007ff6`756b7720 miniruby!thread_start_func_2+0x243 [C:\w\ruby\thread.c @ 677] 19 000000c6`937ffe90 00007ffa`9e0d37b0 miniruby!thread_start_func_1+0x74 [C:\w\ruby\thread_win32.c @ 659] 1a 000000c6`937ffec0 00007ffa`a03de8d7 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x30 1b 000000c6`937ffef0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 1c 000000c6`937fff20 00000000`00000000 ntdll!RtlUserThreadStart+0x2c # 6 Id: 1e88.4f4 Suspend: 1 Teb: 000000c6`92486000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`93bff768 00007ffa`a10d793e ntdll!DbgBreakPoint 01 000000c6`93bff770 00007ffa`a03de8d7 ntdll!DbgUiRemoteBreakin+0x4e 02 000000c6`93bff7a0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`93bff7d0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126430] [Ruby Misc#22249] DevMeeting-2026-09-10
by mame (Yusuke Endoh) 09 Sep '26

09 Sep '26

Issue #22249 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #22249: DevMeeting-2026-09-10 https://bugs.ruby-lang.org/issues/22249 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/09/10 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 2026/09/07. 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/

10 9