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

[ruby-core:124103] [Ruby Bug#21771] pg-1.6.2 testsuite segfaults in ruby4.0.0dev
by mtasaka (Mamoru TASAKA) 10 Dec '25

10 Dec '25

Issue #21771 has been reported by mtasaka (Mamoru TASAKA). ---------------------------------------- Bug #21771: pg-1.6.2 testsuite segfaults in ruby4.0.0dev https://bugs.ruby-lang.org/issues/21771 * Author: mtasaka (Mamoru TASAKA) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-09 master edca81a1bb) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Looks like pg-1.6.2 https://github.com/ged/ruby-pg/tree/c75ed8da19c356b52d83da2627295760780d3d36 testsuite began to segfault, especially the following ``` #!/bin/bash export PGPORT=54321 export RUBY_PG_TEST_DIR=/builddir/build/BUILD/tmp export RUBYLIB=/builddir/build/BUILD/rubygem-pg-1.6.2-build/pg-1.6.2/usr/share/gems/gems/pg-1.6.2/lib:/builddir/build/BUILD/rubygem-pg-1.6.2-build/pg-1.6.2/usr/lib64/gems/ruby/pg-1.6.2 # The above path should be replaced properly rm -rf $RUBY_PG_TEST_DIR exec ruby -S --verbose \ -r ./spec/helpers \ rspec -f d \ spec/pg/connection_spec.rb -E '' \ --seed 1 ``` segfaults like below (will write later) It seems that segfaults began to happen between commit:706d80830b9f0a5a2eac66251d1417abb2ff143c (no problem) and commit:d7e55f84f2bd62d302b29513d4c4dc8ae9aef96f (segfaults) Tried with commit:edca81a1bb72a9dc54a37766d2c80790dec13884 it still segfaults. Note that ruby-pg *compiled* with commit:706d80830b9f0a5a2eac66251d1417abb2ff143 does *not* segfault with ruby commit:edca81a1bb72a9dc54a37766d2c80790dec13884 , so I suspect that there is something wrong with "inlined" function or so. -- https://bugs.ruby-lang.org/

3 8

[ruby-core:124071] [Ruby Misc#21770] Stop bumping RUBY_PATCHLEVEL in released versions
by k0kubun (Takashi Kokubun) 09 Dec '25

09 Dec '25

Issue #21770 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #21770: Stop bumping RUBY_PATCHLEVEL in released versions https://bugs.ruby-lang.org/issues/21770 * Author: k0kubun (Takashi Kokubun) * Status: Open ---------------------------------------- ## Proposal * Stop bumping `RUBY_PATCHLEVEL` from `0` in Ruby 4.0.0+ ## Motivation * As a stable branch maintainer, I find it frustrating that reverting a commit made by `tool/merger.rb` often causes a conflict on `#define RUBY_PATCHLEVEL`. ## Background * From Ruby 2.1.0, we stopped doing multiple patch-level releases for a single version, e.g. [2.0.0-p647](https://www.ruby-lang.org/en/news/2015/08/18/ruby-2-0-0-p647-re… and [2.0.0-p648](https://www.ruby-lang.org/en/news/2015/12/16/ruby-2-0-0-p648-re… for Ruby 2.0.0. * From Ruby 3.2.0, we stopped showing patch levels on `RUBY_DESCRIPTION` [Feature #18513]. We thought "patch levels no longer serves us very well". * Today, we also backport patches using pull requests on GitHub. We often don't bump `RUBY_PATCHLEVEL` there because it's easier to use `git cherry-pick` instead of `tool/merger.rb`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123951] [Ruby Bug#21719] Thread deadlock with explicit require of a base clase in Linux Ruby 3.4
by jcuello＠fu.do (Juan Manuel Cuello) 09 Dec '25

09 Dec '25

Issue #21719 has been reported by jcuello(a)fu.do (Juan Manuel Cuello). ---------------------------------------- Bug #21719: Thread deadlock with explicit require of a base clase in Linux Ruby 3.4 https://bugs.ruby-lang.org/issues/21719 * Author: jcuello(a)fu.do (Juan Manuel Cuello) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I originally [reported the issue](https://github.com/fxn/zeitwerk/issues/321) in Zeitwerk, but we then figured out that it seems to be related to Ruby. Basically, I'm having a threads deadlock when using requires with autoloadable classes: ```ruby # jobs/base.rb # module Jobs class Base end end # jobs/a.rb # require './jobs/base' module Jobs class A < Base def perform puts self.class.name end end end # jobs/b.rb # module Jobs class B < Base def perform puts self.class.name end end end # start.rb # module Jobs autoload :Base, './jobs/base' autoload :A, './jobs/a' autoload :B, './jobs/b' end a = Thread.new { Jobs::A.new.perform } b = Thread.new { Jobs::B.new.perform } a.join b.join ``` ``` ruby --version && ruby start.rb ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] start.rb:12:in 'Thread#join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x00005ca30dfbc500 main thread:0x00005ca30dd30330 * #<Thread:0x000076b1a7d6a658 sleep_forever> rb_thread_t:0x00005ca30dd30330 native:0x000076b1a81b87c0 int:0 * #<Thread:0x000076b1a7d2e928 start.rb:9 sleep_forever> rb_thread_t:0x00005ca30dfbc500 native:0x000076b18c74d6c0 int:0 depended by: tb_thread_id:0x00005ca30dd30330 * #<Thread:0x000076b1a7d2e3b0 start.rb:10 sleep_forever> rb_thread_t:0x00005ca30dfb0fd0 native:0x000076b18c54b6c0 int:0 mutex:0x00005ca30dfe2b60 cond:1 from start.rb:12:in '<main>' ``` Note the require './jobs/base' in `jobs/a.rb`. If I remove it, everything works. The same happens if I add the same explicit require in `jobs/b.rb`. It seems to have been fixed in ruby 3.4 in commit:ea2af5782df63266577ba08a4ef4c30b6d63e564, but not apparent in Linux (which is my case) until commit:6fbc32b5d0da31535cccc0eca1853273313a0b52 I'm not familiar with the ruby codebase, so It's not clear to me why the change to prism fixed the threads issue and why it didn't have impact in Linux until the other fix, but bisecting the source code and running each revision against the code above, that is what I came to. I can create a PR to backport the Linux fix to `ruby_3_4` branch, as in `master` everything is working as expected. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122240] [Ruby Bug#21363] `Namespace.current` should always return the Namespace in which it was defined
by tenderlovemaking (Aaron Patterson) 09 Dec '25

09 Dec '25

Issue #21363 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21363: `Namespace.current` should always return the Namespace in which it was defined https://bugs.ruby-lang.org/issues/21363 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-22T23:07:21Z rm-assertion 17e71c7a24) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I think `Namespace.current` should always return the namespace in which it was defined. Here is an example to demonstrate what I mean: ```ruby File.binwrite("ns.rb", <<-RUBY) # namespace 3 module M def self.test p Namespace.current end TEST = -> { p Namespace.current } end RUBY ns = Namespace.new ns.load "./ns.rb" p Namespace.current ns::M.test ns::M::TEST.call ``` I expect the output of `ns::M.test` and `ns::M::TEST.call` to be the same. Instead the output is like this: ``` #<Namespace:2,user,main> #<Namespace:3,user,optional> #<Namespace:2,user,main> ``` I think a method and lambda defined in the same namespace should return the same value for `Namespace.current` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122114] [Ruby Bug#21341] `Namespace is not a module (TypeError)` without enabling the namespace
by yahonda (Yasuo Honda) 09 Dec '25

09 Dec '25

Issue #21341 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #21341: `Namespace is not a module (TypeError)` without enabling the namespace https://bugs.ruby-lang.org/issues/21341 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-15T08:25:56Z master 427ede2dde) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby on Rails test case has the `module Namespace`. https://github.com/rails/rails/blob/main/activemodel/test/validators/namesp… ```ruby module Namespace class EmailValidator < ::EmailValidator end end ``` This code fails against Ruby 3.5.0dev without enabling the namespace feature. ### Steps to reproduce ```ruby $ ruby -ve 'module Namespace; end' ``` ### Expected behavior It should run without errors. ### Actual behavior It raises the TypeError. ```ruby $ ruby -ve 'module Namespace; end' ruby 3.5.0dev (2025-05-15T08:25:56Z master 427ede2dde) +PRISM [x86_64-linux] -e:1:in '<main>': Namespace is not a module (TypeError) ruby:0: previous definition of Namespace was here ``` Raising this TypeError with RUBY_NAMESPACE=1 looks expected to me. ```ruby $ RUBY_NAMESPACE=1 ruby -ve 'module Namespace; end' ruby 3.5.0dev (2025-05-15T08:25:56Z master 427ede2dde) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. -e:1:in '<main>': Namespace is not a module (TypeError) ruby:0: previous definition of Namespace was here ``` -- https://bugs.ruby-lang.org/

5 8

[ruby-core:121955] [Ruby Bug#21320] Namespaces leak with constant lookup
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21320 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21320: Namespaces leak with constant lookup https://bugs.ruby-lang.org/issues/21320 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program ```ruby X = :top class C X = :super end class D < C p X end ``` prints `:super` normally, and `:top` if running under a namespace. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121952] [Ruby Bug#21318] Namespaces leak with permanent names
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21318 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21318: Namespaces leak with permanent names https://bugs.ruby-lang.org/issues/21318 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Namespaces are not transparent for this program: ```ruby Module.nesting ``` The nesting is empty or not depending on whether it is being executed under a namespace. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121950] [Ruby Bug#21316] Namespaces leak with permanent names
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21316 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21316: Namespaces leak with permanent names https://bugs.ruby-lang.org/issues/21316 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Namespaces are not transparent for this program ```ruby C = Class.new C.name == 'C' ``` because under a non-main user namespace, the name of `C` has the namespace as a prefix. -- https://bugs.ruby-lang.org/

7 12

[ruby-core:122132] [Ruby Bug#21343] Namespace: singleton classes of root namespace leak between namespaces
by jhawthorn (John Hawthorn) 09 Dec '25

09 Dec '25

Issue #21343 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21343: Namespace: singleton classes of root namespace leak between namespaces https://bugs.ruby-lang.org/issues/21343 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby classes all have singleton classes, those singleton classes have singleton classes, and so on with infinite nesting. Since we don't have infinite resources, we create these lazily. Because of this, only a certain number of singleton classes exist in the root namespace. At a certain depth, mutable singleton classes end up shared between namespaces. ``` ruby File.write("/tmp/ntest.rb", <<~'RUBY') p String.singleton_class.singleton_class::Foo String.singleton_class.singleton_class::Bar = 456 RUBY String.singleton_class.singleton_class::Foo = 123 ns = Namespace.new ns.require("/tmp/ntest.rb") p String.singleton_class.singleton_class::Bar ``` ``` RUBY_NAMESPACE=1 ruby nstest2.rb ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. 123 456 ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122070] [Ruby Feature#21335] Namespaces should be present in the backtrace
by tenderlovemaking (Aaron Patterson) 09 Dec '25

09 Dec '25

Issue #21335 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21335: Namespaces should be present in the backtrace https://bugs.ruby-lang.org/issues/21335 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Namespaces can call in to other name spaces. I think it might be helpful if namespace information is in the backtrace. For example: ```ruby File.binwrite "foo.rb", <<-eorb class Foo def self.test(ns1, ns2, count) if count == 0 puts caller else if count % 2 == 0 ns1::Foo.test(ns1, ns2, count - 1) else ns2::Foo.test(ns1, ns2, count - 1) end end end end eorb ns1 = Namespace.new ns1.load "foo.rb" ns2 = Namespace.new ns2.load "foo.rb" ns1::Foo.test(ns1, ns2, 10) ``` The output is like this: ``` See doc/namespace.md for known issues, etc. /Users/aaron/git/ruby/exe/ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' ./test.rb:23:in '<main>' ``` `Foo.test` alternates between namespaces when calling a method, but you can't tell from the backtrace. I think we should include namespaces in the backtrace. -- https://bugs.ruby-lang.org/

5 7