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

[ruby-core:123455] [Ruby Feature#7845] Strip doesn't handle unicode space characters in ruby 1.9.2 & 1.9.3 (does in 1.9.1)
by TALlama (Seth Roby) 09 Oct '25

09 Oct '25

Issue #7845 has been updated by TALlama (Seth Roby). matz (Yukihiro Matsumoto) wrote in #note-17: > That indicates the need for something like (({str.strip(:ascii)})), or opposite (({str.strip(:utf8)})) This issue has been dormant for many years, and Ruby has made a lot of changes to be use UTF-8 defaults while the world has steadily moved in that direction. Should we bring this back into consideration as a fix worth making? It certainly blindsided me, and I've been using Ruby since before this ticket was new. ---------------------------------------- Feature #7845: Strip doesn't handle unicode space characters in ruby 1.9.2 & 1.9.3 (does in 1.9.1) https://bugs.ruby-lang.org/issues/7845#change-114824 * Author: timothyg56 (Timothy Garnett) * Status: Open ---------------------------------------- Strip and associated methods in ruby 1.9.2 and 1.9.3 do not remove leading/trailing unicode space characters (such as non-breaking space \u00A0 and ideographic space \u3000) unlike ruby 1.9.1. I'd expect the 1.9.1 behavior. Looking at the underlying native lstrip! and rstrip! methods it looks like this is because 1.9.1 uses rb_enc_isspace() whereas 1.9.2+ uses rb_isspace(). 1.9.1p378 :001 > "\u3000\u00a0".strip => "" 1.9.2p320 :001 > "\u3000\u00a0".strip => "　 " 1.9.3p286 :001 > "\u3000\u00a0".strip => "　 " -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123318] [Ruby Bug#21614] thread_sched_wait_events race with timer_thread_wakeup
by luke-gru (Luke Gruber) 09 Oct '25

09 Oct '25

Issue #21614 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21614: thread_sched_wait_events race with timer_thread_wakeup https://bugs.ruby-lang.org/issues/21614 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `thread_sched_wait_events` checks th->sched.waiting_reason.flags under thread_sched_lock but not under timer_thread.waiting_lock. The timer thread sets it under the timer_thread.waiting_lock only. This race results in the assertion failure: `../ruby/thread_pthread.c:909: Assertion Failed: thread_sched_to_running_common:sched->running != th` Reproduction script (run it many times): ```ruby require "timeout" def invoke_ruby(args, stdin_data = "", capture_stdout = false, capture_stderr = false, encoding: nil, timeout: 10, reprieve: 1, timeout_error: Timeout::Error, stdout_filter: nil, stderr_filter: nil, ios: nil, signal: :TERM, rubybin: "ruby", precommand: nil, **opt) timeout = 60 in_c, in_p = IO.pipe out_p, out_c = IO.pipe if capture_stdout err_p, err_c = IO.pipe if capture_stderr && capture_stderr != :merge_to_stdout opt[:in] = in_c opt[:out] = out_c if capture_stdout opt[:err] = capture_stderr == :merge_to_stdout ? out_c : err_c if capture_stderr if encoding out_p.set_encoding(encoding) if out_p err_p.set_encoding(encoding) if err_p end ios.each {|i, o = i|opt[i] = o} if ios c = "C" child_env = {} if Array === args and Hash === args.first child_env.update(args.shift) end args = [args] if args.kind_of?(String) # use the same parser as current ruby if args.none? { |arg| arg.start_with?("--parser=") } args = ["--parser=prism"] + args end pid = spawn(child_env, *precommand, rubybin, *args, opt) in_c.close out_c&.close out_c = nil err_c&.close err_c = nil if block_given? return yield in_p, out_p, err_p, pid else th_stdout = Thread.new { out_p.read } if capture_stdout th_stderr = Thread.new { err_p.read } if capture_stderr && capture_stderr != :merge_to_stdout in_p.write stdin_data.to_str unless stdin_data.empty? in_p.close if (!th_stdout || th_stdout.join(timeout)) && (!th_stderr || th_stderr.join(timeout)) timeout_error = nil else $stderr.puts "Error: timed out" status = terminate(pid, signal, opt[:pgroup]) terminated = Time.now end stdout = th_stdout.value if capture_stdout stderr = th_stderr.value if capture_stderr && capture_stderr != :merge_to_stdout out_p.close if capture_stdout err_p.close if capture_stderr && capture_stderr != :merge_to_stdout status ||= Process.wait2(pid)[1] stdout = stdout_filter.call(stdout) if stdout_filter stderr = stderr_filter.call(stderr) if stderr_filter if timeout_error bt = caller_locations msg = "execution of #{bt.shift.label} expired timeout (#{timeout} sec)" raise timeout_error, msg, bt.map(&:to_s) end return stdout, stderr, status end ensure [th_stdout, th_stderr].each do |th| th.kill if th end [in_c, in_p, out_c, out_p, err_c, err_p].each do |io| io&.close end [th_stdout, th_stderr].each do |th| th.join if th end end def terminate(pid, signal = :TERM, pgroup = nil) case pgroup when 0, true pgroup = -pid when nil, false pgroup = pid end begin Process.kill signal, pgroup rescue Errno::EINVAL rescue Errno::ESRCH end $? end rs = [] 100.times do rs << Ractor.new do script = '$stdout.sync=true; def rec; print "."; rec; end; Fiber.new{rec}.resume' invoke_ruby([{}, '-e', script], "", true, true) end end rs.each(&:join) ``` This script is just taken directly from a failed test in the test suite that was run under multiple ractors at once (`test_vm_stack_size`). -- https://bugs.ruby-lang.org/

2 1

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

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

09 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: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