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

[ruby-core:120895] [Ruby master Bug#21117] Inconsistent behaviour between "_1" and "it" variables
by radarek 30 Mar '25

30 Mar '25

Issue #21117 has been reported by radarek (Radosław Bułat). ---------------------------------------- Bug #21117: Inconsistent behaviour between "_1" and "it" variables https://bugs.ruby-lang.org/issues/21117 * Author: radarek (Radosław Bułat) * 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 ---------------------------------------- I believe variables `_1` and `it` should have consistent behaviour and the same as normal local variables. Here are inconsistencies: ```ruby # 1. Assigning new value [1, 2, 3].each { |v| v = v + 1; p v } # works as expected [1, 2, 3].each { it = it + 1; p it } # works as expected [1, 2, 3].each { _1 = _1 + 1; p _1 } # SyntaxError # 2. Using operators like += on them [1, 2, 3].each { |v| v += 1; p v } # works as expected [1, 2, 3].each { it += 1; p it } # SyntaxError but I expected it to work correctly after 1st point [1, 2, 3].each { _1 += 1; p _1 } # works, which is inconsistent with 1 point # however, this one does not work [1, 2, 3].map { _1 += 1 } # runtime error is raised: undefined method '+' for nil (NoMethodError) ``` If both `_1` and `it` are advertised as block local variables then I would expect that overwriting works correctly, both using expressions like `_1 = _1 + 1` and `_1 *= 2`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:120808] [Ruby master Bug#21094] Module#set_temporary_name does not affect a name of a nested module
by andrykonchin (Andrew Konchin) 29 Mar '25

29 Mar '25

Issue #21094 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21094: Module#set_temporary_name does not affect a name of a nested module https://bugs.ruby-lang.org/issues/21094 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Wondering whether it's intentional and correct behaviour: ```ruby m = Module.new m::N = Module.new p m::N.name # => "#<Module:0x000000010d0a00b0>::N" m.set_temporary_name("foo") p m::N.name # => "#<Module:0x000000010d0a00b0>::N" ``` I would expect that setting `foo` as a temporary name changes `m::N.name` to `foo::N`. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114410] [Ruby master Bug#19841] Marshal.dump stack overflow with recursive Time
by segiddins (Samuel Giddins) 29 Mar '25

29 Mar '25

Issue #19841 has been reported by segiddins (Samuel Giddins). ---------------------------------------- Bug #19841: Marshal.dump stack overflow with recursive Time https://bugs.ruby-lang.org/issues/19841 * Author: segiddins (Samuel Giddins) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` ruby #!/usr/bin/env ruby puts RUBY_VERSION t = Time.at(0, 1, :nanosecond) t.instance_variable_set :@itself, t Marshal.dump(t) ``` Yields a stack overflow error from the `Marshal.dump` call, even though Marshal is explicitly able to handle cyclical references -- https://bugs.ruby-lang.org/

6 8

[ruby-core:120979] [Ruby master Feature#21133] [ruby/logger] Add an option to disable writing the header when creating a new log file
by viralpraxis (Iaroslav Kurbatov) 27 Mar '25

27 Mar '25

Issue #21133 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Feature #21133: [ruby/logger] Add an option to disable writing the header when creating a new log file https://bugs.ruby-lang.org/issues/21133 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open ---------------------------------------- Creating a logger automatically writes a hardcoded header comment ("# Logfile created on ..."): https://github.com/ruby/logger/blob/0eb10f2d278435899ce9055c98eb5b53caa0092… As far as I can see, it helps to verify that logdev is writable as early as possible (rather than on the first log entry) and it also serves as a useful indicator of which program created the logfile. However, this header can introduce unnecessary complexity is some use-cases -- especially when working with third-party tools that need to ignore these lines. I think it might make sense to add a new configuration option (`skip_header`) which will be `false` by default so the changes are backward-compatible. Proposed implementation: https://github.com/ruby/logger/pull/119 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:114147] [Ruby master Bug#19765] Ractor.make_shareable ignores self of a proc created from a Method
by Ethan (Ethan -) 27 Mar '25

27 Mar '25

Issue #19765 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #19765: Ractor.make_shareable ignores self of a proc created from a Method https://bugs.ruby-lang.org/issues/19765 * Author: Ethan (Ethan -) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-07-12T00:26:03Z master dfe782be17) [x86_64-darwin21] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- An unshareable receiver of a Proc or a Method will cause make_shareable to error, but this does not happen with a proc from Method#to_proc: ```ruby str = "" a = str.instance_exec { proc { to_s } } Ractor.make_shareable a # => <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00000001064b62c8 (irb):1> (Ractor::IsolationError) b = str.instance_exec { method(:to_s) } Ractor.make_shareable b # => <internal:ractor>:820:in `make_shareable': can not make shareable object for #<Method: String#to_s()> (Ractor::Error) c = str.instance_exec { method(:to_s).to_proc } Ractor.make_shareable c c.call # => "" str[0] = "!" c.call # => "!" ``` Related, maybe: #19372 #19374 Tangential: why does Proc cause Ractor::IsolationError but Method causes Ractor::Error? -- https://bugs.ruby-lang.org/

3 2

[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: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: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