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

[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

[ruby-core:114936] [Ruby master Feature#19908] Update to Unicode 15.1
by nobu (Nobuyoshi Nakada) 18 Mar '25

18 Mar '25

Issue #19908 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #19908: Update to Unicode 15.1 https://bugs.ruby-lang.org/issues/19908 * Author: nobu (Nobuyoshi Nakada) * Status: Assigned * Priority: Normal * Assignee: duerst (Martin Dürst) * Target version: 3.3 ---------------------------------------- The Unicode 15.1 is released. The current enc-unicode.rb seems to fail because of `Indic_Conjunct_break` properties with values. I'm not sure how these properties should be handled well. `/\p{InCB_Liner}/` or `/\p{InCB=Liner}/` as the comments in that file? https://github.com/nobu/ruby/tree/unicode-15.1 is the former. -- https://bugs.ruby-lang.org/

14 23

[ruby-core:120961] [Ruby master Bug#21131] IO.copy_stream: yielded string changes value when duped
by chucke (Tiago Cardoso) 16 Mar '25

16 Mar '25

Issue #21131 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #21131: IO.copy_stream: yielded string changes value when duped https://bugs.ruby-lang.org/issues/21131 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I found an odd situation, when using IO.copy_stream with a File writer quack class, where the data passed to #write somehow ends overwritten, despite the instance being duped. class ProcIO def initialize(block) @block = block end # Implementation the IO write protocol, which yield the given chunk to +@block+. def write(data) @block.call(data.dup) data.bytesize end end rng = Random.new(42) body = Tempfile.new("ruby-bug", binmode: true) body.write(rng.bytes(16_385)) body.rewind payload = [] block = ->(data){ payload << data.dup } IO.copy_stream(body, ProcIO.new(block)) body.rewind if payload.join != body.read puts "it's a bug" end if you use the debugger, you'll see that the first yielded chunk has the correct bytes when yielded the first time, but when the second 1 byte chunk is yielded (IO.copy_stream reads in chunks of 16384 bytes), the first chunk string value suddenly changes. This should not happen, as the first yielded chunk was a string duped from the string yielded by IO.copy_stream (which is expected to be a buffer). -- https://bugs.ruby-lang.org/

5 5

[ruby-core:121083] [Ruby master Bug#21144] Win32: Use Windows time zone ID as the time zone name if TZ is not set
by nobu (Nobuyoshi Nakada) 16 Mar '25

16 Mar '25

Issue #21144 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21144: Win32: Use Windows time zone ID as the time zone name if TZ is not set https://bugs.ruby-lang.org/issues/21144 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ### Problem On Windows, the `Time#zone` uses `_tzname` provided by the runtime library. This is obtained by using `GetTimeZoneInformation`, if the `TZ` environment variable is not set or empty. The problem is that the `StandardName` and `DaylightName` in that information are for UI, and localized. This means that these names may vary across different international editions and language packs, even for the same time zone. ### Solution Use the Windows time zone ID by using `GetDynamicTimeZoneInformation`, which is available since Windows Vista and Windows Server 2008. Since the `TimeZoneKeyName` is the registry key of time zones, the above problem does not occur. This is also mitigate [Bug #20929]. Even it is possible to define non-ascii key name time zone, there is no such name in the standard installations. ### Compatibilities etc - This also changes the result of `Time#inspect`, may not be good for ones who prefer the display names for UI. - There is no way to restore `zone` from `Marshal` data, this does *not* improve. - The PR changes the signature of `ruby_reset_timezone()` and marks internal use only, but this function is declared in `internal/time.h` and probably no problem. -- https://bugs.ruby-lang.org/

4 4