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

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

[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: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) 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