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

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

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

[ruby-core:115165] [Ruby master Bug#19972] Install default/bundled gems into dedicated directories
by vo.x (Vit Ondruch) 16 Jun '26

16 Jun '26

Issue #19972 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19972: Install default/bundled gems into dedicated directories https://bugs.ruby-lang.org/issues/19972 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-24 master c44d65427e) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I think that the current situation, where the same directory (lets call it `Gem.default_dir`) is used for default/bundled gems as well as for user installed gems, is suboptimal. During the times, this has caused us quite some issue on Fedora. Historically, we redefined the `Gem.default_dir` to user home directory, to avoid the mixing of system gems and user installed gems. Unfortunately, with advent of default/bundled gems, we were facing issues that these gems were suddenly not listed, etc. I am realizing this issue in full once again since the "user install" RubyGems feature has landed [1]. I also think that we have arrived to this situation by evolution, not by design. Therefore my proposal is: Keep the `Gem.default_dir` for user `gem install`ed gems and lets install default and bundled gems into separate dedicated directories. Have separate `Gem.bundled_gems_dir` and `Gem.default_gems_dir` structures. Of course, if `Gem.default_dir == Gem.bundled_gems_dir == Gem.default_gems_dir`, we still can have the current layout. I have a simple POC here: https://github.com/ruby/ruby/pull/8761 BTW I have reported it here, because I think that RubyGems provides all it is needed. So it is not RubyGems ticket after all. However, I believe that RubyGems could benefit from this long term and some simplifications/cleanups would be possible. [1]: https://github.com/rubygems/rubygems/pull/5327 -- https://bugs.ruby-lang.org/

6 11

[ruby-core:125776] [Ruby Misc#17137] Cooperation on maintaining official docker ruby images
by hsbt (Hiroshi SHIBATA) 15 Jun '26

15 Jun '26

Issue #17137 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Rejected https://github.com/ruby/docker-images/ and the official Docker library images now follow different maintenance policies, and I have no plan to unify them. ---------------------------------------- Misc #17137: Cooperation on maintaining official docker ruby images https://bugs.ruby-lang.org/issues/17137#change-117688 * Author: deivid (David Rodríguez) * Status: Rejected * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- It was pointed out to me at https://github.com/docker-library/ruby/issues/323 that the ruby-core team has started maintaining their own docker images at https://github.com/ruby/ruby-docker-images, and that the base Dockerfiles were initially started from the official docker images. The maintainers of the official images would be interesting in collaborating on maintaining these images. Maybe merging the projects would be a nice idea from an end user point of view. I'm guessing there's a reason why https://github.com/ruby/ruby-docker-images was started as a separate project, but maybe any improvements over the official project could be merged back. The obvious new feature that I see in the README is the ability to build development images of specific revisions. Anyways, I mentioned the approach of the docker folks to hsbt and he told me to open a ticket here. So here it is! Regards! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125653] [Ruby Bug#22098] Reconsider whether THREAD_EVENT_RESUMED runs with GVL held
by luke-gru (Luke Gruber) 15 Jun '26

15 Jun '26

Issue #22098 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #22098: Reconsider whether THREAD_EVENT_RESUMED runs with GVL held https://bugs.ruby-lang.org/issues/22098 * Author: luke-gru (Luke Gruber) * Status: Open * Assignee: luke-gru (Luke Gruber) * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Today, it's possible to get a deadlock when allocating during a hook for this event. I attached a reproduction script using the `gvltools` gem. One way to fix it would be to not allocate during this hook and change the documentation to be clear that the GVL is not held. Any gems relying on this behavior, like `gvltools`, would need to be patched. Another way to approach it would be to change the call site for this hook invocation. I believe it would need to be added to quite a few places. To maintain Ractor safety, it would also need to be invoked without any locks held. I'm curious about your thoughts @byroot. ---Files-------------------------------- repro.rb (3.11 KB) run_loop.sh (2.82 KB) -- https://bugs.ruby-lang.org/

4 15