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

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

06 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) 05 Oct '25

05 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) 05 Oct '25

05 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:123357] [Ruby Feature#21619] logger: Context API
by chucke (Tiago Cardoso) 01 Oct '25

01 Oct '25

Issue #21619 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Feature #21619: logger: Context API https://bugs.ruby-lang.org/issues/21619 * Author: chucke (Tiago Cardoso) * Status: Open ---------------------------------------- The logger gem is notoriously simple to use, but hard to extend. One can only observe a few of the gems that added tags / json / logstash formatting support to see the same functionality reimplemented in "same but different" ways. For example, `logstash-logger`, `semantic_logger`, or the `activesupport` tagged logger handle tagging in virtually the same way. sidekiq has a (IMO) convoluted API to add per-job context to log message, which somewhat works as long as one does not need per-fiber contexts. Several other "log as JSON" gems fight with the same issues to deliver something that works, and either heavily patch the `Logger` or `Logger::Formatter` or circumvent its usage altogether. The default formatter already supports per-message context, but that context is limited to a few "static" parameters (severity, current time, process id, progname) which are logged in the following manner: Logger.new(STDOUT).info("foo") #=> I, [2025-08-13T15:00:03.830782 #5374] INFO -- : foo There is currently no way to add more parameters, or (if necessary) override the existing ones. These patterns could be coalesced into the main logger gem in a way that extending it should be simpler than what it is right now. == Context API This is a proposal to extend the Logger API in a way that both per-scope or per-message context can be passed downstream to the formatter(s), and logged accordingly: logger = Logger.new(STDOUT) logger.info("foo") #=> I, [2025-08-13T15:00:03.830782 #5374] INFO -- : foo logger.info { "foo" } #=> I, [2025-08-13T15:00:03.830782 #5374] INFO -- : foo # per message context logger.info("foo", context: {user_id: 1}) #=> I, [user_id=1] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo logger.info(context: { user_id: 1 }) { "foo" } #=> I, [user_id=1] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo # or logger.info("foo", context: ["alwaysblue"]) #=> I, [alwaysblue] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo. # per message context logger.with_context(a: 1) do logger.info("foo") #=> I, [a=1] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo end logger.with_context(a: 1) do logger.with_context(b: 2) do logger.info("foo") #=> I, [a=1] [b=2] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo end end This API would achieve the same goal as the examples mentioned above, or the sidekiq `Logger#with` function, in a standard manner, where formatters would just receive context as a bunch of key-value pairs (or an array of "string-able" objects, both work for me). == PR A proposal of the feature in logger can be found in https://github.com/ruby/logger/pull/132. It builds on top of the earlier addition of Logger#with_level, which does the scope-based change in a similar way, but only for the level, storing the context per fiber in the logger. Once context is standardized, adding i.e. a JSON or logstash formatter would be much simpler, formatters would receive it in the method call (instead of the indirection of using thread variables, which is what most mentioned implementations use). Drawbacks One of the main benefits of using the log.info { "msg" } idiom is that the "msg" string never gets allocated if the logger severity level skips logging the message. In the current proposal, the context is always present, and will result in a few allocations bubbling downstream. I'm not sure how important or negligible this concern is though. A concern here would be backwards compatibility, as currently, custom formatters do not expose a method signature which allows sending kwargs. Perhaps there's a way to introspect the formatter method to infer whether the signature supports kwargs, but even if it does, the check does have its cost. Other questions were raised during the PR review by jeremy evans and nevans. There's more discussion in the PR about pros and cons for each, so I'll just list them here: * supporting `with_context` block `:context` kwarg unnecessarily complex, proposal should stick to the former. * context should be stores in formatter rather than logger. * supporting hash and array as context in unnecessary complexity, pick the former * context log format should be like go, concatenated at the end of the message * extend formatter API to help users avoid leaking PII data -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123327] [Ruby Feature#21617] Add Internationalized Domain Name (IDN) support to URI
by byroot (Jean Boussier) 30 Sep '25

30 Sep '25

Issue #21617 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21617: Add Internationalized Domain Name (IDN) support to URI https://bugs.ruby-lang.org/issues/21617 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Originally proposed by @chucke at https://github.com/ruby/uri/issues/76, trying to formalize it here. ### Context [Internalized Domain Names](https://en.wikipedia.org/wiki/Internationalized_domain_name), are getting more common, yet Ruby's `uri` default gem has no support for it: ```ruby >> URI("https://日本語.jp/") URI must be ascii only "https://\u65E5\u672C\u8A9E.jp/" (URI::InvalidURIError) ``` So any program that which to handle arbitrary valid URIs provided by users can't use the `uri` gem, and instead have to depend on third party gems like [`addressable`](https://rubygems.org/gems/addressable) ```ruby >> Addressable::URI.parse("https://日本語.jp/") => #<Addressable::URI:0xd648 URI:https://日本語.jp/> ``` But even there, it won't seamlessly work with other libraries such as `net-http`: ``ruby >> Net::HTTP.get(Addressable::URI.parse("https://日本語.jp/")).bytesize OpenSSL::SSL::SSLSocket#connect_nonblock': SSL_connect returned=1 errno=0 peeraddr=[2001:218:3001:7::110]:443 state=error: ssl/tls alert handshake failure (SSL alert number 40) (OpenSSL::SSL::SSLError) ``` You have to explicitly normalize the URL: ```ruby >> Addressable::URI.parse("https://日本語.jp/").normalize => #<Addressable::URI:0x130d0 URI:https://xn--wgv71a119e.jp/> >> Net::HTTP.get(Addressable::URI.parse("https://日本語.jp/").normalize).bytesize => 8703 ``` ### Feature Request I believe it's would be very useful if the default `uri` gem had the capacity of: - Parsing IDNA domain names. - Convert URLs between their unicode and ASCII forms. The `URI::Generic` class already have a `#normalize` method to ensure the host and schema parts are all lower case, it could be extended to encode IDN hosts into their ASCII equivalent. It would also be useful if the opposite operation was supported for display purposes, not sure what name such a method could have, perhaps `canonicalize`? ### Implementation In https://github.com/ruby/uri/issues/76 @skryukov pointed to his pure Ruby implementation of IDNA 2008, I believe it would be good to upstream parts of it in the `uri` gem to implement these feature. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:123189] [Ruby Bug#21565] YJIT has panicked in rails
by eiskrenkov (Egor Iskrenkov) 30 Sep '25

30 Sep '25

Issue #21565 has been reported by eiskrenkov (Egor Iskrenkov). ---------------------------------------- Bug #21565: YJIT has panicked in rails https://bugs.ruby-lang.org/issues/21565 * Author: eiskrenkov (Egor Iskrenkov) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've got YJIT has panicked crash in rails app locally on my M1 Pro Mac Book pro for 2 times for last 2 weeks ``` Started GET "/api/admin/environments/13/edit" for ::1 at 2025-09-08 18:32:17 +0200 Processing by Api::Admin::EnvironmentsController#edit as JSON Parameters: {"id" => "13", "environment" => {}} ruby: YJIT has panicked. More info to follow... thread '<unnamed>' panicked at ./yjit/src/codegen.rs:5031:9: assertion failed: !val_type.is_imm() stack backtrace: 0: _rust_begin_unwind 1: core::panicking::panic_fmt 2: core::panicking::panic 3: yjit::codegen::jit_guard_known_klass 4: yjit::codegen::gen_equality_specialized 5: yjit::codegen::gen_opt_eq 6: yjit::codegen::gen_single_block 7: yjit::core::gen_block_series 8: yjit::core::branch_stub_hit_body 9: yjit::stats::with_compile_time 10: yjit::cruby::with_vm_lock 11: yjit::core::branch_stub_hit note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. /Users/eiskrenkov/.local/share/mise/installs/ruby/3.4.5/lib/ruby/gems/3.4.0/gems/actionpack-8.0.2.1/lib/action_dispatch/request/session.rb:118: [BUG] YJIT: panicked at ./yjit/src/codegen.rs:5031:9: assertion failed: !val_type.is_imm() ruby 3.4.5 (2025-07-16 revision 20cda200d3) +YJIT +PRISM [arm64-darwin24] ``` It happens randomly, I couldn't find reproduction steps sadly ---Files-------------------------------- ruby-2025-09-08-183231.ips (45.3 KB) -- https://bugs.ruby-lang.org/

3 5

[ruby-core:115552] [Ruby master Misc#20032] Propose @kjtsanaktsidis as a commiter
by jeremyevans0 (Jeremy Evans) 27 Sep '25

27 Sep '25

Issue #20032 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Misc #20032: Propose @kjtsanaktsidis as a commiter https://bugs.ruby-lang.org/issues/20032 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- I'd like to propose @kjtsanaktsidis as a committer, with a focus on bug triaging and fixing. During RubyKaigi 2023, KJ expressed interest in helping triage and fix bugs, and since then, he has fixed numerous bugs. What's most impressive about KJ's contributions is the difficulty of the bugs he has fixed, and the wide range of areas in which he has fixed bugs (GC, threading, FreeBSD support, ractors, rubygems, extensions, tests, old bugs, etc.). Here is a list of bugs KJ has fixed: * #20021 * #19994 * #19928 * #19873 * #19387 * #19680 * #4173 Here is a list of open pull requests submitted by KJ to fix bugs: * #20022 https://github.com/ruby/ruby/pull/9041 * #19991 https://github.com/ruby/ruby/pull/8949 and https://github.com/ruby/ruby/pull/8856 * #20001 https://github.com/ruby/ruby/pull/8903 * #19717 https://github.com/ruby/ruby/pull/8331 * #19144 https://github.com/ruby/ruby/pull/7295 * #18795 https://github.com/ruby/ruby/pull/5992 In addition to these Redmine issues, KJ has also fixed other bugs: * https://github.com/ruby/ruby/commit/9a62fd3cbae2ebb60e2f9cad782af1ad18db4319 * https://github.com/ruby/ruby/commit/76dc327eeffefe02577999fe5f8215f762a581b6 * https://github.com/ruby/ruby/commit/082962e857833dfc16881cb4dfb44caa175590ba * https://github.com/ruby/ruby/commit/edee9b6a12ac846d7b3de2d704e170bf28178cb3 * https://github.com/ruby/ruby/commit/dd406c5a911d2f4a16ce97016666760713540185 * https://github.com/ruby/ruby/commit/7bd7aee02e303de27d2cddfc5ef47e612d6782cb * https://github.com/ruby/ruby/commit/05ffc037ad15560cb2c683682c5bc374156571d7 * https://github.com/ruby/ruby/pull/7867 * https://github.com/ruby/ruby/pull/7865 * https://github.com/ruby/zlib/commit/3b9fe962d8 * https://github.com/ruby/zlib/commit/c96e8b9a57 In addition to bug fixing, KJ has also proposed and implemented a useful Socket feature: * #19179 https://github.com/ruby/ruby/pull/6822 -- https://bugs.ruby-lang.org/

8 14

[ruby-core:123136] [Ruby Feature#21557] Ractor.shareable_proc to make sharable Proc objects, safely and flexibly
by Eregon (Benoit Daloze) 23 Sep '25

23 Sep '25

Issue #21557 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21557: Ractor.shareable_proc to make sharable Proc objects, safely and flexibly https://bugs.ruby-lang.org/issues/21557 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- Following #21039 and #21550, this is a complete proposal which does not require reading these previous proposals (since that caused some confusion). That way, it is hopefully as clear as possible. It also explains how it solves everything we discussed in the previous tickets. To use Ractor effectively, one needs to create Procs which are shareable between Ractors. Of course, such Procs must not refer to any unshareable object (otherwise the Ractor invariant is broken and segfaults follow). One key feature of blocks/Procs is to be able to capture outer variables, e.g.: ```ruby data = ... task = -> { do_work(data) } ``` Ractor shareable procs should be able to use captured variables, because this is one of the most elegant ways to pass data/input in Ruby. But there is a fundamental conflict there, reassigning captured variables cannot be honored by shareable procs, otherwise it breaks the Ractor invariant. So creating a shareable proc internally makes a shallow copy of the environment, to not break the Ractor invariant. We cannot prevent assigning local variables (i.e. raise an exception on `foo = value`), that would be way to weird. But we can raise an error when trying to create a shareable proc in an incompatible situation, that makes it safe by preventing the unsafe cases. ## Reassigning a captured variable inside the block Concretely, it seems we all already agree that this should be a `Ractor::IsolationError`: ```ruby def example a = 1 b = proc { v = a; a += 1; v } r = Ractor.shareable_proc(&b) # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned inside the block [b, r] end example.map(&:call) ``` And that's because without the error the result would be `[1, 1]` which is unexpected (it should be `[1, 2]`), `r.call` should have updated `a` to 2 but it only updated `a` in its environment copy. That basically breaks the lexical scoping of variables captured by blocks. We can check this by static analysis, in fact we already use static analysis for `Ractor.new`: `a = 0; Ractor.new { a = 2 }` which gives `can not isolate a Proc because it accesses outer variables (a). (ArgumentError)`. ## Reassigning a captured variable outside the block The second problematic case is: ```ruby # error: the code clearly assumes it can reassigns `a` but the `shareable_proc` would not respect it, i.e. `shareable_proc` would break Ruby block semantics # Also note the Ractor.shareable_proc call might be far away from the block, so one can't tell when looking at the block that it would be broken by `shareable_proc` (if no error for this case) def example a = 1 b = proc { a } Ractor.shareable_proc(&b) # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside the block a = 2 end ``` This is very similar (it is the symmetric case), the `shareable_proc` cannot honor the `a = 2` assignment, so it should not allow creating a `shareable_proc` in that context and should be `Ractor::IsolationError`. If you don't see the issue in that small example, let's use this example: ```ruby page_views = 0 background_jobs.schedule_every(5.seconds) { puts "#{page_views} page views so far" } threaded_webserver.on("/") do page_views += 1 "Hello" end ``` If `background_jobs` uses `Thread`, everything is fine. If it uses `Ractor`, it needs to make that `schedule_every` block shareable, and if we don't add this safety check then it will always incorrectly print `0 page views so far`. This is what I mean by breaking Ruby block semantics. In this proposal, we prevent this broken semantics situation by `Ractor::IsolationError` when trying to make that `schedule_every` block shareable. One more reason here to forbid this case is that a block that is made shareable is never executed immediately on the current Ractor, because there is no need to make it shareable for that case. And so it means the block will be executed later, by some other Ractor. And that block, if it expects to be executed later, then definitely expects to see up-to-date captured variables (as in the author of the block expects that). We would check this situation by static analysis. There are multiple ways to go about it with trade-offs between precision and implementation complexity. I think we could simplify to: disallow `Ractor.shareable_proc` for any block which captures a variable which is potentially reassigned. In other words, only allow `Ractor.shareable_proc` if all the variables it captures are assigned (exactly) once. More on that later in section `Edge Cases`. ## Ractor.new Note that everything about `Ractor.shareable_proc` should also apply to `Ractor.new`, that way it's convenient to pass data via captured variables for `Ractor.new` too, example: ```ruby x = ... y = ... Ractor.new { compute(x, y) } ``` Currently `Ractor.new` does not allow capturing outer variables at all and needs workarounds such as: ```ruby x = ... y = ... Ractor.new(x, y) { |x, y| compute(x, y) } ``` ## define_method `define_method` (and of course `define_singleton_method` too) have been an issue since the beginning of Ractors, because methods defined by `define_method` just couldn't be called from a Ractor (because the block/Proc wouldn't be shareable and so can't be called from other Ractors). A workaround is to make the block/Proc shareable, but this is inconvenient, verbose and shouldn't be necessary: ```ruby def new_ostruct_member!(name) # :nodoc: unless @table.key?(name) || is_method_protected!(name) if defined?(::Ractor) getter_proc = nil.instance_eval{ Proc.new { @table[name] } } setter_proc = nil.instance_eval{ Proc.new {|x| @table[name] = x} } ::Ractor.make_shareable(getter_proc) ::Ractor.make_shareable(setter_proc) else getter_proc = Proc.new { @table[name] } setter_proc = Proc.new {|x| @table[name] = x} end define_singleton_method!(name, &getter_proc) define_singleton_method!("#{name}=", &setter_proc) end end ``` Instead, this proposal brings the idea for `define_method` to automatically call `Ractor.shareable_proc` on the given block/Proc (and fallback to the original Proc if it would raise), as if it was defined like: ```ruby def define_method(name, &body) body = Ractor.shareable_proc(self: nil, body) rescue body Primitive.define_method(name, &body) end ``` (note that `define_method` knows the `body` Proc's `self` won't be the original `self` anyway, so it's fine to change it to `nil`) This way workarounds like above are no longer needed and the code can be as simple as it used to be: ```ruby def new_ostruct_member!(name) # :nodoc: unless @table.key?(name) || is_method_protected!(name) define_singleton_method!(name) { @table[name] } define_singleton_method!("#{name}=") { |x| @table[name] = x } end end ``` Much nicer, and solves a longstanding issue with Ractor. There should be no compatibility issue since the block is only made shareable when it's safe to do so. This is another argument for making `Ractor.shareable_proc` safe. ## Ractor.shareable_proc and Ractor.shareable_lambda I believe we don't need `Ractor.shareable_lambda` (mentioned in other tickets). `Ractor.shareable_proc` should always preserve the lambda-ness (`Proc#lambda?`) of the given Proc. The role of `Ractor.shareable_proc` is to make the Proc shareable, not change arguments handling. If one wants a shareable lambda they can just use `Ractor.shareable_proc(&-> { ... })`. BTW, the added value of `Ractor.shareable_proc(self: nil, &proc)` vs just `Ractor.make_shareable(proc, copy: true)` is that it enables changing the receiver of the Proc without needing `nil.instance_eval { ... }` around, and it is much clearer. `Ractor.make_shareable(proc)` should be an error [as mentioned here](https://bugs.ruby-lang.org/issues/21039#note-14), because it would mutate the proc inplace and that's too surprising and unsafe (e.g. it would break `Proc#binding` on that Proc instance). `Ractor.make_shareable(proc, copy: true)` can be the same as `Ractor.shareable_proc(self: self, &proc)` (only works if `self` is shareable then), or an error. ## Edge Cases For these examples I'll use `enqueue`, which defines a block to execute later, either in a Thread or Ractor. For the Ractor case, `enqueue` would make the block shareable and send it to a Ractor to execute it. This is a bit more realistic than using plain `Ractor.shareable_proc` instead of `enqueue`, since it makes it clearer the block won't be executed right away on the main Ractor but later on some other Ractor. ### Nested Block Cases If the assignment is in a nested block, it's an error (this case is already detected for `Ractor.new` BTW): ```ruby a = 1 enqueue { proc { a = 1 } } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned inside the block ``` Similarly, if the assignment is in an some block outside, it's the same as if it was assigned directly outside: ```ruby a = 1 p = proc { a = 2 } enqueue { a } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside the block ``` ### Loop Cases This would be a `Ractor::IsolationError`, because `a` is reassigned. It would read a stale value and silently ignore reassignments if there was no `Ractor::IsolationError`. ```ruby a = 0 while condition enqueue { p a } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside the block a += 1 end ``` This is the same case, using a rescue-retry loop: ```ruby begin enqueue { p a } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside a += 1 raise rescue retry if condition end ``` A `for` loop is like a while `loop` because the LHS variable (`a`) and all variables in the loop body are actually declared outside (weird, but that's how it is). ```ruby for a in enum b = rand enqueue { p a } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside the block end binding.local_variables # => [:a, :b] ``` Any assignment inside one of these loops can potentially happen multiple times, so any variable assigned inside one of these loops cannot be captured by a shareable block (i.e., `Ractor::IsolationError` when trying to make a shareable block in such a case). We will need the static analysis to detect such loops. That probably doesn't need a full Control Flow Graph, we just need to determine if an assignment is "inside a while/for/retry" loop (up to a scope barrier like `def`/`class`/`module`). Regular "loops" using blocks are fine though, because they create a new environment/frame for each iteration. These 2 blocks will always see `[0, 1]` and `[0, 2]`, whether shareable or not: ```ruby a = 0 [1, 2].each do |e| enqueue { p [a, e] } # OK, each of these variables is assigned only once end ``` ### eval and binding Static analysis cannot detect `eval` or `binding`. In such an extreme and very rare case the fact that `shareable_proc` makes a copy of the environment is visible: ```ruby a = 1 b = proc { a } s = Ractor.shareable_proc(&b) eval("a = 2") # or binding.local_variable_set(:a, 2), or b.binding.local_variable_set(:a, 2) b.call # => 2 s.call # => 1 ``` This seems unavoidable, unless we prevent shareable procs to use captured variables at all (quite restrictive). BTW, `Proc#binding` is already not supported for a `shareable_proc`: ``` $ ruby -e 'nil.instance_exec { a = 1; b = proc { a }; b2 = Ractor.make_shareable(b); p b2.binding }' -e:1:in `binding': Can't create Binding from isolated Proc (ArgumentError) ``` So `binding`/`eval` is in general already not fully respected with Ractor anyway (and cannot be). ### Multiple Assignments Before This simple example assigns `a` twice. It would be safe because `a` is always assigned before (in execution, not necessarily in source order) creating the block instance/Proc instance, but it is not so easy to detect. Depending on how precise the static analysis is it might allow this case. We can always allow more and start with something simple. ```ruby a = 1 a = 2 Ractor.shareable_proc { a } # Ractor::IsolationError if using the single-assignment-only static analysis, seems OK because not so common ``` ### Error Message Differentiating `... which are reassigned inside/outside the block` might be needlessly complicated, in such a case I think it's fine to simplify the error message and omit the part after `... which are reassigned`. The important part is that the outer variable is reassigned, not whether it's inside or outside. ## Alternatives ### Relaxing the checks for literal blocks `Kernel#lambda` for example has behavior which depends on whether it's given a literal block or not: ```ruby lambda(&proc {}) # => the lambda method requires a literal block (ArgumentError) ``` We could have such a difference, but I don't think it's very useful, if a variable is reassigned, it seems a bad idea to capture and shallow-copy with a shareable proc (unclear, unsafe, etc). The semantics are also simpler if they are the same whether the block is literal or not. ### Removing the checks for reassigning a captured variable outside the block That's basically option 1 of #21550. This would allow known unsafe behavior and break the examples shown above (i.e. it would break code in a nasty way: some assignments are silently ignored, good luck to debug that). It would be hard to then forbid such cases later as it could then be considered incompatible. In my opinion we would commit a big language design mistake if we just give up and allow known unsafe cases like that, people wouldn't be able to trust that local variable assignments are respected (pretty fundamental, isn't it?) and that Ruby blocks behave as they always have been (with lexical scoping for local variables). It would also do nothing to help with `define_method`. `Ractor.shareable_proc(Proc)` is currently unsafe (the main point of #21039), let's address it, not ignore known problems, especially after a lot of discussion and thoughts on how to solve it properly. -- https://bugs.ruby-lang.org/

2 3