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

[ruby-core:126350] [Ruby Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread
by wanabe (_ wanabe) 09 Aug '26

09 Aug '26

Issue #15499 has been updated by wanabe (_ wanabe). It looks like it might be fixed with 1d4822a175a0dfccca8f252b0e757a1991bd54f9, but I'm not sure. ``` $ git checkout 1d4822a175a0dfccca8f252b0e757a1991bd54f9~; if make -j miniruby >/dev/null 2>&1; then ./miniruby -e 'Thread.new { Ractor.receive }; Ractor.receive' & CH=$! && sleep 1 && kill -INT $CH && sleep 1 && ps aux|grep "^[^ ]* *$CH" && kill -KILL $CH; fi HEAD is now at 2fee379f8f0 Checkout .github on omnibus result for notifications [1] 797951 wanabe 797951 0.0 0.0 526288 9920 pts/7 Sl 20:38 0:00 ./miniruby -e Thread.new{ Ractor.receive }; Ractor.receive [1]+ Killed ./miniruby -e 'Thread.new{ Ractor.receive }; Ractor.receive' $ git checkout 1d4822a175a0dfccca8f252b0e757a1991bd54f9; if make -j miniruby >/dev/null 2>&1; then ./miniruby -e 'Thread.new{ Ractor.receive }; Ractor.receive' & CH=$! && sleep 1 && kill -INT $CH && sleep 1 && ps aux|grep "^[^ ]* *$CH" && kill -KILL $CH; fi Previous HEAD position was 2fee379f8f0 Checkout .github on omnibus result for notifications HEAD is now at 1d4822a175a Get ractor message passing working with > 1 thread sending/receiving values in same ractor [1] 798878 <internal:ractor>:431:in 'Ractor.receive': Interrupt from -e:1:in '<main>' [1]+ Interrupt ./miniruby -e 'Thread.new{ Ractor.receive }; Ractor.receive' ``` ---------------------------------------- Bug #15499: Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread https://bugs.ruby-lang.org/issues/15499#change-118474 * Author: apolcyn (alex polcyn) * Status: Assigned * Assignee: ko1 (Koichi Sasada) * ruby -v: master * Backport: 2.4: DONTNEED, 2.5: DONTNEED, 2.6: DONE ---------------------------------------- This issue was noticed when trying to add ruby 2.6 support to the "grpc" ruby gem (this gem is a native C-extension), and was caught by a unit test. There are several APIs on the grpc ruby gem (https://github.com/grpc/grpc/tree/master/src/ruby) that invoke "rb_thread_call_without_gvl" on the current thread, doing a blocking operation in the "without gvl" callback and cancel that blocking operation in the "unblocking function". These APIs work in ruby versions prior to ruby 2.6 (e.g. ruby 2.5), but have problems when used on ruby 2.6 Minimal repro: My system: ``` > lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.6 (stretch) Release: 9.6 Codename: stretch > ruby -v ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux # I installed ruby 2.6.0 with rvm - https://rvm.io/rvm/install > GRPC_CONFIG=dbg gem install grpc --platform ruby # build grpc gem from source with debug symbols ``` ruby script, "repro.rb" that looks like this: ```ruby require 'grpc' ch = GRPC::Core::Channel.new('localhost:1234', {}, :this_channel_is_insecure) ch.watch_connectivity_state(ch.connectivity_state, Time.now + 360) ``` Run "ruby repro.rb" with an interactive shell, and it will hang there. At this point, ctrl^C the process, and it will not terminate. What should happen is this unblocking func should be invoked: https://github.com/grpc/grpc/blob/master/src/ruby/ext/grpc/rb_channel.c#L354, but as seen with logging or debuggers, that unblocking func is never ran. Thus the blocking operation never completes and the main thread is stuck. When the same repro.rb is ran on e.g. ruby 2.5.3 or ruby 2.4.1, the blocking operation is unblocked and the process terminates, as expected, when sending it a SIGINT. Also note that if the blocking operation is put in a background thread, e.g. with this script: ```ruby require 'grpc' th = Thread.new do ch = GRPC::Core::Channel.new('localhost:1234', {}, :this_channel_is_insecure) ch.watch_connectivity_state(ch.connectivity_state, Time.now + 360) end th.join ``` then "unblocking" functions will in fact be invoked upon sending the process a SIGINT, so this looks like a problem specifically with rb_thread_call_without_gvl being used on the main thread. Please let me know and I can provide more details or alternative repro cases. Thanks in advance. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121478] [Ruby Bug#21206] Segmentation fault on ISeq#to_binary
by shyouhei (Shyouhei Urabe) 09 Aug '26

09 Aug '26

Issue #21206 has been reported by shyouhei (Shyouhei Urabe). ---------------------------------------- Bug #21206: Segmentation fault on ISeq#to_binary https://bugs.ruby-lang.org/issues/21206 * Author: shyouhei (Shyouhei Urabe) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM +GC [aarch64-linux-gnu] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Found this SEGV using bootsnap. This could well be architecture dependent because of ISeqs being so by nature. Also this doesn't happen when the ISeq is created using `compile_prism`. ``` $ ruby -ve 'RubyVM::InstructionSequence.compile_parsey("def f(g) = each {nil rescue g+it}").to_binary' ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM +GC [aarch64-linux-gnu] -e:1: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM +GC [aarch64-linux-gnu] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0010 e:000009 CFUNC :to_binary c:0002 p:0008 s:0006 e:000005 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:000190 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' -e:1:in 'to_binary' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000000000000000 x1: 0x0000ffff8a15d0a8 x2: 0x0000000000000000 x3: 0x0000000000000003 x4: 0x0000000000000000 x5: 0x0000ffffa4346b50 x6: 0x0000000000000005 x7: 0x00000000fffffffe x18: 0x000000000116810c x19: 0x0000ffff8a15d0a8 x20: 0x0000000000000000 x21: 0x0000000000000001 x22: 0x0000ffffc0f0d968 x23: 0x0000ffffc0f0d4c0 x24: 0x0000000000000018 x25: 0x0000ffffa3c98530 x26: 0x0000000000000000 x27: 0x0000000000000002 x28: 0x0000ffffc0f0d4e8 x29: 0x0000ffffc0f0d410 sp: 0x0000ffffc0f0d410 fau: 0x0000000000000000 -- C level backtrace information ------------------------------------------- /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(0xffffa3e8ff84) [0xffffa3e8ff84] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(0xffffa3e95514) [0xffffa3e95514] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(0xffffa3ce760c) [0xffffa3ce760c] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(0xffffa3e0de88) [0xffffa3e0de88] linux-vdso.so.1(__kernel_rt_sigreturn+0x0) [0xffffa43447a0] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(rb_str_cmp+0x24) [0xffffa3e17d94] [0xffffa3980b9c] [0xffffa3980efc] [0xffffa3f418c8] [0xffffa3c98d4c] [0xffffa3da2484] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(rb_st_foreach+0x44) [0xffffa3e06944] [0xffffa3f213e4] [0xffffa3d46ea4] [0xffffa3e6c92c] [0xffffa3e767a8] [0xffffa3e8cae8] [0xffffa3ce6ac4] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(ruby_run_node+0x9c) [0xffffa3cebba0] [0xaaaae2be0b30] [0xffffa39684c4] [0xffffa3968598] [0xaaaae2be0bb0] -- Other runtime information ----------------------------------------------- * Loaded script: -e * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so 7 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so 8 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/rbconfig.rb 9 /usr/lib/ruby/3.4.0/rubygems/compatibility.rb 10 /usr/lib/ruby/3.4.0/rubygems/defaults.rb 11 /usr/lib/ruby/3.4.0/rubygems/deprecate.rb 12 /usr/lib/ruby/3.4.0/rubygems/errors.rb 13 /usr/lib/ruby/3.4.0/rubygems/target_rbconfig.rb 14 /usr/lib/ruby/3.4.0/rubygems/unknown_command_spell_checker.rb 15 /usr/lib/ruby/3.4.0/rubygems/exceptions.rb 16 /usr/lib/ruby/3.4.0/rubygems/basic_specification.rb 17 /usr/lib/ruby/3.4.0/rubygems/stub_specification.rb 18 /usr/lib/ruby/3.4.0/rubygems/platform.rb 19 /usr/lib/ruby/3.4.0/rubygems/specification_record.rb 20 /usr/lib/ruby/3.4.0/rubygems/util/list.rb 21 /usr/lib/ruby/3.4.0/rubygems/version.rb 22 /usr/lib/ruby/3.4.0/rubygems/requirement.rb 23 /usr/lib/ruby/3.4.0/rubygems/specification.rb 24 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb 25 /usr/lib/ruby/3.4.0/rubygems/util.rb 26 /usr/lib/ruby/3.4.0/rubygems/dependency.rb 27 /usr/lib/ruby/3.4.0/rubygems/core_ext/kernel_gem.rb 28 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so 29 /usr/lib/ruby/3.4.0/monitor.rb 30 /usr/lib/ruby/3.4.0/rubygems.rb 31 /usr/lib/ruby/3.4.0/bundled_gems.rb 32 /usr/lib/ruby/3.4.0/rubygems/path_support.rb 33 /usr/lib/ruby/3.4.0/error_highlight/version.rb 34 /usr/lib/ruby/3.4.0/error_highlight/base.rb 35 /usr/lib/ruby/3.4.0/error_highlight/formatter.rb 36 /usr/lib/ruby/3.4.0/error_highlight/core_ext.rb 37 /usr/lib/ruby/3.4.0/error_highlight.rb 38 /usr/lib/ruby/3.4.0/did_you_mean/version.rb 39 /usr/lib/ruby/3.4.0/did_you_mean/core_ext/name_error.rb 40 /usr/lib/ruby/3.4.0/did_you_mean/levenshtein.rb 41 /usr/lib/ruby/3.4.0/did_you_mean/jaro_winkler.rb 42 /usr/lib/ruby/3.4.0/did_you_mean/spell_checker.rb 43 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb 44 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb 45 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/name_error_checkers.rb 46 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/method_name_checker.rb 47 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/key_error_checker.rb 48 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/null_checker.rb 49 /usr/lib/ruby/3.4.0/did_you_mean/tree_spell_checker.rb 50 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/require_path_checker.rb 51 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/pattern_key_name_checker.rb 52 /usr/lib/ruby/3.4.0/did_you_mean/formatter.rb 53 /usr/lib/ruby/3.4.0/did_you_mean.rb 54 /usr/lib/ruby/3.4.0/syntax_suggest/core_ext.rb * Process memory map: aaaae2be0000-aaaae2be1000 r-xp 00000000 00:34 763738 /usr/bin/ruby3.4 aaaae2bff000-aaaae2c00000 r--p 0000f000 00:34 763738 /usr/bin/ruby3.4 aaaae2c00000-aaaae2c01000 rw-p 00010000 00:34 763738 /usr/bin/ruby3.4 aaab18253000-aaab18545000 rw-p 00000000 00:00 0 [heap] ffff87c00000-ffff881f3000 r--s 00000000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffff88200000-ffff88201000 ---p 00000000 00:00 0 ffff88201000-ffff882a2000 rw-p 00000000 00:00 0 ffff882a2000-ffff882a3000 ---p 00000000 00:00 0 ffff882a3000-ffff88344000 rw-p 00000000 00:00 0 ffff88344000-ffff88345000 ---p 00000000 00:00 0 ffff88345000-ffff883e6000 rw-p 00000000 00:00 0 ffff883e6000-ffff883e7000 ---p 00000000 00:00 0 ffff883e7000-ffff88488000 rw-p 00000000 00:00 0 ffff88488000-ffff88489000 ---p 00000000 00:00 0 ffff88489000-ffff8852a000 rw-p 00000000 00:00 0 ffff8852a000-ffff8852b000 ---p 00000000 00:00 0 ffff8852b000-ffff885cc000 rw-p 00000000 00:00 0 ffff885cc000-ffff885cd000 ---p 00000000 00:00 0 ffff885cd000-ffff8866e000 rw-p 00000000 00:00 0 ffff8866e000-ffff8866f000 ---p 00000000 00:00 0 ffff8866f000-ffff88710000 rw-p 00000000 00:00 0 ffff88710000-ffff88711000 ---p 00000000 00:00 0 ffff88711000-ffff887b2000 rw-p 00000000 00:00 0 ffff887b2000-ffff887b3000 ---p 00000000 00:00 0 ffff887b3000-ffff88854000 rw-p 00000000 00:00 0 ffff88854000-ffff88855000 ---p 00000000 00:00 0 ffff88855000-ffff888f6000 rw-p 00000000 00:00 0 ffff888f6000-ffff888f7000 ---p 00000000 00:00 0 ffff888f7000-ffff88998000 rw-p 00000000 00:00 0 ffff88998000-ffff88999000 ---p 00000000 00:00 0 ffff88999000-ffff88a3a000 rw-p 00000000 00:00 0 ffff88a3a000-ffff88a3b000 ---p 00000000 00:00 0 ffff88a3b000-ffff88adc000 rw-p 00000000 00:00 0 ffff88adc000-ffff88add000 ---p 00000000 00:00 0 ffff88add000-ffff88b7e000 rw-p 00000000 00:00 0 ffff88b7e000-ffff88b7f000 ---p 00000000 00:00 0 ffff88b7f000-ffff88c20000 rw-p 00000000 00:00 0 ffff88c20000-ffff88c21000 ---p 00000000 00:00 0 ffff88c21000-ffff88cc2000 rw-p 00000000 00:00 0 ffff88cc2000-ffff88cc3000 ---p 00000000 00:00 0 ffff88cc3000-ffff88d64000 rw-p 00000000 00:00 0 ffff88d64000-ffff88d65000 ---p 00000000 00:00 0 ffff88d65000-ffff88e06000 rw-p 00000000 00:00 0 ffff88e06000-ffff88e07000 ---p 00000000 00:00 0 ffff88e07000-ffff88ea8000 rw-p 00000000 00:00 0 ffff88ea8000-ffff88ea9000 ---p 00000000 00:00 0 ffff88ea9000-ffff88f4a000 rw-p 00000000 00:00 0 ffff88f4a000-ffff88f4b000 ---p 00000000 00:00 0 ffff88f4b000-ffff88fec000 rw-p 00000000 00:00 0 ffff88fec000-ffff88fed000 ---p 00000000 00:00 0 ffff88fed000-ffff8908e000 rw-p 00000000 00:00 0 ffff8908e000-ffff8908f000 ---p 00000000 00:00 0 ffff8908f000-ffff89130000 rw-p 00000000 00:00 0 ffff89130000-ffff89131000 ---p 00000000 00:00 0 ffff89131000-ffff891d2000 rw-p 00000000 00:00 0 ffff891d2000-ffff891d3000 ---p 00000000 00:00 0 ffff891d3000-ffff89274000 rw-p 00000000 00:00 0 ffff89274000-ffff89275000 ---p 00000000 00:00 0 ffff89275000-ffff89316000 rw-p 00000000 00:00 0 ffff89316000-ffff89317000 ---p 00000000 00:00 0 ffff89317000-ffff893b8000 rw-p 00000000 00:00 0 ffff893b8000-ffff893b9000 ---p 00000000 00:00 0 ffff893b9000-ffff8945a000 rw-p 00000000 00:00 0 ffff8945a000-ffff8945b000 ---p 00000000 00:00 0 ffff8945b000-ffff894fc000 rw-p 00000000 00:00 0 ffff894fc000-ffff894fd000 ---p 00000000 00:00 0 ffff894fd000-ffff8959e000 rw-p 00000000 00:00 0 ffff8959e000-ffff8959f000 ---p 00000000 00:00 0 ffff8959f000-ffff89640000 rw-p 00000000 00:00 0 ffff89800000-ffff89810000 ---p 00000000 00:00 0 ffff89810000-ffff8a010000 rw-p 00000000 00:00 0 ffff8a0d0000-ffff8a0e0000 rw-p 00000000 00:00 0 ffff8a0ef000-ffff8a120000 rw-p 00000000 00:00 0 ffff8a120000-ffff8a122000 r-xp 00000000 00:34 763838 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so ffff8a122000-ffff8a13f000 ---p 00002000 00:34 763838 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so ffff8a13f000-ffff8a140000 r--p 0000f000 00:34 763838 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so ffff8a140000-ffff8a141000 rw-p 00010000 00:34 763838 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so ffff8a150000-ffffa3600000 rw-p 00000000 00:00 0 ffffa3610000-ffffa36d0000 rw-p 00000000 00:00 0 ffffa36d0000-ffffa36d2000 r-xp 00000000 00:34 763811 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so ffffa36d2000-ffffa36ef000 ---p 00002000 00:34 763811 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so ffffa36ef000-ffffa36f0000 r--p 0000f000 00:34 763811 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so ffffa36f0000-ffffa36f1000 rw-p 00010000 00:34 763811 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so ffffa3700000-ffffa3710000 rw-p 00000000 00:00 0 ffffa3710000-ffffa3712000 r-xp 00000000 00:34 763767 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so ffffa3712000-ffffa372f000 ---p 00002000 00:34 763767 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so ffffa372f000-ffffa3730000 r--p 0000f000 00:34 763767 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so ffffa3730000-ffffa3731000 rw-p 00010000 00:34 763767 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so ffffa3740000-ffffa3790000 rw-p 00000000 00:00 0 ffffa379e000-ffffa3900000 rw-p 00000000 00:00 0 ffffa3900000-ffffa391f000 r-xp 00000000 00:34 566619 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 ffffa391f000-ffffa392f000 ---p 0001f000 00:34 566619 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 ffffa392f000-ffffa3930000 r--p 0001f000 00:34 566619 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 ffffa3930000-ffffa3931000 rw-p 00020000 00:34 566619 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 ffffa3940000-ffffa3ada000 r-xp 00000000 00:34 770271 /usr/lib/aarch64-linux-gnu/libc.so.6 ffffa3ada000-ffffa3aed000 ---p 0019a000 00:34 770271 /usr/lib/aarch64-linux-gnu/libc.so.6 ffffa3aed000-ffffa3af0000 r--p 0019d000 00:34 770271 /usr/lib/aarch64-linux-gnu/libc.so.6 ffffa3af0000-ffffa3af2000 rw-p 001a0000 00:34 770271 /usr/lib/aarch64-linux-gnu/libc.so.6 ffffa3af2000-ffffa3afe000 rw-p 00000000 00:00 0 ffffa3b00000-ffffa3b85000 r-xp 00000000 00:34 770303 /usr/lib/aarch64-linux-gnu/libm.so.6 ffffa3b85000-ffffa3b9f000 ---p 00085000 00:34 770303 /usr/lib/aarch64-linux-gnu/libm.so.6 ffffa3b9f000-ffffa3ba0000 r--p 0008f000 00:34 770303 /usr/lib/aarch64-linux-gnu/libm.so.6 ffffa3ba0000-ffffa3ba1000 rw-p 00090000 00:34 770303 /usr/lib/aarch64-linux-gnu/libm.so.6 ffffa3bb0000-ffffa3bdd000 r-xp 00000000 00:34 566603 /usr/lib/aarch64-linux-gnu/libcrypt.so.1.1.0 ffffa3bdd000-ffffa3bef000 ---p 0002d000 00:34 566603 /usr/lib/aarch64-linux-gnu/libcrypt.so.1.1.0 ffffa3bef000-ffffa3bf0000 r--p 0002f000 00:34 566603 /usr/lib/aarch64-linux-gnu/libcrypt.so.1.1.0 ffffa3bf0000-ffffa3bf1000 rw-p 00030000 00:34 566603 /usr/lib/aarch64-linux-gnu/libcrypt.so.1.1.0 ffffa3bf1000-ffffa3bf9000 rw-p 00000000 00:00 0 ffffa3c00000-ffffa41cb000 r-xp 00000000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffffa41cb000-ffffa41d6000 ---p 005cb000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffffa41d6000-ffffa41f0000 r--p 005d6000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffffa41f0000-ffffa41f1000 rw-p 005f0000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffffa41f1000-ffffa4206000 rw-p 00000000 00:00 0 ffffa420f000-ffffa4220000 r--s 00000000 00:34 763738 /usr/bin/ruby3.4 ffffa4220000-ffffa4230000 rw-p 00000000 00:00 0 ffffa4230000-ffffa42aa000 r-xp 00000000 00:34 767074 /usr/lib/aarch64-linux-gnu/libgmp.so.10.5.0 ffffa42aa000-ffffa42bf000 ---p 0007a000 00:34 767074 /usr/lib/aarch64-linux-gnu/libgmp.so.10.5.0 ffffa42bf000-ffffa42c0000 r--p 0007f000 00:34 767074 /usr/lib/aarch64-linux-gnu/libgmp.so.10.5.0 ffffa42c0000-ffffa42c1000 rw-p 00080000 00:34 767074 /usr/lib/aarch64-linux-gnu/libgmp.so.10.5.0 ffffa42d0000-ffffa42ea000 r-xp 00000000 00:34 566707 /usr/lib/aarch64-linux-gnu/libz.so.1.3 ffffa42ea000-ffffa42ff000 ---p 0001a000 00:34 566707 /usr/lib/aarch64-linux-gnu/libz.so.1.3 ffffa42ff000-ffffa4300000 r--p 0001f000 00:34 566707 /usr/lib/aarch64-linux-gnu/libz.so.1.3 ffffa4300000-ffffa4301000 rw-p 00020000 00:34 566707 /usr/lib/aarch64-linux-gnu/libz.so.1.3 ffffa4307000-ffffa432e000 r-xp 00000000 00:34 769991 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 ffffa4339000-ffffa433d000 rw-p 00000000 00:00 0 ffffa4340000-ffffa4342000 rw-p 00000000 00:00 0 ffffa4342000-ffffa4344000 r--p 00000000 00:00 0 [vvar] ffffa4344000-ffffa4345000 r-xp 00000000 00:00 0 [vdso] ffffa4345000-ffffa4347000 r--p 0002e000 00:34 769991 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 ffffa4347000-ffffa4349000 rw-p 00030000 00:34 769991 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 ffffc0eef000-ffffc0f10000 rw-p 00000000 00:00 0 [stack] Segmentation fault ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126346] [Ruby Bug#22218] Line TracePoint misses executed loop condition after a guard
by nagachika (Tomoyuki Chikanaga) 09 Aug '26

09 Aug '26

Issue #22218 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED to 3.3: REQUIRED, 3.4: DONE, 4.0: REQUIRED ruby_3_4 commit:7096aad15fc249bc04ddc6335156ba90e68dbdd2 merged revision(s) commit:79e6d37b5569be4c772e9d41e8a5447e82c09683. ---------------------------------------- Bug #22218: Line TracePoint misses executed loop condition after a guard https://bugs.ruby-lang.org/issues/22218#change-118464 * Author: ioquatix (Samuel Williams) * Status: Closed * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: DONE, 4.0: REQUIRED ---------------------------------------- `TracePoint.new(:line)` can miss the line event for an executed loop condition when the loop follows a conditional guard. This is related to [Bug #15980](https://bugs.ruby-lang.org/issues/15980), which fixed the same control-flow problem for line coverage. The coverage-specific workaround does not apply to ordinary line TracePoint consumers, so TracePoint and Coverage can still disagree. ## Affected versions This affects Ruby 3.3 and later. The behavior was reproduced on Ruby 3.4.4 and Ruby 4.0.5, both of which report `[1, 3]`. Ruby 3.3.0 through 3.3.11 retain the same coverage-only compiler guard; the source explicitly notes that the TracePoint line event does not occur. Ruby 4.1 development versions are also affected without the proposed patch. ## Reproduction ```ruby source = <<~RUBY raise if 1 == 2 while true break end RUBY lines = [] TracePoint.new(:line) do |trace| lines << trace.lineno if trace.path == "example.rb" end.enable do eval(source, binding, "example.rb") end p lines ``` ### Actual result ```ruby [1, 3] ``` ### Expected result ```ruby [1, 2, 3] ``` The same problem occurs with a non-constant predicate, for example: ```ruby def read return if @finished while chunk = super consume(chunk) end end ``` ## Cause Jump-to-jump peephole optimization retargets the conditional branch past the synthetic jump carrying the line event. As a result, execution reaches the loop body without visiting the event-bearing instruction. ## Proposed Fix The proposed fix is [ruby/ruby#18122](https://github.com/ruby/ruby/pull/18122). Ruby already stops this jump-to-jump optimization when line coverage is enabled and the skipped jump has event flags. The patch generalizes that existing guard: it skips this specific retargeting whenever the intermediate jump carries `RUBY_EVENT_LINE` or `RUBY_EVENT_COVERAGE_LINE`, regardless of whether coverage is active. Other jump-to-jump folding remains enabled. The change only retains the event-bearing jump that TracePoint must visit; it does not add trace-edge metadata or require new VM, YJIT, or ZJIT handling. This is the smaller alternative suggested in the discussion of [ruby/ruby#17825](https://github.com/ruby/ruby/pull/17825). ### Performance The retained jump costs one additional YARV dispatch when the interpreter traverses an affected edge. Performance-sensitive JIT execution can optimize away the extra control-flow overhead: YJIT emits no machine jump when it can place the target block next, while ZJIT cleans up the jump chain in its control-flow graph. The following results compare Ruby immediately before and after the patch on an Apple M4 Pro. Each result is the median of 9 or 11 samples after 3 warmups: | Targeted benchmark | Baseline | Patched | Change | |---|---:|---:|---:| | Hot affected edge, interpreter | 46.20 M iterations/s | 45.74 M iterations/s | -1.0% | | Minimal guarded reader, interpreter | 30.95 M calls/s | 30.13 M calls/s | -2.7% | | Minimal guarded reader, YJIT | 272.56 M calls/s | 272.56 M calls/s | 0.0% | | Minimal guarded reader, ZJIT | 435.34 M calls/s | 436.89 M calls/s | +0.4% | For a synthetic hot-edge benchmark, two long YJIT runs in opposite order varied between -0.5% and +0.4%, and ZJIT differed by +0.04%. There was therefore no repeatable JIT regression. The interpreter figures are deliberately concentrated worst cases where every iteration or call traverses the affected edge. ## Related work - Previous coverage issue: [Bug #15980](https://bugs.ruby-lang.org/issues/15980) - Earlier edge-metadata approach: [ruby/ruby#17825](https://github.com/ruby/ruby/pull/17825) - Selective peephole fix: [ruby/ruby#18122](https://github.com/ruby/ruby/pull/18122) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126344] [Ruby Bug#11438] native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32
by nagachika (Tomoyuki Chikanaga) 09 Aug '26

09 Aug '26

Issue #11438 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED to 3.3: WONTFIX, 3.4: DONE, 4.0: REQUIRED ruby_3_4 commit:44145cf4dc64fa4cebbec10d2ec3454fbfd65559 merged revision(s) commit:e585c9449965a6837374e0c5436cf4be731802df. ---------------------------------------- Bug #11438: native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32 https://bugs.ruby-lang.org/issues/11438#change-118461 * Author: rickerliang (l ly) * Status: Closed * Assignee: windows * ruby -v: 2.2.2 * Backport: 3.3: WONTFIX, 3.4: DONE, 4.0: REQUIRED ---------------------------------------- In function native_thread_init_stack() use VirtualQuery to get thread's stack start address.But some situation(ruby embbed in other application and initial it on the fly),native_thread_init_stack() will be called at low stack address and VirtualQuery return memory info BaseAddress + RegionSize < thread stack base(teb.StackBase). In this situation,subsequently call stack_check() at high stack address will cause stack_overflow exception,because esp > machine.stack_start: (teb.StackLimit < machine.stack_start < esp < teb.StackBase) but actually it is not stack overflow at this time. Use teb.StackBase instead of VirtualQuery get thread stack base is a more reliable solution. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126049] [Ruby Bug#22191] `Signal.trap(:EXIT)` exception only shown if `at_exit` also raises
by Earlopain (Earlopain _) 09 Aug '26

09 Aug '26

Issue #22191 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22191: `Signal.trap(:EXIT)` exception only shown if `at_exit` also raises https://bugs.ruby-lang.org/issues/22191 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-29T14:34:40Z master 7a07a54298) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```rb Signal.trap(:EXIT, proc { raise "foo" }) # No output ``` ```rb Signal.trap(:EXIT, proc { raise "foo" }) at_exit { raise "bar" } # test.rb:2:in 'block in <main>': bar (RuntimeError) # test.rb:1:in 'block in <main>': foo (RuntimeError) ``` A bit weird -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125997] [Ruby Bug#22189] `Enumerator::Lazy#to_enum` does not accept method names as strings
by nobu (Nobuyoshi Nakada) 09 Aug '26

09 Aug '26

Issue #22189 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22189: `Enumerator::Lazy#to_enum` does not accept method names as strings https://bugs.ruby-lang.org/issues/22189 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `Kernel#to_enum` accepts a `String` as well as a `Symbol`. ```ruby [1,2,3].to_enum(:map).to_a #=> [1, 2, 3] [1,2,3].to_enum("map").to_a #=> [1, 2, 3] [1,2,3].lazy.to_enum(:map).to_a #=> [1, 2, 3] [1,2,3].lazy.to_enum("map").to_a #=> [] ``` Related to [Bug #7877]. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125864] [Ruby Bug#22133] Ruby's default SIGINT handling ignores `Thread.handle_interrupt` masking.
by ioquatix (Samuel Williams) 09 Aug '26

09 Aug '26

Issue #22133 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #22133: Ruby's default SIGINT handling ignores `Thread.handle_interrupt` masking. https://bugs.ruby-lang.org/issues/22133 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Ruby's default SIGINT handling currently bypasses `Thread.handle_interrupt` masking. When a process receives SIGINT with the default Ruby handler installed, CRuby calls `rb_interrupt()` directly. That can raise `Interrupt` immediately inside code wrapped by `Thread.handle_interrupt(SignalException => :never)`, including while blocked in operations like `Thread::Queue#pop`. This is inconsistent with other asynchronous exception delivery paths, such as `Thread#raise`, and with other default signal exceptions such as SIGTERM. Those paths enqueue a pending interrupt on the target thread, allowing `Thread.handle_interrupt` to defer delivery until the configured point. ## Background This was discovered while working on `Async`/`Async::Container` signal handling. Async relies on `Thread.handle_interrupt` and scheduler-level interruption boundaries to keep signal delivery deterministic. The current default SIGINT path means a Ctrl-C can escape a masked section and interrupt internal synchronization code, which can break graceful shutdown behavior. A minimal reproduction is: ```ruby waiting = Thread::Queue.new release = Thread::Queue.new inner = false Thread.new do waiting.pop Process.kill(:INT, Process.pid) release.push(true) end begin Thread.handle_interrupt(SignalException => :never) do begin waiting.push(true) release.pop rescue Interrupt inner = true raise end end rescue Interrupt puts "outer" end puts inner ``` Expected output: ```text outer false ``` Current affected behavior can produce `inner == true`, meaning the `Interrupt` was delivered inside the masked region. ## Proposed fix Route default SIGINT through the same pending-interrupt mechanism as other default signal exceptions, while preserving the traditional exception class and no-message `Interrupt` object. Concretely, the PR replaces the direct `rb_interrupt()` default SIGINT path with a helper that enqueues an `Interrupt` on the main thread and wakes that thread. This makes default SIGINT respect `Thread.handle_interrupt(SignalException => :never)` in the same way as default SIGTERM/SignalException and `Thread#raise`. ## Pull request PR: https://github.com/ruby/ruby/pull/17533 The PR includes: 1. A failing regression test for default SIGINT with `Thread.handle_interrupt`. 2. The implementation change routing default SIGINT through the pending interrupt queue. 3. Ruby/spec coverage for default SIGINT -> `Interrupt` and default SIGTERM -> `SignalException` being maskable by `Thread.handle_interrupt`. Once accepted, I would like to request backports for supported Ruby branches where this default SIGINT behavior is present. -- https://bugs.ruby-lang.org/

7 6

[ruby-core:125661] [Ruby Bug#22099] Keyword-only method silently accepts a positional argument
by rumoto (Hiroki Motoyoshi) 09 Aug '26

09 Aug '26

Issue #22099 has been reported by rumoto (Hiroki Motoyoshi). ---------------------------------------- Bug #22099: Keyword-only method silently accepts a positional argument https://bugs.ruby-lang.org/issues/22099 * Author: rumoto (Hiroki Motoyoshi) * Status: Open * ruby -v: ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A method that declares only keyword parameters accepts a positional argument without raising, but only from the second call onward; a prior valid keyword call to the same method is required to trigger it. Once triggered, the positional value is bound to the first keyword and an explicitly passed keyword of the same name is dropped. ```ruby class Foo def bar(a: nil, b: nil) p [:body, a: a, b: b] end end foo = Foo.new foo.bar(a: 1, b: 2) #=> [:body, {a: 1, b: 2}] foo.bar(99, a: 0) #=> [:body, {a: 99, b: nil}] foo.bar(99, b: 0) #=> [:body, {a: nil, b: 99}] ``` Although one positional argument is passed, no exception is raised. The positional value (`99`) is bound to the first keyword `a`, and the explicitly passed keyword (`a: 0` / `b: 0`) is not reflected in the result. Since `bar` accepts no positional arguments, an `ArgumentError (wrong number of arguments (given 1, expected 0))` should be raised. -- https://bugs.ruby-lang.org/

6 6

[ruby-core:125939] [Ruby Bug#22183] parse.y interpolation inside lambda literal
by kddnewton (Kevin Newton) 09 Aug '26

09 Aug '26

Issue #22183 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22183: parse.y interpolation inside lambda literal https://bugs.ruby-lang.org/issues/22183 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is an odd bug that I think is just leaking parse.y internals to do with paren_nest and lambda_beginning_p. In parse.y, `p->lex.lpar_beg` is not isolated when the lexer enters a string interpolation (`tSTRING_DBEG`). So `lambda_beginning_p()` can be true inside an interpolation that appears between a lambda's `->` and its body, causing a `do` or `{` inside the interpolation to be lexed as `keyword_do_LAMBDA` / `tLAMBEG` and produce a syntax error. ```ruby -> a = "#{foo do end}" do end ``` ```console $ ruby --parser=parse.y -c test.rb test.rb: test.rb:1: syntax error found (SyntaxError) > 1 | -> a = "#{foo do end}" do end | ^~ unexpected 'do' for lambda, ... ``` The same applies with a brace block inside the interpolation: ```ruby -> a = "#{foo { }}" do end # parse.y: syntax error at the `{`, lexed as tLAMBEG ``` I'm not 100% sure about this one to be honest. I guess it could potentially have been a design decision? But it seems inconsistent: ```ruby -> a = ("#{foo do end}") do end # parse.y: OK -> a = "#{foo do end}" do end # parse.y: syntax error ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125803] [Ruby Bug#22124] void value missed in parse.y
by kddnewton (Kevin Newton) 09 Aug '26

09 Aug '26

Issue #22124 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22124: void value missed in parse.y https://bugs.ruby-lang.org/issues/22124 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` $ ruby --parser=parse.y -cwe 'x = return a b do end' Syntax OK $ ruby --parser=prism -cwe 'x = return a b do end' ruby: -e:1: syntax error found (SyntaxError) > 1 | x = return a b do end | ^~~~~~~~~~~~~~~~~ unexpected void value expression ``` I think it's likely because of the wrapped block expression. -- https://bugs.ruby-lang.org/

5 4