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

[ruby-core:117003] [Ruby master Bug#20314] Simultaneous Timeout expires may raise an exception after the block
by mame (Yusuke Endoh) 11 Dec '25

11 Dec '25

Issue #20314 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20314: Simultaneous Timeout expires may raise an exception after the block https://bugs.ruby-lang.org/issues/20314 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Launchable reports `TestTimeout#test_nested_timeout` as a flaky test, and I reproduced it as follows. ```ruby require "timeout" class A < Exception end class B < Exception end begin Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do nil while true end end rescue A, B p $! #=> #<A: execution expired> # Exception B is raised after the above call returns #=> test.rb:16:in `p': execution expired (B) p :end # not reach end ``` This is because the timer thread performs two consecutive `Thread#raise` to the target thread. I have discussed this with @ko1 and have come up with three solutions. ### Solution 1 When multiple nested Timeouts expire simultaneously, raise an exception for the outer-most Timeout and let the inner Timeouts expire without throwing an exception. In the above example, it would only raise A. The problem with this approach is that if you are rescuing A in the inner block, it may never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue A sleep # The exception A is caught. The inner Timeout is already expired, so the code (may) never end. end end end ``` Note that, if A and B did not occur at the same time, it would raise B. This is a race condition. ### Solution 2 When multiple nested Timeouts expire simultaneously, raise an exception for the inner-most Timeout and let the outer Timeouts wait until the inner-most Timeout returns. In the above example, it would raise either A or B, not both. The problem with this approach is that if you are rescuing B in the inner block, it never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue B sleep # The outer Timeout waits for the inner timeout, and the inner Timeout never return. So this code never ends. end end end ``` ### Solution 3 Make thread interrupt queue one length. If the target thread has already been `Thread#raise(A)`, the new `Thread#raise(B)` blocks until the target thread processes A. Since there will be no more simultaneous Thread#raise, there will be no more exceptions after the end of the block. The timeout timer thread should be changed in consideration that `Thread#raise` may block. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123261] [Ruby Bug#21607] require 'concurrent-ruby' causes segfault with Ruby 3.4.6 on linux/i686
by satadru (Satadru Pramanik) 11 Dec '25

11 Dec '25

Issue #21607 has been reported by satadru (Satadru Pramanik). ---------------------------------------- Bug #21607: require 'concurrent-ruby' causes segfault with Ruby 3.4.6 on linux/i686 https://bugs.ruby-lang.org/issues/21607 * Author: satadru (Satadru Pramanik) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [i686-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As mentioned at https://github.com/ruby/ruby/pull/14532#issuecomment-3288983469 chronos@buppie-i686:2.23 M58 /usr/local/lib/crew/packages (master >|SPARSE)$ ruby -e "require 'concurrent-ruby' ; puts 'success'" Segmentation fault This causes a segfault on i686 only on our Chromebrew/i686 systems. armv7l and x86_64 do not have this issue. This may be linked to the update to prism 1.5.x? Docker reproducer on our i686 ChromeOS Milestone 58 based container image: docker run --init --platform linux/386 --rm --net=host -v $(pwd):/output -h $(hostname)-i686 --tmpfs /tmp --ulimit "nofile=$(ulimit -Sn):$(ulimit -Hn)" -it satmandu/crewbuild:alex-i686.m58 # Note the lack of an issue with 3.4.5 with this command: ruby -e "require 'concurrent-ruby' ; puts 'success'" # In that container, upgrade ruby to 3.4.6: CREW_REPO=https://github.com/chromebrew/chromebrew.git CREW_BRANCH=updater-ruby_3.4.6 crew update \ && yes | crew upgrade # Then run the breaking command: ruby -e "require 'concurrent-ruby' ; puts 'success'" # Note the segfault. -- https://bugs.ruby-lang.org/

8 17

[ruby-core:123902] [Ruby Bug#21710] Segfault when reading object_id after it is set inside RUBY_INTERNAL_EVENT_NEWOBJ
by ivoanjo (Ivo Anjo) 11 Dec '25

11 Dec '25

Issue #21710 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #21710: Segfault when reading object_id after it is set inside RUBY_INTERNAL_EVENT_NEWOBJ https://bugs.ruby-lang.org/issues/21710 * Author: ivoanjo (Ivo Anjo) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-24T08:44:28Z master aeb7689e69) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hey 👋. I caught a following segfault when running the [Datadog Ruby Profiler](https://github.com/datadog/dd-trace-rb) test suite on 4.0.0-preview2. The Datadog Ruby Profiler still uses object_ids in `RUBY_INTERNAL_EVENT_NEWOBJ` to simulate weak references. (We know this is deprecated and we plan to move to [`rb_gc_mark_weak`](https://bugs.ruby-lang.org/issues/19783) in the future). I was able to reproduce this bug with both 4.0.0-preview2 as well as a ruby-head build from 2025-11-24. Here's a [very simple reproducer](https://github.com/ivoanjo/lowlevel-toolkit/pull/1): ```c static void on_newobj_event(VALUE tpval, void *data) { VALUE obj = rb_tracearg_object(rb_tracearg_from_tracepoint(tpval)); if (!rb_objspace_internal_object_p(obj)) rb_obj_id(obj); } static VALUE add_object_id(RB_UNUSED_VAR(VALUE _)) { VALUE tp = rb_tracepoint_new(0, RUBY_INTERNAL_EVENT_NEWOBJ, on_newobj_event, NULL); rb_tracepoint_enable(tp); rb_yield(Qnil); rb_tracepoint_disable(tp); return Qnil; } ``` ```ruby puts RUBY_DESCRIPTION require "lowlevel-toolkit" foo = Struct.new(:foo) bar = nil LowlevelToolkit.add_object_id { bar = foo.new(1) } bar.object_id ``` and here's the segfault: ``` examples/add_object_id.rb:8: [BUG] Segmentation fault at 0x0000000000000000 ruby 4.0.0dev (2025-11-24T08:44:28Z master aeb7689e69) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0012 e:000011 l:y b:---- CFUNC :object_id c:0002 p:0044 s:0008 E:002170 l:n b:---- EVAL examples/add_object_id.rb:8 [FINISH] c:0001 p:0000 s:0003 E:001dc0 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- examples/add_object_id.rb:8:in '<main>' examples/add_object_id.rb:8:in 'object_id' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000079c33b33e2cd RBP: 0x00007ffdcee65d10 RSP: 0x00007ffdcee65cd0 RAX: 0x0000000000000000 RBX: 0x000079c33a4ff058 RCX: 0x000079c339000000 RDX: 0x0000000000000000 RDI: 0x0000000000000000 RSI: 0x00000000000fe000 R8: 0x000079c33b35c078 R9: 0x000079c31f2814d0 R10: 0x000058e4893a6ee0 R11: 0xb84a1fbe2b4aab11 R12: 0x0000000000000002 R13: 0x0000000000000000 R14: 0x000058e489384b60 R15: 0x000079c33a5fefa0 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_print_backtrace+0x24) [0x79c33b392149] .rvm/src/ruby-head/vm_dump.c:1105 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_vm_bugreport+0x33f) [0x79c33b39291b] .rvm/src/ruby-head/vm_dump.c:1450 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_bug_for_fatal_signal+0x147) [0x79c33b13a3e2] .rvm/rubies/ruby-head/lib/libruby.so.4.0(sigsegv+0x84) [0x79c33b2bea4d] .rvm/src/ruby-head/signal.c:948 .rvm/rubies/ruby-head/lib/libruby.so.4.0(sigill) (null):0 /lib/x86_64-linux-gnu/libc.so.6(0x79c33ac45330) [0x79c33ac45330] .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_obj_field_get+0x105) [0x79c33b33e2cd] .rvm/src/ruby-head/variable.c:1412 .rvm/rubies/ruby-head/lib/libruby.so.4.0(object_id_get+0x4e) [0x79c33b16ed28] .rvm/src/ruby-head/gc.c:1875 .rvm/rubies/ruby-head/lib/libruby.so.4.0(object_id0+0x46) [0x79c33b16ed78] .rvm/src/ruby-head/gc.c:1895 .rvm/rubies/ruby-head/lib/libruby.so.4.0(object_id+0xb1) [0x79c33b16ee93] .rvm/src/ruby-head/gc.c:1936 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_find_object_id+0x43) [0x79c33b16f6ea] .rvm/src/ruby-head/gc.c:2179 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_obj_id+0x2e) [0x79c33b16f75a] .rvm/src/ruby-head/gc.c:2234 .rvm/rubies/ruby-head/lib/libruby.so.4.0(ractor_safe_call_cfunc_0+0x30) [0x79c33b35c0a8] .rvm/src/ruby-head/vm_insnhelper.c:3718 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_cfunc_with_frame_+0x221) [0x79c33b35ccb1] .rvm/src/ruby-head/vm_insnhelper.c:3902 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_cfunc_with_frame+0x76) [0x79c33b35cf26] .rvm/src/ruby-head/vm_insnhelper.c:3948 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_cfunc_other+0x12b) [0x79c33b35d053] .rvm/src/ruby-head/vm_insnhelper.c:3974 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_cfunc+0x147) [0x79c33b35d49a] .rvm/src/ruby-head/vm_insnhelper.c:4056 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_method_each_type+0x180) [0x79c33b360161] .rvm/src/ruby-head/vm_insnhelper.c:4888 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_method+0xa1) [0x79c33b360c1d] .rvm/src/ruby-head/vm_insnhelper.c:5014 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_general+0x2f) [0x79c33b360e1f] .rvm/src/ruby-head/vm_insnhelper.c:5058 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_sendish+0x1d3) [0x79c33b363689] .rvm/src/ruby-head/vm_insnhelper.c:6124 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_exec_core+0x3b1d) [0x79c33b36b42c] .rvm/src/ruby-head/insns.def:903 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_vm_exec+0x140) [0x79c33b384d94] .rvm/src/ruby-head/vm.c:2784 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_iseq_eval_main+0x3d) [0x79c33b385be2] .rvm/src/ruby-head/vm.c:3050 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_ec_exec_node+0x128) [0x79c33b145eb4] .rvm/src/ruby-head/eval.c:283 .rvm/rubies/ruby-head/lib/libruby.so.4.0(ruby_run_node+0x8a) [0x79c33b146025] .rvm/src/ruby-head/eval.c:321 .rvm/rubies/ruby-head/bin/ruby(rb_main+0x4c) [0x58e47500e51e] ./main.c:42 .rvm/rubies/ruby-head/bin/ruby(main+0x62) [0x58e47500e596] ./main.c:62 ``` Let me know if I can provide any more info! -- https://bugs.ruby-lang.org/

6 24

[ruby-core:123827] [Ruby Misc#21690] Inconsistent `rb_popcount64()` definition
by daniel.domjan 11 Dec '25

11 Dec '25

Issue #21690 has been reported by daniel.domjan (Dániel Domján). ---------------------------------------- Misc #21690: Inconsistent `rb_popcount64()` definition https://bugs.ruby-lang.org/issues/21690 * Author: daniel.domjan (Dániel Domján) * Status: Open ---------------------------------------- The `rb_popcount64()` function is defined both in `internal/bits.h` and `parser_bits.h`, but the definition of these functions is different on the `#else` branch. ```c // internal/bits.h static inline unsigned int rb_popcount64(uint64_t x) { ... #else x = (x & 0x5555555555555555) + (x >> 1 & 0x5555555555555555); x = (x & 0x3333333333333333) + (x >> 2 & 0x3333333333333333); x = (x & 0x0707070707070707) + (x >> 4 & 0x0707070707070707); x = (x & 0x000f000f000f000f) + (x >> 8 & 0x000f000f000f000f); x = (x & 0x0000001f0000001f) + (x >>16 & 0x0000001f0000001f); x = (x & 0x000000000000003f) + (x >>32 & 0x000000000000003f); return (unsigned int)x; #endif } ``` ```c // parser_bits.h static inline unsigned int rb_popcount64(uint64_t x) { ... #else x = (x & 0x5555555555555555) + (x >> 1 & 0x5555555555555555); x = (x & 0x3333333333333333) + (x >> 2 & 0x3333333333333333); x = (x & 0x0707070707070707) + (x >> 4 & 0x0707070707070707); x = (x & 0x001f001f001f001f) + (x >> 8 & 0x001f001f001f001f); x = (x & 0x0000003f0000003f) + (x >>16 & 0x0000003f0000003f); x = (x & 0x000000000000007f) + (x >>32 & 0x000000000000007f); return (unsigned int)x; #endif } ``` ```diff x = (x & 0x5555555555555555) + (x >> 1 & 0x5555555555555555); x = (x & 0x3333333333333333) + (x >> 2 & 0x3333333333333333); x = (x & 0x0707070707070707) + (x >> 4 & 0x0707070707070707); - x = (x & 0x000f000f000f000f) + (x >> 8 & 0x000f000f000f000f); + x = (x & 0x001f001f001f001f) + (x >> 8 & 0x001f001f001f001f); - x = (x & 0x0000001f0000001f) + (x >>16 & 0x0000001f0000001f); + x = (x & 0x0000003f0000003f) + (x >>16 & 0x0000003f0000003f); - x = (x & 0x000000000000003f) + (x >>32 & 0x000000000000003f); + x = (x & 0x000000000000007f) + (x >>32 & 0x000000000000007f); ``` IIUC, this is a modified [hamming weight](https://en.wikipedia.org/wiki/Hamming_weight) based on [this SO answer](https://stackoverflow.com/a/73300535), so both implementations give the same result, but it's a bit confusing at first look, so I flagged it as `Misc` instead of `Bug`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123914] [Ruby Bug#21712] Prism and parse.y inconsistency in command call with block and `.()`
by tompng (tomoya ishida) 11 Dec '25

11 Dec '25

Issue #21712 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21712: Prism and parse.y inconsistency in command call with block and `.()` https://bugs.ruby-lang.org/issues/21712 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `a b do end.()` `a b do end&.()` are parsed differently. Prism: parse success, parse.y: SyntaxError I personally like Prism's behavior: `.()` and `&.()` are accepted where `.f()` and `&.f()` are accepted. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123063] [Ruby Feature#21552] allow String.strip and similar to take a parameter similar to String.delete
by MSP-Greg (Greg L) 11 Dec '25

11 Dec '25

Issue #21552 has been reported by MSP-Greg (Greg L). ---------------------------------------- Feature #21552: allow String.strip and similar to take a parameter similar to String.delete https://bugs.ruby-lang.org/issues/21552 * Author: MSP-Greg (Greg L) * Status: Open ---------------------------------------- Regrading `String.strip` (and `lstrip`, `rstrip`, and `!` versions) Some text data representations differentiate between what one might call vertical and horizontal white space, and the 'strip' methods currently strip both. It would be helpful if they had an optional parameter similar to `String.delete` with a one multi-character selector, so one could do: ```ruby t = str.strip " \t" ``` One can use a regex for this, but this much simpler. -- https://bugs.ruby-lang.org/

7 11

[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