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

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

20 May '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 6

[ruby-core:122191] [Ruby Bug#21351] Ruby master segfaults when initializing `Zlib::GzipReader`
by st0012 (Stan Lo) 19 May '25

19 May '25

Issue #21351 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #21351: Ruby master segfaults when initializing `Zlib::GzipReader` https://bugs.ruby-lang.org/issues/21351 * Author: st0012 (Stan Lo) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-13T14:16:58Z master bb180b87b4) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ### Ruby Version ``` ruby 3.5.0dev (2025-05-13T14:16:58Z master bb180b87b4) +PRISM [arm64-darwin24] last_commit=[Bug #21331] Prohibit modification during stlike loop ``` ### Steps to reproduce ``` $ ruby -e "require 'zlib'; Zlib::GzipReader.new('')" ``` ### C backtrace ``` /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_vm_bugreport+0xb6c) [0x102571c30] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_bug_for_fatal_signal+0x100) [0x1023a3ebc] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(sigsegv+0x84) [0x1024caae0] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x1998fb624] /Users/hung-wulo/.gem/ruby/ruby-master/gems/zlib-3.2.1/lib/zlib.bundle(gzfile_new+0x30) [0x11d6d2efc] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_class_alloc+0xac) [0x1024366e8] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(vm_exec_core+0x38f4) [0x102549ac4] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_vm_exec+0x1b0) [0x102544e08] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_ec_exec_node+0x8c) [0x1023aef64] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(ruby_run_node+0x40) [0x1023aee8c] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(main+0x68) [0x1022f0980] ``` Full report is in the attached file ---Files-------------------------------- crash_report.txt (20.2 KB) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121830] [Ruby Feature#21309] Can Thread::Mutex be Ractor shareable?
by osyoyu (Daisuke Aritomo) 19 May '25

19 May '25

Issue #21309 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #21309: Can Thread::Mutex be Ractor shareable? https://bugs.ruby-lang.org/issues/21309 * Author: osyoyu (Daisuke Aritomo) * Status: Open ---------------------------------------- ## Background Keeping a `Mutex` object in a constant or a class instance variable is a common pattern seen in code with thread safety in mind. However, this kind of code does not play well with Ractors: ```ruby require 'thread' class C MUTEX = Mutex.new def self.foo MUTEX.synchronize { p 1 } end end Ractor.new { C.foo }.take ``` ``` t.rb:11: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x000000011d80f368 run> terminated with exception (report_on_exception is true): t.rb:7:in 'C.foo': can not access non-shareable objects in constant C::MUTEX by non-main ractor. (Ractor::IsolationError) from t.rb:12:in 'block in <main>' <internal:ractor>:711:in 'Ractor#take': thrown by remote Ractor. (Ractor::RemoteError) from t.rb:13:in '<main>' t.rb:7:in 'C.foo': can not access non-shareable objects in constant C::MUTEX by non-main ractor. (Ractor::IsolationError) from t.rb:12:in 'block in <main>' ``` Many libraries follow this pattern. `Mutex` not being Ractor shareable is blocking these libraries from being used from inside Ractors. `Timeout` in stdlib in particular has large impact since it is required from many other gems by default, including `net/http`. https://github.com/ruby/timeout/blob/v0.4.3/lib/timeout.rb#L49-L50 https://github.com/lostisland/faraday/blob/v2.13.1/lib/faraday/middleware.r… ## Proposal Make built-in concurrency primitives (Thread::Mutex, Thread::ConditionVariable and Thread::Queue) Ractor shareable. While this idea may not be strictly aligned with idea of the Ractor world (exchanging messages for controlling concurrency?), I have the feeling that too many code is blocked from running in Ractors because `Mutex` is not Ractor shareable. Allowing `Mutex`es to be shared would make a large portion of existing Ruby code Ractor-compatible, or at least make migration much easier. I believe that it won't be semantically incorrect, since they are concurrency primitives after all. One thing to consider that the current `Mutex` implementation is based on the GVL (I believe so). Migration to some other implementation e.g. pthread_mutex or CRITICAL_SECTION may be needed to make Mutex work well on Ractors. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:122192] [Ruby Bug#21352] Invalid read in shape lookup code
by Earlopain (Earlopain _) 19 May '25

19 May '25

Issue #21352 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21352: Invalid read in shape lookup code https://bugs.ruby-lang.org/issues/21352 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-19T04:27:50Z master 40c957ba21) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism runs tests with valgrind and it recently started to report an invalid read in `rb_shape_lookup`. Example workflow: https://github.com/ruby/prism/actions/runs/15111527208/job/42471945845?pr=3… ``` Invalid read of size 8 rb_shape_lookup (shape.c:347) rb_obj_shape (shape.h:184) rb_shape_obj_too_complex_p (shape.c:1098) rb_free_generic_ivar (variable.c:1274) rb_gc_obj_free_vm_weak_references (gc.c:2061) rb_gc_impl_shutdown_free_objects (default.c:2965) rb_objspace_free_objects (gc.c:1759) ruby_vm_destruct (vm.c:3209) rb_ec_cleanup (eval.c:263) ruby_run_node (eval.c:319) rb_main (main.c:42) main (main.c:62) ``` cc @byroot since you did recent changes around the shape code. I'm lacking knowledge to dig into this, so it may be a false positive (it uses https://github.com/Shopify/ruby_memcheck which does some heuristics). I confirmed that this happens locally on current ruby-dev when running `bundle exec rake test:valgrind` from `ruby/prism`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122149] [Ruby Bug#21345] crash on evaluating 'a=>a,*,'
by masterleep2 (Bill Lipa) 19 May '25

19 May '25

Issue #21345 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #21345: crash on evaluating 'a=>a,*,' https://bugs.ruby-lang.org/issues/21345 * Author: masterleep2 (Bill Lipa) * Status: Open * ruby -v: ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` ruby -e 'a=>a,*,' -e: [BUG] Unexpected node type in pattern matching expression: PM_IMPLICIT_REST_NODE ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [arm64-darwin24] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:0001f0 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /opt/local/lib/libruby.3.4.dylib(rb_vm_bugreport+0xb6c) [0x104cbcfdc] /opt/local/lib/libruby.3.4.dylib(rb_bug_without_die_internal+0xfc) [0x104afa12c] /opt/local/lib/libruby.3.4.dylib(rb_bug+0x1c) [0x104e07970] /opt/local/lib/libruby.3.4.dylib(pm_compile_pattern.cold.2+0x0) [0x104e0750c] /opt/local/lib/libruby.3.4.dylib(pm_compile_pattern+0x42a8) [0x104abd78c] /opt/local/lib/libruby.3.4.dylib(pm_compile_pattern+0x3f90) [0x104abd474] /opt/local/lib/libruby.3.4.dylib(pm_compile_match_required_node+0x3b4) [0x104abdb54] /opt/local/lib/libruby.3.4.dylib(pm_compile_node+0x1670) [0x104a8659c] /opt/local/lib/libruby.3.4.dylib(pm_compile_scope_node+0x1c34) [0x104ac2018] /opt/local/lib/libruby.3.4.dylib(pm_iseq_compile_node+0x84) [0x104a84e60] /opt/local/lib/libruby.3.4.dylib(pm_iseq_new_with_opt_try+0x1c) [0x104b5cbc8] /opt/local/lib/libruby.3.4.dylib(rb_protect+0xbc) [0x104b060cc] /opt/local/lib/libruby.3.4.dylib(pm_iseq_new_with_opt+0x14c) [0x104b5c034] /opt/local/lib/libruby.3.4.dylib(pm_iseq_new_main+0xc4) [0x104b5c23c] /opt/local/lib/libruby.3.4.dylib(ruby_process_options+0x16a4) [0x104c12a30] /opt/local/lib/libruby.3.4.dylib(ruby_options+0xb0) [0x104b04b04] /opt/local/bin/ruby3.4(main+0x64) [0x1041eff20] ``` ---Files-------------------------------- crash.txt (14.1 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115995] [Ruby master Bug#20112] Ractors not working properly in ruby 3.3.0
by ariasdiniz (Aria Diniz) 19 May '25

19 May '25

Issue #20112 has been reported by ariasdiniz (Aria Diniz). ---------------------------------------- Bug #20112: Ractors not working properly in ruby 3.3.0 https://bugs.ruby-lang.org/issues/20112 * Author: ariasdiniz (Aria Diniz) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I recently installed Ruby 3.3.0, and noticed that some of my scripts that use Ractors started to struggle with performance. After doing some benchmarks, I noticed that, while Ractors seem to be working well on Ruby 3.2.2, they're not working properly on 3.3.0. I'm using Ubuntu 22.04.3 LTS Here is the benchmark code: ``` ruby # frozen_string_literal: true require 'benchmark' Ractor.new { :warmup } if defined?(Ractor) Benchmark.bmbm do |x| x.report("Thread: ") do threads = [] 8.times do |i| threads << Thread.new do 20000000.times do |j| ((i * 20000000) + j)**2 end end end threads.each(&:join) end x.report("Ractor: ") do ractors = [] 0..8.times do |i| ractors << Ractor.new(i) do |k| 20000000.times do |j| ((k * 20000000) + j)**2 end end end ractors.map(&:take) end end ``` Here is the results for Ruby 3.2.2: Rehearsal -------------------------------------------- Thread: 7.666909 0.001091 7.668000 ( 7.675266) Ractor: 19.318528 0.012017 19.330545 ( 2.505888) ---------------------------------- total: 26.998545sec user system total real Thread: 7.918141 0.004011 7.922152 ( 7.928772) Ractor: 19.366414 0.003954 19.370368 ( 2.517993) Here is the results for Ruby 3.3.0: Rehearsal -------------------------------------------- Thread: 8.634152 0.010895 8.645047 ( 8.645104) Ractor: 100.172179 0.035985 100.208164 ( 15.213245) --------------------------------- total: 108.853211sec user system total real Thread: 9.451236 0.004002 9.455238 ( 9.460132) Ractor: 118.463294 0.119942 118.583236 ( 18.462157) -- https://bugs.ruby-lang.org/

5 4

[ruby-core:122091] [Ruby Bug#21338] TracePoint Not Triggered for Kernel#block_given?
by cfis (Charlie Savage) 19 May '25

19 May '25

Issue #21338 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21338: TracePoint Not Triggered for Kernel#block_given? https://bugs.ruby-lang.org/issues/21338 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When updating ruby-prof for Ruby 3.4, various tests now fail because a method enter/leave tracepoint is not triggered for `Kernel#block_given?` For example: https://github.com/ruby-prof/ruby-prof/blob/master/test/line_number_test.rb… In 3.3 a tracepoint was triggered but not in earlier Ruby versions. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:122176] [Ruby Bug#21349] default gems should have version >= 1
by masterleep2 (Bill Lipa) 19 May '25

19 May '25

Issue #21349 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #21349: default gems should have version >= 1 https://bugs.ruby-lang.org/issues/21349 * Author: masterleep2 (Bill Lipa) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Many of the default gems have version numbers less than 1, including venerable offerings such as net-http and yaml. Versions starting with 0 often imply a prereleased or beta status. Surely if a gem has been released as part of the base distribution of ruby itself for a number of years, it is at least worthy of a 1.0 version number. This would reduce uncertainty or confusion about the quality / production readiness of gems distributed with ruby. From ruby 3.4.4: benchmark (default: 0.4.0) cgi (default: 0.4.2) delegate (default: 0.4.0) english (default: 0.8.0) error_highlight (default: 0.7.0) find (default: 0.2.0) io-console (default: 0.8.0) io-nonblock (default: 0.3.1) io-wait (default: 0.3.1) net-http (default: 0.6.0) net-protocol (default: 0.2.2) open-uri (default: 0.5.0) open3 (default: 0.2.1) optparse (default: 0.6.0) ostruct (default: 0.6.1) pathname (default: 0.4.0) pp (default: 0.6.2) prettyprint (default: 0.2.0) pstore (default: 0.1.4) readline (default: 0.0.4) reline (default: 0.6.0) resolv (default: 0.6.0) ruby2_keywords (default: 0.0.5) securerandom (default: 0.4.1) shellwords (default: 0.2.2) singleton (default: 0.3.0) tempfile (default: 0.3.1) time (default: 0.4.1) timeout (default: 0.4.3) tmpdir (default: 0.3.1) tsort (default: 0.2.0) un (default: 0.3.0) weakref (default: 0.1.3) yaml (default: 0.4.0) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121597] [Ruby Bug#21257] YJIT can generate infinite loop when OOM
by rianmcguire (Rian McGuire) 18 May '25

18 May '25

Issue #21257 has been reported by rianmcguire (Rian McGuire). ---------------------------------------- Bug #21257: YJIT can generate infinite loop when OOM https://bugs.ruby-lang.org/issues/21257 * Author: rianmcguire (Rian McGuire) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We've found an edge case where YJIT can generate an infinite loop (jump to the same address) when it's out-of-memory. Reproduction: ```ruby def first second end def second ::File end # Make `second` side exit on its first instruction trace = TracePoint.new(:line) { } trace.enable(target: method(:second)) 32.times do |i| puts i first if i == 29 # We've JITed the methods now - trigger the bug # Trigger a constant cache miss in rb_vm_opt_getconstant_path (in `second`) next time it's called module InvalidateConstantCache File = nil end # nb. this only works in yjit dev mode RubyVM::YJIT.simulate_oom! end end ``` This hangs indefinitely when run with YJIT (`./configure --enable-yjit=dev` is required for simulate_oom). If we attach a debugger to the Ruby process at this point, it's stuck in an infinite loop: ``` $ lldb -p 9753 (lldb) process attach --pid 9753 Process 9753 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x0000000104b202b8 -> 0x104b202b8: b 0x104b202b8 0x104b202bc: nop 0x104b202c0: nop 0x104b202c4: nop Target 0: (ruby) stopped. Executable module set to "/Users/rian/opt/ruby/bin/ruby". Architecture set to: arm64-apple-macosx-. ``` We've reproduced this on: ``` ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin23] ruby 3.5.0dev (2025-04-08T06:46:45Z master b68fe530f1) +PRISM [arm64-darwin23] ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:122136] [Ruby Bug#21344] Segment Fault Caused by no Backported Patches
by tianstcht (Haotian Cheng) 18 May '25

18 May '25

Issue #21344 has been reported by tianstcht (Haotian Cheng). ---------------------------------------- Bug #21344: Segment Fault Caused by no Backported Patches https://bugs.ruby-lang.org/issues/21344 * Author: tianstcht (Haotian Cheng) * Status: Open * ruby -v: 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux-gnu] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In my local machine(3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux-gnu]), which is the default version in ubuntu2404, a segmentation fault can be stably triggered by the poc including malicious xml data. The poc here: ```ruby require "rexml/document" puts REXML::VERSION def poc1(size) input = <<EOF <mydoc> <tt>#{'&' + '1'*size + '#x2F3F' + ' '}</tt> </mydoc> EOF parser = REXML::Document.new input end poc1(8_999_999) ``` The issue has been fixed in this commit: https://github.com/ruby/ruby/commit/b959263b58e26ef630c085f9f7ddc04373a998c7 But the fix haven't been backported to Ruby 3.2 and 3.3. Based on the developer's response, I think the backporting may be needed so the issue built. -- https://bugs.ruby-lang.org/

3 4