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

[ruby-core:121247] [Ruby master Bug#21173] RUBY_FREE_AT_EXIT does not work when error in -r
by peterzhu2118 (Peter Zhu) 19 Mar '25

19 Mar '25

Issue #21173 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21173: RUBY_FREE_AT_EXIT does not work when error in -r https://bugs.ruby-lang.org/issues/21173 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- PR: https://github.com/ruby/ruby/pull/12859 When loading a file using the command line -r, it is processed before RUBY_FREE_AT_EXIT is checked. So if the loaded file raises an error, it will cause memory to not be freed with RUBY_FREE_AT_EXIT. For example `ruby -rtest.rb -e ""` will report a large amount of memory leaks if `test.rb` raises. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121278] [Ruby master Bug#21179] Introduction Happy Eyeballs Version 2 broke `Socket.tcp` from secondary Ractors
by byroot (Jean Boussier) 19 Mar '25

19 Mar '25

Issue #21179 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21179: Introduction Happy Eyeballs Version 2 broke `Socket.tcp` from secondary Ractors https://bugs.ruby-lang.org/issues/21179 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- ```ruby require "socket" Ractor.new do Socket.tcp("example.com", 80) end.take ``` ``` socket.rb:1046:in 'Socket::HostnameResolutionStore#get_addrinfo': can not access non-shareable objects in constant Socket::HostnameResolutionStore::PRIORITY_ON_V6 by non-main ractor. (Ractor::IsolationError) from socket.rb:724:in 'block in Socket.tcp_with_fast_fallback' from socket.rb:720:in 'Socket.tcp_with_fast_fallback' ``` Proposed patch: https://github.com/ruby/ruby/pull/12896 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121403] [Ruby Bug#21192] Coverage no longer reports coverage information about tracepoint handlers
by deivid 19 Mar '25

19 Mar '25

Issue #21192 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #21192: Coverage no longer reports coverage information about tracepoint handlers https://bugs.ruby-lang.org/issues/21192 * Author: deivid (David Rodríguez) * Status: Open * ruby -v: 2.6 until now * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I minimized the issue like this: ### repro.rb ```ruby require "coverage" Coverage.start require_relative "a" puts Coverage.result ``` ### a.rb ```ruby TracePoint.trace(:line) do |tp| puts "TracePoint handler" end puts "Outside" ``` In Ruby 2.5, program's out was: ``` $ docker run --rm -it --mount type=bind,source=$(pwd),target=/foo ruby:2.5 ruby /foo/repro.rb TracePoint handler Outside TracePoint handler {"/foo/a.rb"=>[1, 2, nil, nil, 1]} ``` In Ruby 2.6 or higher: ``` $ docker run --rm -it --mount type=bind,source=$(pwd),target=/foo ruby:3.4 ruby /foo/repro.rb TracePoint handler Outside TracePoint handler {"/foo/a.rb" => [1, 0, nil, nil, 1]} ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:121399] [Ruby Feature#15854] Tracing instance variable assignment
by Eregon (Benoit Daloze) 18 Mar '25

18 Mar '25

Issue #15854 has been updated by Eregon (Benoit Daloze). I think tracing ivar assignments would be prohibitively slow, and so probably not really usable in practice. ---------------------------------------- Feature #15854: Tracing instance variable assignment https://bugs.ruby-lang.org/issues/15854#change-112374 * Author: igaiga (Kuniaki Igarashi) * Status: Assigned * Assignee: ko1 (Koichi Sasada) ---------------------------------------- I suggest a feature "tracing instance variable assignment". It's useful for debugging. Use case: In Rails, we use instance variables in views and controllers. When we got a bug caused by instance variable unintentional values, if we traced instance variable assignment timing, it would be good informations. And in Rails views, there are no source codes of self class. That's built dynamically. Current behavior (Ruby2.6): In Ruby 2.6, only if there is a source code file to assign instance variable, we can trace instance variable assignment by following code (check_instance_variable_assignment.rb). But it's difficult if the assignment codes are defined dynamically. For example, in Rails view. (And in another story, global variables assignment are traced by Kernel#trace_var.) check_instance_variable_assignment.rb ```ruby def trace_start TracePoint.trace(:line) do |tp| target_class_name = "Foo" target_instance_variable_name = "@bar" line = File.open(tp.path, "r"){|f| f.readlines[tp.lineno - 1] } node = RubyVM::AbstractSyntaxTree.parse(line).children.last # check instance variable assignment next unless node.type == :IASGN # check class name target_class = Kernel.const_get(target_class_name) next unless tp.self.is_a?(target_class) # check variable name instance_variable_name = node.children.first next unless instance_variable_name == target_instance_variable_name.to_sym puts "#{target_class_name} #{target_instance_variable_name} is assigned in #{tp.path}:#{tp.lineno} #{tp.defined_class} #{tp.method_id}" end end class Foo def bar @bar = "text" end end trace_start Foo.new.bar #=> Foo @bar is assigned in check_instance_variable_assignment.rb:25 Foo bar ``` Suggesting feature example: Add new arguments for TracePoint.new method like :line and :call to trace instance variables assignment. - :iasgn (IASGN name from RubyVM::AbstractSyntaxTree::Node) - :casgn (CVASGN (or CASGN?) name from RubyVM::AbstractSyntaxTree::Node. I think class variables tracing is useful too.) And get informations - class name (It might be get by trace_point.self) - variable name ("@foo", "@@foo") A sample code to use the feature: tp_iasgn.rb ```ruby TracePoint.trace(:iasgn) do |tp| target_class_name = "Foo" target_instance_variable_name = "@bar" # check class name target_class = Kernel.const_get(target_class_name) next unless tp.self.is_a?(target_class) # check variable name next unless target_instance_variable_name == tp.variable_name puts "#{target_class_name} #{target_instance_variable_name} is assigned in #{tp.path}:#{tp.lineno} #{tp.method_id} #{tp.defined_class}" puts caller # even in dynamic code case, we can get caller informations. end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121394] [Ruby Feature#21190] Proposal for the Deconstruct Method in the MatchData Class
by aristotelesbr 18 Mar '25

18 Mar '25

Issue #21190 has been reported by aristotelesbr (Aristóteles Costa). ---------------------------------------- Feature #21190: Proposal for the Deconstruct Method in the MatchData Class https://bugs.ruby-lang.org/issues/21190 * Author: aristotelesbr (Aristóteles Costa) * Status: Open ---------------------------------------- ## Context: The MatchData class currently lacks the deconstruct method, which is necessary for extracting values from a string using pattern matching in Ruby. ## Current Extraction Method Currently, extraction can be done as follows: ```rb result = /(\d{2})(\d{2})(\d{9})/.match("5586987654321") puts result[1] # => "55" puts result[2] # => "86" puts result[3] # => "987654321" ``` ## Proposed Solution: Implement the deconstruct method in the MatchData class to allow conversion of the MatchData object into an array, enabling deconstruction of its components. ```rb class MatchData def deconstruct self.to_a end end result = /(\d{2})(\d{2})(\d{9})/.match("5586987654321") result in [_ , country_code, area_code, number] puts country_code # => "55" puts area_code # => "86" puts number # => "987654321" ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121392] [Ruby Misc#21189] Canonical Git server hardening
by hsbt (Hiroshi SHIBATA) 18 Mar '25

18 Mar '25

Issue #21189 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #21189: Canonical Git server hardening https://bugs.ruby-lang.org/issues/21189 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- I'm working hardening git.ruby-lang.org and ruby organization of GitHub in recent days. Our write grant policy is: 1. Add account name and email address of git configuration to https://github.com/ruby/git.ruby-lang.org/blob/master/config/email.yml 2. Add account name and public key to https://github.com/ruby/git.ruby-lang.org/blob/master/recipes/files/var/git… 3. (Optional) GitHub account with 1 and 2 configuration. I found that some committers are incomplete or inconsistency configuration for Git server and GitHub. I removed write grant of GitHub repository from the following users because they didn't register `email.yml` and `authorized_keys`. ``` - luislavena - xibbar - nahi - haileys - sonots - gogotanaka - gotoyuzo - aamine ``` The following users didn't register their pubkeys into `authorized_keys`. ``` - drbrain - eban - gotoken - seki - suke - wanabe ``` The following users didn't register their mail address into `email.yml`. ``` - charliesome - dblack - emboss - funny_falcon - gogotanaka - hone - kanemoto - keiju - kosako - sonots - tarui - tmm1 - wyhaines ``` I will remove them from `email.yml` and `authorized_keys`. I will recover your account if you hope to keep write grant of our Git server and GitHub. Please send your key and mail address to https://github.com/ruby/git.ruby-lang.org/. -- https://bugs.ruby-lang.org/

1 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:121388] [Ruby Feature#15854] Tracing instance variable assignment
by st0012 (Stan Lo) 17 Mar '25

17 Mar '25

Issue #15854 has been updated by st0012 (Stan Lo). How about this naming convention: - `ivar_set` - `cvar_set` - `gvar_set` `ivar`, `cvar`, and `gvar` all match Ruby's [internal glossary](https://docs.ruby-lang.org/en/master/contributing/glossary_md.htm…, and is quite commonly used in the community too (based on my personal experience). I picked `set` because: - It matches the `*_variable_set` method names - It's one character shorter than `asgn` And finally, if nobody else is looking at this, I'd like to give it a try 🙂 ---------------------------------------- Feature #15854: Tracing instance variable assignment https://bugs.ruby-lang.org/issues/15854#change-112361 * Author: igaiga (Kuniaki Igarashi) * Status: Assigned * Assignee: ko1 (Koichi Sasada) ---------------------------------------- I suggest a feature "tracing instance variable assignment". It's useful for debugging. Use case: In Rails, we use instance variables in views and controllers. When we got a bug caused by instance variable unintentional values, if we traced instance variable assignment timing, it would be good informations. And in Rails views, there are no source codes of self class. That's built dynamically. Current behavior (Ruby2.6): In Ruby 2.6, only if there is a source code file to assign instance variable, we can trace instance variable assignment by following code (check_instance_variable_assignment.rb). But it's difficult if the assignment codes are defined dynamically. For example, in Rails view. (And in another story, global variables assignment are traced by Kernel#trace_var.) check_instance_variable_assignment.rb ```ruby def trace_start TracePoint.trace(:line) do |tp| target_class_name = "Foo" target_instance_variable_name = "@bar" line = File.open(tp.path, "r"){|f| f.readlines[tp.lineno - 1] } node = RubyVM::AbstractSyntaxTree.parse(line).children.last # check instance variable assignment next unless node.type == :IASGN # check class name target_class = Kernel.const_get(target_class_name) next unless tp.self.is_a?(target_class) # check variable name instance_variable_name = node.children.first next unless instance_variable_name == target_instance_variable_name.to_sym puts "#{target_class_name} #{target_instance_variable_name} is assigned in #{tp.path}:#{tp.lineno} #{tp.defined_class} #{tp.method_id}" end end class Foo def bar @bar = "text" end end trace_start Foo.new.bar #=> Foo @bar is assigned in check_instance_variable_assignment.rb:25 Foo bar ``` Suggesting feature example: Add new arguments for TracePoint.new method like :line and :call to trace instance variables assignment. - :iasgn (IASGN name from RubyVM::AbstractSyntaxTree::Node) - :casgn (CVASGN (or CASGN?) name from RubyVM::AbstractSyntaxTree::Node. I think class variables tracing is useful too.) And get informations - class name (It might be get by trace_point.self) - variable name ("@foo", "@@foo") A sample code to use the feature: tp_iasgn.rb ```ruby TracePoint.trace(:iasgn) do |tp| target_class_name = "Foo" target_instance_variable_name = "@bar" # check class name target_class = Kernel.const_get(target_class_name) next unless tp.self.is_a?(target_class) # check variable name next unless target_instance_variable_name == tp.variable_name puts "#{target_class_name} #{target_instance_variable_name} is assigned in #{tp.path}:#{tp.lineno} #{tp.method_id} #{tp.defined_class}" puts caller # even in dynamic code case, we can get caller informations. end ``` -- https://bugs.ruby-lang.org/

1 0

[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:121246] [Ruby master Bug#21172] Race condition in `register_fstring`
by byroot (Jean Boussier) 16 Mar '25

16 Mar '25

Issue #21172 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21172: Race condition in `register_fstring` https://bugs.ruby-lang.org/issues/21172 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: WONTFIX, 3.2: WONTFIX, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- This is a rare bug with very low criticality, but it can cause occasional CI failures. I leave it to branch maintainers to decide if it's worth backporting or not. ### Timeline - A `"foo" oid=1` string is interned. - `"foo" oid=1` is no longer referenced and will be swept in the future. - Another `"foo" oid=2` string is interned. - `register_fstring` finds `"foo" oid=1`, but since it is about to be swept, removes it from `fstring_table` and insert `"foo" oid=2` instead. - `"foo" oid=1` is swept, since it has the `RSTRING_FSTR` flag, a `st_delete` is issued in `fstring_table` which removes `"foo" oid=2`. Unfortunately, I couldn't come up with a minimal reproduction for this, but it did reproduce consistently with a large amount of tests and a very specific seed. ### Consequence This has little to no consequence on real world code. It just breaks a few ruby tests that is attempting to ensure some strings were interned. -- https://bugs.ruby-lang.org/

2 2