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

[ruby-core:120915] [Ruby master Bug#21125] Kernel is called first
by mikik0 (Hashino Mikiko) 26 Mar '25

26 Mar '25

Issue #21125 has been reported by mikik0 (Hashino Mikiko). ---------------------------------------- Bug #21125: Kernel is called first https://bugs.ruby-lang.org/issues/21125 * Author: mikik0 (Hashino Mikiko) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Kernel#system is being called when there is a column or method name named system. The other methods of Kernel reproduce the problem. Ex.Rand returns a random value, and exit terminates the program. ## Reproducible script: ``` ruby class ObjectifiedHash def initialize(hash) @hash = hash end private attr_reader :hash def method_missing(method_name, *args, &block) if hash.key?(method_name.to_sym) hash[method_name.to_sym] else super end end def respond_to_missing?(method_name, include_private = false) hash.key?(method_name.to_sym) || super end end class Foo def system(...) # Kernel#system is called raw.system(...) # (...) passes if there is no # raw.system end def initialize(raw) @raw = raw end def get_system system end private attr_reader :raw end class Test def self.run obj = ObjectifiedHash.new({ system: 'system' }) foo = Foo.new(obj) # foo.system would pass. # After executing foo.system, hoge.get_system also passes. # p foo.system p foo.get_system end end Test.run ``` ## Execution Results ``` shell hoge.rb:26:in 'Kernel#system': wrong number of arguments (given 0, expected 1+) (ArgumentError) raw.system(...) ^^^ from ruby.rb:26:in 'Foo#system' from ruby.rb:36:in 'Foo#get_system' from ruby.rb:54:in 'Test.run' from ruby.rb:58:in '<main>' ``` ## Expected results ``` shell "system" ``` PR that may be relevant: https://github.com/ruby/ruby/pull/11028 -- https://bugs.ruby-lang.org/

3 6

[ruby-core:121400] [Ruby Bug#21191] Ruby 3.4.2 crashes unexpectedly
by datanoise (Kent Sibilev) 26 Mar '25

26 Mar '25

Issue #21191 has been reported by datanoise (Kent Sibilev). ---------------------------------------- Bug #21191: Ruby 3.4.2 crashes unexpectedly https://bugs.ruby-lang.org/issues/21191 * Author: datanoise (Kent Sibilev) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Running my Rails app in development mode with Ruby 3.4.2 crashes with: Thread 15 Crashed:: puma srv tp 003 0 libsystem_kernel.dylib 0x19323f720 __pthread_kill + 8 1 libsystem_pthread.dylib 0x193277f70 pthread_kill + 288 2 libsystem_c.dylib 0x193184908 abort + 128 3 libruby.3.4.dylib 0x10176c30c die + 12 4 libruby.3.4.dylib 0x101a78e38 rb_bug + 32 5 libruby.3.4.dylib 0x101a49570 yjit::yjit::rb_bug_panic_hook::_$u7b$$u7b$closure$u7d$$u7d$::h0f4c55d7c8e55fcf + 340 6 libruby.3.4.dylib 0x1019d242c std::panicking::rust_panic_with_hook::h9a5dc30b684e2ff4 + 740 7 libruby.3.4.dylib 0x1019d2030 std::panicking::begin_panic_handler::_$u7b$$u7b$closure$u7d$$u7d$::hbcb5de8b840ae91c + 104 8 libruby.3.4.dylib 0x1019d1188 std::sys::backtrace::__rust_end_short_backtrace::ha657d4b4d65dc993 + 12 9 libruby.3.4.dylib 0x1019d1cdc rust_begin_unwind + 32 10 libruby.3.4.dylib 0x101a6a8c8 core::panicking::panic_fmt::hda207213c7ca0065 + 32 11 libruby.3.4.dylib 0x101a6a938 core::panicking::panic::h58f3db1cc4835fac + 52 12 libruby.3.4.dylib 0x1019f3330 yjit::codegen::jit_guard_known_klass::h231d0cbaae1c099c + 2852 13 libruby.3.4.dylib 0x1019ec404 yjit::codegen::gen_equality_specialized::h93a21f50d2816872 + 760 14 libruby.3.4.dylib 0x1019ec82c yjit::codegen::gen_opt_eq::h5396bf9fac489b74 + 36 15 libruby.3.4.dylib 0x1019df604 yjit::codegen::gen_single_block::h01cba096a3e9933d + 2996 16 libruby.3.4.dylib 0x101a200a8 yjit::core::gen_block_series::h1b8008b9e695e93a + 132 17 libruby.3.4.dylib 0x101a21fe0 yjit::core::branch_stub_hit_body::ha9f3b0e799953b26 + 916 18 libruby.3.4.dylib 0x101a3a390 yjit::stats::with_compile_time::hb64811b90dfb965e + 64 19 libruby.3.4.dylib 0x101a66088 yjit::cruby::with_vm_lock::hf301ea5cad023986 + 84 20 libruby.3.4.dylib 0x101a253e4 yjit::core::branch_stub_hit::h44174fb9640d7093 + 80 21 ??? 0x150002078 ??? 22 libruby.3.4.dylib 0x10190ad58 vm_exec_core + 9576 23 libruby.3.4.dylib 0x1019072d8 rb_vm_exec + 492 24 libruby.3.4.dylib 0x10192ed2c invoke_block_from_c_bh + 872 25 libruby.3.4.dylib 0x10192e46c catch_i + 108 26 libruby.3.4.dylib 0x101918e78 vm_catch_protect + 200 27 libruby.3.4.dylib 0x101919888 rb_f_catch + 112 28 ??? 0x1502acbe4 ??? 29 libruby.3.4.dylib 0x10190ad58 vm_exec_core + 9576 30 libruby.3.4.dylib 0x101907304 rb_vm_exec + 536 31 libruby.3.4.dylib 0x10191ba24 vm_invoke_proc + 712 32 libruby.3.4.dylib 0x1018db74c thread_do_start_proc + 668 33 libruby.3.4.dylib 0x1018dae18 thread_start_func_2 + 796 34 libruby.3.4.dylib 0x1018da994 nt_start + 248 35 libsystem_pthread.dylib 0x1932782e4 _pthread_start + 136 36 libsystem_pthread.dylib 0x1932730fc thread_start + 8 ---Files-------------------------------- ruby-2025-03-18-112226.ips (97.7 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120884] [Ruby master Bug#21115] Etc.getgrgid is not Ractor-safe but is marked as such
by Eregon (Benoit Daloze) 25 Mar '25

25 Mar '25

Issue #21115 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21115: Etc.getgrgid is not Ractor-safe but is marked as such https://bugs.ruby-lang.org/issues/21115 * 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 require 'etc' 20.times.map do Ractor.new do 1000.times do raise unless Etc.getgrgid(Process.gid).gid == Process.gid end end end.each(&:take) ``` Running it a few times gives a segfault: ``` $ ruby ractor_getgrgid.rb ractor_getgrgid.rb:4: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x00007f251b7d0478 run> terminated with exception (report_on_exception is true): ractor_getgrgid.rb:6:in 'block (3 levels) in <main>': unhandled exception from <internal:numeric>:257:in 'Integer#times' from ractor_getgrgid.rb:5:in 'block (2 levels) in <main>' #<Thread:0x00007f251b7dde70 run> terminated with exception (report_on_exception is true): ractor_getgrgid.rb:6:in 'block (3 levels) in <main>': unhandled exception from <internal:numeric>:257:in 'Integer#times' from ractor_getgrgid.rb:5:in 'block (2 levels) in <main>' ractor_getgrgid.rb:6: [BUG] Segmentation fault at 0x00000000706d7564 ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:---- s:0019 e:000018 CFUNC :getgrgid c:0004 p:0009 s:0014 e:000013 BLOCK ractor_getgrgid.rb:6 c:0003 p:0024 s:0011 e:000010 METHOD <internal:numeric>:257 c:0002 p:0005 s:0006 e:000005 BLOCK ractor_getgrgid.rb:5 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] ``` Etc is marked as Ractor-safe since https://github.com/ruby/ruby/pull/3954. But that is not correct, etc.c uses many C functions which are not thread-safe, such as `getgrgid()`. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:118823] [Ruby master Bug#20670] fork deadlocks in child process due to timer thread
by jhawthorn (John Hawthorn) 22 Mar '25

22 Mar '25

Issue #20670 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20670: fork deadlocks in child process due to timer thread https://bugs.ruby-lang.org/issues/20670 * Author: jhawthorn (John Hawthorn) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- We've been seeing an occasional failure in the Rails CI related to a test which forks and I managed to reduce it to the following reproduction. ``` ruby Thread.new do loop { sleep 0.0001 } end 1000.times do pid = fork{} Process.waitpid(pid) rescue Exception Process.kill(:KILL, pid) raise end ``` This hangs on Ruby 3.3 and HEAD (_fairly_ reliably), but completes always on Ruby 3.2 In a debugger it seems like the timer thread acquires `vm->ractor.sched.lock` in the parent process just as the process is forking. The child process then ends up stuck inside of `thread_sched_atfork` when trying to acquire the same lock. I've opened https://github.com/ruby/ruby/pull/11356 with a fix -- https://bugs.ruby-lang.org/

4 4

[ruby-core:121429] [Ruby Bug#21196] Ruby 3.4 ignores visibility when passing arguments using `...`
by toy (Ivan Kuchin) 21 Mar '25

21 Mar '25

Issue #21196 has been reported by toy (Ivan Kuchin). ---------------------------------------- Bug #21196: Ruby 3.4 ignores visibility when passing arguments using `...` https://bugs.ruby-lang.org/issues/21196 * Author: toy (Ivan Kuchin) * 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 ---------------------------------------- If method is passing arguments using `...`, then receiver visibility gets ignored if once called without receiver: ```ruby class A private def foo = :foo def bar = :bar end class B def initialize(o) @o = o end def foo(...) = @o.foo(...) def bar = @o.bar def internal_foo = foo def internal_bar = bar end def try p yield rescue => e p e end ``` If `foo` is called first without receiver through `internal_foo`: ```ruby b = B.new(A.new) try{ b.internal_foo } try{ b.internal_bar } try{ b.foo } try{ b.bar } ``` Visibility of `A#foo` gets ignored: ``` ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] :foo #<NoMethodError: private method 'bar' called for an instance of A> :foo #<NoMethodError: private method 'bar' called for an instance of A> ``` ``` ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux] #<NoMethodError: private method `foo' called for an instance of A> #<NoMethodError: private method `bar' called for an instance of A> #<NoMethodError: private method `foo' called for an instance of A> #<NoMethodError: private method `bar' called for an instance of A> ``` If `internal_foo` is not called before `foo`: ```ruby b = B.new(A.new) try{ b.foo } try{ b.bar } ``` Visibility of `A#foo` gets checked: ``` ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] #<NoMethodError: private method 'foo' called for an instance of A> #<NoMethodError: private method 'bar' called for an instance of A> ``` ``` ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux] #<NoMethodError: private method `foo' called for an instance of A> #<NoMethodError: private method `bar' called for an instance of A> ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121421] [Ruby Feature#21194] How to manage application-level information in Ruby application
by mame (Yusuke Endoh) 21 Mar '25

21 Mar '25

Issue #21194 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #21194: How to manage application-level information in Ruby application https://bugs.ruby-lang.org/issues/21194 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- ## Goal I want to manage application-level information (e.g., application configuration) while making it easily accessible from the part classes of the application. Additionally, I want to support multiple instances of the application within a single process. ## Current approach 1: Global variables The simplest way to achieve this is by using global variables. ```ruby class MyApp class Part1 def run using $config[:part1]... end end class Part2 def run using $config[:part2]... end end def initialize(config) $config = config @part1 = Part1.new @part2 = Part2.new end def run @part1.run @part2.run end end app1 = MyApp.new({ part1: "aaa", part2: "bbb" }) # app2 = MyApp.new({ part1: "AAA", part2: "BBB" }) # Cannot create this app1.run ``` This code is simple and clear, but it does not allow creating multiple `MyApp` instances with different configurations. To achieve that, we would need to create separate process using `fork` or `spawn`. This limitation remains even if we replace global variables with constants (`MyApp::Config`) or class methods (`MyApp.config`). ## Current approach 2: Passing configuration via `initialize` A textbook and well-structured approach is to explicitly pass configuration through `initialize`. ```ruby class MyApp class Part1 def initialize(config) @config = config end def run using @config[:part1]... end end class Part2 def initialize(config) @config = config end def run using @config[:part2]... end end def initialize(config) @part1 = Part1.new(config) @part2 = Part2.new(config) end def run @part1.run @part2.run end end app1 = MyApp.new({ part1: ..., part2: ... }) app2 = MyApp.new({ part1: ..., part2: ... }) app1.run app2.run ``` This approach allows creating multiple MyApp instances with different configurations in a single Ruby process. However, it has two major drawbacks: * `config` must be passed explicitly in every `initialize` and `new` call, making the code verbose. * Both `Part1` and `Part2` instances hold their own `@config` variables, which is redundant -- especially when creating a large number of small instances (e.g., tree nodes). ## Current approach 3: Thread-local storage Storing configuration in `Thread[:config]` allows multiple application instances without explicit parameter passing. ```ruby class MyApp class Part1 def run using Thread[:config][:part1]... end end class Part2 def run using Thread[:config][:part2]... end end def initialize(config) @config = config @part1 = Part1.new @part2 = Part2.new end def run Thread[:config] = config @part1.run @part2.run end end app1 = MyApp.new({ part1: ..., part2: ... }) app2 = MyApp.new({ part1: ..., part2: ... }) app1.run app2.run ``` This approach is mostly effective but has an issue: * `Thread[:config] = @config` must be set at the beginning of `MyApp#run`. While this is manageable if there is only one public API, it becomes error-prone when multiple APIs exist. Note that using `Fiber#[]` instead of `Thread#[]` has the same issue. ## Proposal Ideally, we want to support multiple application instances while keeping the simplicity of the global variable approach. To achieve this, I propose introducing a new type variable, such as `$@config`: * `$@config` belongs to an instance * When accessing `$@config`, it is looked up not only in `self` but also by traversing the call stack to find the nearest `self` instance that has `$@config`. With this, the code could be written as follows: ```ruby class MyApp class Part1 def run $@config[:part1] # accesses MyApp's $@config end end class Part2 def run $@config[:part2] end end def initialize(config) $@config = config @part1 = Part1.new @part2 = Part2.new end def run @part1.run @part2.run end end app1 = MyApp.new({ part1: ..., part2: ... }) app2 = MyApp.new({ part1: ..., part2: ... }) app1.run app2.run ``` This behaves similarly to dynamically scoped variables but differs in that it is resolved through the `self` instances. (`Thread.new` is a bit problematic: if you use `Thread.new` in a method of `MyApp::Part1`, you wouldn't have access to `$@config` in it. It might be nice to take over all `$@x` variables.) ## Feedback wanted Whenever I write a large Ruby application, I encounter this problem. However, TBH, I am not entirely confident that my proposed solution is the best one. Do you ever encounter this problem? How do you deal with the problem when you do? Is there a better workaround? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121420] [Ruby Bug#18878] parse.y: Foo::Bar {} is inconsistently rejected
by qnighy (Masaki Hara) 21 Mar '25

21 Mar '25

Issue #18878 has been updated by qnighy (Masaki Hara). Now `Foo::Bar {}` parses in parse.y too, but `Foo::Bar {} + 1` still doesn't parse unlike in Prism. ---------------------------------------- Bug #18878: parse.y: Foo::Bar {} is inconsistently rejected https://bugs.ruby-lang.org/issues/18878#change-112403 * Author: qnighy (Masaki Hara) * Status: Open * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The following source doesn't parse: ```ruby Foo::Bar {} ``` despite the following: ```ruby bar # local variable or method call Bar # constant bar() # method call Bar() # method call bar {} # method call Bar {} # method call bar() {} # method call Bar() {} # method call Foo::bar # method call Foo::Bar # constant Foo::bar() # method call Foo::Bar() # method call Foo::bar {} # method call # Foo::Bar {} # SyntaxError Foo::bar() {} # method call Foo::Bar() {} # method call ``` Especially considering `Bar {}`, this looks like a missing implementation rather than an intentional behavior. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120128] [Ruby master Bug#20934] `UnboundMethod#bind_call` may cause "double free or corruption" with Ractor
by wanabe (_ wanabe) 20 Mar '25

20 Mar '25

Issue #20934 has been reported by wanabe (_ wanabe). ---------------------------------------- Bug #20934: `UnboundMethod#bind_call` may cause "double free or corruption" with Ractor https://bugs.ruby-lang.org/issues/20934 * Author: wanabe (_ wanabe) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-06T18:51:08Z :detached: 8ad6860ff7) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When I call `UnboundMethod#bind_call` on both main Ractor and child Ractor, probable errors can be encountered. Here is an issue reproduce script `ractor_issue.rb`. ``` def foo 10000.times do Object.instance_method(:object_id).bind_call(self) end end Ractor.new { foo } foo ``` And there are some examples of execution results. ``` $ ./miniruby -v ractor_issue.rb ruby 3.4.0dev (2024-12-06T18:51:08Z :detached: 8ad6860ff7) +PRISM [x86_64-linux] ractor_issue.rb:7: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. double free or corruption (fasttop) Aborted (core dumped) ``` ``` $ ./miniruby -v ractor_issue.rb ruby 3.4.0dev (2024-12-06T18:51:08Z :detached: 8ad6860ff7) +PRISM [x86_64-linux] ractor_issue.rb:7: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x00007fc6c16bfb18 run> terminated with exception (report_on_exception is true): ractor_issue.rb:3:in 'UnboundMethod#bind_call': undefined method 'object_id' for main (NoMethodError) from ractor_issue.rb:3:in 'block in Object#foo' from <internal:numeric>:257:in 'Integer#times' from ractor_issue.rb:2:in 'Object#foo' from ractor_issue.rb:8:in '<main>' ``` Please try running it several times, as there is a probability of successful completion. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:121205] [Ruby master Feature#21163] Inconsistencies in Kernel.Float compared to other number parsing methods
by herwin (Herwin W) 19 Mar '25

19 Mar '25

Issue #21163 has been reported by herwin (Herwin W). ---------------------------------------- Feature #21163: Inconsistencies in Kernel.Float compared to other number parsing methods https://bugs.ruby-lang.org/issues/21163 * Author: herwin (Herwin W) * Status: Open ---------------------------------------- Not sure if I consider the following points to be bugs, but they sure did surprise me: Item 1: Hexadecimal is the only prefix accepted If you use the "0x" prefix, your value is parsed as hexadecimal float: ```ruby Float("0x10") # => 16.0 Float("0x0.8") # => 0.5 # Since Ruby 3.4 ``` This is the only accepted prefix, "010" is not parsed as octal, but as decimal 10. "0b10" and "0o10" are parse errors. If "0x" works, I would expect these to work too. Item 2: Inconsistency with String#to_f String#to_f does not parse hexadecimal strings, "0x10".to_f simply returns 0.0. Generally, the methods in Kernel are stricter than the methods on String, so valid input for the Kernel methods yields the same result in the String methods, I think this is the only exception Item 3: Inconsistency with Kernel#Integer ```ruby Integer("0x1_0a") # => 0x10a Float("0x1_0") # => 16.0 # This underscore is accepted Float("0x1_0a") # => ArgumentError ``` Kernel.Float does accept underscores in hexadecimal strings, but only if all values are digits. As soon as there is a `[a-fA-F]` in the input, it is an ArgumentError -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121239] [Ruby master Bug#21170] Corrupted Hash (bad VALUE and missing entry) when -1 returned from .hash
by jhawthorn (John Hawthorn) 19 Mar '25

19 Mar '25

Issue #21170 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21170: Corrupted Hash (bad VALUE and missing entry) when -1 returned from .hash https://bugs.ruby-lang.org/issues/21170 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` ruby class MyObj attr_reader :hash def initialize(val) = @hash = val end values = 0.downto(-16).to_a hash = {} values.each do |val| hash[MyObj.new(val)] = val end p hash.values # => [0, -2, -3, -4, -5, -6, -7, -8, -9, -10, -11, -12, -13, -14, -15, false, -16] ``` --- st_table reserves -1 as a special hash value to indicate that an entry has been deleted. So that that's a valid value to be returned from the hash function, do_hash replaces -1 with 0 so that it is not mistaken for the sentinel. Previously, when upgrading an AR table to an ST table, rb_st_add_direct_with_hash was used which did not perform the same conversion, this could lead to a hash in a broken state where one if its entries which was supposed to exist being marked as a tombstone. The hash could then become further corrupted when the ST table required resizing as the falsely tombstoned entry would be skipped but it would be counted in num entries, leading to an uninitialized entry at index 15. https://github.com/ruby/ruby/pull/12852 -- https://bugs.ruby-lang.org/

5 5