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

[ruby-core:122703] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by matz (Yukihiro Matsumoto) 10 Jul '25

10 Jul '25

Issue #17473 has been updated by matz (Yukihiro Matsumoto). Regarding the original proposal, I'd accept making Pathname built-in, considering its wide accepting among the community, especially with Rails. Whether to keep the built-in Pathname in the C implementation or implement it in Ruby is left for future discussion. Matz. ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-113980 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: akr (Akira Tanaka) ---------------------------------------- pathname is one of most useful utility class of Ruby. I'm happy to use Pathname without require it. Any thought? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122685] [Ruby Bug#21505] [Ractor] calling exit from non-main ractor will hang if main ractor waits on it
by luke-gru (Luke Gruber) 09 Jul '25

09 Jul '25

Issue #21505 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21505: [Ractor] calling exit from non-main ractor will hang if main ractor waits on it https://bugs.ruby-lang.org/issues/21505 * Author: luke-gru (Luke Gruber) * Status: Open * Assignee: ractor * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby r = Ractor.new do exit end r.join # hangs ``` Should `exit` be allowed in ractors? It would be easiest to disallow, as the code might be tricky if we allow it. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122698] [Ruby Bug#21506] Fix timeout in `Addrinfo.getaddrinfo` to actually take effect
by shioimm (Misaki Shioi) 09 Jul '25

09 Jul '25

Issue #21506 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Bug #21506: Fix timeout in `Addrinfo.getaddrinfo` to actually take effect https://bugs.ruby-lang.org/issues/21506 * Author: shioimm (Misaki Shioi) * Status: Open * Assignee: shioimm (Misaki Shioi) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ### Description This change fixes an issue where the timeout option in `Addrinfo.getaddrinfo` was not functioning as expected. https://github.com/ruby/ruby/pull/13803/files It also addresses a related issue where specifying `fast_fallback: false` with `resolv_timeout` for `Socket.tcp` and`TCPSocket.new` would have no effect. ### Background The timeout option was originally introduced in: https://github.com/ruby/ruby/commit/6382f5cc91ac9e36776bc854632d9a1237250da7 However, the value was noy used in current implementation: https://github.com/ruby/ruby/blob/3f0e0d5c8bf9046aee7f262a3f9a7524d51aaf3e/… Therefore, even if a timeout is specified and the duration elapses during name resolution, nothing happens. This is clearly not the intended behavior. ### What this change does `Addrinfo.getaddrinfo` has been made interruptible as of Feature #19965. This change uses that feature to interrupt name resolution when the specified timeout period elapses, raising a user-specified timeout error. The timeout can be specified in milliseconds. ### Notes The same issue affects `Socket.tcp` and `TCPSocket.new` when `resolv_timeout` is set along with `fast_fallback: false`. `resolv_timeout` was introduced in the following commits: https://github.com/ruby/ruby/commit/6382f5cc91ac9e36776bc854632d9a1237250da7 https://github.com/ruby/ruby/commit/511fe23fa2bdf1f17faa91e0558be47b5bb62b2a The reason is that with `fast_fallback: false`, these methods internally call the same `rsock_getaddrinfo()` as `Addrinfo.getaddrinfo`. This change addresses that as well. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122411] [Ruby Bug#21396] Set#initialize should call Set#add on items passed in
by tenderlovemaking (Aaron Patterson) 09 Jul '25

09 Jul '25

Issue #21396 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21396: Set#initialize should call Set#add on items passed in https://bugs.ruby-lang.org/issues/21396 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby class Foo < Set def add(item) = super(item.bytesize) end x = Foo.new(["foo"]) p x p x.include?(3) ``` On Ruby 3.4 the output is this: ``` > ruby -v test.rb ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] #<Foo: {3}> true ``` On Ruby master the output is this: ``` > make run ./miniruby -I./lib -I. -I.ext/common -r./arm64-darwin24-fake ./test.rb #<Set: {"foo"}> false ``` The bug is that `initialize` is not calling `add` for the elements passed in, so the subclass doesn't get a chance to change them. I've sent a PR here: https://github.com/ruby/ruby/pull/13518 -- https://bugs.ruby-lang.org/

5 11

[ruby-core:122303] [Ruby Bug#21375] Set[] does not call #initialize
by Ethan (Ethan -) 08 Jul '25

08 Jul '25

Issue #21375 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #21375: Set[] does not call #initialize https://bugs.ruby-lang.org/issues/21375 * Author: Ethan (Ethan -) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-26T17:42:35Z master 909a0daab6) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I have a subclass of Set that overrides #initialize. Following #21216, .new does call #initialize but .[] does not. ```ruby class MySet < Set def initialize(enum = nil) compare_by_identity super end end MySet.new.compare_by_identity? # => true MySet[].compare_by_identity? # => false ``` -- https://bugs.ruby-lang.org/

6 6

[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:122238] [Ruby Bug#21362] Namespace: Inline method caches poisoned with builtins
by jhawthorn (John Hawthorn) 08 Jul '25

08 Jul '25

Issue #21362 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21362: Namespace: Inline method caches poisoned with builtins https://bugs.ruby-lang.org/issues/21362 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` ruby File.write("/tmp/ntest.rb", <<~'RUBY') class Integer def succ = self + 2 end module Test def self.run = 10.times.to_a end RUBY module Test def self.run = 10.times.to_a end ns = Namespace.new ns.require("/tmp/ntest.rb") p namespaced: ns::Test.run p main: Test.run ``` ``` RUBY_NAMESPACE=1 ruby test_namespace_succ.rb ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. {namespaced: [0, 2, 4, 6, 8]} {main: [0, 2, 4, 6, 8]} ``` What's happening here is that we have a number of "builtin" Ruby files which are loaded during the VM boot. The instruction sequences and method definitions from these files end up as part of the "root" namespace. However this iseq can still include inline caches, and in this example we see the cache poisoned by being run in a namespace with succ redefined. I was surprised by this, I expected it to call using the "root" namespace. It's definitely a strange edge-case to redefine `succ`, but the namespace semantics here are important because how this is defined impacts how useful builtins can be: - If builtins inherit their namespace from the caller, then they cannot use inline caches (or inline caches must always check for namespace validity) and also cannot be JIT compiled (unless the JIT also checks for namespace validity, and given the complexity of rb_current_namespace, it would be very undesirable). This is very bad as converting C code to builtin Ruby has been important for getting better performance. - If builtins make calls using the "root" namespace, inline caching and the JIT should work (actually there may be advantages to both since the namespace is mostly immutable). However this will limit what we are able to move from C to Ruby, as it wouldn't be possible to have the same semantics as C methods (where the caller's namespace is used). -- https://bugs.ruby-lang.org/

4 3

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

07 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:122659] [Ruby Bug#21502] Segfault with 3.2.8 with frida gem
by MatzFan (Brian Cohen) 06 Jul '25

06 Jul '25

Issue #21502 has been reported by MatzFan (Brian Cohen). ---------------------------------------- Bug #21502: Segfault with 3.2.8 with frida gem https://bugs.ruby-lang.org/issues/21502 * Author: MatzFan (Brian Cohen) * Status: Open * ruby -v: 3.2.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've just seen a segfault executing the following code in irb with the frida gem: ``` shell $ rbenv versions * 3.2.8 (set by /home/me/.rbenv/version) $ gem install frida Fetching frida-0.1.1.gem Building native extensions. This could take a while... frida has been successfully compiled and installed, frida-core is no longer required and can be safely removed. Successfully installed frida-0.1.1 1 gem installed $ irb irb(main):001:0> require 'frida' => true irb(main):002:0> mgr = Frida::DeviceManager.new => #<CFrida::DeviceManager:0x00007fd91dbf49a8> irb(main):003:0> devices = mgr.enumerate_devices => [#<Device: id="local", name="Local System", type="local">, ... irb(main):004:0> device = devices.last => #<Device: id="emulator-5554", name="Android Emulator 5554", type="usb"> irb(main):005:0> device.is_lost => false irb(main):006:0> device.enumerate_applications (irb):6: [BUG] Segmentation fault at 0x0000000000020000 ... see attached backtrace ``` Happy to provide more information about my system setup if required. ---Files-------------------------------- segfault_3.2.8 (46.7 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122652] [Ruby Bug#18940] Ruby Ractor fails with IOError when handling higher concurrency
by jhawthorn (John Hawthorn) 04 Jul '25

04 Jul '25

Issue #18940 has been updated by jhawthorn (John Hawthorn). Status changed from Assigned to Closed This doesn't reproduce on my machine on 3.5dev, and there have been a number of improvements to Ractors likely to have solved this. Please reopen if that's not the case :) ---------------------------------------- Bug #18940: Ruby Ractor fails with IOError when handling higher concurrency https://bugs.ruby-lang.org/issues/18940#change-113932 * Author: brodock (Gabriel Mazetto) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.2.0dev (2022-07-26T16:40:03Z master 3b1ed03d8c) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Reproduction server: ``` require 'socket' # Set based on CPU count CONCURRENCY = 8 server = TCPServer.new(8080) workers = CONCURRENCY.times.map do Ractor.new do loop do # receive TCPSocket session = Ractor.recv request = session.gets puts request session.print "HTTP/1.1 200\r\n" session.print "Content-Type: text/html\r\n" session.print "\r\n" session.print "Hello world! Current time is #{Time.now}" session.close end end end loop do conn, _ = server.accept # pass TCPSocket to one of the workers workers.sample.send(conn, move: true) end ``` run apache benchmark against code above: ``` ab -n 20000 -c 20 http://localhost:8080/ ``` or run using hey (https://github.com/rakyll/hey) ``` hey -n 20000 -c 20 http://localhost:8080/ ``` you should see something like this on the benchmark tool side: ``` Summary: Total: 32.9538 secs Slowest: 2.6317 secs Fastest: 0.0002 secs Average: 0.0331 secs Requests/sec: 606.9098 Response time histogram: 0.000 [1] | 0.263 [16968] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 0.527 [1740] |■■■■ 0.790 [0] | 1.053 [0] | 1.316 [0] | 1.579 [0] | 1.842 [0] | 2.105 [20] | 2.369 [0] | 2.632 [6] | Latency distribution: 10% in 0.0008 secs 25% in 0.0010 secs 50% in 0.0012 secs 75% in 0.0016 secs 90% in 0.0075 secs 95% in 0.3101 secs 99% in 0.3175 secs Details (average, fastest, slowest): DNS+dialup: 0.0322 secs, 0.0002 secs, 2.6317 secs DNS-lookup: 0.0006 secs, 0.0000 secs, 0.0127 secs req write: 0.0001 secs, 0.0000 secs, 0.0095 secs resp wait: 0.0007 secs, 0.0000 secs, 0.0140 secs resp read: 0.0001 secs, 0.0000 secs, 0.0088 secs Status code distribution: [200] 18735 responses Error distribution: [1231] Get "http://localhost:8080/": dial tcp [::1]:8080: connect: connection refused [16] Get "http://localhost:8080/": dial tcp [::1]:8080: connect: connection reset by peer [1] Get "http://localhost:8080/": net/http: HTTP/1.x transport connection broken: unexpected EOF [1] Get "http://localhost:8080/": read tcp 127.0.0.1:57078->127.0.0.1:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57054->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57058->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57059->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57062->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57067->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57068->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57069->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57070->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57071->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57072->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57075->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57076->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57087->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57088->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57089->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57090->[::1]:8080: read: connection reset by peer ``` and this on the ruby process: ``` ... GET / HTTP/1.1 GET / HTTP/1.1 #<Thread:0x0000000100fbf6e8 run> terminated with exception (report_on_exception is true): ractor.rb:21:in `write': GET / HTTP/1.1 uninitialized stream (IOError) from ractor.rb:21:in `print' from ractor.rb:21:in `block (3 levels) in <main>' from ractor.rb:11:in `loop' from ractor.rb:11:in `block (2 levels) in <main>' GET / HTTP/1.1 GET / HTTP/1.1 ``` -- https://bugs.ruby-lang.org/

1 0