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

[ruby-core:122214] [Ruby Bug#21355] `csv/test/csv/interface/test_read.rb` at test-bundled-gems is flaky recent days
by hsbt (Hiroshi SHIBATA) 24 Jun '25

24 Jun '25

Issue #21355 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21355: `csv/test/csv/interface/test_read.rb` at test-bundled-gems is flaky recent days https://bugs.ruby-lang.org/issues/21355 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I faced test failure of `make test-bundled-gems` in GitHub Actions. It caused by `csv` testing with `Ractor`. https://github.com/ruby/ruby/actions/runs/15156308046/job/42611877817?pr=13… ``` /home/runner/work/ruby/ruby/src/gems/src/csv/test/csv/interface/test_read.rb:56: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. <OBJ_INFO:rb_ractor_confirm_belonging@../src/ractor_core.h:370> (File) /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:3 ruby 3.5.0dev (2025-05-21T07:35:21Z pull/13391/merge 7c1f3e8f7e) [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

2 2

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

23 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

[ruby-core:120465] [Ruby master Bug#20998] rb_str_locktmp() changes flags of frozen strings and string literals
by Eregon (Benoit Daloze) 17 Jun '25

17 Jun '25

Issue #20998 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #20998: rb_str_locktmp() changes flags of frozen strings and string literals https://bugs.ruby-lang.org/issues/20998 * Author: Eregon (Benoit Daloze) * 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 ---------------------------------------- ```ruby # frozen_string_literal: true # BOILERPLATE START require 'tmpdir' require 'rbconfig' def inline_c_extension(c_code) Dir.mktmpdir('inline_c_extension') do |dir| File.write("#{dir}/cext.c", c_code) File.write("#{dir}/extconf.rb", <<~RUBY) require 'mkmf' create_makefile('cext') RUBY out = IO.popen([RbConfig.ruby, 'extconf.rb'], chdir: dir, &:read) raise "ruby extconf.rb failed: #{$?.inspect}\n#{out}" unless $?.success? out = IO.popen(['make'], chdir: dir, &:read) raise "make failed: #{$?.inspect}\n#{out}" unless $?.success? require "#{dir}/cext.#{RbConfig::CONFIG['DLEXT']}" end end inline_c_extension <<~C #include "ruby.h" static VALUE foo(VALUE self, VALUE str) { rb_str_locktmp(str); return str; } void Init_cext(void) { VALUE c = rb_define_class("Foo", rb_cObject); rb_define_singleton_method(c, "foo", foo, 1); } C # BOILERPLATE END a = "str" # imagine a million line of codes in between b = "str" Foo.foo(a) b << "." # can't modify string; temporarily locked (RuntimeError) # What? Who "locked" that immutable frozen string literal? # It should be: can't modify frozen String: "str" (FrozenError) ``` Same problem with: ```ruby Foo.foo("abc") # imagine a million line of codes in between Foo.foo("abc") # emporal locking already locked string (RuntimeError) ``` Related: https://github.com/oracle/truffleruby/issues/3752 It seems a clear bug to mutate a frozen string (with visible side effects), even more so for shared frozen string literals. I think rb_str_locktmp() should raise (a FrozenError, as it's effectively attempting to mutate it, same as calling `rb_str_modify()`) if called on a frozen string, because it makes little sense, I think "locking a string" only makes sense for mutable strings. The alternative would be to noop on frozen strings for rb_str_locktmp() and rb_str_unlocktmp(), I think that's susprising, and potentially hiding more bugs, e.g. if one by mistake tries to mutate the RSTRING_PTR() or so. Any attempt to mutate a frozen string should fail, so might as well fail early. -- https://bugs.ruby-lang.org/

7 16

[ruby-core:117684] [Ruby master Bug#20452] Ruby 3.3 on Alpine Linux results in a relatively shallow SystemStackError exception
by Earlopain (A S) 17 Jun '25

17 Jun '25

Issue #20452 has been reported by Earlopain (A S). ---------------------------------------- Bug #20452: Ruby 3.3 on Alpine Linux results in a relatively shallow SystemStackError exception https://bugs.ruby-lang.org/issues/20452 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.1 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This is a redo of https://bugs.ruby-lang.org/issues/14387, reported against a non-eol version. The same issue still applies on recent rubies, though I personally only have tested 3.3 and 3.2: ```rb n = 100000 res = {} 1.upto(n).to_a.inject(res) do |r, i| r[i] = {} end def f(x) x.each_value { |v| f(v) } end f(res) ``` The patch from https://bugs.ruby-lang.org/issues/14387#note-13 still works, though as per https://bugs.ruby-lang.org/issues/14387#note-16 it can't be accepted as is. With the patch applied: ``` (irb):8:in `block in f': stack level too deep (SystemStackError) from (irb):8:in `each_value' from (irb):8:in `f' from (irb):8:in `block in f' from (irb):8:in `each_value' from (irb):8:in `f' from (irb):8:in `block in f' from (irb):8:in `each_value' from (irb):8:in `f' ... 11549 levels... from /usr/local/lib/ruby/gems/3.3.0/gems/irb-1.11.0/exe/irb:9:in `<top (required)>' from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' ``` Without the patch: ``` (irb):8:in `each_value': stack level too deep (SystemStackError) from (irb):8:in `f' from (irb):8:in `block in f' from (irb):8:in `each_value' from (irb):8:in `f' from (irb):8:in `block in f' from (irb):8:in `each_value' from (irb):8:in `f' from (irb):8:in `block in f' ... 286 levels... from /usr/local/lib/ruby/gems/3.3.0/gems/irb-1.11.0/exe/irb:9:in `<top (required)>' from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' ``` To reproduce, I have removed lines 102-105 from https://github.com/docker-library/ruby/blob/f5753434bb23041dd9913bb7b650e7b…. Check out the previous ticket for more information, there are a few conversations about possible solutions. -- https://bugs.ruby-lang.org/

4 11

[ruby-core:121992] [Ruby Bug#21325] make ruby more middle-aged man friendly
by pynix (Pynix wang) 15 Jun '25

15 Jun '25

Issue #21325 has been reported by pynix (Pynix wang). ---------------------------------------- Bug #21325: make ruby more middle-aged man friendly https://bugs.ruby-lang.org/issues/21325 * Author: pynix (Pynix wang) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- after 35, I lose all interests about programming. no linux, no vim, no iterm2, and no much much. when I want to format a ruby time to string. I will try `Time.now.format("yy-MM-dd")`, but I get `private method 'format' called for an instance of Time` ohh, I google `ruby time format`, then I get `strftime`, I know this is from c standard library. answer me, looking my eyes. why? baby why? why I have to use c style method with ruby in 2025. format is the first choose when we not familiar with `Time` class, so, `format` is private, so we can rename it to `_format`, and make `format` a copy of `strftime` and deprecate the old one, -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120738] [Ruby master Bug#21048] [Prism] rescue in modifier form with condition behaves differently
by Earlopain (Earlopain _) 13 Jun '25

13 Jun '25

Issue #21048 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21048: [Prism] rescue in modifier form with condition behaves differently https://bugs.ruby-lang.org/issues/21048 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- With the following code there is a discrepancy in how prism and parse.y consider precedence: ```rb $called = false def foo $called = true end foo rescue nil if false puts "Called: #{$called}" ``` Prism interprets it as `(foo rescue nil) if false`, not calling the method. `parse.y` does `foo rescue (nil if false)` since at least Ruby 2.0 ```sh $ ruby -v ruby 3.5.0dev (2025-01-19T12:44:20Z master f27ed98eff) +PRISM [x86_64-linux] $ ruby code.rb Called: true $ ruby --parser=parse.y code.rb Called: false ``` -- https://bugs.ruby-lang.org/

6 6

[ruby-core:122261] [Ruby Bug#21368] Moving objects with finalizer between Ractors crashes
by peterzhu2118 (Peter Zhu) 11 Jun '25

11 Jun '25

Issue #21368 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21368: Moving objects with finalizer between Ractors crashes https://bugs.ruby-lang.org/issues/21368 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When an object is moved to a different Ractor, the finalizers are not copied to the new object, so it will have the `FL_FINALIZE` flag set but no entry in the finalizer table. The following script crashes: ```ruby r = Ractor.new do loop { Ractor.receive } end 1_000.times do o = Object.new ObjectSpace.define_finalizer(o, proc { |id| }) r.send(o, move: true) end ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:118577] [Ruby master Bug#20631] Build failure with Xcode 16 beta and macOS 15 (Sequoia) Beta
by hsbt (Hiroshi SHIBATA) 11 Jun '25

11 Jun '25

Issue #20631 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20631: Build failure with Xcode 16 beta and macOS 15 (Sequoia) Beta https://bugs.ruby-lang.org/issues/20631 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found some issues with Xcode 16 beta and macOS 15 (Sequoia) Beta. `TestRubyOptions` and `TestVMDump` are failed with them. full log: https://gist.github.com/hsbt/378fe2ba47e734f2562ba9a154e1795b I'm not sure why macOS require `sudo` command for that. ---- And I and @katei also found the regression of https://bugs.ruby-lang.org/issues/18912#note-15. ``` >> pid = fork { p File.realpath "/" } >> Process.waitpid(pid) objc[82573]: +[NSPlaceholderMutableString initialize] may have been in progress in another thread when fork() was called. objc[82573]: +[NSPlaceholderMutableString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. => 82573 ``` -- https://bugs.ruby-lang.org/

2 8