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

[ruby-core:112664] [Ruby master Bug#19473] can't be called from trap context (ThreadError) is too limiting
by Eregon (Benoit Daloze) 24 Jun '25

24 Jun '25

Issue #19473 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19473: can't be called from trap context (ThreadError) is too limiting https://bugs.ruby-lang.org/issues/19473 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Simple reproducer: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] -e:1:in `synchronize': can't be called from trap context (ThreadError) from -e:1:in `block in <main>' from -e:1:in `kill' from -e:1:in `<main>' ``` Expected behavior: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' truffleruby 22.3.1, like ruby 3.0.3, GraalVM CE Native [x86_64-linux] :OK $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' jruby 9.4.0.0 (3.1.0) 2022-11-23 95c0ec159f OpenJDK 64-Bit Server VM 17.0.6+10 on 17.0.6+10 +jit [x86_64-linux] :OK ``` This exception is highly problematic, for instance it breaks `Timeout.timeout` in `trap`: https://github.com/ruby/timeout/issues/17#issuecomment-1142035939 I suppose this behavior is because *sometimes* it's problematic to lock a Mutex in trap, e.g., if it's already locked by the main thread/fiber. However, that's just one case, not all, so we should not raise an exception early like that. There seems to be no valid reason to prevent *all* `Mutex#synchronize` in `trap`. After all, if the Mutex for instance is only used in `trap`, it's well-defined AFAIK. For instance a given trap handler does not seem executed concurrently: ``` $ ruby -ve 'trap(:HUP) { puts "in trap\n"+caller.join("\n")+"\n\n"; sleep 0.1 }; pid = Process.pid; Process.wait fork { 20.times { Process.kill :HUP, pid } }; sleep 1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' ``` And if the trap handler using the Mutex is never called while the Mutex is held by the main thread/fiber, there is also no problem. -- https://bugs.ruby-lang.org/

5 18

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

24 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:115422] [Ruby master Bug#20009] Marshal.load raises exception when load dumped class include non-ASCII
by ippachi (Kazuya Hatanaka) 15 Jun '25

15 Jun '25

Issue #20009 has been reported by ippachi (Kazuya Hatanaka). ---------------------------------------- Bug #20009: Marshal.load raises exception when load dumped class include non-ASCII https://bugs.ruby-lang.org/issues/20009 * Author: ippachi (Kazuya Hatanaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Reproduction code ```ruby class Cクラス; end Marshal.load(Marshal.dump(Cクラス)) ``` ## Actual result ``` <internal:marshal>:34:in `load': undefined class/module C\xE3\x82\xAF\xE3\x83\xA9\xE3\x82\xB9 (ArgumentError) from marshal.rb:2:in `<main>' ``` ## Expected result Returns `Cクラス` ## Impacted area An exception is raised in Rails under the following conditions * minitest is used with default settings * Parallel execution with parallelize * test class names contain non-ASCII characters The default parallelization uses DRb, and Marshal is used inside DRb. ## Other After trying various things, I thought I could fix it by making `rb_path_to_class` support strings containing non-ASCII characters, but I couldn't find anything more than that. -- https://bugs.ruby-lang.org/

6 11

[ruby-core:121574] [Ruby Bug#21255] Ruby couldn't build with Windows SDK 10.0.26100
by hsbt (Hiroshi SHIBATA) 14 Jun '25

14 Jun '25

Issue #21255 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21255: Ruby couldn't build with Windows SDK 10.0.26100 https://bugs.ruby-lang.org/issues/21255 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I tried to build ruby.exe with Windows SDK 10.0.26100. But it failed with: ``` dmyext.obj dmyenc.obj linking shared-library x64-vcruntime140-ruby350.dll x64-vcruntime140-ruby350.def : error LNK2001: 外部シンボル "Avx2WmemEnabledWeakValue" は未解決です。 dummy.lib : fatal error LNK1120: 1 件の未解決の外部参照 ``` (This message is the japanese edition of VS2019 Ver.16.11.45) I and @nobu faced the same issue at GitHub Actions. ``` x64-vcruntime140-ruby350.def : error LNK2001: unresolved external symbol Avx2WmemEnabledWeakValue ``` https://github.com/nobu/ruby/actions/runs/13630688130/job/38097613034#step:… I resolved this issue to downgrade Windows SDK to 10.0.22261. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121721] [Ruby Bug#21283] Some tests of TestMkmfConvertible is failing with VS2022 17.14.0 preview 4.0
by hsbt (Hiroshi SHIBATA) 14 Jun '25

14 Jun '25

Issue #21283 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21283: Some tests of TestMkmfConvertible is failing with VS2022 17.14.0 preview 4.0 https://bugs.ruby-lang.org/issues/21283 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following tests are broken with VS2022 17.14.0 preview 4.0. ``` 1) Error: TestMkmfConvertible#test_typeof_typedef: Test::Unit::ProxyError: invalid byte sequence in UTF-8 V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:21:in 'block (2 levels) in TestMkmfConvertible#test_typeof_typedef' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:16:in 'Array#each' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:16:in 'block in TestMkmfConvertible#test_typeof_typedef' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:15:in 'Array#each' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:15:in 'TestMkmfConvertible#test_typeof_typedef' 2) Error: TestMkmfConvertible#test_typeof_builtin: Test::Unit::ProxyError: invalid byte sequence in UTF-8 V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:8:in 'block (2 levels) in TestMkmfConvertible#test_typeof_builtin' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:7:in 'Array#each' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:7:in 'block in TestMkmfConvertible#test_typeof_builtin' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:6:in 'Array#each' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:6:in 'TestMkmfConvertible#test_typeof_builtin' ``` They are working fine with VS2019. -- https://bugs.ruby-lang.org/

3 6

[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