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

[ruby-core:121437] [Ruby Bug#21197] Prism does not accept newline after defined? keyword
by kddnewton (Kevin Newton) 14 Jul '25

14 Jul '25

Issue #21197 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21197: Prism does not accept newline after defined? keyword https://bugs.ruby-lang.org/issues/21197 * Author: kddnewton (Kevin Newton) * Status: Open * Assignee: prism * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` defined? (1) ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120618] [Ruby master Bug#21029] Prism behavior for `defined? (;x)` differs
by qnighy (Masaki Hara) 14 Jul '25

14 Jul '25

Issue #21029 has been reported by qnighy (Masaki Hara). ---------------------------------------- Bug #21029: Prism behavior for `defined? (;x)` differs https://bugs.ruby-lang.org/issues/21029 * Author: qnighy (Masaki Hara) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-11T03:21:57Z master 1b3037081e) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism has a different behavior for `(;expr)` when used in `defined?` predicate: ```console % ./miniruby --parser=prism -e "p defined? (;x)" nil % ./miniruby --parser=parse.y -e "p defined? (;x)" "expression" ``` Although not a significant difference, aligning either of them with the other would be better. -- https://bugs.ruby-lang.org/

5 11

[ruby-core:111027] [Ruby master Bug#19154] Specify require and autoload guarantees in ractors
by fxn (Xavier Noria) 14 Jul '25

14 Jul '25

Issue #19154 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #19154: Specify require and autoload guarantees in ractors https://bugs.ruby-lang.org/issues/19154 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given a file `c.rb`: ```ruby class C end ``` the following script: ```ruby r1 = Ractor.new do require './c.rb' end r2 = Ractor.new do require './c.rb' end r1.take r2.take ``` raises: ``` % ruby -v foo.rb ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22] foo.rb:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x000000010fee2928 run> terminated with exception (report_on_exception is true): #<Thread:0x00000001102acfe0 run> terminated with exception (report_on_exception is true): <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' from foo.rb:6:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require'<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': : can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' from foo.rb:6:in `block in <main>' <internal:ractor>:698:in `take': thrown by remote Ractor. (Ractor::RemoteError) from foo.rb:9:in `<main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' from foo.rb:2:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' ``` Would it be possible to have documentation about their interaction? This is important also to understand autoloading within ractors, since constant references may trigger `require` calls. -- https://bugs.ruby-lang.org/

5 13

[ruby-core:121621] [Ruby Feature#21262] Proposal: `Ractor::Port`
by ko1 (Koichi Sasada) 08 Jul '25

08 Jul '25

Issue #21262 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #21262: Proposal: `Ractor::Port` https://bugs.ruby-lang.org/issues/21262 * Author: ko1 (Koichi Sasada) * Status: Assigned * Assignee: ko1 (Koichi Sasada) * Target version: 3.5 ---------------------------------------- # Proposal: `Ractor::Port` In concurrent Ruby applications using Ractors, safely and efficiently communicating results between Ractors is a common challenge. We propose `Ractor::Port` as a lightweight, safe, and ergonomic abstraction to simplify communication patterns, especially in request-response models. ```ruby # usage example port = Ractor::Port.new Ractor.new port do |port| port << 42 port << 43 end # Success: wait for sending port.receive #=> 42 Ractor.new port do |port| port.receive # Error: only the creator Ractor can receive from this port. end port.receive #=> 43 ``` This is a similar concept to ["Channel"](https://bugs.ruby-lang.org/issues/21121), but it is tightly coupled with the creator Ractor and no other Ractors can receive anything from that port. In that sense, it is conceptually closer to a socket file descriptor (e.g., a destination and port number pair in TCP/IP). We can implement `Port` with `Ractor.receive_if` like this: ```ruby class Ractor::Port def initialize @r = Ractor.current @tag = genid() end def send obj @r << [@tag, obj] end def receive raise unless @r == Ractor.current Ractor.receive_if do |(tag, result) if tag == @tag return result end end end end ``` With `Ractor::Port`, we can deprecate `Ractor.receive_if`, `Ractor.yield`, and `Ractor#take`. Ports act as clear, self-contained endpoints for message passing, which makes these older primitives redundant. Furthermore, Port-based communication is significantly easier to implement and reason about—especially when considering synchronization challenges around `Ractor.select` and rendezvous semantics. ## Background: Limitations of current communication patterns Let's discuss how to make server-like service ractors. ### No response server We can make server-like Ractors like this: ```ruby # EX1 def fib(n) = n > 1 : fib(n-2) + fib(n-1) : 1 # A ractor calculate fib(n) fib_srv = Ractor.new do while true param = Ractor.receive result = fib(param) end end fib_srv << 10 ``` In this case, the main Ractor requests `fib_srv` to calculate `fib(10)`. However, currently, there is no way to retrieve the result. ### Return value to the sender ractor There are several possible approaches. First, we can send the sender Ractor along with the parameter, and ask the server to send the result back to the sender. ```ruby # EX2 fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << result end end fib_srv << [10, Ractor.current] do_some_work() Ractor.receive #=> fib(10) ``` This approach works well in simple cases. However, with EX2, handling multiple concurrent responses becomes difficult. The results are pushed into the same mailbox, and since `Ractor.receive` retrieves messages without discriminating the source, it's unclear which server returned which result. ```ruby # EX3 def fact(n) = n > 1 : fact(n-1) * n fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << result end end fact_srv = Ractor.new do while true param, sender = Ractor.receive result = fact(param) sender << result end end fib_srv << [10, Ractor.current] fib_srv << [20, Ractor.current] fact_srv << [10, Ractor.current] fact_srv << [20, Ractor.current] do_some_work() Ractor.receive #=> fib(10) or fact(10), which? # If the servers uses Ractors more (calculate them in parallel), # fib(20) and fact(20) can be returned. ``` Because `Ractor.receive` retrieves all messages indiscriminately, developers must add their own tagging logic to distinguish results. While tagging (as shown in EX4) helps, it introduces additional complexity and brittleness. ### Responses with request ID The following code returns a result with request id (a pair of the name of server and a parameter). ```ruby # EX4 fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << [[:fib, param], result] end end fact_srv = Ractor.new do while true param, sender = Ractor.receive result = fact(param) sender << [[:fact, param], result] end end do_some_work() fib_srv << [10, Ractor.current] fib_srv << [20, Ractor.current] fact_srv << [10, Ractor.current] fact_srv << [20, Ractor.current] Ractor.receive_if do |id, result| case id in [:fib, n] p "fib(#{n}) = #{result}" in [:fact, n] p "fact(#{n}) = #{result}" end end # or if you want to use specific results, like: p fib20: Ractor.receive_if{|id, result| id => [:fib, 20]; result} p fact10: Ractor.receive_if{|id, result| id => [:fact, 10]; result} p fact20: Ractor.receive_if{|id, result| id => [:fact, 20]; result} p fib10: Ractor.receive_if{|id, result| id => [:fib, 10]; result} ``` This approach closely resembles pattern matching in Erlang or Elixir, where responses are tagged and matched structurally. However, this solution still has an issue: if `do_some_work()` uses `Ractor.receive`, it may accidentally consume any message. In other words, `Ractor.receive` can only be safely used when you're certain that no other code is using it. (Another trivial issue is, different servers can return same identity, like `[:fact, num]` returned by NewsPaper server. It is confusing). ### Using channels To solve this issue, we can make a channel with different Ractors. Channels can be implemented using Ractors, as illustrated below. ```ruby # EX5 # Servers are completely same to EX3 fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << result end end fact_srv = Ractor.new do while true param, sender = Ractor.receive result = fact(param) sender << result end end # Create a new channel using a Ractor def new_channel Ractor.new do while true Ractor.yield Ractor.receive end end end fib_srv << [10, fib10_ch = new_channel] fib_srv << [20, fib20_ch = new_channel] fact_srv << [10, fact10_ch = new_channel] fact_srv << [20, fact20_ch = new_channel] do_something() p fib20: fib20_ch.take # wait for fib(20) p fact10: fact10_ch.take # wait for fact(10) p fib10: fib10_ch.take # wait for fib(10) p fact20: fact10_ch.take # wait for fact(20) # or chs = [fib10_ch, fib20_ch, fact10_ch, fact20_ch] while !chs.empty? ch, result = Ractor.select(*chs) # wait for multiple channels p ch, result chs.delete ch end ``` Channel approach solves the issue of EX4. The above implementation introduce some overhead to create channel ractors, but we can introduce special implementation to reduce this Ractor creation overhead. However, in the Actor model, the communication pattern is to send a message to a specific actor. In contrast, channels are used to send messages through a shared conduit, without caring which receiver (if any) handles the message. Also, channels can have some overhead, as discussed below. ### Summary of background Currently, when implementing request-response patterns with Ractors, developers face challenges in tracking results, managing identifiers, and avoiding message conflicts. Existing primitives like `receive_if`, `take`, or channels implemented with Ractors are either error-prone or inefficient. ## Proposal Introduce `Ractor::Port` as an alternative to channels. It is a natural extension of the Actor model. In fact, it is thin wrapper of current send/receive model as illustrated at the top of this proposal. With the `Ractor::Port`, we can rewrite above examples with it. ```ruby # EX6 # Completely same as EX3's servers fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << result end end fact_srv = Ractor.new do while true param, sender = Ractor.receive result = fact(param) sender << result end end fib_srv << [10, fib10_port = Ractor::Port.new] fib_srv << [20, fib20_port = Ractor::Port.new] fact_srv << [10, fact10_port = Ractor::Port.new] fact_srv << [20, fact20_port = Ractor::Port.new] do_something p fib10_port.receive #=> fib(10) p fib20_port.receive #=> fib(20) p fact10_port.receive #=> fact(10) p fact20_port.receive #=> fact(20) # or ports = [fib10_port, fib20_port, fact10_port, fact20_port] while !ports.empty? port, result = Ractor.select(*ports) case port when fib10_port p fib10: result ... else raise "This should not happen (BUG)." end ports.delete(port) end ``` `Ractor::Port` resolves key pain points in message passing between Ractors: * It guarantees that incoming messages are only delivered to the intended Ractor, preventing tag collisions. * It enables message routing without relying on global receive blocks (`Ractor.receive`), which are prone to unintended consumption. * It replaces more complex primitives like `.receive_if`, `.yield`, and `#take` with a simpler, composable abstraction. * It maps cleanly to the Actor model semantics Ruby intends to support with Ractors. While the pattern looks similar to using channels, the semantics and guarantees are different in meaningful ways. The advantages of using Ports include: * Safer than channels in practice * When using a Port, if `#send` succeeds, it means the destination Ractor is still alive (i.e., it's running). * In contrast, with a channel, there's no guarantee that any Ractor is still available to receive from it. * Of course, even with a port, there's no guarantee that the destination Ractor will actually process the message — it might ignore it. * But at least you don't need to worry about the Ractor having already terminated unexpectedly. * In other words, using a port eliminates one major failure case, making the communication model more predictable. * This is one of the reasons why Ruby went with the "Actor" model (hence the name Ractor), instead of the "CSP" model. * Faster than channels in both creation and message transmission * When creating a channel, we need to prepare a container data structure. When creating a port, it is lightweight data (a pair of Ractor and newly created ID). * On the channel transmission, we need copying a data to channel and a copying to the receiving ractor. On the port, it only needs to copy from the src ractor to the dst ractor. This issue becomes more significant due to Ractor-local garbage collection and isolation of object spaces. * Easy to implement. We only need to implement `Port#receive` to synchronize with other ractors. * `#send/.receive` is easy to implement because we only need to lock the receiving ractor. * `.yield/#take` is not easy to implement because we need to lock taking and receiving ractors because it is rendezvous style synchronization. * `.select` is DIFFICULT to support current spec. Now CI doesn't stable yet. * A simpler spec reduces bugs, and maybe leads to faster implementation. Disadvantages: 1. It is not a well-known concept, especially for Go language users. 2. We need additional abstraction like producer(s)-consumer(s) concurrent applications. For (2), I want to introduce an example code. We can write a 1-producer, multiple-consumer pattern with a channel. ```ruby # channel version of 1 producer & consumers ch = new_channel RN = 10 # make 10 consumers consumers = RN.times.map do Ractor.new ch do while param = ch.receive task(param) end end end tasks.each do |task| ch << task end ``` With Port, we need to introduce a load balancing mechanism: ```ruby # Port version of 1 producer & consumers control_port = Ractor::Port.new consumers = RN.times.map do Ractor.new control_port control_port do |control_port| while true control_port << [:ready, Ractor.current] # register - ready param = Ractor.receive # it assumes task doesn't use Ractor.receive task(param) end end end tasks.each do |task| control_port.receive => [:ready, consumer] # send a task to a ready consumer consumer << task end ``` Of course we can make a library for that (like OTP on Erlang). ### Default port of Ractors Each Ractor has a default port and `Ractor#send` is equal to `Ractor.current.default_port#send`. Of course, `Ractor.receive` is equal to `Ractor.current.default_port.receive`. For the simple case, we can keep to use `Ractor#send` and `Ractor.receive` ### Deprecation of Ractor#take and Ractor.yield With the Port concept, we can focus solely on send and receive—that is, direct manipulation of a Ractor’s mailbox. Ports provide a clean and functional alternative to `Ractor#take` and `Ractor.yield`, making them unnecessary in most use cases. Moreover, Ports are significantly easier to implement, as they require only locking the receiving Ractor, while yield/take involve complex rendezvous-style synchronization. By removing these primitives, we can simplify the specification and reduce implementation complexity—especially around features like `Ractor.select`, which are notoriously hard to get right. ### `Ractor.select` with ports We should wait for multiple port simultaneously so `Ractor.select()` should accept ports. Now `Ractor.select()` can also receiving and yielding the value, but if we remove the `#take` functionality, `Ractor.select` only need to support ports. ### Wait for termination `Ractor#take` is designed from an idea of getting termination result (like `Thread#value`). For this purpose, we can introduce `Ractor#join` or `Ractor#value` like Threads or we can keep the name `Ractor#take` for this purpose. We can make `Ractor#join` as a following pseudo-code: ```ruby class Ractor def join # wait for the termination register_termination_port port = Port.new port.receive end # when this ractor terminates, send a message to the registered port def monitor port @monitor_port = port end private def atexit @monitor_port << termination_message end end # there are some questions. # * can we register multiple ports? # * should we support `#join` and `#value` like threads? # or should we support only `#join` to return the value? # * or keep this name as `#take`? Ractor.new do 42 end.join #=> 42 (or true?) ``` It is very similar to `monitor` in Erlang or Elixir. We can also make a supervisor in Erlang like that: ```ruby sv_port = Ractor::Port.new rs = N.times.map do Ractor.new do do_something() end.monitor sv_port end while termination_notice = sv_port.receive p termination_notice end # With Ractor#take, we can write similar code if there is no Ractor.yield rs = N.times.map do Ractor.new do do_something() end end while r, msg = Ractor.select(*rs) p [r, msg] end ``` ## Discussion ### `send` with tag (symbols) If we force users to send a tagged message every time, we can achieve the same effect as Port concept, because a Port can be thought of as a combination of a tag and a destination Ractor. ```ruby r = Ractor.new do loop do tag, msg = Ractor.receive # return 2 values case tag when :TAG p [tag, msg] else # ignore end end end r.send :TAG, 42 r.send :TAGE, 84 # this typo and the message is silently ignored ``` However it has two issues: * If we make a typo in tag name, the message will be silently ignored. * The tag name may conflict with unrelated codes (libraries) ### `Ractor.yield` and `Ractor#take` with channel ractor If we want to leave the `.yield` and `#take`, we can emulate them with channel ractor. ```ruby class Ractor def initialize @yield_ractor = Ractor.new do takers = [] while tag, msg = Ractor.receive case tag when :register @takers << msg when :unregister @takers.delete msg when :yield @takers.pop << msg end end end end def self.yield obj @yield_ractor << [:yield, obj] end def take @yield_ractor << [:register, port = Ractor::Port.new] port.receive ensure @yield_ractor << [:unregister, port] end end ``` ### Opening and closing the port This proposal doesn't contain opening and closing the port, but we can discuss about it. To introduce this attribute, we need to manage which ports (tags) are opening. ## Implementation Now the native implementation is not finished, but we can implement it using the `Ractor.receive_if` mechanism, so we estimate that only a few weeks of work are needed to complete it. ## Summary This proposal introduces the following features and deprecations. * `Ractor::Port` * `Port#send(msg)` – sends a message to the creator of the port. * `Port#receive` – receives a message from the port. * A port is a lightweight data structure (a pair of a Ractor and a tag). * `Ractor#join` or `Ractor#value` – to wait for Ractor termination (like `Thread#join`) * `Ractor#monitor` – to observe when another Ractor terminates * Deprecations: * `Ractor#take` * `Ractor.yield` * `Ractor.receive_if` Thank you for reading this long proposal. If you have any use cases that cannot be addressed with `Ractor::Port`, I'd love to hear them. P.S. Thanks to mame for reviewing this proposal and suggesting that I use ChatGPT to improve the writing. -- https://bugs.ruby-lang.org/

2 7

[ruby-core:117392] [Ruby master Feature#20405] Inline comments
by nobu (Nobuyoshi Nakada) 08 Jul '25

08 Jul '25

Issue #20405 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #20405: Inline comments https://bugs.ruby-lang.org/issues/20405 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose a new inline comment syntax. ```ruby p (| This is a comment (| and nested one |) /:|) (:|) #=> :| ``` -- https://bugs.ruby-lang.org/

7 10

[ruby-core:115203] [Ruby master Bug#19981] bootstraptest/test_ractor.rb: Segmentation fault on arm32
by jaruga (Jun Aruga) 02 Jul '25

02 Jul '25

Issue #19981 has been reported by jaruga (Jun Aruga). ---------------------------------------- Bug #19981: bootstraptest/test_ractor.rb: Segmentation fault on arm32 https://bugs.ruby-lang.org/issues/19981 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I faced the following segmentation fault on Ubuntu jammy arm32 (emulated environment by `SETARCH='setarch linux32 --verbose --32bit'`) in both Travis CI arm64 [log](https://app.travis-ci.com/github/ruby/ruby/jobs/612418476#L2422 ) and RubyCI arm64-neoverse server. I tested it on the latest ruby master branch `14fa5e39d72c84d3e12e10dc5d77a6e6200c10f5`. I was able to reproduce this issue on RubyCI arm64-neoverse server, and prepared the reproducing script. So, you can try to debug on the server. It seems that the `-O3` flag triggered the issue. Because I didn't see the issue when Travis CI setting `- optflags=-O1` in `.travis.yml` on the current master branch. https://github.com/junaruga/report-ruby-ractor-segmentation-fault ``` + arm-linux-gnueabihf-gcc --version arm-linux-gnueabihf-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 + setarch linux32 --verbose --32bit make -s test Switching on ADDR_LIMIT_32BIT. Execute command `make'. Fstderr output is not empty <internal:ractor>:760: [BUG] Segmentation fault at 0x0000000c ruby 3.3.0dev (2023-10-30T09:27:06Z master 14fa5e39d7) [armv8l-linux-eabihf] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0021 e:000020 METHOD <internal:ractor>:760 c:0004 p:0008 s:0014 e:000013 BLOCK bootstraptest.test_ractor.rb_541_1260.rb:4 c:0003 p:0018 s:0011 e:000010 METHOD <internal:kernel>:187 c:0002 p:0004 s:0006 e:000005 BLOCK bootstraptest.test_ractor.rb_541_1260.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bootstraptest.test_ractor.rb_541_1260.rb:3:in `block in <main>' <internal:kernel>:187:in `loop' bootstraptest.test_ractor.rb_541_1260.rb:4:in `block (2 levels) in <main>' <internal:ractor>:760:in `yield' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ r0: 0x00000000 r1: 0x00000001 r2: 0x00000007 r3: 0x00000000 r4: 0x00c935c8 r5: 0x00000002 r6: 0x00000002 r7: 0x00000000 r8: 0x00000004 r9: 0x00c646b0 r10: 0x00000002 sp: 0xd5d91c90 fau: 0x0000000c -- Other runtime information ----------------------------------------------- * Loaded script: bootstraptest.test_ractor.rb_541_1260.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so 7 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so * Process memory map: 00640000-0093a000 r-xp 00000000 103:03 29263803 /home/jaruga/git/ruby/ruby/build/ruby 0094a000-0094e000 r--p 002fa000 103:03 29263803 /home/jaruga/git/ruby/ruby/build/ruby 0094e000-0094f000 rw-p 002fe000 103:03 29263803 /home/jaruga/git/ruby/ruby/build/ruby 0094f000-00956000 rw-p 00000000 00:00 0 00bf3000-00cba000 rw-p 00000000 00:00 0 [heap] d5700000-d5721000 rw-p 00000000 00:00 0 d5721000-d5800000 ---p 00000000 00:00 0 d5900000-d5921000 rw-p 00000000 00:00 0 d5921000-d5a00000 ---p 00000000 00:00 0 d5a00000-d5a21000 rw-p 00000000 00:00 0 d5a21000-d5b00000 ---p 00000000 00:00 0 d5b00000-d5b21000 rw-p 00000000 00:00 0 d5b21000-d5c00000 ---p 00000000 00:00 0 d5c5f000-d5c60000 ---p 00000000 00:00 0 d5c60000-d5c90000 rw-p 00000000 00:00 0 d5c9f000-d5ca0000 ---p 00000000 00:00 0 d5ca0000-d5cd0000 rw-p 00000000 00:00 0 d5cde000-d5cdf000 ---p 00000000 00:00 0 d5cdf000-d5cef000 rw-p 00000000 00:00 0 d5cef000-d5cf0000 ---p 00000000 00:00 0 d5cf0000-d5d81000 rw-p 00000000 00:00 0 d5d81000-d5d82000 ---p 00000000 00:00 0 d5d82000-d5e12000 rw-p 00000000 00:00 0 d5e12000-d5e13000 ---p 00000000 00:00 0 d5e13000-d5ea3000 rw-p 00000000 00:00 0 d5ea3000-d5ea4000 ---p 00000000 00:00 0 d5ea4000-d5f34000 rw-p 00000000 00:00 0 d5f34000-d5f35000 ---p 00000000 00:00 0 d5f35000-d5fc5000 rw-p 00000000 00:00 0 d5fc5000-d5fc6000 ---p 00000000 00:00 0 d5fc6000-d6056000 rw-p 00000000 00:00 0 d6056000-d6057000 ---p 00000000 00:00 0 d6057000-d60e7000 rw-p 00000000 00:00 0 d60e7000-d60e8000 ---p 00000000 00:00 0 d60e8000-d6178000 rw-p 00000000 00:00 0 d6178000-d6179000 ---p 00000000 00:00 0 d6179000-d6209000 rw-p 00000000 00:00 0 d6209000-d620a000 ---p 00000000 00:00 0 d620a000-d629a000 rw-p 00000000 00:00 0 d629a000-d629b000 ---p 00000000 00:00 0 d629b000-d632b000 rw-p 00000000 00:00 0 d632b000-d632c000 ---p 00000000 00:00 0 d632c000-f5d10000 rw-p 00000000 00:00 0 f5d10000-f5d12000 r-xp 00000000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d12000-f5d21000 ---p 00002000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d21000-f5d22000 r--p 00001000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d22000-f5d23000 rw-p 00002000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d30000-f5d32000 r-xp 00000000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d32000-f5d41000 ---p 00002000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d41000-f5d42000 r--p 00001000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d42000-f5d43000 rw-p 00002000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d4f000-f5d50000 ---p 00000000 00:00 0 f5d50000-f5d71000 rw-p 00000000 00:00 0 f5d71000-f5d72000 ---p 00000000 00:00 0 f5d72000-f5d93000 rw-p 00000000 00:00 0 f5d93000-f5d94000 ---p 00000000 00:00 0 f5d94000-f5db5000 rw-p 00000000 00:00 0 f5db5000-f5db6000 ---p 00000000 00:00 0 f5db6000-f5dd7000 rw-p 00000000 00:00 0 f5dd7000-f5dd8000 ---p 00000000 00:00 0 f5dd8000-f5df9000 rw-p 00000000 00:00 0 f5df9000-f5dfa000 ---p 00000000 00:00 0 f5dfa000-f5e1b000 rw-p 00000000 00:00 0 f5e1b000-f5e1c000 ---p 00000000 00:00 0 f5e1c000-f5e3d000 rw-p 00000000 00:00 0 f5e3d000-f5e3e000 ---p 00000000 00:00 0 f5e3e000-f5e5f000 rw-p 00000000 00:00 0 f5e5f000-f5e60000 ---p 00000000 00:00 0 f5e60000-f66a0000 rw-p 00000000 00:00 0 f66af000-f73b0000 rw-p 00000000 00:00 0 f73b5000-f7436000 rw-p 00000000 00:00 0 f7436000-f76b0000 r--p 0006f000 103:03 11802136 /usr/lib/locale/locale-archive f76b0000-f78b0000 r--p 00000000 103:03 11802136 /usr/lib/locale/locale-archive f78b0000-f79bc000 r-xp 00000000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79bc000-f79cc000 ---p 0010c000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79cc000-f79ce000 r--p 0010c000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79ce000-f79cf000 rw-p 0010e000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79cf000-f79d9000 rw-p 00000000 00:00 0 f79e0000-f7a21000 r-xp 00000000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a21000-f7a30000 ---p 00041000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a30000-f7a31000 r--p 00040000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a31000-f7a32000 rw-p 00041000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a40000-f7a6b000 r-xp 00000000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a6b000-f7a7b000 ---p 0002b000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a7b000-f7a7c000 r--p 0002b000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a7c000-f7a7d000 rw-p 0002c000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a7d000-f7a85000 rw-p 00000000 00:00 0 f7a88000-f7aa7000 r-xp 00000000 103:03 11670015 /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 f7aac000-f7ab3000 r--s 00000000 103:03 11670285 /usr/lib/arm-linux-gnueabihf/gconv/gconv-modules.cache f7ab3000-f7ab5000 rw-p 00000000 00:00 0 f7ab5000-f7ab6000 r-xp 00000000 00:00 0 [sigpage] f7ab6000-f7ab8000 r--p 0001e000 103:03 11670015 /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 f7ab8000-f7ab9000 rw-p 00020000 103:03 11670015 /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ff7dd000-fffdc000 rw-p 00000000 00:00 0 [stack] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120601] [Ruby master Bug#21024] Ruby including <cstdbool> generates compilation warning with GCC 15, header is deprecated in C++17,
by jprokop (Jarek Prokop) 02 Jul '25

02 Jul '25

Issue #21024 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #21024: Ruby including <cstdbool> generates compilation warning with GCC 15, header is deprecated in C++17, https://bugs.ruby-lang.org/issues/21024 * Author: jprokop (Jarek Prokop) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- C++ compiler in GCC 15 now generates a warning when trying to include `<cstdbool>`. This file is being included when compiling with C++ compiler from `include/ruby/internal/stdbool.h`. In C++, true, false and bool are keywords so including headers for boolean definitions should not be necessary. Alternatively, just including <stdbool.h> should be sufficient as that is what the `#include <cstdbool>` results in with GCC. Simplest fix is just deleting the lines that are including the file (see attached patch and comments 2 and 3 from downstream issue linked in the bottom section "Additional info"). Considering the wide array of compilers Ruby aims to support to be compiled with I wanted to make an issue here first to make sure there isn't a supported compiler that wouldn't agree with this approach. Reproduction: Obtain GCC 15, for Fedora Rawhide there is currently a repo of maintainer, I use it in Fedora Rawhide container (podman is replaceable for docker here): ``` host$ podman run -it --rm registry.fedoraproject.org/fedora:rawhide bash container# echo "[gcc_15] name=pre-release GCC 15 Repo baseurl=https://fedorapeople.org/~dmalcolm/gcc/gcc-15-mass-prebuild/$basear… type=rpm-md skip_if_unavailable=True gpgcheck=0 repo_gpgcheck=0 enabled=1 enabled_metadata=1" > /etc/yum.repos.d/gcc_15.repo container# dnf install --assumeyes g++ ruby-devel ``` ^ should install `g++-15.0.0` and `ruby.h` needed for the reproducer. Note: that baseurl is a custom space of a Fedora maintainer. Have a file named for example `main.cpp`: ``` cpp #include <ruby.h> int main(void) { return 0; } ``` Compile with GCC 15 ``` $ g++ main.cpp ``` Current behavior: Compiling throws warning: ``` $ g++ main.cpp In file included from /usr/include/ruby/internal/stdbool.h:30, from /usr/include/ruby/backward/2/bool.h:22, from /usr/include/ruby/defines.h:74, from /usr/include/ruby/ruby.h:25, from /usr/include/ruby.h:38, from reproducer.cpp:1: /usr/include/c++/15/cstdbool:48:6: warning: #warning "<cstdbool> is deprecated in C++17, remove the #include" [-Wcpp] 48 | # warning "<cstdbool> is deprecated in C++17, remove the #include" | ^~~~~~~ ``` Expected: Compilation throws no warnings and compiles the executable: ``` $ g++ reproducer.cpp $ echo $? 0 ``` Additional info: ``` $ g++ --version g++ (GCC) 15.0.0 20241203 (Red Hat 15.0.0-0) Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` This was met during recompilation of libdnf5 that includes `-Werror` in their compilation flags, See downstream discussion: https://bugzilla.redhat.com/show_bug.cgi?id=2336567 Considering the inclusion of the <cstdbool> throws me up to 5 years ago back ( https://github.com/ruby/ruby/blob/9e6e39c3512f7a962c44dc3729c98a0f8be90341/… ), I assume this warning will be the case with older rubies as well as newest master when using GCC 15. ---Files-------------------------------- 0001-Stop-including-cstdbool-in-include-ruby-internal-std.patch (869 Bytes) -- https://bugs.ruby-lang.org/

5 6

[ruby-core:120315] [Ruby master Bug#20968] `Array#fetch_values` unexpected method name in stack trace
by koic (Koichi ITO) 24 Jun '25

24 Jun '25

Issue #20968 has been reported by koic (Koichi ITO). ---------------------------------------- Bug #20968: `Array#fetch_values` unexpected method name in stack trace https://bugs.ruby-lang.org/issues/20968 * Author: koic (Koichi ITO) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-19T04:44:56Z master 2783868de2) +PRISM [x86_64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It seems that the current Ruby implementation is displaying unexpected method name in stack trace. ## Expected Similar to `Hash#fetch_values`, the method name `Array#fetch_values` is expected to be displayed in the stack trace. ```console $ ruby -e '{k: 42}.fetch_values(:unknown)' -e:1:in 'Hash#fetch_values': key not found: :unknown (KeyError) from -e:1:in '<main>' $ ruby -e '[1].fetch_values(42)' -e:1:in 'Array#fetch_values': index 42 outside of array bounds: -1...1 (IndexError) from -e:1:in '<main>' ``` ## Actual The stack trace displays the `Array#fetch` method, which user is not aware of, along with the `<internal.array>` stack trace. ```console $ ruby -e '[1].fetch_values(42)' <internal:array>:211:in 'Array#fetch': index 42 outside of array bounds: -1...1 (IndexError) from <internal:array>:211:in 'block in Array#fetch_values' from <internal:array>:211:in 'Array#map!' from <internal:array>:211:in 'Array#fetch_values' from -e:1:in '<main>' ``` It likely requires an approach such as implementing it in C, as suggested in https://github.com/ruby/ruby/pull/11555. -- https://bugs.ruby-lang.org/

10 21

[ruby-core:119041] [Ruby master Bug#20714] Handle optional dependencies in `bundled_gems.rb`
by Earlopain (A S) 23 Jun '25

23 Jun '25

Issue #20714 has been reported by Earlopain (A S). ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I've encountered a few places around bundled gems where the library doesn't care if the gem is available, but will still provide some functionallity if it is. The way to accomplish that right now seems to be by setting `$VERBOSE = nil` and resetting it later again to not bother the user with the warning about the gem. However, this has the effect of silencing the warning about other gems as well, that may not be prepared about the bundling. From `ruby/reline` for example: https://github.com/ruby/reline/blob/c90f08f7e308d2f1cdd7cfaf9939fe45ce546fd… Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f378… I propose to simply delay the warning to the next require. GitHub PR at ... -- https://bugs.ruby-lang.org/

5 30

[ruby-core:121498] [Ruby Bug#21210] IO::Buffer gets invalidated on GC compaction
by hanazuki (Kasumi Hanazuki) 18 Jun '25

18 Jun '25

Issue #21210 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21210: IO::Buffer gets invalidated on GC compaction https://bugs.ruby-lang.org/issues/21210 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 3.5.0dev (2025-04-01T16:11:01Z master 30e5e7c005) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- commit:6012145299cfa4ab561360c78710c7f2941a7e9d implemented compaction for `IO::Buffer`. It looks like this doesn't work well with an `IO::Buffer` that shares memory region with a String object. I think the problem is that an `IO::Buffer` holds the raw pointer to the String content, and now the content can be moved by GC when the String is embedded. ```ruby str = +"hello" buf = IO::Buffer.for(str) p buf.valid? GC.verify_compaction_references(expand_heap: true, toward: :empty) p buf.valid? #=> should be true ``` This example should print two trues. Actually: ``` % ./ruby -v --disable-gems test.rb ruby 3.5.0dev (2025-04-01T16:11:01Z master 30e5e7c005) +PRISM [x86_64-linux] true false ``` -- https://bugs.ruby-lang.org/

5 9