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

[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

[ruby-core:121489] [Ruby Bug#21207] CSV gem not installing in head
by MSP-Greg (Greg L) 14 Apr '25

14 Apr '25

Issue #21207 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21207: CSV gem not installing in head https://bugs.ruby-lang.org/issues/21207 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: ruby 3.5.0dev (2025-03-31T14:56:29Z master 8a475d15d6) +PRISM * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The current MinGW workflow in Ruby shows: ```text skipped bundled gems: csv-3.3.4.gem not found in bundled_gems ``` I verified the same locally with both a Windows UCRT build and an Ubuntu build, and the ruby-loco builds are also failing. The current line in `bundled_gems`: ```text csv 3.3.3 https://github.com/ruby/csv e0874e47e2730dacccdb0c534a2cdc073d3bdaea ``` If one changes that to the below, ruby-loco builds pass. ```text csv 3.3.4 https://github.com/ruby/csv e0874e47e2730dacccdb0c534a2cdc073d3bdaea ``` But, Ruby's CI fails in the `./.github/actions/setup/directories` step. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:121642] [Ruby Bug#21266] YJIT GC safety crash with proc objects as block argument
by alanwu (Alan Wu) 13 Apr '25

13 Apr '25

Issue #21266 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #21266: YJIT GC safety crash with proc objects as block argument https://bugs.ruby-lang.org/issues/21266 * Author: alanwu (Alan Wu) * Status: Open * Assignee: yjit * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- ```ruby # Run with --yjit-call-threshold=1 def foo(args) = bar(*args, &proc { _1 }) def bar(_, _, _, _, *rest) = yield rest GC.stress = true foo([1,2,3,4]) foo([1,2,3,4]) ``` The proc in these calls get collected on the yield to the GC to allocate the rest parameter arary. ``` ../vm_core.h:1668: Assertion Failed: vm_block_handler_type:rb_obj_is_proc(block_handler) ``` Or in release builds: ``` ../test.rb:1: [BUG] Segmentation fault at 0x0000000000000020 ruby 3.3.6 (2024-11-05 revision 75015d4c1f) +YJIT [arm64-darwin24] -- C level backtrace information ------------------------------------------- /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_bugreport+0xb4c) [0x104595590] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_bug_for_fatal_signal+0x100) [0x1043d6120] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(sig_do_nothing+0x0) [0x1044fc4b0] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x187572de4] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_invokeblock+0x144) [0x10456b004] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116555] [Ruby master Feature#20233] pkg-config not working on MSVC
by jmarrec (Julien Marrec) 13 Apr '25

13 Apr '25

Issue #20233 has been reported by jmarrec (Julien Marrec). ---------------------------------------- Feature #20233: pkg-config not working on MSVC https://bugs.ruby-lang.org/issues/20233 * Author: jmarrec (Julien Marrec) * Status: Open * Priority: Normal ---------------------------------------- The PKG_CONFIG variable is not respected in win32/Makefile.sub Also, need to ideally use the `--msvc-syntax` flag (pkgconf 1.4.0, released 7 years ago, adds it). But mostly, I realized that the `try_ldflags` in `lib/mkmf.rb` actually passes these ldflags as the `opt` parameter to the `link_command` function, and not as `ldflags`. While the UNIX systems are forgiving, the MSVC compiler is not, and because the flags are passed before the `-link`, MSVC complains that it ignores it and therefore cannot find the requested library. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121629] [Ruby Bug#21265] Crash when proc from Symbol#to_proc called outside refinement scope
by alanwu (Alan Wu) 11 Apr '25

11 Apr '25

Issue #21265 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #21265: Crash when proc from Symbol#to_proc called outside refinement scope https://bugs.ruby-lang.org/issues/21265 * Author: alanwu (Alan Wu) * Status: Open * ruby -v: ruby 3.4.2 and trunk * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- ```ruby class RefinedScope using(Module.new { refine(Kernel) { def itself = 0 } }) ITSELF = :itself.to_proc end RefinedScope::ITSELF[0] ``` ``` ../vm_method.c:1371: Assertion Failed: prepare_callable_method_entry:RB_TYPE_2_P(defined_class, RUBY_T_ICLASS, RUBY_T_MODULE): defined_class: T_FALSE ``` Or SEGV without `-DRUBY_DEBUG`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121626] [Ruby Feature#21263] eval-after-require hook
by znz (Kazuhiro NISHIYAMA) 11 Apr '25

11 Apr '25

Issue #21263 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Feature #21263: eval-after-require hook https://bugs.ruby-lang.org/issues/21263 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open ---------------------------------------- I want to register hook after require. But I have no idea how to write it. Expected use cases: 1. Load related things after require. For example, IRB load related RBS after require something. 2. Soft dependency. For example, mashalling libraries load codes supporting bigdecimal, date, or some optional data types after require them only. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121625] [Ruby Feature#18035] Introduce general model/semantic for immutability.
by ioquatix (Samuel Williams) 10 Apr '25

10 Apr '25

Issue #18035 has been updated by ioquatix (Samuel Williams). I found a good example of why the proposed interface would be a good idea: https://github.com/ruby/resolv/pull/62 This PR introduces lot of `freeze`. For example: ```ruby return { :nameserver => nameserver.freeze, :search => search.freeze, :ndots => ndots.freeze }.freeze ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-112680 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0