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

[ruby-core:121674] [Ruby Bug#21270] init_fast_fallback_inetsock_internal (default for TCPSocket.new/TCPSocket.open) isn't fiber aware
by drahosj (Jake Drahos) 16 Apr '25

16 Apr '25

Issue #21270 has been reported by drahosj (Jake Drahos). ---------------------------------------- Bug #21270: init_fast_fallback_inetsock_internal (default for TCPSocket.new/TCPSocket.open) isn't fiber aware https://bugs.ruby-lang.org/issues/21270 * Author: drahosj (Jake Drahos) * Status: Open * ruby -v: ruby 3.4.2 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Sockets created via `init_fast_fallback_inetsock_internal()` don't get a chance to call the scheduler hook(s). This is the default for connections created with TCPSocket.new unless fast_fallback is specified as false. Unfortunately, this has the effect of blocking all fibers in the thread if the initial connect() call hangs. TCPSocket.open() is used in Net::HTTP, which means the issue is present there. Here's a quick proof of concept. It works as intended as written (starts both fibers even though the first fiber hangs). Switching to the default `TCPSocket.new` call causes the whole thread to block. NOTE: Uses the "toy" scheduler from test/fiber/scheduler.rb, but the Socketry async gem is also affected (should affect all schedulers since the hook isn't called). ``` ruby require 'socket' require_relative 'scheduler' Fiber.set_scheduler(Scheduler.new) puts "#{Fiber.current.object_id}: Main fiber" Fiber.schedule do puts "#{Fiber.current.object_id}: Creating socket" # Assuming that attempting to connect to example.com on port 12345 hangs # Default causes the scheduler to hang and never create second fiber # TCPSocket.new("example.com", 12345) TCPSocket.new("example.com", 12345, fast_fallback: false) puts "#{Fiber.current.object_id}: Connected" end Fiber.schedule do puts "#{Fiber.current.object_id}: Sleeping" sleep 2 puts "#{Fiber.current.object_id}: Done sleeping" end puts "#{Fiber.current.object_id}: Both fibers started" ``` Running the working PoC: ``` shell $ ruby async-connect.rb 16: Main fiber 24: Creating socket 32: Sleeping 16: Both fibers started 32: Done sleeping [Hangs here until the socket connection eventually times out] ``` However, without `fast_fallback: false`, the `TCPSocket.new` call will block the entire scheduler, never creating the second fiber: ``` shell $ ruby async-request.rb 16: Main fiber 24: Creating socket [Hangs here until the connect times out] ``` Here's a stack dump of the hung version: ``` #0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56 #1 0x00007fc9e4c9581c in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=0, nr=270) at cancellation.c:49 #2 0x00007fc9e4c95871 in __syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=0, nr=270) at cancellation.c:75 #3 0x00007fc9e4d1af07 in __GI___select (nfds=<optimized out>, readfds=<optimized out>, writefds=<optimized out>, exceptfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/select.c:69 #4 0x00007fc9e5233c9f in rb_fd_select (n=<optimized out>, readfds=<optimized out>, writefds=<optimized out>, exceptfds=<optimized out>, timeout=<optimized out>) at /usr/src/debug/ruby-3.4.2/thread.c:4163 #5 0x00007fc9e5236cc6 in native_fd_select (n=<optimized out>, readfds=<optimized out>, writefds=<optimized out>, exceptfds=<optimized out>, timeout=<optimized out>, th=<optimized out>) at /usr/src/debug/ruby-3.4.2/thread_pthread.c:2380 #6 do_select (p=p@entry=140504668626880) at /usr/src/debug/ruby-3.4.2/thread.c:4314 #7 0x00007fc9e50e7416 in rb_ensure (b_proc=0x7fc9e52368b0 <do_select>, data1=140504668626880, e_proc=0x7fc9e5232440 <select_set_free>, data2=140504668626880) at /usr/src/debug/ruby-3.4.2/eval.c:1074 #8 0x00007fc9e523700f in rb_thread_fd_select (max=max@entry=21, read=read@entry=0x7fc9cadce430, write=write@entry=0x7fc9cadce440, except=except@entry=0x0, timeout=timeout@entry=0x0) at /usr/src/debug/ruby-3.4.2/thread.c:4374 #9 0x00007fc9c97b5050 in init_fast_fallback_inetsock_internal (v=v@entry=140504668627872) at /usr/src/debug/ruby-3.4.2/ext/socket/ipsocket.c:894 #10 0x00007fc9e50e7416 in rb_ensure ( b_proc=b_proc@entry=0x7fc9c97b4950 <init_fast_fallback_inetsock_internal>, data1=data1@entry=140504668627872, e_proc=e_proc@entry=0x7fc9c97b7880 <fast_fallback_inetsock_cleanup>, data2=data2@entry=140504668627872) at /usr/src/debug/ruby-3.4.2/eval.c:1074 #11 0x00007fc9c97b7f3c in rsock_init_inetsock (self=self@entry=140504646018560, remote_host=remote_host@entry=140504646018640, remote_serv=remote_serv@entry=24691, local_host=local_host@entry=4, local_serv=local_serv@entry=4, type=type@entry=0, resolv_timeout=<optimized out>, connect_timeout=<optimized out>, fast_fallback=<optimized out>, test_mode_settings=<optimized out>) at /usr/src/debug/ruby-3.4.2/ext/socket/ipsocket.c:1285 #12 0x00007fc9c97b8216 in tcp_init (argc=<optimized out>, argv=<optimized out>, sock=140504646018560) at /usr/src/debug/ruby-3.4.2/ext/socket/tcpsocket.c:76 ``` `tcp_init` is the TCPSocket#initialize defined in tcpsocket.c, which just calls into the pure-C stack without ever backing out to check io_wait as is done in other socket-creation code path. It looks like the main difference is that init_fast_fallback_inetsock_internal hasn't been updated to be Fiber-aware (eg. init_inetsock_internal calls `rsock_connect` which uses the Fiber-aware `wait_connectable`), but `init_fast_fallback_inetsock_internal` is hard-coded to use thread stuff. In case anybody stumbles across this wondering why `Net::HTTP` sometimes blocks the Fiber scheduler during connect(), here's a quick workaround by hacking default `fast_fallback: false` into `TCPSocket.open`: ``` ruby orig_open = TCPSocket.method(:open) TCPSocket.define_singleton_method(:open) do |*args, **kwargs, &block| kwargs[:fast_fallback] ||= false orig_open.call(*args, **kwargs, &block) end ``` A slightly fancier workaround would be to have TCPSocket#initialize default `fast_fallback` to false if the current scheduler is non-nil. That would get rid of unexpected scheduler blocking without requiring a rewrite of the fast fallback code to be fiber-aware. I'm not sure if that's as trivial to implement in a c-defined method as it is in a native Ruby definition. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121507] [Ruby Bug#21212] IO::Buffer can be freed while its slice is locked
by hanazuki (Kasumi Hanazuki) 16 Apr '25

16 Apr '25

Issue #21212 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21212: IO::Buffer can be freed while its slice is locked https://bugs.ruby-lang.org/issues/21212 * 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 ---------------------------------------- ```ruby buffer = IO::Buffer.new(100) slice = buffer.slice buffer.locked do buffer.free rescue p $! #=> IO::Buffer::LockedError (expected) end slice.locked do p slice.locked? #=> true (expected) p buffer.locked? #=> false (what should this be?) slice.free rescue p $! #=> IO::Buffer::LockedError (expected) buffer.free # Should we allow this? slice.set_value(:U8, 0, 42) # raises IO::Buffer::InvalidatedError (surprising!) end ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121540] [Ruby Feature#21216] Implement Set as a core class
by jeremyevans0 (Jeremy Evans) 14 Apr '25

14 Apr '25

Issue #21216 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21216: Implement Set as a core class https://bugs.ruby-lang.org/issues/21216 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- I propose to implement Set as a core class. Set has been an autoloaded standard library since Ruby 3.2. The standard library Set is less efficient than it could be, as it uses Hash for storage, which stores unnecessary values for each item in the set. I've submitted a pull request that implements Set as a core class: https://github.com/ruby/ruby/pull/13074 Implementation details for the pull request: * Core Set uses a modified version of `st_table`, named `set_table`. Other than `s/st_/set_/`, the main difference is that the stored records do not have values, making them 1/3 smaller. `st_table_entry` stores `hash`, `key`, and `record` (value), while `set_table_entry` only stores `hash` and `key`. This results in large sets using ~33% less memory compared to stdlib Set. For small sets, core Set uses 20% less memory (160 bytes, while stdlib set uses 40 for Set and 160 for Hash). * All methods are implemented as cfuncs, except the pretty_print methods, which were moved to `lib/pp.rb` (which is where the pretty_print methods for other core classes are defined). As is typical for core classes, internal calls call C functions and not Ruby methods. For example, to check if something is a Set, `rb_obj_is_kind_of` is used, instead of calling `is_a?(Set)` on the related object. * Almost all methods use the same algorithm that the pure-Ruby implementation used. The exception is when calling `Set#divide` with a block with 2-arity. stdlib Set used a lazy-loaded tsort to implement this. I developed an algorithm that only allocates a single intermediate hash and does not need tsort. * The `flatten_merge` protected method is no longer necessary, so it is not implemented (it could be). * Similar to Hash/Array, subclasses of Set are no longer reflected in `inspect` output. * Documentation from stdlib Set was moved to core Set, with minor updates. I developed a comprehensive benchmark suite for all public Set methods (results attached). As you would expect, core Set is faster than stdlib Set in the majority of cases (90%), and multiple times faster in many cases (47% of cases are at least 2x faster, 31% of cases are at least 4x faster). There are a few cases where it is significantly slower: * `Set.new` with no arguments (~1.6x) * `Set#compare_by_identity` for small sets (~1.3x) * `Set#clone` for small sets (~1.5x) * `Set#dup` for small sets (~1.7x) Some of these are slower as Set does not currently use the AR table optimization that Hash does, so a new set_table is initialized for each Set. I'm not sure it's worth the complexity to have an AR table-like optimization for small sets (for hashes it makes sense, as small hashes are used everywhere in Ruby). The rbs and repl_type_completor bundled gems will need updates to support core Set. The pull request marks them as allowed failures. This passes all set tests with no changes. The following specs needed modification: * Modifying frozen set error message (changed for the better) * `Set#divide` when passed a 2-arity block no longer yields the same object as both the first and second argument (this seems like an issue with the previous implementation). * Set-like objects that override `is_a?` such that `is_a?(Set)` return `true` are no longer treated as Set instances. * `Set.allocate.hash` is no longer the same as `nil.hash` * `Set#join` no longer calls `Set#to_a` (it calls the underlying C function). * `Set#flatten_merge` protected method is not implemented. Previously, `set.rb` added a `SortedSet` autoload, which loads `set/sorted_set.rb`. This replaces the `Set` autoload in `prelude.rb` with a `SortedSet` autoload, but I recommend removing it and `set/sorted_set.rb` before the release of Ruby 3.5. This moves `test/set/test_set.rb` to `test/ruby/test_set.rb`, reflecting that switch to a core class. This does not move the spec files, as I'm not sure how they should be handled currently. Eventually, the set spec files should be moved to `spec/ruby/core`, but maybe not until Ruby 3.4 is no longer supported. This does not add any functions to the C-API (all functions in `set.c` are static). I think such functions can be added later as we find other places in core where it makes sense to use a Set instead of a Hash or Array, or as we get requests from extension authors. This is partially inspired by changes in Python 2.4 (released in November 2004), which changed the set implementation from a standard library class backed by a hash (dict in Python terms) to having it as a core class. ---Files-------------------------------- set-benchmark-output.txt (74.9 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120043] [Ruby master Bug#20919] IO#seek does not clear the character buffer in some cases while transcoding
by javanthropus (Jeremy Bopp) 14 Apr '25

14 Apr '25

Issue #20919 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20919: IO#seek does not clear the character buffer in some cases while transcoding https://bugs.ruby-lang.org/issues/20919 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.4.0dev (2024-11-28T12:38:16Z master 3af1a04741) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When transcoding characters, `IO#seek` only clears the internal character buffer if `IO#getc` is called first: ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-16le')) # Character buffer WILL NOT be cleared f.seek(2, :SET) f.getc # => 'a'.encode('utf-16le'); should be '2'.encode('utf-16le') end Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind # Added a call to #getc here f.getc f.ungetc('a'.encode('utf-16le')) # Character buffer WILL be cleared now f.seek(2, :SET) f.getc # => '2'.encode('utf-16le') end ``` -- https://bugs.ruby-lang.org/

2 6

[ruby-core:120906] [Ruby master Feature#21121] Ractor channels
by luke-gru (Luke Gruber) 14 Apr '25

14 Apr '25

Issue #21121 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #21121: Ractor channels https://bugs.ruby-lang.org/issues/21121 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- # Motivation: It would be nice be able to `Ractor.yield` in a non-blocking way. Right now a `Ractor.yield` blocks until another ractor calls `r.take` on the yielding ractor. This is bad in the following scenario: ```ruby main = Ractor.current rs = 10.times.map do Ractor.new(main) do |m| ret = [] loop do # do a bunch of work that takes a while, then: begin obj = m.take rescue Ractor::ClosedError end if obj ret << obj else break end end ret end end 50.times do |i| Ractor.yield(i) # this will block until some ractor calls take on us, but it could be a while if there is processing before the `take` call. end main.close_outgoing # Ideally, we could do some work in main ractor that takes some time while the other ractors do their processing. But we're blocking right now # during all the calls to `Ractor.yield`. # Finally, get the results while rs.any? r, obj = Ractor.select(*rs) $stderr.puts "Ractor #{r} got #{obj}" rs.delete(r) end ``` I'd like other ractors to be able to do work in a "fire and forget" kind of way. It isn't possible right now due to the limitations of `Ractor.yield` and `Ractor#take`. What we need is some kind of `yield` buffer so the yielder doesn't block. I propose that Ractor channels would allow this type of programming to work. ## Example using channels: ```ruby chan = Ractor::Channel.new # We could specify buffer size like Go or it could be dynamically growable rs = 10.times.map do Ractor.new(chan) do |c| ret = [] loop do obj, _closed = c.receive # returns `[nil, true]` if `c` is closed and its buffer is empty. It blocks if the buffer is empty and `c` is not closed. if obj ret << obj else break end end ret end end 50.times do |i| chan.send(i) # non-blocking, fills a buffer and only wakes a receiver if there is one end chan.close # Do some processing while ractors do their work. # Then, collect the results while rs.any? r, obj = Ractor.select(*rs) puts "Ractor #{r} got #{obj}" rs.delete(r) end ``` With an API similar to this, we could have "fire and forget" processing with ractors. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:121611] [Ruby Bug#21261] Backport fix for crash in TCPSocket.open(..., nil)
by jhawthorn (John Hawthorn) 14 Apr '25

14 Apr '25

Issue #21261 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21261: Backport fix for crash in TCPSocket.open(..., nil) https://bugs.ruby-lang.org/issues/21261 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- https://github.com/ruby/ruby/pull/12934 https://github.com/ruby/ruby/commit/b148dfef5aa208cafa28626fd84c9762bfdfe0ac -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121519] [Ruby Bug#21214] VmRSS consumption increase in Ruby 3.4.2 vs Ruby 3.3.6
by mood_vuadensl (LOIC VUADENS) 14 Apr '25

14 Apr '25

Issue #21214 has been reported by mood_vuadensl (LOIC VUADENS). ---------------------------------------- Bug #21214: VmRSS consumption increase in Ruby 3.4.2 vs Ruby 3.3.6 https://bugs.ruby-lang.org/issues/21214 * Author: mood_vuadensl (LOIC VUADENS) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello, After updating Ruby from 3.3.6 to 3.4.2, our batch-style (not based on rails) application exceed its memory limit. Below is an example script that runs on both versions and demonstrates that 'ObjectSpace.memsize_of_all' does not vary significantly, but the OS 'VmRSS' increases significantly. Do you have any information on what might have caused this increase or any lead to reduce this peak? Here is the result on a Linux 5.15.167.4-microsoft-standard-WSL2: with Ruby 3.3.6: ```text ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] On start on 3.3.6 - OS VmRSS: 20628 kB - ObjectSpace.memsize_of_all: 1.73MB On first full workload: 0 - OS VmRSS: 521504 kB - ObjectSpace.memsize_of_all: 289.74MB .... After workload - OS VmRSS: 573484 kB - ObjectSpace.memsize_of_all: 251.59MB After data released - OS VmRSS: 487404 kB - ObjectSpace.memsize_of_all: 1.73MB ``` and 3.4.2: ```text ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] On start on 3.4.2 - OS VmRSS: 13132 kB - ObjectSpace.memsize_of_all: 1.71MB On first full workload: 0 - OS VmRSS: 612508 kB - ObjectSpace.memsize_of_all: 315.47MB .... After workload - OS VmRSS: 725356 kB - ObjectSpace.memsize_of_all: 251.57MB After data released - OS VmRSS: 616364 kB - ObjectSpace.memsize_of_all: 1.71MB ``` and the associated script: ```ruby require 'objspace' BYTES_TO_MB = 1024 * 1024 $stdout.sync = true srand(1) # Declare supporting code def print_info(context) puts context GC.start os_mem_metric = File.readlines("/proc/#{Process.pid}/status").find { |line| line.start_with?('VmRSS:') } puts "- OS #{os_mem_metric}" puts "- ObjectSpace.memsize_of_all: #{(ObjectSpace.memsize_of_all.to_f/BYTES_TO_MB).round(2)}MB" puts '' end def random_string = Array.new(10) { rand(99) }.join class A def initialize @a = random_string @b = rand(1000000000000) end end # Main print_info "On start on #{RUBY_VERSION}" objects = Array.new(1_000_000) { A.new } hashes = Array.new(250_000) { { a: rand(100_000), b: rand(100_000), c: random_string } } arrays = Array.new(250_000) { [rand(100_000), rand(100_000), random_string] } keep_if = ->(index) { index.even? } 0.upto(3) do |i_loop| objects = objects.map.with_index { |obj, index| keep_if.call(index) ? obj : A.new } hashes = hashes.map.with_index { |obj, index| keep_if.call(index) ? obj : { a: rand(10_000), b: rand(10_000) } } arrays = arrays.map.with_index { |obj, index| keep_if.call(index) ? obj : [rand(10_000), rand(10_000)] } print_info " On first full workload: #{i_loop}" if i_loop.zero? keep_if = ->(index) { index.odd? } if i_loop == 1 keep_if = ->(index) { index%5 == 0 } if i_loop == 2 keep_if = ->(index) { index.even? } if i_loop == 3 print '.' end puts '' print_info 'After workload' objects.clear hashes.clear arrays.clear print_info 'After data released' ``` Regards -- https://bugs.ruby-lang.org/

4 8

[ruby-core:121542] [Ruby Bug#21217] Integer.sqrt produces wrong results even on input <= 1e18
by hjroh0315 (Matthew Roh) 14 Apr '25

14 Apr '25

Issue #21217 has been reported by hjroh0315 (Matthew Roh). ---------------------------------------- Bug #21217: Integer.sqrt produces wrong results even on input <= 1e18 https://bugs.ruby-lang.org/issues/21217 * Author: hjroh0315 (Matthew Roh) * Status: Open * ruby -v: 3.2.2 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello, I have been so far using Ruby in various online judge platforms that support it, while recently I discovered a very intriguing issue regarding `Integer.sqrt`. Please refer to the two following verdicts on this recent problem that requires the usage of such a function: - [Python 3.11.4](https://atcoder.jp/contests/abc400/submissions/64536518) - [Ruby 3.2.2](https://atcoder.jp/contests/abc400/submissions/64577995) The input constraints of the problem guarantees that n <= 1e18, and judging from the fact that [implementing the same functionality using binary search](https://atcoder.jp/contests/abc400/submissions/64578791) gets a correct verdict, it is quite apparent that `Integer.sqrt` is producing wrong results even on input <= 1e18. While I have not been able to reproduce this issue locally, it is not hard to imagine that the latest version of Ruby might still have the same issue considering there has been no similar bugfix request in the last 2~3 years. I believe an easy way to fix this bug is to simply adjust the result to the correct one using a linear search (`while(x*x<=n)x++; while(x*x>n)x--;`) in the end. Thank you for reading the bugfix request, and for your continued effort on maintaining the language. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:121500] [Ruby Bug#21211] Incomplete Backtrace for Socket Errors in Ruby 3.4+
by ioquatix (Samuel Williams) 14 Apr '25

14 Apr '25

Issue #21211 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21211: Incomplete Backtrace for Socket Errors in Ruby 3.4+ https://bugs.ruby-lang.org/issues/21211 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: shioimm (Misaki Shioi) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When invoking `Socket.tcp` with an invalid hostname (e.g., "foo.bar") in Ruby 3.4, the error raised does not provide a complete backtrace indicating the original application code that made the call. This behavior differs from Ruby 3.3 where the backtrace includes the relevant context. ## Steps to Reproduce: Run the following code in an IRB session with Ruby 3.4.2: ```ruby require 'socket' Socket.tcp("foo.bar", 80) ``` Observe the error output: ``` /opt/rubies/3.4.2/lib/ruby/3.4.0/socket.rb:955:in 'Addrinfo.getaddrinfo': getaddrinfo: nodename nor servname provided, or not known (Socket::ResolutionError) from /opt/rubies/3.4.2/lib/ruby/3.4.0/socket.rb:955:in 'Socket.resolve_hostname' from /opt/rubies/3.4.2/lib/ruby/3.4.0/socket.rb:711:in 'block (2 levels) in Socket.tcp_with_fast_fallback' ``` ## Expected Behavior: The error backtrace should include the original application code that triggered the socket call, providing better context for debugging. ``` /Users/samuel/.rubies/ruby-3.1.6/lib/ruby/3.1.0/socket.rb:227:in `getaddrinfo': getaddrinfo: nodename nor servname provided, or not known (SocketError) from /Users/samuel/.rubies/ruby-3.1.6/lib/ruby/3.1.0/socket.rb:227:in `foreach' from /Users/samuel/.rubies/ruby-3.1.6/lib/ruby/3.1.0/socket.rb:632:in `tcp' from (irb):2:in `<main>' from /Users/samuel/.rubies/ruby-3.1.6/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>' from /Users/samuel/.rubies/ruby-3.1.6/bin/irb:25:in `load' from /Users/samuel/.rubies/ruby-3.1.6/bin/irb:25:in `<main>' ``` The change in how error backtraces are reported in Ruby 3.4 diminishes the ability to trace errors to user-level code, impacting debugging efforts. Can we restore or improve the backtrace reporting for socket-related errors. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121302] [Ruby master Bug#21183] Ractor error with Prism::VERSION
by getajobmike (Mike Perham) 14 Apr '25

14 Apr '25

Issue #21183 has been reported by getajobmike (Mike Perham). ---------------------------------------- Bug #21183: Ractor error with Prism::VERSION https://bugs.ruby-lang.org/issues/21183 * Author: getajobmike (Mike Perham) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/error_highlight/base.rb:88:in 'ErrorHighlight.prism_find': can not access non-shareable objects in constant Prism::VERSION by non-main Ractor. (Ractor::IsolationError) #<Thread:0x000000011e89fbb0 run> terminated with exception (report_on_exception is true): from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/error_highlight/base.rb:65:in 'ErrorHighlight.spot' /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/error_highlight/base.rb:88:in 'ErrorHighlight.prism_find' from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/error_highlight/core_ext.rb:6:in 'ErrorHighlight::CoreExt#generate_snippet' from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/error_highlight/core_ext.rb:14:in 'ErrorHighlight::CoreExt#detailed_message' : from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/did_you_mean/core_ext/name_error.rb:24:in 'DidYouMean::Correctable#detailed_message' ``` -- https://bugs.ruby-lang.org/

5 4