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

[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 _) 14 Jun '25

14 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:122515] [Ruby Bug#21436] Date#ajd returns incorrect positive values due to integer overflow for large negative years
by Stranger6667 (Dmitry Dygalo) 11 Jun '25

11 Jun '25

Issue #21436 has been reported by Stranger6667 (Dmitry Dygalo). ---------------------------------------- Bug #21436: Date#ajd returns incorrect positive values due to integer overflow for large negative years https://bugs.ruby-lang.org/issues/21436 * Author: Stranger6667 (Dmitry Dygalo) * Status: Open * ruby -v: 3.2.8 - 3.4.4 (and older versions too) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `Date#ajd` (astronomical Julian Day number) returns incorrect positive values instead of negative values for certain large negative years due to signed integer overflow in the `RB_INT2FIX` function. ```ruby require 'date' # Works correctly Date.civil(-110823815392979, 2, 19).ajd #=> (-80956797141128945/2) # BUG - returns positive instead of negative Date.civil(-11082381539297990, 2, 19).ajd #=> (1127692322401036327/2) # Should be negative! # Works correctly (takes a different code path) Date.civil(-111111111082381539297990, 2, 19).ajd #=> (-81166666645679714453739481/2) ``` In [ext/date/date_core.c](https://github.com/ruby/ruby/blob/v3_4_4/ext/date/dat…, the `ir` value can overflow ```c if (FIXNUM_P(r) && FIX2LONG(r) <= (FIXNUM_MAX / 2)) { long ir = FIX2LONG(r); ir = ir * 2 - 1; // On Date.civil(-11082381539297990, 2, 19).ajd // // ir = -8095679714453739481 return rb_rational_new2(LONG2FIX(ir), INT2FIX(2)); // Overflow in LONG2FIX } ``` Then in [include/ruby/internal/arithmetic/long.h](https://github.com/ruby/ruby/blob/… (`LONG2FIX` is an alias for `RB_INT2FIX`) ```c static inline VALUE RB_INT2FIX(long i) { RBIMPL_ASSERT_OR_ASSUME(RB_FIXABLE(i)); /* :NOTE: VALUE can be wider than long. As j being unsigned, 2j+1 is fully * defined. Also it can be compiled into a single LEA instruction. */ const unsigned long j = RBIMPL_CAST((unsigned long)i); const unsigned long k = (j << 1) + RUBY_FIXNUM_FLAG; const long l = RBIMPL_CAST((long)k); const SIGNED_VALUE m = l; /* Sign extend */ const VALUE n = RBIMPL_CAST((VALUE)m); RBIMPL_ASSERT_OR_ASSUME(RB_FIXNUM_P(n)); return n; } ``` It effectively goes: ``` j = (unsigned long)-8095679714453739481 // 10351064359255812135 k = (10351064359255812135 << 1) + RUBY_FIXNUM_FLAG // 2255384644802072655 ... ``` So, `2255384644802072655` encodes `1127692322401036327`, which is the numerator for the observed `ajd` return value in the reproducer above. It also affects `Date` comparisons (since `ajd` is used in `cmp_gen`) -- https://bugs.ruby-lang.org/

1 0

[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

[ruby-core:122352] [Ruby Bug#21388] make install and bundled gems
by MSP-Greg (Greg L) 10 Jun '25

10 Jun '25

Issue #21388 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21388: make install and bundled gems https://bugs.ruby-lang.org/issues/21388 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-31T09:43:52Z master 32c708efbd) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Two issues: 1. Currently, `make install` from the `MinGW (UCRT)` workflow shows two gems not being installed (`syslog` cannot be installed on Windows): ``` skipped bundled gems: csv-3.3.5.gem not found in bundled_gems power_assert-2.0.6dev.gem not found in bundled_gems syslog-0.3.0.gem not found in bundled_gems ``` A simple patch file will fix this: ```patch diff --git a/gems/bundled_gems b/gems/bundled_gems index 8891f1c462..ca66b48ed6 100644 --- a/gems/bundled_gems +++ b/gems/bundled_gems @@ -7,7 +7,7 @@ # if `revision` is not given, "v"+`version` or `version` will be used. minitest 5.25.5 https://github.com/minitest/minitest -power_assert 2.0.5 https://github.com/ruby/power_assert a7dab941153b233d3412e249d25da52a6c5691de +power_assert 2.0.6dev https://github.com/ruby/power_assert a7dab941153b233d3412e249d25da52a6c5691de rake 13.3.0 https://github.com/ruby/rake test-unit 3.6.8 https://github.com/test-unit/test-unit rexml 3.4.1 https://github.com/ruby/rexml @@ -33,7 +33,7 @@ rinda 0.2.0 https://github.com/ruby/rinda drb 2.2.3 https://github.com/ruby/drb nkf 0.2.0 https://github.com/ruby/nkf syslog 0.3.0 https://github.com/ruby/syslog -csv 3.3.4 https://github.com/ruby/csv 69d9886238a504bfac60fa516cd08ad2a855a2a8 +csv 3.3.5 https://github.com/ruby/csv 69d9886238a504bfac60fa516cd08ad2a855a2a8 repl_type_completor 0.1.11 https://github.com/ruby/repl_type_completor 25108aa8d69ddaba0b5da3feff1c0035371524b2 ostruct 0.6.1 https://github.com/ruby/ostruct 50d51248bec5560a102a1024aff4174b31dca8cc pstore 0.2.0 https://github.com/ruby/pstore ``` 2. Sometime ago, one could cache the *.gem files, and they would not be downloaded. Now, regardless of the cache, they are always downloaded. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118412] [Ruby master Misc#20600] @ruby-lang.org has been migrated to Cloudflare
by shugo (Shugo Maeda) 10 Jun '25

10 Jun '25

Issue #20600 has been reported by shugo (Shugo Maeda). ---------------------------------------- Misc #20600: @ruby-lang.org has been migrated to Cloudflare https://bugs.ruby-lang.org/issues/20600 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- @ruby-lang.org has been migrated to Cloudflare, because ruby-lang.org was migrated from Google Domains to Squarespace, and Squarespace's e-mail forwarding doesn't work with custom MX records including subdomains:( I and Shibata-san are adding e-mail routing rules on Cloudflare, so if you have an e-mail address on ruby-lang.org, please verify the e-mail routing address when receiving an email from Cloudflare. -- https://bugs.ruby-lang.org/

6 13