June 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125798] [Ruby Bug#22122] A Ractor/Ractor::Port memory leak (or so it would seem)
by miles-georgi (Miles Georgi) 19 Jun '26

19 Jun '26

Issue #22122 has been reported by miles-georgi (Miles Georgi). ---------------------------------------- Bug #22122: A Ractor/Ractor::Port memory leak (or so it would seem) https://bugs.ruby-lang.org/issues/22122 * Author: miles-georgi (Miles Georgi) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi! If I do something like this: ```ruby #!/usr/bin/env ruby 1000.times do return_port = Ractor::Port.new ractor = Ractor.new(return_port) do |return_port| return_port << Ractor::Port.new while receive end 10_000.times { ractor << true } # If you uncomment this then the leak goes away: # 10_000.times { return_port.receive } ractor << nil ractor.join end GC.start ractor_count = 0 port_count = 0 ObjectSpace.each_object do ractor_count += 1 if Ractor === it port_count += 1 if Ractor::Port === it end puts "ractors: #{ractor_count} ports: #{port_count}" ``` Then I see: ``` ractors: 1001 ports: 10001001 ``` Note that you can also just make the number of loops super big or infinite and just watch the memory grow. But a possible hint: if I uncomment that line that pulls stuff out of the ports it's creating, then I get: ``` ractors: 1 ports: 1 ``` Which is what I would expect since nothing references any of the ractors or ports created by the script and the ractors have all terminated. I can reproduce in both: ruby 4.1.0dev (2026-06-19T18:04:54Z master 1c1dafa769) +PRISM [x86_64-linux] and ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] Attached is the script. Thanks! ---Files-------------------------------- ractor-and-port-leak-script (542 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125788] [Ruby Bug#22120] Segfault caused by ar_find_entry_hint() not checking for conversion to st_table
by Eregon (Benoit Daloze) 19 Jun '26

19 Jun '26

Issue #22120 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22120: Segfault caused by ar_find_entry_hint() not checking for conversion to st_table https://bugs.ruby-lang.org/issues/22120 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: Eregon (Benoit Daloze) * Target version: 4.1 * ruby -v: ruby 4.1.0dev (2026-06-17T10:52:40Z master 0888fa8cb5) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- While perusing code in hash.c (motivated by some crashes reported in https://github.com/DataDog/dd-trace-rb/issues/5718) I found it suspicious that `ar_find_entry_hint()` didn't reread `bound` in the loop and yet called arbitrary code through `#eql?`. Indeed, ar_find_entry_hint() does not check if bound or the storage (AR->ST) changed and would return a bin index which is not correct to access: ```c static unsigned ar_find_entry_hint(VALUE hash, ar_hint_t hint, st_data_t key) { unsigned i, bound = RHASH_AR_TABLE_BOUND(hash); const ar_hint_t *hints = RHASH_AR_TABLE(hash)->ar_hint.ary; /* if table is NULL, then bound also should be 0 */ for (i = 0; i < bound; i++) { if (hints[i] == hint) { ar_table_pair *pair = RHASH_AR_TABLE_REF(hash, i); if (ar_equal(key, pair->key)) { RB_DEBUG_COUNTER_INC(artable_hint_hit); return i; } else { RB_DEBUG_COUNTER_INC(artable_hint_miss); } } } RB_DEBUG_COUNTER_INC(artable_hint_notfound); return RHASH_AR_TABLE_MAX_BOUND; } ``` Fix: https://github.com/ruby/ruby/pull/17383 With the conversion from AR to ST it can actually trigger a segfault: This repro uses a single thread and mutates inside `eql?` for simplicity, but the same crash happens with another Thread mutating while the main Thread is in `eql?`. ```ruby class Key attr_reader :v def initialize(v, h = nil) @v = v @h = h end def hash = 0 def eql?(other) if @h # Trigger AR->ST conversion @h[42] = 42 end other.is_a?(Key) && @v == other.v end def inspect = "K(#{@v})" end h = {} 8.times { |i| h[Key.new(i)] = i } # Not in the hash, so ar_find_entry_hint checks every entry. lookup_key = Key.new(-1, h) p h[lookup_key] ``` ``` $ ./miniruby ar_find_entry_hint_bug.rb ar_find_entry_hint_bug.rb:15: [BUG] Segmentation fault at 0x0000000000000004 ruby 4.1.0dev (2026-06-17T10:52:40Z master 0888fa8cb5) +PRISM [arm64-darwin25] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0003 p:0021 s:0018 e:000015 l:y b:0001 r:0x0 METHOD ar_find_entry_hint_bug.rb:15 [FINISH] c:0002 p:0046 s:0011 E:0014e0 l:n b:---- r:0x0 EVAL ar_find_entry_hint_bug.rb:27 [FINISH] c:0001 p:0000 s:0003 E:002480 l:y b:---- r:0x0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- ar_find_entry_hint_bug.rb:27:in '<main>' ar_find_entry_hint_bug.rb:15:in 'eql?' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000000000000004 x1: 0x00000000000011bf x2: 0x000000016b9ed680 x3: 0x0000000000000000 x4: 0x0000000000000001 x5: 0x0000000000000001 x6: 0x0000000104d400a0 x7: 0xfffff0003ffff800 x18: 0x0000000000000000 x19: 0x000000016b9ed6d0 x20: 0x0000000104d41200 x21: 0x0000000000000000 x22: 0x00000000000011bf x23: 0x0000000000000000 x24: 0x0000000000000000 x25: 0x0000000104a96000 x26: 0x0000000000000009 x27: 0x0000000afd00aa00 x28: 0x0000000104a96000 lr: 0x00000001046a21dc fp: 0x000000016b9ed6c0 sp: 0x000000016b9ed680 -- C level backtrace information ------------------------------------------- /Users/benoit.daloze/code/ruby/miniruby(rb_vm_bugreport+0xbfc) [0x1046aec04] /Users/benoit.daloze/code/ruby/vm_dump.c:1473 /Users/benoit.daloze/code/ruby/miniruby(rb_vm_bugreport) (null):0 /Users/benoit.daloze/code/ruby/miniruby(rb_bug_for_fatal_signal+0x10c) [0x1044c7cd4] /Users/benoit.daloze/code/ruby/error.c:1140 /Users/benoit.daloze/code/ruby/miniruby(sigsegv+0x94) [0x1045ff93c] /Users/benoit.daloze/code/ruby/signal.c:948 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x1891a57a4] /Users/benoit.daloze/code/ruby/miniruby(lookup_method_table+0x7c) [0x1046a21dc] ./vm_method.c:1363 /Users/benoit.daloze/code/ruby/miniruby(search_method0) ./vm_method.c:1822 /Users/benoit.daloze/code/ruby/miniruby(search_method+0x14) [0x104685960] ./vm_method.c:1845 /Users/benoit.daloze/code/ruby/miniruby(callable_method_entry_or_negative) ./vm_method.c:2049 /Users/benoit.daloze/code/ruby/miniruby(callable_method_entry+0x10) [0x104677fd0] ./vm_method.c:2078 /Users/benoit.daloze/code/ruby/miniruby(rb_callable_method_entry) ./vm_method.c:2085 /Users/benoit.daloze/code/ruby/miniruby(rb_vm_search_method_slowpath) ./vm_insnhelper.c:2039 /Users/benoit.daloze/code/ruby/miniruby(vm_search_method_slowpath0+0x8) [0x10467e6cc] ./vm_insnhelper.c:2214 /Users/benoit.daloze/code/ruby/miniruby(vm_exec_core) ./vm_insnhelper.c:2277 /Users/benoit.daloze/code/ruby/miniruby(vm_exec_loop+0x0) [0x10467a970] /Users/benoit.daloze/code/ruby/vm.c:2796 /Users/benoit.daloze/code/ruby/miniruby(rb_vm_exec) /Users/benoit.daloze/code/ruby/vm.c:2799 /Users/benoit.daloze/code/ruby/miniruby(rb_funcallv_scope+0x238) [0x10468a0c0] ./vm_eval.c:101 /Users/benoit.daloze/code/ruby/miniruby(rb_funcallv+0x8) [0x10468a4cc] ./vm_eval.c:1084 /Users/benoit.daloze/code/ruby/miniruby(rb_funcall) ./vm_eval.c:1141 /Users/benoit.daloze/code/ruby/miniruby(RB_TEST+0x0) [0x10455f248] /Users/benoit.daloze/code/ruby/object.c:161 /Users/benoit.daloze/code/ruby/miniruby(rb_eql) /Users/benoit.daloze/code/ruby/object.c:163 /Users/benoit.daloze/code/ruby/miniruby(rb_any_cmp+0xd0) [0x1044ff0e0] /Users/benoit.daloze/code/ruby/hash.c:138 /Users/benoit.daloze/code/ruby/miniruby(ar_equal+0xc) [0x104508328] /Users/benoit.daloze/code/ruby/hash.c:603 /Users/benoit.daloze/code/ruby/miniruby(ar_find_entry+0x54) [0x104500af4] /Users/benoit.daloze/code/ruby/hash.c:617 /Users/benoit.daloze/code/ruby/miniruby(ar_lookup) /Users/benoit.daloze/code/ruby/hash.c:1025 /Users/benoit.daloze/code/ruby/miniruby(rb_hash_aref) /Users/benoit.daloze/code/ruby/hash.c:2037 /Users/benoit.daloze/code/ruby/miniruby(vm_exec_core+0x4790) [0x104680c18] ./vm_insnhelper.c:6958 /Users/benoit.daloze/code/ruby/miniruby(vm_exec_loop+0x0) [0x10467a970] /Users/benoit.daloze/code/ruby/vm.c:2796 /Users/benoit.daloze/code/ruby/miniruby(rb_vm_exec) /Users/benoit.daloze/code/ruby/vm.c:2799 /Users/benoit.daloze/code/ruby/miniruby(rb_ec_exec_node+0xb4) [0x1044d317c] /Users/benoit.daloze/code/ruby/eval.c:284 /Users/benoit.daloze/code/ruby/miniruby(ruby_run_node+0x4c) [0x1044d3074] /Users/benoit.daloze/code/ruby/eval.c:322 /Users/benoit.daloze/code/ruby/miniruby(rb_main+0x1c) [0x104410980] ./main.c:42 /Users/benoit.daloze/code/ruby/miniruby(main) ./main.c:62 -- Other runtime information ----------------------------------------------- * Loaded script: ar_find_entry_hint_bug.rb * Ruby Box: disabled * Loaded features: 0 enumerator.so 1 monitor.so 2 thread.rb 3 fiber.so 4 rational.so 5 complex.so 6 pathname.so 7 ruby2_keywords.rb 8 set.rb ``` I can also repro on 3.2.11. Reproducing locally seems harder on 3.3, 3.4 and 4.0 but I believe they are affected too since they use very similar code and miss those checks, so we should backport there as well. Backporting to 3.2 may make sense too since this could be seen as a form of DoS. The repro depends on how the `ar_table` and `st_table` layouts overlap and specific values written & read. --- For completeness, I initially tried another repro, which shows unclear semantics but doesn't crash: ```ruby $break = false class Key def hash = 42 def eql?(o) if $break $break = false H.shift H[Key.new] = 42 until H.size == 8 o.equal?($key1) else equal?(o) end end end $key1 = key1 = Key.new key2 = Key.new key3 = Key.new h = { key1 => 1, key2 => 2 } H = h p h $break = true p h[key3] ``` ``` $ ./miniruby bug.rb {#<Key:0x0000000101041200> => 1, #<Key:0x0000000101041240> => 2} 2 ``` So reading a key considered `eql?` to `key1` returns the value for `key2`, that seems quite surprising. The underlying issue there is `ar_find_entry_hint()` returns an index but doesn't read the value, so the value is read after `eql?`, in which/during which the Hash may have changed. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:125475] [Ruby Feature#22067] New TypedData bit to allow the type to be freed in parallel
by luke-gru (Luke Gruber) 18 Jun '26

18 Jun '26

Issue #22067 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #22067: New TypedData bit to allow the type to be freed in parallel https://bugs.ruby-lang.org/issues/22067 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- CRuby `TypedData` types are used internally in the VM and in C extensions and currently any `free` functions for these types are run with the VM lock held as well as the VM barrier (or, in the case of MMTk, are not freed in parallel). In short, no other Ruby threads or GC threads can run while these `free` functions are called. In order to allow one or more worker GC threads to free these `TypedData` objects, we need a way to specify that a `TypedData` type can be freed in parallel alongside the Ruby GC thread or Ruby code that is being run by another thread. Otherwise, we cannot free these types in the workers and must rely on the Ruby GC thread to do so. This is because it can be unsafe to call these `free` functions, depending on how they're implemented. Most `TypedData` are safe to free in parallel. The exceptions are those `free` functions that read or modify global state without locking. ### Examples ```c static void example_data_free(void *ptr) { st_delete(live_example_datas, (st_data_t*)&ptr, NULL); // Not thread-safe! } ``` If 2 of these `TypedData` objects are freed at the same time, this could corrupt the `st_table`. A lock must be held when manipulating this table. Because Ruby code can also run alongside a sweep worker, the lock must also be held when adding to or iterating this table. ```c rb_nativethread_lock_t example_data_lock; static void example_data_free(void *ptr) { rb_native_mutex_lock(&example_data_lock); st_delete(live_example_datas, (st_data_t*)&ptr, NULL); rb_native_mutex_unlock(&example_data_lock); } static void live_examples_add(void *ptr) { rb_native_mutex_lock(&example_data_lock); st_insert(live_example_datas, (st_data_t)ptr, (st_data_t)ptr); rb_native_mutex_unlock(&example_data_lock); } static void Init_example(void) { rb_native_mutex_initialize(&example_data_lock); } ``` If a CRuby developer or user wants to make their code compaction-safe, they don’t need to worry about parallel sweep workers because the workers don't run during compaction. ### Proposal I propose adding a new flag to `TypedData` that allows both CRuby developers and extension authors to opt-in to allow their `TypedData` type to be freed in parallel. It could be called something like `RUBY_TYPED_PARALLEL_FREE_SAFE`. In our branch where we are developing parallel sweeping, most `TypedData` internal to the VM are given this flag. I believe C extension authors would opt in as well if they see that parallel sweeping gives good performance benefits to Ruby applications. We would need to document what is safe and what is not safe inside these `free` functions for types that are marked with this bit. If the user needs to use a native mutex to protect their `TypedData` from being corrupted when freed in parallel, they must do so. However, if they lock this native mutex in non-free function code paths as well, they may not allocate objects or use `ruby_xmalloc` while this mutex is held. These are some examples of trickiness when it comes to concurrency in the Ruby VM. I believe having a section in the extension documentation about these types of free functions (or elsewhere such as the Concurrency Guide) would give CRuby developers and extension authors more confidence in adding this bit to their types. ### A possible future: parallel marking? If in the future CRuby gets parallel marking, we believe we probably would need another bit for `TypedData` so we can register them as parallel-mark safe. If that’s the case, it’s unfortunate that authors that want this feature would need to update their extension again with a new bit if this bit were to be made public. One could argue that we should have a single bit that indicates safety for both parallel freeing and parallel marking. However, we believe the specifics of what could and couldn’t be executed inside these `free` and `mark` functions would be too hard to work out today for a combined bit without locking us into a specific parallel marking implementation. ### Alternative We could not expose the parallel-free-safe bit to extension authors and only free internal `TypedData` objects in parallel. However, this does slow the current implementation of parallel sweeping down because even if one of these objects is on a heap page, the Ruby GC thread needs to further post-process the page after the sweep thread sweeps it. It would also limit further optimizations to parallel sweeping. ### Details of the bit Worker threads could only free `TypedData` objects that have this new bit set alongside the `RUBY_TYPED_FREE_IMMEDIATELY` bit. Otherwise, the Ruby GC thread must free them. Also, if the type has `0` or `RUBY_TYPED_DEFAULT_FREE`/`RUBY_DEFAULT_FREE` as the free function, it can be freed in parallel. ### Conclusion Parallel sweeping is being actively developed and adding this bit increases performance of the developing implementation of parallel sweeping. It allows `TypedData` types to be freed by worker thread(s), which decreases GC pause times. Since `TypedData` are also exposed to extension authors, we need to whitelist these types for parallel freeing, as not all of these functions are currently safe. By documenting what is and isn’t safe, extension authors can write correct `free` functions that are safe to be freed by worker threads. Alternatively, we could have this bit be internal to CRuby. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:125770] [Ruby Bug#22116] Segfault with YJIT when `define_method` + `super()` calls a method that creates a `Hash.new { ... }`
by mame (Yusuke Endoh) 17 Jun '26

17 Jun '26

Issue #22116 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22116: Segfault with YJIT when `define_method` + `super()` calls a method that creates a `Hash.new { ... }` https://bugs.ruby-lang.org/issues/22116 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: alanwu (Alan Wu) * Target version: 4.1 * ruby -v: ruby 4.1.0dev (2026-06-15T10:28:20Z master c2879d4eb1) +YJIT +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- With the latest Ruby master, enabling YJIT causes a SEGV with the following code: ```ruby class C def foo Hash.new {|h, k| h[k] = [] } end end class D < C define_method(:foo) do super() end end 1000.times { D.new.foo } ``` ``` $ ruby --yjit test.rb <internal:hash>:38: [BUG] Segmentation fault at 0x0000000000000001 ruby 4.1.0dev (2026-06-15T10:28:20Z master c2879d4eb1) +YJIT +PRISM [x86_64-linux] ``` According to git bisect: * commit:d256629bf9e194838d1837be74dcc0b8ff0bcfd6 with YJIT doesn't crash, * commit:ea7d3eb89b8c5192c0cf9a885a17b0aeaef1067a without YJIT doesn't, and * commit:ea7d3eb89b8c5192c0cf9a885a17b0aeaef1067a with YJIT does So I suspect commit:ea7d3eb89b8c5192c0cf9a885a17b0aeaef1067a is the culprit. @alanwu Could you take a look? Here is the full trace: ``` $ ruby --yjit test.rb <internal:hash>:38: [BUG] Segmentation fault at 0x0000000000000001 ruby 4.1.0dev (2026-06-15T10:28:20Z master c2879d4eb1) +YJIT +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0008 p:0016 s:0038 e:000034 l:y b:0001 r:0x743253071000 METHOD <internal:hash>:38 [FINISH] c:0007 p:---- s:0026 e:000025 l:y b:0001 r:(nil) CFUNC :new c:0006 p:0005 s:0022 e:000021 l:y b:0001 r:0x743253071234 METHOD test.rb:3 c:0005 p:0004 s:0018 e:000017 l:n b:---- r:0x7432530711a9 BLOCK test.rb:9 c:0004 p:0017 s:0014 e:000013 l:n b:---- r:0x743253071000 BLOCK test.rb:13 c:0003 p:0024 s:0011 e:000010 l:y b:0001 r:(nil) METHOD <internal:numeric>:262 c:0002 p:0022 s:0006 e:000005 l:n b:---- r:(nil) EVAL test.rb:13 [FINISH] c:0001 p:0000 s:0003 E:0005a0 l:y b:---- r:(nil) DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:13:in '<main>' <internal:numeric>:262:in 'times' test.rb:13:in 'block in <main>' test.rb:9:in 'block in <class:D>' test.rb:3:in 'foo' test.rb:3:in 'new' <internal:hash>:38:in 'initialize' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x0000743276f981dc RBP: 0x0000000000000000 RSP: 0x00007ffd90e92b50 RAX: 0x0000000000000001 RBX: 0x0000000000000000 RCX: 0x0000000000000000 RDX: 0x00007432762b3500 RDI: 0x00005c69e4f08628 RSI: 0x00007432774ae380 R8: 0x0000000000000014 R9: 0x0000000000000014 R10: 0x0000000000000014 R11: 0x0000000000000000 R12: 0x00007432762b3500 R13: 0x00007432774ae380 R14: 0x00007432762ff0c8 R15: 0x00007432763fef68 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(rb_print_backtrace+0x11) [0x743276fcaee0] /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm_dump.c:1111 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(rb_vm_bugreport) /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm_dump.c:1473 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(rb_bug_for_fatal_signal+0x109) [0x743276d65799] /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/error.c:1140 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(sigsegv+0x48) [0x743276eef1c8] /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/signal.c:948 /lib/x86_64-linux-gnu/libc.so.6(0x743276845f60) [0x743276845f60] /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(rb_vm_make_proc_lambda+0x2c) [0x743276f981dc] internal/imemo.h:168 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(VM_FRAME_CFRAME_P+0x0) [0x743276f9867c] /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm_core.h:1979 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(VM_FRAME_RUBYFRAME_P) /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm_core.h:1557 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(vm_block_handler_escape) /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm.c:1109 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(vm_make_env_each) /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm.c:1103 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(vm_make_env_object+0x5) [0x743276f9892d] /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm.c:1180 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(rb_vm_make_proc_lambda) /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm.c:1621 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(rb_vm_make_proc) /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm_core.h:1979 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(rb_vm_bh_to_procval) /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm_insnhelper.c:552 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1(rb_vm_bh_to_procval) /tmp/ruby-build.20260615205957.112028.2eogNm/ruby-master/vm_insnhelper.c:543 [0x74325306f444] -- Other runtime information ----------------------------------------------- * Loaded script: test.rb * Ruby Box: disabled * Loaded features: 0 enumerator.so 1 monitor.so 2 thread.rb 3 fiber.so 4 rational.so 5 complex.so 6 pathname.so 7 ruby2_keywords.rb 8 set.rb 9 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/encdb.so 10 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/trans/transdb.so 11 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/rbconfig.rb 12 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/defaults.rb 13 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/deprecate.rb 14 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/errors.rb 15 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/target_rbconfig.rb 16 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/win_platform.rb 17 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/util/atomic_file_writer.rb 18 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/unknown_command_spell_checker.rb 19 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/exceptions.rb 20 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/basic_specification.rb 21 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/stub_specification.rb 22 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/platform.rb 23 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/specification_record.rb 24 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/version.rb 25 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/requirement.rb 26 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/specification.rb 27 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/util.rb 28 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/dependency.rb 29 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/core_ext/kernel_gem.rb 30 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/monitor.rb 31 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems.rb 32 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/bundled_gems.rb 33 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/rubygems/path_support.rb 34 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/error_highlight/version.rb 35 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/error_highlight/base.rb 36 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/error_highlight/formatter.rb 37 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/error_highlight/core_ext.rb 38 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/error_highlight.rb 39 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/version.rb 40 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/core_ext/name_error.rb 41 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/levenshtein.rb 42 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/jaro_winkler.rb 43 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/spell_checker.rb 44 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb 45 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb 46 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/spell_checkers/name_error_checkers.rb 47 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/spell_checkers/method_name_checker.rb 48 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/spell_checkers/key_error_checker.rb 49 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/spell_checkers/null_checker.rb 50 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/tree_spell_checker.rb 51 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/spell_checkers/require_path_checker.rb 52 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/spell_checkers/pattern_key_name_checker.rb 53 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean/formatter.rb 54 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/did_you_mean.rb 55 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/syntax_suggest/core_ext.rb * Process memory map: 5c69c4431000-5c69c4432000 r--p 00000000 103:02 80372576 /home/mame/.local/share/mise/installs/ruby/ruby-dev/bin/ruby 5c69c4432000-5c69c4433000 r-xp 00001000 103:02 80372576 /home/mame/.local/share/mise/installs/ruby/ruby-dev/bin/ruby 5c69c4433000-5c69c4434000 r--p 00002000 103:02 80372576 /home/mame/.local/share/mise/installs/ruby/ruby-dev/bin/ruby 5c69c4434000-5c69c4435000 r--p 00002000 103:02 80372576 /home/mame/.local/share/mise/installs/ruby/ruby-dev/bin/ruby 5c69c4435000-5c69c4436000 rw-p 00003000 103:02 80372576 /home/mame/.local/share/mise/installs/ruby/ruby-dev/bin/ruby 5c69e4f02000-5c69e541e000 rw-p 00000000 00:00 0 [heap] 74324ec00000-74324ee38000 r--s 00000000 103:02 48134286 /usr/lib/x86_64-linux-gnu/libc.so.6 74324ef56000-743251400000 rw-p 00000000 00:00 0 743251400000-743252ece000 r--s 00000000 103:02 80372578 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1.0 74325306f000-743253072000 r-xp 00000000 00:00 0 [anon:Ruby:rb_jit_reserve_addr_space] 743253072000-74325b06f000 ---p 00000000 00:00 0 [anon:Ruby:rb_jit_reserve_addr_space] 74325b216000-74325b3b2000 rw-p 00000000 00:00 0 74325b3b2000-74325b3f0000 r--s 00000000 103:02 80372576 /home/mame/.local/share/mise/installs/ruby/ruby-dev/bin/ruby 74325b3f0000-74325b510000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 74325b520000-74325b590000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 74325b5a0000-74325b5b0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 74325b5bf000-74325b5c0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b5c0000-74325b661000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b661000-74325b662000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b662000-74325b703000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b703000-74325b704000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b704000-74325b7a5000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b7a5000-74325b7a6000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b7a6000-74325b847000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b847000-74325b848000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b848000-74325b8e9000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b8e9000-74325b8ea000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b8ea000-74325b98b000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b98b000-74325b98c000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325b98c000-74325ba2d000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325ba2d000-74325ba2e000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325ba2e000-74325bacf000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bacf000-74325bad0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bad0000-74325bb71000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bb71000-74325bb72000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bb72000-74325bc13000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bc13000-74325bc14000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bc14000-74325bcb5000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bcb5000-74325bcb6000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bcb6000-74325bd57000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bd57000-74325bd58000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bd58000-74325bdf9000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bdf9000-74325bdfa000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bdfa000-74325be9b000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325be9b000-74325be9c000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325be9c000-74325bf3d000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bf3d000-74325bf3e000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bf3e000-74325bfdf000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bfdf000-74325bfe0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325bfe0000-74325c081000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c081000-74325c082000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c082000-74325c123000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c123000-74325c124000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c124000-74325c1c5000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c1c5000-74325c1c6000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c1c6000-74325c267000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c267000-74325c268000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c268000-74325c309000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c309000-74325c30a000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c30a000-74325c3ab000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c3ab000-74325c3ac000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c3ac000-74325c44d000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c44d000-74325c44e000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c44e000-74325c4ef000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c4ef000-74325c4f0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c4f0000-74325c591000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c591000-74325c592000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c592000-74325c633000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c633000-74325c634000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c634000-74325c6d5000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c6d5000-74325c6d6000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c6d6000-74325c777000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c777000-74325c778000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c778000-74325c819000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c819000-74325c81a000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c81a000-74325c8bb000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c8bb000-74325c8bc000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c8bc000-74325c95d000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c95d000-74325c95e000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c95e000-74325c9ff000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 74325c9ff000-74325d200000 rw-p 00000000 00:00 0 74325d200000-743275200000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_cache] 743275200000-743276200000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_list] 743276210000-7432762f0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 7432762ff000-743276400000 rw-p 00000000 00:00 0 743276400000-7432767f6000 r--p 00000000 103:02 48104134 /usr/lib/locale/locale-archive 743276800000-743276828000 r--p 00000000 103:02 48134286 /usr/lib/x86_64-linux-gnu/libc.so.6 743276828000-7432769c1000 r-xp 00028000 103:02 48134286 /usr/lib/x86_64-linux-gnu/libc.so.6 7432769c1000-743276a30000 r--p 001c1000 103:02 48134286 /usr/lib/x86_64-linux-gnu/libc.so.6 743276a30000-743276a34000 r--p 0022f000 103:02 48134286 /usr/lib/x86_64-linux-gnu/libc.so.6 743276a34000-743276a36000 rw-p 00233000 103:02 48134286 /usr/lib/x86_64-linux-gnu/libc.so.6 743276a36000-743276a43000 rw-p 00000000 00:00 0 743276a60000-743276aa0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 743276aa5000-743276ac6000 rw-p 00000000 00:00 0 743276ac6000-743276aca000 r--p 00000000 103:02 48107690 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 743276aca000-743276aed000 r-xp 00004000 103:02 48107690 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 743276aed000-743276af1000 r--p 00027000 103:02 48107690 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 743276af1000-743276af2000 r--p 0002a000 103:02 48107690 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 743276af2000-743276af3000 rw-p 0002b000 103:02 48107690 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 743276af3000-743276b04000 r--p 00000000 103:02 48134302 /usr/lib/x86_64-linux-gnu/libm.so.6 743276b04000-743276b8f000 r-xp 00011000 103:02 48134302 /usr/lib/x86_64-linux-gnu/libm.so.6 743276b8f000-743276bfe000 r--p 0009c000 103:02 48134302 /usr/lib/x86_64-linux-gnu/libm.so.6 743276bfe000-743276bff000 r--p 0010a000 103:02 48134302 /usr/lib/x86_64-linux-gnu/libm.so.6 743276bff000-743276c00000 rw-p 0010b000 103:02 48134302 /usr/lib/x86_64-linux-gnu/libm.so.6 743276c00000-743276c60000 r--p 00000000 103:02 80372578 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1.0 743276c60000-74327728f000 r-xp 00060000 103:02 80372578 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1.0 74327728f000-743277477000 r--p 0068f000 103:02 80372578 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1.0 743277477000-74327749f000 r--p 00877000 103:02 80372578 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1.0 74327749f000-7432774a6000 rw-p 0089f000 103:02 80372578 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/libruby.so.4.1.0 7432774a6000-7432774bd000 rw-p 00000000 00:00 0 7432774c9000-7432774cd000 rw-p 00000000 00:00 0 7432774cd000-7432774cf000 r--p 00000000 103:02 48105802 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7432774cf000-7432774e4000 r-xp 00002000 103:02 48105802 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7432774e4000-7432774fd000 r--p 00017000 103:02 48105802 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7432774fd000-7432774fe000 r--p 0002f000 103:02 48105802 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7432774fe000-7432774ff000 rw-p 00030000 103:02 48105802 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7432774ff000-743277507000 rw-p 00000000 00:00 0 743277507000-743277511000 r--p 00000000 103:02 48112326 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 743277511000-743277576000 r-xp 0000a000 103:02 48112326 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 743277576000-74327758b000 r--p 0006f000 103:02 48112326 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 74327758b000-74327758c000 r--p 00083000 103:02 48112326 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 74327758c000-74327758d000 rw-p 00084000 103:02 48112326 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 74327758d000-743277590000 r--p 00000000 103:02 48103922 /usr/lib/x86_64-linux-gnu/libz.so.1.3.1 743277590000-7432775a3000 r-xp 00003000 103:02 48103922 /usr/lib/x86_64-linux-gnu/libz.so.1.3.1 7432775a3000-7432775ab000 r--p 00016000 103:02 48103922 /usr/lib/x86_64-linux-gnu/libz.so.1.3.1 7432775ab000-7432775ac000 r--p 0001d000 103:02 48103922 /usr/lib/x86_64-linux-gnu/libz.so.1.3.1 7432775ac000-7432775ad000 rw-p 0001e000 103:02 48103922 /usr/lib/x86_64-linux-gnu/libz.so.1.3.1 7432775b0000-7432775c0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 7432775c1000-7432775c2000 r--p 00000000 103:02 80376884 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/trans/transdb.so 7432775c2000-7432775c4000 r-xp 00001000 103:02 80376884 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/trans/transdb.so 7432775c4000-7432775c5000 r--p 00003000 103:02 80376884 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/trans/transdb.so 7432775c5000-7432775c6000 r--p 00003000 103:02 80376884 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/trans/transdb.so 7432775c6000-7432775c7000 rw-p 00004000 103:02 80376884 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/trans/transdb.so 7432775c7000-7432775c8000 r--p 00000000 103:02 80374180 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/encdb.so 7432775c8000-7432775c9000 r-xp 00001000 103:02 80374180 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/encdb.so 7432775c9000-7432775ca000 r--p 00002000 103:02 80374180 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/encdb.so 7432775ca000-7432775cb000 r--p 00002000 103:02 80374180 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/encdb.so 7432775cb000-7432775cc000 rw-p 00003000 103:02 80374180 /home/mame/.local/share/mise/installs/ruby/ruby-dev/lib/ruby/4.1.0+3/x86_64-linux/enc/encdb.so 7432775cc000-7432775cd000 rw-p 00000000 00:00 0 7432775cd000-7432775ce000 rw-p 00000000 00:00 0 7432775ce000-7432775d0000 rw-p 00000000 00:00 0 7432775d0000-7432775d4000 r--p 00000000 00:00 0 [vvar] 7432775d4000-7432775d6000 r--p 00000000 00:00 0 [vvar_vclock] 7432775d6000-7432775d8000 r-xp 00000000 00:00 0 [vdso] 7432775d8000-7432775d9000 r--p 00000000 103:02 48134270 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7432775d9000-743277607000 r-xp 00001000 103:02 48134270 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 743277607000-743277615000 r--p 0002f000 103:02 48134270 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 743277615000-743277617000 r--p 0003d000 103:02 48134270 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 743277617000-743277618000 rw-p 0003f000 103:02 48134270 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 743277618000-743277619000 rw-p 00000000 00:00 0 7ffd90e74000-7ffd90e95000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Segmentation fault ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124288] [Ruby Bug#21790] `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts
by adamoffat (Adam Moffat) 17 Jun '26

17 Jun '26

Issue #21790 has been reported by adamoffat (Adam Moffat). ---------------------------------------- Bug #21790: `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts https://bugs.ruby-lang.org/issues/21790 * Author: adamoffat (Adam Moffat) * Status: Open * ruby -v: 3.3.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby's `Socket.getaddrinfo` hangs indefinitely in forked child processes on macOS 26.1 (Tahoe) when resolving IPv4-only hostnames. This is a regression that does not occur on macOS 15.x (Sonoma) or earlier. **Ruby version:** ruby 3.3.8 (2025-04-09 revision b200bad6cd) [arm64-darwin24] Also confirmed this affects Ruby 3.2.6 and 3.4.1. **Reproducible script:** ``` ruby require "socket" require "timeout" puts "Ruby #{RUBY_VERSION} on #{RUBY_PLATFORM}" Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) puts "Parent: DNS completed" pid = fork do puts "Child: Attempting DNS resolution..." begin Timeout.timeout(90) do Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) end puts "Child: SUCCESS" exit 0 rescue Timeout::Error puts "Child: FAILED - hung for 90 seconds" exit 1 end end Process.wait(pid) ``` **Note:** Remove the `Timeout.timeout(90)` wrapper to observe the hang indefinitely. The timeout is included only to allow the script to exit for testing purposes. **Result of reproduce process:** ``` Ruby 3.3.8 on arm64-darwin24 Parent: DNS completed Child: Attempting DNS resolution... Child: FAILED - hung for 90 seconds ``` The child process hangs with one thread consuming 100% CPU. Expected result: The child process should complete DNS resolution successfully, as it does on macOS 15.x and earlier. **Analysis:** Stack trace shows: Main thread: Blocked in `wait_getaddrinfo` → `_pthread_cond_wait` DNS thread: Spinning in `_gai_nat64_second_pass` → `nw_path_access_agent_cache` → `_os_log_preferences_refresh` → `SIGSEGV` The crash occurs in macOS's NAT64 synthesis code path. Ruby's signal handler catches the `SIGSEGV` but cannot recover, causing the DNS thread to spin. **Key observations:** - Only affects IPv4-only hosts. Hosts with IPv6 (like google.com) work correctly. - Using `AF_INET` instead of `AF_UNSPEC` works. `Socket.getaddrinfo("api.segment.io", 443, Socket::AF_INET, :STREAM)` succeeds. - Python is not affected. Python calls `getaddrinfo()` synchronously without a background thread. - Parent must do DNS before fork. If the parent has not called getaddrinfo(), the child works correctly. **Workaround:** - Use `resolv-replace` to bypass the native DNS resolver: `require "resolv-replace"` **Impact:** This breaks all Ruby applications using pre-forking worker models (Resque, Unicorn, Puma, Sidekiq, Passenger) on macOS Tahoe. **Apple Bug Report:** Filed with Apple as Feedback Assistant #FB21364061 ---Files-------------------------------- stack_trace.txt (66.6 KB) ruby_dns_fork_bug.rb (1.02 KB) -- https://bugs.ruby-lang.org/

2 9

[ruby-core:125782] [Ruby Feature#22119] Thread: inherit storage on child threads
by chucke (Tiago Cardoso) 17 Jun '26

17 Jun '26

Issue #22119 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Feature #22119: Thread: inherit storage on child threads https://bugs.ruby-lang.org/issues/22119 * Author: chucke (Tiago Cardoso) * Status: Open ---------------------------------------- ## Motivation At work, we've been dealing with the need of propagating context across threads. The use cases are several, ranging from propagating logging / observability context, region / database shards, etc, on worker threads for specific workloads which require that implicit knowledge. We've historically used thread variables for it, via the `Thread#thread_variable_get/set` family of functions, and have been enforcing / gating usage of threads via a wrapper function which does the context propagation heavy-lifting. Something like: ``` ruby def new_thread do logging_context = Logging.current_context.deep_dup database_context = DB.current_context.deep_dup # etc, etc Thread.new do Logging.set_context(logging_context) DB.set_context/database_context) yield end end ``` alongside a plethora of checks and rubocops for forbid direct usage of `Thread.new`. However, we recently found out that that's not enough, since 3rd party libraries that we use will make their own use of `Thread.new` without our custom context propagation, which broke our logic in cases where we'd require p.ex. correcy database context. In order to fix that, we've resorted to monkeypatching `Thread.new` (and `Fiber.new`), which feels necessary for this use case, but not right. This seems like a feature missing from ruby. ## Research `ruby` does have prior art for "inheritable" storage: `Fiber#storage`; when a new fiber is created, by default, it'll have the same storage from the fiber it was created from (unless `Fiber.new(storage: nil)`). This is exactly what's missing here. Another example, with a little more ceremony, of the same problem solved in ruby is concurrent-ruby's [ThreadLocalVar](https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/ThreadLocalVar.html), which seems to be inspired in Java's own [InheritableThreadLocal](https://docs.oracle.com/en/java/javase/11/docs/api/…. ## Proposal `ruby` should have an OTTB solution for inheritable thread storage. Some options to consider: ### 1: :storage kwarg An option would be to align with `Fiber.new` and support a `storage` kwarg: ``` ruby Thread.current.thread_variable_set(:foo, "bar") Thread.new(storage: nil) do # this has to be default Thread.current.thread_variable_get(:foo) #=> nil end Thread.new(storage: Thread.current.storage) do # would be a new method Thread.current.thread_variable_get(:foo) #=> nil end ``` as mentioned above, for backwards compatibility reasons, by default storage wouldn't be inherited, which wouldn't fit our use-case that well, unless the default could be changed viat env var, i.e. `RUBY_THREAD_STORAGE=inherit` or something of the kind (which ruby historically hasn't supported). ### 2. Thread::Variable A new primitive, `Thread::Variable`, could be integrated, that would have the same semantics as concurrent-ruby's `ThreadLocalVar`: ``` ruby VAL = Thread::Variable.new(2) Thread.new do puts VAL.value #=> 2 VAL.value = 3 puts VAL.value #=> 3 end.join puts VAL.value #=> 2 ``` I feel like 1. is more aligned with how ruby has dealt with the problem space, but the backwards compatibility issues may be a problem, so 2 is probably more feasible, despite its Java'iness. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:112045] [Ruby master Bug#19378] Windows: Use less syscalls for faster require of big gems
by aidog (Andi Idogawa) 16 Jun '26

16 Jun '26

Issue #19378 has been reported by aidog (Andi Idogawa). ---------------------------------------- Bug #19378: Windows: Use less syscalls for faster require of big gems https://bugs.ruby-lang.org/issues/19378 * Author: aidog (Andi Idogawa) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello 🙂 ## Problem require is slow on windows for big gems. (example: require 'gtk3'=> 3 seconds+). This is a problem for people who want to make cross platform GUI apps with ruby. ## Possible Reason As touched on in [#15797](https://bugs.ruby-lang.org/issues/15797) it seems like require uses realpath, which is emulated on windows. It checks every parent directory. The same syscalls run many times. ## Testfile C:\tmp\speedtest\testrequire.rb: ``` ruby require __dir__ + "/helloworld1.rb" require __dir__ + "/helloworld2.rb" ``` ``` shell ruby --disable-gems C:\tmp\speedtest\testrequire.rb ``` ### Syscalls per File/Directory: 1. CreateFile 2. QueryInformationVolume 3. QueryIdInformation 4. QueryAllInformationFile 5. QueryNameInformationFile 6. QueryNameInformationFile 7. QueryNormalizedNameInformationFile 8. CloseFile ### Files/Directories checked 1. C:\tmp 2. C:\tmp\speedtest 3. C:\tmp\speedtest\helloworld1.rb 4. C:\tmp 5. C:\tmp\speedtest 6. C:\tmp\speedtest\helloworld2.rb For two required files Ruby had to do 8*6 = **48** syscalls. The syscalls orginate from rb_w32_reparse_symlink_p / lstat Rubygems live in subfolders with 9+ parts: "C:\Ruby32-x64\lib\ruby\gems\3.2.0\gems\glib2-4.0.8\lib\glib2\variant.rb" Each file takes 8 * 9 = **72**+ calls. For variant.rb it is **80** calls. The result for the syscalls don't change in such a short time, so it should be possible to cache it. With require_relative it's twice as many calls. ## Other testcases Same result: ``` ruby File.realpath __dir__ + "/helloworld1.rb" File.realpath __dir__ + "/helloworld2.rb" ``` ``` ruby File.stat __dir__ + "/helloworld1.rb" File.stat __dir__ + "/helloworld2.rb" ``` It does not happen in $LOAD_PATH.resolve_feature_path(__dir__ + "/helloworld1.rb") ## Request Would it be possible to cache the stat calls when using require? I tried to implement a cache inside the ruby source code, but failed. If not, is there now a way to combine ruby files into one? I previously talked about require here: [YJIT: Windows support lacking.](https://bugs.ruby-lang.org/issues/19325#note-11) ## How to reproduce Ruby versions: At least 3.0+, most likely older ones too. Tested using Ruby Installer 3.1 and 3.2. [Procmon Software by Sysinternals](https://learn.microsoft.com/en-us/sysinternals/downloads/proc… -- https://bugs.ruby-lang.org/

6 8

[ruby-core:125781] [ANN] Dev.us.kg - A new forum for Ruby core and contributor discussions
by amine kheddache 16 Jun '26

16 Jun '26

Hello Ruby core team, I'm excited to announce the launch of **Dev.us.kg**, a new, free community forum for Ruby developers of all skill levels, including those interested in Ruby's core development and ecosystem. 🔗 Forum: https://dev.us.kg **What you can do on the forum:** - Discuss Ruby internals and implementation topics - Share and review Ruby patches or experimental features - Get help with Ruby development questions - Connect with other Ruby contributors The forum is completely free, has no tracking, and is open to everyone. It's a space to learn, share, and build together. Join us and help build a welcoming Ruby community: 👉 https://dev.us.kg Best regards, AmineKHD

1 0

[ruby-core:125643] [Ruby Bug#22095] Prism rejects a multiple assignment in a rescue modifier value that parse.y accepts
by Kai (kai matsudate) 16 Jun '26

16 Jun '26

Issue #22095 has been reported by Kai (kai matsudate). ---------------------------------------- Bug #22095: Prism rejects a multiple assignment in a rescue modifier value that parse.y accepts https://bugs.ruby-lang.org/issues/22095 * Author: Kai (kai matsudate) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Problem parse.y and Prism parse the following differently: ```ruby a rescue b, c = 1 ``` parse.y accepts it, but Prism rejects it. ## Cause In the grammar, the value of a rescue modifier is a statement, so it may itself be a multiple assignment. In Prism, multiple-assignment detection is only enabled at the statement level (`PM_BINDING_POWER_STATEMENT`). But Prism parses the rescue value with the rescue modifier's right binding power (`PM_BINDING_POWER_COMPOSITION`), so it does not recognize the multiple assignment and fails at the comma. I opened a draft PR with a proposed fix: https://github.com/ruby/prism/pull/4128 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125779] [Ruby Feature#5617] Allow install RubyGems into dediceted directory
by hsbt (Hiroshi SHIBATA) 16 Jun '26

16 Jun '26

Issue #5617 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Rejected Closing as rejected for the same reason as #19972. I'd rather keep relying on the default/bundled gems extraction than add and maintain a separate RubyGems install directory. ---------------------------------------- Feature #5617: Allow install RubyGems into dediceted directory https://bugs.ruby-lang.org/issues/5617#change-117692 * Author: vo.x (Vit Ondruch) * Status: Rejected * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Hello, I would like to propose my patch, which allows to optionally install RubyGems library into dedicated directory, out of the default Ruby directory structure. This should enable to easily share one RubyGems library by more Ruby implementations and avoids code duplication. I did this patch since Fedora prohibits duplication of system libraries [1], which would be the case if MRI and JRuby are installed in parallel. Thank you for considering this patch. Vit [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_l… ---Files-------------------------------- 0001-Allow-to-install-RubyGems-into-custom-location-outsi.patch (3.3 KB) 0002-Avoid-duplication-of-datadir.rb-which-belongs-to-Rub.patch (878 Bytes) 0003-Removed-superfluous-bracket.patch (846 Bytes) Allow-to-install-RubyGems-into-custom-location-outsi.patch (3.31 KB) custom_rubygems_location.patch (3.01 KB) 20120606-Allow-to-install-RubyGems-into-custom-location-outsi.patch (3.32 KB) -- https://bugs.ruby-lang.org/

1 0