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

[ruby-core:116946] [Ruby master Bug#20302] Multiple refinements cannot be applied to the same module
by mame (Yusuke Endoh) 06 Oct '25

06 Oct '25

Issue #20302 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20302: Multiple refinements cannot be applied to the same module https://bugs.ruby-lang.org/issues/20302 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: shugo (Shugo Maeda) * ruby -v: ruby 3.4.0dev (2024-02-20T07:17:20Z master a605234bfa) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- If we are using multiple refinements for the Kernel module, it seems that only the last refinement is enabled. In the following example, we can call `f2` of M2, which is enabled later. but cannot call `f1` of M1. ```ruby module M1 refine(Kernel) do def f1 = :f1 end end module M2 refine(Kernel) do def f2 = :f2 end end class Foo using M1 using M2 def test p f2 #=> :f2 p f1 # expected => :f1 # actual => undefined local variable or method 'f1' for an instance of Foo end end Foo.new.test ``` Note that if I change `refine(Kernel)` to `refine(Object)`, it works as expected. So I think there is a problem only when the refinement target is a module. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123402] [Ruby Feature#16769] Struct.new(..., immutable: true)
by CoderMiguel (Michael Newman) 06 Oct '25

06 Oct '25

Issue #16769 has been updated by CoderMiguel (Michael Newman). Breadcrumbs for those who land here early in their search: The [Data object](https://docs.ruby-lang.org/en/3.2/Data.html) is a reasonable alternative to this feature. ---------------------------------------- Feature #16769: Struct.new(..., immutable: true) https://bugs.ruby-lang.org/issues/16769#change-114771 * Author: k0kubun (Takashi Kokubun) * Status: Rejected ---------------------------------------- ## Background We've discussed interface to pass Struct attributes (like `immutable: true`, which is actually not added yet) at once. But I believe just adding `immutable: true` alone is really helpful in various cases. Thus I've spun out this ticket only for `immutable: true` from [Feature #16122]. ## Proposal ```rb Post = Struct.new(:id, :name, immutable: true) post = Post.new(1, "hello world") post.id = 2 # NoMethodError (undefined method `id=' for #<struct Post id=1, name="hello world">) ``` Given `immutable: true`, an instance returned by `.new` is frozen, and writer methods are not defined. ## Use case * Allow using Struct's nice features when we need an immutable model, instead of defining a normal class with `attr_reader`s and methods to support the Struct's features. * If it were a Struct, `to_s`, `inspect`, `==`, and a bunch of other methods are nicely defined by default. Deconstructing a Struct on Pattern Matching is also available. * This level of support from the entire ecosystem may not be available if it's just a third-party library. * We could achieve a similar thing if we call `Post.new(...).freeze` or override `#initialize` to call `freeze` inside it, but it is not fun and feels like a workaround. * Today I suggested to use Struct for a model class to take advantage of the above benefits in a code review, but the implementation stuck with a bare class with `attr_reader`s because the author didn't want writer methods to be defined (of course we don't want to manually undef them from a Struct class either) and calling `freeze` to workaround it seems tricky. I strongly desired Ruby's Struct is useful enough to cover this use case. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123288] [Ruby Bug#21610] Use ec->interrupt_mask to prevent interrupts.
by ioquatix (Samuel Williams) 05 Oct '25

05 Oct '25

Issue #21610 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21610: Use ec->interrupt_mask to prevent interrupts. https://bugs.ruby-lang.org/issues/21610 * Author: ioquatix (Samuel Williams) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program can trigger `rb_bug` in `rb_fiber_scheduler_unblock`: ```ruby require 'async/scheduler' scheduler = Async::Scheduler.new Fiber.set_scheduler(scheduler) Signal.trap(:USR1) do end q = Thread::Queue.new Thread.new do loop do Ractor.new do Process.kill(:USR1, $$) end.join end end Fiber.schedule do Fiber.schedule do 1.upto(1000000) do |i| sleep 0.01 q.pop q.push(1) puts "1 iter push/pop" end end Fiber.schedule do 1.upto(1000000) do |i| sleep 0.01 q.push(i) q.pop puts "1 iter push/pop#2" end end Fiber.schedule do gets exit! end end ``` In brief, when `rb_fiber_scheduler_unblock` executes with `ec->interrupt_flag` set, the following sequence can occur: ``` Thread A (Signaling) Thread B (Blocked Fiber) -------------------- --------------------- calls unblock(fiber_x) ├─ enters scheduler user code fiber_x sleeping in scheduler.block() ├─ ⚠️ SIGNAL INTERRUPT ⚠️ ├─ raises SignalException ├─ unblock operation aborted ├─ scheduler state inconsistent └─ returns believing success └─ fiber_x waits forever ⚠️ ``` Confirmed fix: https://github.com/ruby/ruby/pull/14588 -- https://bugs.ruby-lang.org/

2 6

[ruby-core:122121] [Ruby Bug#21342] Segfault: invalid keeping_mutexes when using Mutex in Thread then Fiber after GC
by maciej.mensfeld (Maciej Mensfeld) 05 Oct '25

05 Oct '25

Issue #21342 has been reported by maciej.mensfeld (Maciej Mensfeld). ---------------------------------------- Bug #21342: Segfault: invalid keeping_mutexes when using Mutex in Thread then Fiber after GC https://bugs.ruby-lang.org/issues/21342 * Author: maciej.mensfeld (Maciej Mensfeld) * Status: Open * ruby -v: 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby crashes with a `[BUG] invalid keeping_mutexes error` when attempting to GC locked mutex that was used in a Thread within a Fiber context after garbage collection. The error indicates an attempt to unlock a mutex that is not locked, suggesting a state management issue with mutexes across Thread and Fiber boundaries. ## Ruby Version `ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux]` ## Reproduce Process ``` ruby # segv.rb 5.times do m = Mutex.new Thread.new do m.synchronize do end end.join Fiber.new do GC.start m.lock end.resume end ``` 1. Save the above code to a file (e.g., `segv.rb`) 2. Run with `ruby segv.rb` 3. The crash occurs intermittently - sometimes it crashes immediately, sometimes it hangs, once in a while it works ## Actual Result The program crashes with the following error: ``` segv.rb: [BUG] invalid keeping_mutexes: Attempt to unlock a mutex which is not locked ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux] ``` whole segfault in the attached txt file. Full crash backtrace shows the error originates from: - `rb_threadptr_unlock_all_locking_mutexes` in thread.c:450 - `rb_thread_terminate_all` in thread.c:467 The crash suggests an issue in mutex state management during thread termination. ## Expected Result The script should complete successfully without crashing. The mutex should be properly managed across Thread and Fiber contexts, and garbage collection should not interfere with mutex state. ---Files-------------------------------- crash.txt (23.4 KB) -- https://bugs.ruby-lang.org/

7 10

[ruby-core:123209] [Ruby Bug#21569] [armv7, musl] SIGBUS in ibf_load_object_float due to unaligned VFP double load when reading IBF
by amacxz (Aleksey Maximov) 05 Oct '25

05 Oct '25

Issue #21569 has been reported by amacxz (Aleksey Maximov). ---------------------------------------- Bug #21569: [armv7, musl] SIGBUS in ibf_load_object_float due to unaligned VFP double load when reading IBF https://bugs.ruby-lang.org/issues/21569 * Author: amacxz (Aleksey Maximov) * Status: Open * ruby -v: ruby 3.3.8 (2025-04-09 revision b200bad6cd) [armv7a-linux-musleabihf] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Environment: CPU: ARMv7-A (NVIDIA Tegra 2), VFPv3-D16, no NEON OS/libc: Linux, musl (ld-musl-armhf.so.1) Compiler: GCC 14.3.0 Ruby: 3.3.8 (built from source via Gentoo ebuild) CFLAGS actually used by system: "-Os -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard" During make install (or Gentoo’s ebuild install phase) Ruby runs: ``` shell ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- \ --disable-gems -r./armv7a-linux-musleabihf-fake ./tool/rbinstall.rb \ --make=make --dest-dir="$D" --extout=.ext --ext-build-dir=./ext \ --mflags="-j1" --make-flags=" V=1" --gnumake --install=all --exclude=doc ``` This reliably triggers a SIGBUS on armv7 hard-float. Observed crash: ``` Thread "ruby33" received signal SIGBUS (Bus error). #0 ibf_load_object_float () from libruby33.so.3.3 (gdb) bt #0 ibf_load_object_float #1 ibf_load_object #2 rb_ibf_load_iseq_complete #3 ibf_load_iseq #4 ... (gdb) info reg r0 = 0xb6f508b6 (not 8-byte aligned) pc = 0xb6cacf78 <ibf_load_object_float+32> (gdb) x/6i $pc-8 ... 0xb6cacf74: vldr d0, [r0] <-- VFP double load from unaligned addr → SIGBUS ``` Root cause In compile.c: ``` c static VALUE ibf_load_object_float(const struct ibf_load *load, const struct ibf_object_header *header, ibf_offset_t offset) { const double *dblp = IBF_OBJBODY(double, offset); return DBL2NUM(*dblp); } ``` IBF_OBJBODY(double, ...) may return an unaligned pointer. On ARMv7, VFP vldr with an unaligned double address raises SIGBUS (no kernel fixup). Hence the crash while loading IBF. Proposed fix Read into an aligned local with memcpy: ``` --- a/compile.c +++ b/compile.c @@ -12921,10 +12921,12 @@ static VALUE ibf_load_object_float(const struct ibf_load *load, const struct ibf_object_header *header, ibf_offset_t offset) { - const double *dblp = IBF_OBJBODY(double, offset); - return DBL2NUM(*dblp); + /* IBF buffer may be unaligned on some platforms. On ARMv7, a VFP + * double load from an unaligned address causes SIGBUS. */ + double d; + memcpy(&d, IBF_OBJBODY(void, offset), sizeof(d)); + return DBL2NUM(d); } ``` Notes: The issue reproduces consistently on Tegra2 (armv7a, vfpv3-d16, no NEON) with musl, but (IMO) conceptually applies to any strict-alignment ARMv7 platform. A similar audit may be required for other IBF loaders reading 8-byte types. Please review and merge the fix (or implement an equivalent alignment-safe read for IBF floats). I can test any proposed patch on this hardware. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:123175] [Ruby Bug#21561] Wrong encoding for File.dirname result on Windows
by thyresias (Thierry Lambert) 04 Oct '25

04 Oct '25

Issue #21561 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #21561: Wrong encoding for File.dirname result on Windows https://bugs.ruby-lang.org/issues/21561 * Author: thyresias (Thierry Lambert) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I placed the file containing the code below in a directory named "à_signaler" to show the effect on non-ascii characters: ```ruby def dirname_encoding(file) h = { "file" => file, "File.dirname(file)" => File.dirname(file), "File.expand_path(file)" => File.expand_path(file), "File.expand_path(File.dirname(file))" => File.expand_path(File.dirname(file)), "File.dirname(File.expand_path(file))" => File.dirname(File.expand_path(file)), } puts h.each do |name, value| puts "#{name} = #{value.inspect} (#{value.encoding})" end end dirname_encoding "foo.bar" dirname_encoding "foo/bar" ``` The result: ``` file = "foo.bar" (UTF-8) File.dirname(file) = "." (US-ASCII) File.expand_path(file) = "D:/à_signaler/foo.bar" (UTF-8) File.expand_path(File.dirname(file)) = "D:/\xE0_signaler" (US-ASCII) File.dirname(File.expand_path(file)) = "D:/à_signaler" (UTF-8) file = "foo/bar" (UTF-8) File.dirname(file) = "foo" (UTF-8) File.expand_path(file) = "D:/à_signaler/foo/bar" (UTF-8) File.expand_path(File.dirname(file)) = "D:/à_signaler/foo" (UTF-8) File.dirname(File.expand_path(file)) = "D:/à_signaler/foo" (UTF-8) ``` The source problem is the encoding US-ASCII for "." This may be linked to Bug #20699. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123299] [Ruby Bug#21611] Ruby 3.4.6 can't be built with GCC 15.2.1
by watson1978 (Shizuo Fujita) 04 Oct '25

04 Oct '25

Issue #21611 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Bug #21611: Ruby 3.4.6 can't be built with GCC 15.2.1 https://bugs.ruby-lang.org/issues/21611 * Author: watson1978 (Shizuo Fujita) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Arch Linux provides GCC 15.2.1. https://archlinux.org/packages/core/x86_64/gcc/ When I build Ruby 3.4.6 with GCC 15.2.1, it cause error: ### How to Reproduce Here is a Dockerfile to reproduce the error: ``` FROM archlinux:latest RUN pacman -Syu --noconfirm RUN pacman -S --noconfirm curl base-devel libffi zlib openssl readline libyaml RUN curl -O https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.6.tar.gz RUN tar -xvzf ruby-3.4.6.tar.gz RUN cd ruby-3.4.6 && ./configure && make -j && make install ``` Then, run `docker build -t ruby . --platform=linux/amd64` command to reproduce the error. ``` $ docker build -t ruby . --platform=linux/amd64 [+] Building 362.6s (9/9) FINISHED docker:desktop-linux => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 332B 0.0s => [internal] load metadata for docker.io/library/archlinux:latest 0.3s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [1/6] FROM docker.io/library/archlinux:latest@sha256:8fe9851fcd8bd23ea0e6bfa99483d8778e40b45e0fd7bb8188c94cbdd8c25a38 0.0s => => resolve docker.io/library/archlinux:latest@sha256:8fe9851fcd8bd23ea0e6bfa99483d8778e40b45e0fd7bb8188c94cbdd8c25a38 0.0s => CACHED [2/6] RUN pacman -Syu --noconfirm 0.0s => [3/6] RUN pacman -S --noconfirm curl base-devel libffi zlib openssl readline libyaml 24.4s => [4/6] RUN curl -O https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.6.tar.gz 1.2s => [5/6] RUN tar -xvzf ruby-3.4.6.tar.gz 1.1s => ERROR [6/6] RUN cd ruby-3.4.6 && ./configure && make -j && make install 335.5s ------ > [6/6] RUN cd ruby-3.4.6 && ./configure && make -j && make install: 0.765 checking for ruby... false 0.888 checking build system type... x86_64-pc-linux-gnu 1.452 checking host system type... x86_64-pc-linux-gnu 1.452 checking target system type... x86_64-pc-linux-gnu ... 288.3 compiling enc/ascii.c 300.8 gcc: fatal error: Killed signal terminated program cc1 301.1 compilation terminated. 301.2 gcc: fatal error: Killed signal terminated program cc1 301.2 compilation terminated. 301.5 make: *** [Makefile:489: complex.o] Error 1 301.5 In file included from ./include/ruby/internal/assume.h:29, 301.5 from ./include/ruby/backward/2/assume.h:24, 301.5 from ./include/ruby/defines.h:72, 301.5 from ./include/ruby/ruby.h:25, 301.5 from ./include/ruby/encoding.h:19, 301.5 from encindex.h:14, 301.5 from compile.c:19: 301.5 compile.c: In function ‘ibf_load_catch_table’: 301.6 make: *** Waiting for unfinished jobs.... 301.6 make: *** [Makefile:489: io.o] Error 1 301.7 compile.c:13163:39: warning: taking address of packed member of ‘struct iseq_catch_table’ may result in an unaligned pointer value [-Waddress-of-packed-member] 301.7 13163 | RB_OBJ_WRITE(parent_iseq, &table->entries[i].iseq, catch_iseq); 301.7 ./include/ruby/internal/cast.h:31:29: note: in definition of macro ‘RBIMPL_CAST’ 301.7 31 | # define RBIMPL_CAST(expr) (expr) 301.7 | ^~~~ 301.7 compile.c:13163:13: note: in expansion of macro ‘RB_OBJ_WRITE’ 301.7 13163 | RB_OBJ_WRITE(parent_iseq, &table->entries[i].iseq, catch_iseq); 301.7 | ^~~~~~~~~~~~ 301.8 gcc: fatal error: Killed signal terminated program cc1 301.8 compilation terminated. 301.9 make: *** [Makefile:489: process.o] Error 1 309.6 gcc: fatal error: Killed signal terminated program cc1 309.6 compilation terminated. 309.6 make: *** [Makefile:489: vm.o] Error 1 313.7 gcc: fatal error: Killed signal terminated program cc1 313.7 compilation terminated. 313.7 make: *** [Makefile:489: string.o] Error 1 334.5 At top level: 334.5 cc1: note: unrecognized command-line option ‘-Wno-self-assign’ may have been intended to silence earlier diagnostics 334.5 cc1: note: unrecognized command-line option ‘-Wno-parentheses-equality’ may have been intended to silence earlier diagnostics 334.5 cc1: note: unrecognized command-line option ‘-Wno-constant-logical-operand’ may have been intended to silence earlier diagnostics ------ Dockerfile:7 -------------------- 5 | RUN curl -O https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.6.tar.gz 6 | RUN tar -xvzf ruby-3.4.6.tar.gz 7 | >>> RUN cd ruby-3.4.6 && ./configure && make -j && make install 8 | -------------------- ERROR: failed to build: failed to solve: ResourceExhausted: process "/bin/sh -c cd ruby-3.4.6 && ./configure && make -j && make install" did not complete successfully: cannot allocate memory ``` -- https://bugs.ruby-lang.org/

5 5

[ruby-core:123386] [Ruby Bug#21624] [BUG] Segmentation fault at 0x0000000000000000
by mriffe (Mel Riffe) 03 Oct '25

03 Oct '25

Issue #21624 has been reported by mriffe (Mel Riffe). ---------------------------------------- Bug #21624: [BUG] Segmentation fault at 0x0000000000000000 https://bugs.ruby-lang.org/issues/21624 * Author: mriffe (Mel Riffe) * Status: Open * ruby -v: ruby 3.3.9 (2025-07-24 revision f5c772fc7c) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The attached file contains the core dump I receive running `bin/rake db:setup` in a Ruby on Rails project. I'm looking for help on where the actual problem lies. Any assistance will be appreciated. **Background** I'm moving from a Mac Book Pro to an Ubuntu (24.04) Desktop, as my daily development machine. At first I suspected the `mysql2` gem, so I uninstalled it, and installed it again. I verified I have `libmysqlclient-dev` installed; I figure the gem wouldn't compile without the headers but I wanted to be sure. I do not have experience debugging core dumps/segmentation faults. Instruction would be greatly appreciated. What additional information can I provide to aid running down and solving this issue? Plus, if this is not the location for this notification, kindly point me in the right direction. Thank you for your time and energy. ---Files-------------------------------- error.out (381 KB) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123389] [Ruby Feature#21625] Allow IO#wait_readable together with IO#ungetc
by YO4 (Yoshinao Muramatsu) 03 Oct '25

03 Oct '25

Issue #21625 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Feature #21625: Allow IO#wait_readable together with IO#ungetc https://bugs.ruby-lang.org/issues/21625 * Author: YO4 (Yoshinao Muramatsu) * Status: Open ---------------------------------------- ### Background IO#wait_readable calles rb_io_check_byte_readable() in that C implementation, so that is treated as binary reading class operation. ```ruby open(IO::NULL, "rt") { |f| f.ungetc(?a); f.wait_readable } # => in 'IO#wait_readable': byte oriented read for character buffered IO (IOError) ``` This is inconsistent with the behavior of IO#select. ```ruby open(IO::NULL, "rt") { |f| f.ungetc(?a); IO.select([f]) } # => [[#<File:NUL (closed)>], [], []] ``` ### Proposal Change IO#wait_readable into character reading class function. This allows mixing usage of IO#wait_readable and IO#ungetc. This change avoids the IOError that previously occurred, but in that case, an exception is thrown when the binary read method is subsequently called. Overall behavior remains unchanged, but exceptions will occur at more desirable locations. If the method being called next is a character method, no exception will be thrown. But that is the desired behavior. ### related methods IO#io_wait_priority may apply similar changes for consistency. IO#ready? seems to have the same issue. This is in the io-wait default gem. IO#wait already respects the character read buffer. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123375] [Ruby Bug#21622] Prism wrongly accepts command call to be a key of keyword argument
by tompng (tomoya ishida) 03 Oct '25

03 Oct '25

Issue #21622 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21622: Prism wrongly accepts command call to be a key of keyword argument https://bugs.ruby-lang.org/issues/21622 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-02T03:48:32Z master 88222caaa9) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- These are syntax error in parse.y but accepted in Prism ~~~ruby p(p a, x: b => value) p(p a, x: => value) p(p a, &block => value) p(p a, *args => value) p(p a, **kwargs => value) ~~~ Maybe as a result, Prism accepts command call within command call ~~~ruby p p 1, &block => 2, &block p p p 1 => 2 => 3 => 4 ~~~ -- https://bugs.ruby-lang.org/

3 2