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

[ruby-core:123399] [Ruby Bug#21626] Backport WASI setjmp handler memory leak fixes
by white-axe (Hao Liu) 08 Oct '25

08 Oct '25

Issue #21626 has been reported by white-axe (Hao Liu). ---------------------------------------- Bug #21626: Backport WASI setjmp handler memory leak fixes https://bugs.ruby-lang.org/issues/21626 * Author: white-axe (Hao Liu) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The WASI builds of Ruby 3.2, 3.3 and 3.4 currently have bugs in the handling of setjmp/longjmp that cause memory leaks. In Ruby 3.2, 3.3 and 3.4, there is a bug where the stack pointer is sometimes not reset after a longjmp, leading to leaking of part of the stack and the garbage collector being unable to garbage collect some Ruby objects since the garbage collector looks for GC roots on the stack. In Ruby 3.3 and 3.4, https://github.com/ruby/ruby/pull/8902 caused a second bug where setjmp buffers are not freed after a longjmp. The combination of these two bugs causes the WASI builds of Ruby 3.3 and 3.4 to very rapidly run out of memory when running this script. The memory leak is much less noticeable in the WASI build of Ruby 3.2. ```ruby loop do array = [0] for item in array break end end ``` To test it out, save this script as test.rb in the current working directory and then run these commands. This tests the WASI build of Ruby 3.4, but you can change the "3.4" to "3.3" to test out the build for Ruby 3.3. If you use the Ruby 3.5 build instead by replacing "3.4" with "head", it will not crash anymore. ``` curl -Lo ruby.tar.gz https://github.com/ruby/ruby.wasm/releases/download/2.7.2/ruby-3.4-wasm32-u… tar xzf ruby.tar.gz --strip-components=1 wasmtime --dir .::/ usr/local/bin/ruby test.rb ``` These two bugs should have been fixed in Ruby 3.5 by https://github.com/ruby/ruby/pull/12995, but the fix contained bugs that were later amended by https://github.com/ruby/ruby/pull/13026 and https://github.com/ruby/ruby/pull/13142. I'm requesting for the changes from all three of these pull requests to be backported to Ruby 3.2, 3.3 and 3.4, which could be done with the patch below. For Ruby 3.2, only the changes to wasm/setjmp.c and wasm/setjmp.h are required because the other changes are only to fix the second bug. ```patch --- a/cont.c +++ b/cont.c @@ -1509,6 +1509,51 @@ cont_restore_thread(rb_context_t *cont) rb_raise(rb_eRuntimeError, "can't call across trace_func"); } +#if defined(__wasm__) && !defined(__EMSCRIPTEN__) + if (th->ec->tag != sec->tag) { + /* find the lowest common ancestor tag of the current EC and the saved EC */ + + struct rb_vm_tag *lowest_common_ancestor = NULL; + size_t num_tags = 0; + size_t num_saved_tags = 0; + for (struct rb_vm_tag *tag = th->ec->tag; tag != NULL; tag = tag->prev) { + ++num_tags; + } + for (struct rb_vm_tag *tag = sec->tag; tag != NULL; tag = tag->prev) { + ++num_saved_tags; + } + + size_t min_tags = num_tags <= num_saved_tags ? num_tags : num_saved_tags; + + struct rb_vm_tag *tag = th->ec->tag; + while (num_tags > min_tags) { + tag = tag->prev; + --num_tags; + } + + struct rb_vm_tag *saved_tag = sec->tag; + while (num_saved_tags > min_tags) { + saved_tag = saved_tag->prev; + --num_saved_tags; + } + + while (min_tags > 0) { + if (tag == saved_tag) { + lowest_common_ancestor = tag; + break; + } + tag = tag->prev; + saved_tag = saved_tag->prev; + --min_tags; + } + + /* free all the jump buffers between the current EC's tag and the lowest common ancestor tag */ + for (struct rb_vm_tag *tag = th->ec->tag; tag != lowest_common_ancestor; tag = tag->prev) { + rb_vm_tag_jmpbuf_deinit(&tag->buf); + } + } +#endif + /* copy vm stack */ #ifdef CAPTURE_JUST_VALID_VM_STACK MEMCPY(th->ec->vm_stack, --- a/signal.c +++ b/signal.c @@ -854,6 +854,7 @@ check_stack_overflow(int sig, const uintptr_t addr, const ucontext_t *ctx) * otherwise it can cause stack overflow again at the same * place. */ if ((crit = (!ec->tag->prev || !--uplevel)) != FALSE) break; + rb_vm_tag_jmpbuf_deinit(&ec->tag->buf); ec->tag = ec->tag->prev; } reset_sigmask(sig); --- a/vm.c +++ b/vm.c @@ -2829,6 +2829,7 @@ vm_exec_handle_exception(rb_execution_context_t *ec, enum ruby_tag_type state, V if (VM_FRAME_FINISHED_P(ec->cfp)) { rb_vm_pop_frame(ec); ec->errinfo = (VALUE)err; + rb_vm_tag_jmpbuf_deinit(&ec->tag->buf); ec->tag = ec->tag->prev; EC_JUMP_TAG(ec, state); } --- a/vm_trace.c +++ b/vm_trace.c @@ -455,6 +455,7 @@ rb_exec_event_hooks(rb_trace_arg_t *trace_arg, rb_hook_list_t *hooks, int pop_p) if (state) { if (pop_p) { if (VM_FRAME_FINISHED_P(ec->cfp)) { + rb_vm_tag_jmpbuf_deinit(&ec->tag->buf); ec->tag = ec->tag->prev; } rb_vm_pop_frame(ec); --- a/wasm/setjmp.c +++ b/wasm/setjmp.c @@ -143,9 +143,11 @@ rb_wasm_try_catch_init(struct rb_wasm_try_catch *try_catch, try_catch->try_f = try_f; try_catch->catch_f = catch_f; try_catch->context = context; + try_catch->stack_pointer = NULL; } // NOTE: This function is not processed by Asyncify due to a call of asyncify_stop_rewind +__attribute__((noinline)) void rb_wasm_try_catch_loop_run(struct rb_wasm_try_catch *try_catch, rb_wasm_jmp_buf *target) { @@ -154,6 +156,10 @@ rb_wasm_try_catch_loop_run(struct rb_wasm_try_catch *try_catch, rb_wasm_jmp_buf target->state = JMP_BUF_STATE_CAPTURED; + if (try_catch->stack_pointer == NULL) { + try_catch->stack_pointer = rb_wasm_get_stack_pointer(); + } + switch ((enum try_catch_phase)try_catch->state) { case TRY_CATCH_PHASE_MAIN: // may unwind @@ -175,6 +181,8 @@ rb_wasm_try_catch_loop_run(struct rb_wasm_try_catch *try_catch, rb_wasm_jmp_buf // stop unwinding // (but call stop_rewind to update the asyncify state to "normal" from "unwind") asyncify_stop_rewind(); + // reset the stack pointer to what it was before the most recent call to try_f or catch_f + rb_wasm_set_stack_pointer(try_catch->stack_pointer); // clear the active jmpbuf because it's already stopped _rb_wasm_active_jmpbuf = NULL; // reset jmpbuf state to be able to unwind again --- a/wasm/setjmp.h +++ b/wasm/setjmp.h @@ -65,6 +65,7 @@ struct rb_wasm_try_catch { rb_wasm_try_catch_func_t try_f; rb_wasm_try_catch_func_t catch_f; void *context; + void *stack_pointer; int state; }; ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123405] [Ruby Misc#21628] Sync default gems to ruby/ruby with GitHub Actions
by k0kubun (Takashi Kokubun) 08 Oct '25

08 Oct '25

Issue #21628 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #21628: Sync default gems to ruby/ruby with GitHub Actions https://bugs.ruby-lang.org/issues/21628 * Author: k0kubun (Takashi Kokubun) * Status: Open ---------------------------------------- ## Announcement We will change the way default gems are synchronized to ruby/ruby. * **Before**: Push to gem repository → webhook.cgi → git.ruby-lang.org pushes to ruby/ruby * **After**: Push to gem repository → GitHub Actions on gem repository → GitHub Actions on ruby/ruby pushes to ruby/ruby ## Background * The apache2 server for https://git.ruby-lang.org has been taken down because it has been under DDoS attacks and we couldn't handle it. As a result, its webhook.cgi is no longer online. * It was hard for default gem maintainers to notice sync failures, look at their logs, and fix them. * Moving the implementation to GitHub Actions would make them more visible and accessible for the maintainers. ## Operations To set up sync from ruby/xxx to ruby/ruby, you need to do the following operations: 1. [Optional] Remove `https://git.ruby-lang.org/webhook` from Settings > Webhooks if it's currently set. 2. On Settings > Secrets and variables > Actions > Organization secrets, make sure the repository has access to `RUBY_SYNC_DEFAULT_GEMS_PRIVATE_KEY` * Consult @hsbt if it's not visible for the repository. "ruby-sync-default-gems GitHub App Private Key" is managed under the "Ruby core team" 1Password vault. 3. Add a GitHub Actions workflow list this [.github/workflows/sync-ruby.yml](https://github.com/ruby/erb/blob/v5.0.3/.github/workflows/sync-ruby.yml) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123414] [Ruby Bug#21629] Ruby-3.4.7 fails to build using clang / llvm
by debo (David Bohman) 08 Oct '25

08 Oct '25

Issue #21629 has been reported by debo (David Bohman). ---------------------------------------- Bug #21629: Ruby-3.4.7 fails to build using clang / llvm https://bugs.ruby-lang.org/issues/21629 * Author: debo (David Bohman) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [x86_64-darwin16] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Here is the error I encountered. This is using clang version 21.1.3 as the compiler toolchain on Darwin. ``` DYLD_LIBRARY_PATH=.:../../.. ASAN_OPTIONS=detect_leaks=0 "clang -I../../../.ext/include/x86_64-darwin16 -I../../../../ruby-3.4.7/include -I../../../../ruby-3.4.7/ext/-test-/public_header_warnings -I/usr/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wmisleading-indentation -Wundef -fno-common -pipe -D_TEST_OK -Werror -c conftest.c" In file included from conftest.c:1: In file included from ../../../../ruby-3.4.7/include/ruby.h:38: In file included from ../../../../ruby-3.4.7/include/ruby/ruby.h:28: In file included from ../../../../ruby-3.4.7/include/ruby/internal/arithmetic.h:24: In file included from ../../../../ruby-3.4.7/include/ruby/internal/arithmetic/char.h:29: ../../../../ruby-3.4.7/include/ruby/internal/core/rstring.h:398:24: error: default initialization of an object of type 'struct RString' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 398 | struct RString retval; | ^ ../../../../ruby-3.4.7/include/ruby/internal/core/rbasic.h:86:17: note: member 'klass' declared 'const' here 86 | const VALUE klass; | ^ 1 error generated. checked program was: /* begin */ 1: #include "ruby.h" 2: 3: int main(int argc, char **argv) 4: { 5: return !!argv[argc]; 6: } /* end */ ``` The configuration is the following: ``` CC=clang CXX=clang++ CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ../ruby-3.4.7/configure --enable-shared --with-rdoc=ri,html ``` -- https://bugs.ruby-lang.org/

4 17

[ruby-core:123350] [Ruby Bug#21618] Allow to use the build-in prism version to parse code
by Earlopain (Earlopain _) 08 Oct '25

08 Oct '25

Issue #21618 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21618: Allow to use the build-in prism version to parse code https://bugs.ruby-lang.org/issues/21618 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism is a multi-version parser, which is a great feature. If one calls `Prism.parse("foo")`, it will always use the latest version prism knows about. This may or may not be the version that is currently executing. This is problematic when one wants to introspect code the same way that the currently running ruby version would. Consider that some syntax will be disallowed in the next ruby version. I would have to specify the ruby version I want to parse as in order to not run into syntax errors: `Prism.parse("foo", version: RUBY_VERSION)`. But doing so is not feasable because `prism` is distributed out of sync with ruby itself. If the user already has prism in their lockfile, the user may run a prism version that doesn't yet know about lets say ruby 4.0 and thus raise. Similarly, it may parse as an older patch version that has subtle behaviour differences. `ripper` does not have this issue because it is always tied to the ruby version and it is not distributed as a gem, so what the user has will always be exactly what ruby shipped with. I wish for a similar API that utilizes the prism version bundled with ruby itself. Libraries like `rails` have moved from ripper to prism because of its superior developer experience but it risks breaking in unexpected ways with new `prism` versions that know about more recent syntax. `error_highlight` for example also suffers from the same defect. It seems like prism currently has 34 methods that optionally take a version (per the rbi file). Many of these are trivial helper methods like `Prism.parse_success?` (does the parse result have any errors?). I would be happy with supporting only the minimal functions like `Prism.parse` and `Prism.parse_file`. Currently I don't have a use-case for any of the other methods. Pretty much just functions to mirror `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.compile`. It would be optimal if I would be able to transparently call `Prism.parse("foo", version: "current")` (or maybe even have an unspecified version mean the build-in prism version) but I am not sure how feasable that is since I'm pretty sure logic for this would have to live in ruby itself. @kddnewton does this feature request make sense? Do you have any other ideas/inputs? -- https://bugs.ruby-lang.org/

4 13

[ruby-core:123383] [Ruby Bug#21623] Endless method definition without parenthesis is wrongly accepted in Prism
by tompng (tomoya ishida) 08 Oct '25

08 Oct '25

Issue #21623 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21623: Endless method definition without parenthesis is wrongly accepted in Prism https://bugs.ruby-lang.org/issues/21623 * 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 def f x: = 1 def f ... = 1 def f * = 1 def f ** = 1 def f & = 1 def f *a = 1 def f **a = 1 def f &a = 1 ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123413] PAY OR BE EXPOSED
by ruby-core＠ml.ruby-lang.org 07 Oct '25

07 Oct '25

1 0

[ruby-core:123411] PAY OR BE EXPOSED
by ruby-core＠ml.ruby-lang.org 07 Oct '25

07 Oct '25

1 0

[ruby-core:122164] [Ruby Feature#21347] Add `open_timeout` as an overall timeout option for `Socket.tcp`
by shioimm (Misaki Shioi) 07 Oct '25

07 Oct '25

Issue #21347 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #21347: Add `open_timeout` as an overall timeout option for `Socket.tcp` https://bugs.ruby-lang.org/issues/21347 * Author: shioimm (Misaki Shioi) * Status: Open ---------------------------------------- I propose to add an overall timeout option to `Socket.tcp` (and `TCPSocket.new`) ### Background Currently, `TCPSocket.new` and `Socket.tcp` accept two kind of timeout options: - `resolv_timeout`, which controls the timeout for DNS resolution - `connect_timeout`, which controls the timeout for the connection attempt With the introduction of Happy Eyeballs Version 2 (as per [RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305)) in[ Feature #20108](https://bugs.ruby-lang.org/issues/20108) and [Feature #20782](https://bugs.ruby-lang.org/issues/20782), both address resolution and connection attempts are now parallelized. As a result, the sum of `resolv_timeout` and `connect_timeout` no longer represents the total timeout duration. This is because, in HEv2, name resolution and connection attempts are performed concurrently, causing the two timeouts to overlap. Example: When `resolv_timeout: 200ms` and `connect_timeout: 100ms` are set: 1. An IPv6 address is resolved after the method starts immediately (IPv4 is still being resolved). 2. A connection attempt is initiated to the IPv6 address 3. After 100ms, `connect_timeout` is exceeded. However, since `resolv_timeout` still has 100ms left, the IPv4 resolution continues. 4. After 200ms from the start, the method raises a `resolv_timeout` error. In this case, the total elapsed time before a timeout is 200ms, not the expected 300ms (100ms + 200ms). Furthermore, in HEv2, connection attempts are also parallelized. It starts a new connection attempts every 250ms for resolved addresses. This makes the definition of `connect_timeout` even more ambiguous—specifically, it becomes unclear from which point the timeout is counted. Additionally, these methods initiate new connection attempts every 250ms (Connection Attempt Delay) for each candidate address, thereby parallelizing connection attempts. However, this behavior makes it unclear from which point in time the connect_timeout is actually measured. Currently, a `connect_timeout` is raised only after the last connection attempt exceeds the timeout. Example: When `connect_timeout: 100ms` is set and 3 address candidates: 1. Connect to address `a` at t=0ms. 2. Connect to address `b` at t=250ms. 3. Connect to address `c` at t=500ms. 4. If all fail, the exception is raised at t=1500ms (1000ms after `c`, 1250ms after `b`, 1500ms after `a`). 1. Start a connection attempt to the address `a` 2. 250ms after step 1, start a new connection attempt to the address `b` 3. 500ms after step 1, start a new connection attempt to the address `c` 4. 1000ms after step 3 (1000ms after starting the connection to `c`, 1250ms after starting the connection to `b,` and 1500ms after starting the connection to `a`) `connect_timeout` is raised This behavior aims to favor successful connections by allowing more time for each attempt, but it results in a timeout model that is difficult to reason about. These methods have supported `resolv_timeout` and `connect_timeout` options even before the introduction of HEv2. However, in many use cases, it would be more convenient if a timeout occurred after a specified duration from the start of the method. Similar functions in other languages (such as PHP, Python, and Go) typically allow specifying only an overall timeout. ### Proposal I propose adding an `open_timeout` option to `Socket.tcp` in the following PR, which triggers a timeout after a specified duration has elapsed from the start of the method. https://github.com/ruby/ruby/pull/13368 The name `open_timeout` aligns with the existing accessor used in `Net::HTTP`. If `open_timeout` is specified together with `resolv_timeout` and `connect_timeout`, I propose that only `open_timeout` be used and the others be ignored. While it is possible to support combinations of `open_timeout`, `resolv_timeout`, and `connect_timeout`, doing so would require defining which timeout takes precedence in which situations. In this case, I believe it is more valuable to keep the behavior simple and easy to understand, rather than supporting more complex use cases. If this proposal is accepted, I also plan to extend `open_timeout` support to `TCPSocket.new`. While the long-term future of `resolv_timeout` and `connect_timeout` may warrant further discussion, I believe the immediate priority is to offer a straightforward way to specify an overall timeout. ### Outcome If `open_timeout` is also supported by `TCPSocket.new`, users would be able to manage total connection timeouts directly in `Net::HTTP#connect` without relying on `Timeout.timeout`. https://github.com/ruby/ruby/blob/aa0f689bf45352c4a592e7f1a044912c40435266/… -- https://bugs.ruby-lang.org/

3 8

[ruby-core:123401] [Ruby Misc#21627] No usages of rb_enumeratorize
by ricardo.trindade743＠gmail.com (Ricardo Trindade) 07 Oct '25

07 Oct '25

Issue #21627 has been reported by ricardo.trindade743(a)gmail.com (Ricardo Trindade). ---------------------------------------- Misc #21627: No usages of rb_enumeratorize https://bugs.ruby-lang.org/issues/21627 * Author: ricardo.trindade743(a)gmail.com (Ricardo Trindade) * Status: Open * Assignee: ricardo.trindade743(a)gmail.com (Ricardo Trindade) ---------------------------------------- Throughout the codebase there seems to be no usages of the rb_enumeratorize method. Behind the scenes it is calling rb_enumeratorize_with_size which seems to be the recommended option, and this method has way more usages. Would it be ok to cleanup the method and its usages? Last issue reported here https://bugs.ruby-lang.org/issues/7302. If I get it correctly it seems to point that the method should be internal. Happy to work on a PR for this. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112552] [Ruby master Bug#19461] Time.local performance tanks in forked process (on macOS only?)
by ioquatix (Samuel Williams) 06 Oct '25

06 Oct '25

Issue #19461 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19461: Time.local performance tanks in forked process (on macOS only?) https://bugs.ruby-lang.org/issues/19461 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following program demonstrates a performance regression in forked child processes when invoking `Time.local`: ```ruby require 'benchmark' require 'time' def sir_local_alot result = Benchmark.measure do 10_000.times do tm = ::Time.local(2023) end end $stderr.puts result end sir_local_alot pid = fork do sir_local_alot end Process.wait(pid) ``` On Linux the performance is similar, but on macOS, the performance is over 100x worse on my M1 laptop. -- https://bugs.ruby-lang.org/

5 10