- ruby-core - ml.ruby-lang.org

[ruby-core:124901] [Ruby Bug#21931] GC Crash in `String#%` (backport 726205b354d1068147719fb42e1de743f1838ef1)
by byroot (Jean Boussier) 03 Mar '26

03 Mar '26

Issue #21931 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21931: GC Crash in `String#%` (backport 726205b354d1068147719fb42e1de743f1838ef1) https://bugs.ruby-lang.org/issues/21931 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: WONTFIX, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Reproduction ```ruby GC.stress = true class Args def to_ary Array.new(64) { "x" * 1024 } end end fmt = "%s" * 64 100_000.times do fmt % Args.new end ``` Patch that should be backported https://github.com/ruby/ruby/commit/726205b354d1068147719fb42e1de743f1838ef1 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124891] [Ruby Misc#21928] Prism backport handling
by Earlopain (Earlopain _) 03 Mar '26

03 Mar '26

Issue #21928 has been reported by Earlopain (Earlopain _). ---------------------------------------- Misc #21928: Prism backport handling https://bugs.ruby-lang.org/issues/21928 * Author: Earlopain (Earlopain _) * Status: Open * Assignee: prism ---------------------------------------- https://bugs.ruby-lang.org/issues/21927 got marked for backport for 4.0 and 3.4. It's a trivial fix but since prism is a gem, ruby should contain a released version of prism only. 3.4 in particular currently contains prism 1.5.2. Backporting to that version would require at least two changes in `ruby/ruby` because of changes in prism itself. So it is not as easy as just `tool/sync_default_gems`. Currently the practise has been to just backport the lastest prism version but personally I don't think that is sustainable. At best it causes more work than necessary and at worst you get fresh new bugs in what is supposed to be a stable ruby release. https://github.com/ruby/prism/pull/3231 is a good example of something that should not be backported to all maintained ruby versions when it gets merged. I propose to maintain stable branches for prism. Branch maintainers can simply cherry-pick what they think should be backported and prism takes care of releasing the appropriate versions, branched from the version that the stable ruby version originally shipped with. As far as I'm aware, that's also the strategy other gems go with. It happens less frequent now that many gems are no longer standard gems but openssl for example has branches for this purpose https://github.com/ruby/openssl/branches. I'm not sure how it handles versions, some gems I see do `1.2.3.4` which doesn't exactly follow semver, but it should possible to do it by following semver. What do you think @kddnewton? I know that so far you've wanted to do the latest stable version but I think prism is too intertwined with ruby itself for the current approach. Especially now that there are two stable branches that ship with prism it doesn't get easier. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124893] [Ruby Bug#14582] Unable to use `method__entry` and `method_return` tracing probes since 2.5
by jacobcarlborg (Jacob Carlborg) 01 Mar '26

01 Mar '26

Issue #14582 has been updated by jacobcarlborg (Jacob Carlborg). I've created a pull request to fix this: https://github.com/ruby/ruby/pull/16084. ---------------------------------------- Bug #14582: Unable to use `method__entry` and `method_return` tracing probes since 2.5 https://bugs.ruby-lang.org/issues/14582#change-116552 * Author: guilhermereiscampos (Guilherme Reis Campos) * Status: Open * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Hi, I am trying to use dtrace/systemtap probes and not being able to use it after the 2.5. The 2.4 version works fine. I was hoping this was fixed on 2.6-preview, but apparently not (just downloaded dev and tested). I tried on OSX using dtrace and also on ubuntu (vagrant). ``` # test.rb class Foo def bar 100.times { "Bar" } end end foo = Foo.new foo.bar # test.stp probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__entry") # you will need to change this to your ruby path of your version. { printf("%s => %s.%s in %s:%d\n", thread_indent(1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__return") { printf("%s <= %s.%s in %s:%d\n", thread_indent(-1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } ``` dtrace was something similar to it. I was expecting to see this output: ``` # lots of calls # .... # then: 4090 ruby(9667): <= Gem::Specification.unresolved_deps in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/specification.rb:1298 4095 ruby(9667): => MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:197 4100 ruby(9667): => MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:247 4104 ruby(9667): <= MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:251 4109 ruby(9667): <= MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:204 4283 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 4303 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 0 ruby(9667): => Foo.bar in test.rb:3 16 ruby(9667): <= Foo.bar in test.rb:5 ``` (The output above is 2.4) my ruby (all versions that I tested) was install with rb-env: ``` RUBY_CONFIGURE_OPTS='--enable-dtrace --disable-install-doc' rbenv install 2.5.0 ``` I am happy to provide details if required. I'd also be happy to fix it if I have guidance. Thanks, -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123894] [Ruby Bug#21709] Inconsistent encoding by Regexp.escape
by thyresias (Thierry Lambert) 26 Feb '26

26 Feb '26

Issue #21709 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #21709: Inconsistent encoding by Regexp.escape https://bugs.ruby-lang.org/issues/21709 * Author: thyresias (Thierry Lambert) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby %w(foo être).each do |s| puts "string: #{s.inspect} -> #{s.encoding}" puts "escaped: #{Regexp.escape(s).inspect} -> #{Regexp.escape(s).encoding}" end ``` Output: ``` string: "foo" -> UTF-8 escaped: "foo" -> US-ASCII string: "être" -> UTF-8 escaped: "être" -> UTF-8 ``` The result should always match the encoding of the argument. -- https://bugs.ruby-lang.org/

5 13

[ruby-core:124878] [Ruby Feature#4477] Kernel:exec and backtick (`) don't work for certain system commands
by schneems (Richard Schneeman) 24 Feb '26

24 Feb '26

Issue #4477 has been updated by schneems (Richard Schneeman). Just found out about this behavior today when this code ``` out = `command -v ruby` ``` Works on my mac but not on linux (github actions) with an error `Errno::ENOENT: No such file or directory - command`. That is because on my mac `command` is ALSO on the PATH, but on linux it is not. I could fix it by adding a redirect ``` out = `command -v ruby 2>/dev/null` ``` Which triggers the shell behavior. I find it surprising that exec mentions this behavior https://www.rubydoc.info/stdlib/core/Kernel:exec but backticks https://ruby-doc.org/3.4.1/Kernel.html#method-i-60 doesn't. ---------------------------------------- Feature #4477: Kernel:exec and backtick (`) don't work for certain system commands https://bugs.ruby-lang.org/issues/4477#change-116537 * Author: JWuttke (Joachim Wuttke) * Status: Closed * Assignee: akr (Akira Tanaka) ---------------------------------------- From documentation and common sense, I would expect that Kernel:exec and backtick (`) work for _all_ kind of system commands. This is currently not the case. ~$ cat test1 echo success ~$ cat test2 #!/bin/sh echo success ~$ chmod a+x test? ~$ ruby1.8 -e 'p `test1`' -e:1: command not found: test1 "" ~$ ruby1.9 -e 'p `test1`' -e:1:in ``': Exec format error - test1 (Errno::ENOEXEC) from -e:1:in `<main>' ~$ ruby1.8 -e 'p `test2`' "success\n" ~$ ruby1.9 -e 'p `test2`' "success\n" This problem has been reported before (#3856: strange Kernel#exec behavior with bash's source command). As a workaround, it has been suggested to append a semikolon to the system command: ~$ ruby1.8 -e 'p `test1;`' "success\n" ~$ ruby1.9 -e 'p `test1;`' "success\n" The report #3856 has been closed with the decision "not a bug". This I cannot accept. For many years, I got used to run system commands through `<cmd>`. When it failed, I spent painfully long time to search for a bug in my Ruby code and in the system command before I realized the problem was due to an unexpected restriction of Ruby's exec/backtick. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124497] [Ruby Feature#21835] Unbundle bunled gems like net-ftp
by hsbt (Hiroshi SHIBATA) 24 Feb '26

24 Feb '26

Issue #21835 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21835: Unbundle bunled gems like net-ftp https://bugs.ruby-lang.org/issues/21835 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- I would like to unundle the following bundled gems: * net-ftp * net-pop * prime The main purpose of bundled gems is to ensure their functionality by running tests with ruby head every time. However, the above gems for older protocols or purposes should be handled the same as other regular gems. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:117027] [Ruby master Bug#20319] Singleton class is being frozen lazily in some cases
by andrykonchin (Andrew Konchin) 24 Feb '26

24 Feb '26

Issue #20319 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #20319: Singleton class is being frozen lazily in some cases https://bugs.ruby-lang.org/issues/20319 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I've noticed suspicious behaviour (it doesn't affect anything in practice for me though) when an object becomes frozen only its own singleton class becomes frozen immediately. A singleton class of the immediate singleton class becomes frozen lazily after `#singleton_class` method call: ```ruby o = Object.new klass = o.singleton_class.singleton_class o.freeze puts klass.frozen? # false <== here we expect true puts o.singleton_class.singleton_class.frozen? # true puts klass.frozen? # true ``` I would expect all created singleton classes in an object singleton classes chain to become frozen immediately. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:124869] [Ruby Feature#21923] DTrace USDT probe Ruby method arguments and return value
by jacobcarlborg (Jacob Carlborg) 23 Feb '26

23 Feb '26

Issue #21923 has been reported by jacobcarlborg (Jacob Carlborg). ---------------------------------------- Feature #21923: DTrace USDT probe Ruby method arguments and return value https://bugs.ruby-lang.org/issues/21923 * Author: jacobcarlborg (Jacob Carlborg) * Status: Open ---------------------------------------- I'm interested in improving the DTrace USDT probes in Ruby. I would like to expose the Ruby method arguments and return value to the DTrace probes `(c)method-entry` and `(c)method-return`. This would be done by adding a fifth argument to the DTrace probes. For `method-entry` this would be the Ruby arguments the Ruby method is called with and for `method-return` it would be the Ruby return value the Ruby method returned. My idea is to serialize the arguments as a JSON array and pass that as a C string, containing the JSON data, to the USDT probes. On the DTrace side, there's a `json` function available that can be used to extract parts of the JSON structure using a simple query string, example: `json(copyinstr(arg4), "success.foo.bar[1].baz")`. Because the serialization can fail, the top level JSON member would be `success` or `error` indicating if the serialization was successful or not. Using JSON to pass data to a DTrace USDT probe has precedence in the form of a Rust crate [1], created by one of the original DTrace authors, that uses the same approach. I have a proof of concept implementing this. I would like to get some feedback on how to best implement this. I think the main challenge is how to implement this without any side effects. Ruby already has support for serializing to JSON, but that is implemented in a separate gem, using a C extension. The challenges I see are: * There shouldn't be any side effects when enabling DTrace probes, therefore directly using the gem is not a good alternative. It needs to load a dynamic library and new constants will become available to the Ruby code, if this gem is used. * The JSON serialization for DTrace needs to live in the Ruby VM and not in a separate gem. The question is then: should the JSON serialization for the gem and the DTrace probes be shared? Alternatively there could be an implementation of JSON serialization, for the gem, and a DTrace probe argument serialization, that happens to use JSON, but would be an implementation detail. * If the JSON serialization should be shared between DTrace probes and the gem, is there a mechanism to share code between the Ruby VM and a gem without publicly exposing it, i.e. to C extensions? Or would there need to be an official JSON API that other C extensions could use? * The current JSON implementation relies on exceptions. For DTrace, it would be better not to rely on exceptions. But I guess it would be possible to catch all exceptions. * The current JSON implementation will, except for the `JSON` class, expose some additional constants which should not happen when using DTrace. This will introduce side effects. This should be possible to handle by slightly modifying the implementation. * The current JSON serialization supports customizing the serialization by implementing the `to_json`/`as_json` methods. If serializing DTrace arguments with support for the `to_json`/`as_json` methods, the advantage is that this is already implemented by some third-party libraries. The disadvantage is that it could cause side effects. * When DTrace probes are enabled and serializing the DTrace probe arguments and some Ruby methods are called, it would be best if those weren't traced. Can a global variable be used to check if the Ruby VM already is currently serializing DTrace probe arguments? Or is an atomic or thread-local variable necessary? Or is there a better alternative to do this? [1] https://github.com/oxidecomputer/usdt -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124868] [Ruby Feature#19107] Allow trailing comma in method signature
by Earlopain (Earlopain _) 23 Feb '26

23 Feb '26

Issue #19107 has been updated by Earlopain (Earlopain _). > What about the lambda arguments? @nobu it's unclear to me so I didn't change them. I added https://bugs.ruby-lang.org/issues/21875 to the next dev meeting. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116524 * Author: byroot (Jean Boussier) * Status: Closed * Assignee: core ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124867] [Ruby Feature#19107] Allow trailing comma in method signature
by nobu (Nobuyoshi Nakada) 23 Feb '26

23 Feb '26

Issue #19107 has been updated by nobu (Nobuyoshi Nakada). Assignee changed from prism to core What about the lambda arguments? commit:731b6092e9268af960bf0f060e37504f4deb7380 seems not to allow `->(a,) {}`. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116523 * Author: byroot (Jean Boussier) * Status: Closed * Assignee: core ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0