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

[ruby-core:123631] [Ruby Bug#21660] No-parentheses endless method definition that has parameter destructuring is wrongly accepted in Prism
by tompng (tomoya ishida) 06 Nov '25

06 Nov '25

Issue #21660 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21660: No-parentheses endless method definition that has parameter destructuring is wrongly accepted in Prism https://bugs.ruby-lang.org/issues/21660 * Author: tompng (tomoya ishida) * Status: Open * Assignee: prism * ruby -v: ruby 3.5.0dev (2025-11-01T00:18:01Z master 17a7b4e031) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- This is syntax error in parse.y but not in Prism. ~~~ruby def f a, (b) = 1 ~~~ Related to #21623 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117434] [Ruby master Bug#20409] Missing reporting some invalid breaks
by kddnewton (Kevin Newton) 06 Nov '25

06 Nov '25

Issue #20409 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20409: Missing reporting some invalid breaks https://bugs.ruby-lang.org/issues/20409 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

3 7

[ruby-core:123500] [Ruby Bug#21644] Stack consistency error for the `newrange` INSN peephole optimization with chilled string
by viralpraxis (Iaroslav Kurbatov) 05 Nov '25

05 Nov '25

Issue #21644 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #21644: Stack consistency error for the `newrange` INSN peephole optimization with chilled string https://bugs.ruby-lang.org/issues/21644 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- PR:https://github.com/ruby/ruby/pull/14879 Confirmed on every version since 3.4. ``` shell $ ruby -v -e '("a" || "b").."c"' ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] -e:1: warning: possibly useless use of .. in void context -e:1: [BUG] Stack consistency error (sp: 7, bp: 6) ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0002 p:0013 s:0007 e:000005 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:001920 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ruby/3.4.7/lib/libruby.so.3.4(rb_print_backtrace+0x8) [0x78aa9573c882] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_dump.c:823 ruby/3.4.7/lib/libruby.so.3.4(rb_vm_bugreport) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_dump.c:1155 ruby/3.4.7/lib/libruby.so.3.4(rb_bug_without_die_internal+0x6b) [0x78aa9544c62f] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/error.c:1097 ruby/3.4.7/lib/libruby.so.3.4(rb_bug) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/error.c:1115 ruby/3.4.7/lib/libruby.so.3.4(vm_stack_consistency_error+0x1f) [0x78aa9544f091] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_insnhelper.c:6523 ruby/3.4.7/lib/libruby.so.3.4(vm_get_cref) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/insns.def:1134 ruby/3.4.7/lib/libruby.so.3.4(vm_setclassvariable) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_insnhelper.c:1630 ruby/3.4.7/lib/libruby.so.3.4(vm_setclassvariable) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_insnhelper.c:1627 ruby/3.4.7/lib/libruby.so.3.4(vm_exec_core) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/insns.def:253 ruby/3.4.7/lib/libruby.so.3.4(vm_exec_loop+0xa) [0x78aa95724959] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm.c:2622 ruby/3.4.7/lib/libruby.so.3.4(rb_vm_exec) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm.c:2598 ruby/3.4.7/lib/libruby.so.3.4(rb_ec_exec_node+0xa5) [0x78aa95525695] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/eval.c:281 ruby/3.4.7/lib/libruby.so.3.4(ruby_run_node+0x83) [0x78aa95529333] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/eval.c:319 ruby/3.4.7/bin/ruby(rb_main+0x21) [0x59d86f5e0186] ./main.c:43 ruby/3.4.7/bin/ruby(main) ./main.c:68 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x7a) [0x78aa9502a1ca] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x78aa9502a28b] ../csu/libc-start.c:360 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:347 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0 [0x59d86f5e01d5] ``` The optimization in question: https://github.com/ruby/ruby/blob/957c832db137e67289e93dfd9fd9e915b1f2fc87/… Before entering this `newrange` optimization, the iseq looks like this: ``` == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(1,17)> 0000 putchilledstring "a" ( 1)[Li] 0002 dup 0003 branchif 8 0005 pop 0006 putchilledstring "b" 0008 putchilledstring "c" 0010 newrange 0 0012 leave ``` So the optimization constructs a new range using the wrong operands (`"b"` and `"c"` instead of `"a"` and `"c"`). Also, I'm wondering why chilled strings are not ||-peephole-optimized? ``` ruby ruby --dump insn -ve '"a" || "b"' ruby 3.5.0dev (2025-10-19T14:22:25Z master 957c832db1) +PRISM [x86_64-linux] == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putchilledstring "a" ( 1)[Li] 0002 dup 0003 branchif 8 0005 pop 0006 putchilledstring "b" 0008 leave ``` ```ruby ruby --enable-frozen-string-literal --dump insn -ve '"a" || "b"' ruby 3.5.0dev (2025-10-19T14:22:25Z master 957c832db1) +PRISM [x86_64-linux] == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putobject "a" ( 1)[Li] 0002 leave ``` ```ruby ruby --disable-frozen-string-literal --dump insn -ve '"a" || "b"' ruby 3.5.0dev (2025-10-19T14:22:25Z master 957c832db1) +PRISM [x86_64-linux] == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putstring "a" ( 1)[Li] 0002 leave ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123687] [Ruby Bug#21670] 3.4.5 crashing with "try to mark T_NONE object"
by esaron (Es Aron) 05 Nov '25

05 Nov '25

Issue #21670 has been reported by esaron (Es Aron). ---------------------------------------- Bug #21670: 3.4.5 crashing with "try to mark T_NONE object" https://bugs.ruby-lang.org/issues/21670 * Author: esaron (Es Aron) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We're experiencing a large number of crashes while running tests in CI on Ubuntu 22.04 runners. It is inconsistent, and we cannot reproduce reliably, although when the crash happens it appears to always happen in the same place, even if during different tests. This occurs both with and without YJIT enabled. ---Files-------------------------------- 3.4.5-crash-logs.txt (185 KB) -- https://bugs.ruby-lang.org/

4 4

[ruby-core:123632] [Ruby Bug#21661] Endless method definition as a default value of block parameter is wrongly accepted in Prism
by tompng (tomoya ishida) 03 Nov '25

03 Nov '25

Issue #21661 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21661: Endless method definition as a default value of block parameter is wrongly accepted in Prism https://bugs.ruby-lang.org/issues/21661 * Author: tompng (tomoya ishida) * Status: Open * Assignee: prism * ruby -v: ruby 3.5.0dev (2025-11-01T00:18:01Z master 17a7b4e031) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- These are syntax error in parse.y but not in Prism. ~~~ruby p do |a = def f = 1; b| end p do |a = def f = 1| 2; b|c end # `|` inside block parameter ~~~ Normal assignment as a default value `p do |a = b = 1| end` is already syntax error. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123146] [Ruby Bug#21559] Unicode normalization nfd -> nfc -> nfd is not reversible
by tompng (tomoya ishida) 02 Nov '25

02 Nov '25

Issue #21559 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21559: Unicode normalization nfd -> nfc -> nfd is not reversible https://bugs.ruby-lang.org/issues/21559 * Author: tompng (tomoya ishida) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I expect `nfd(nfc(str)) == nfd(str)` but found a string that doesn't. ~~~ruby # Ruby 3.1 - 3.5 str = "s\u{11930}\u{323}\u{11930}\u{307}" p str.unicode_normalize(:nfd) == str.unicode_normalize(:nfc).unicode_normalize(:nfd) #=> false ~~~ ~~~ruby # ruby 3.5.0dev str = "s\u{1611e}\u{323}\u{1611e}\u{307}\u{1611f}" p str.unicode_normalize(:nfd) == str.unicode_normalize(:nfc).unicode_normalize(:nfd) #=> false ~~~ -- https://bugs.ruby-lang.org/

4 7

[ruby-core:123644] [Ruby Bug#21662] Variables other than those in the conditional score are replaced.
by binh (binh chau) 02 Nov '25

02 Nov '25

Issue #21662 has been reported by binh (binh chau). ---------------------------------------- Bug #21662: Variables other than those in the conditional score are replaced. https://bugs.ruby-lang.org/issues/21662 * Author: binh (binh chau) * Status: Open * ruby -v: 3.2.2 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` class Bar attr_accessor :name end class Foo attr_accessor :bar def initialize(bar=nil) @bar = bar || Bar.new end def bug! if !bar.is_a?(Bar) bar = '' elsif bar.name == 'bar' end end end Foo.new.bug! ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123651] [Ruby Bug#21664] Segfault when running Ractor tests in the same process
by Eregon (Benoit Daloze) 02 Nov '25

02 Nov '25

Issue #21664 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21664: Segfault when running Ractor tests in the same process https://bugs.ruby-lang.org/issues/21664 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: ractor * ruby -v: ruby 3.5.0dev (2025-11-01T19:14:42Z master 48c7f349f6) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When running the tests from https://github.com/ruby/ruby/blob/master/bootstraptest/test_ractor.rb in a single process, I see segfaults occurring every time on the following tests: ``` # move object with generic ivar # move object with many generic ivars # move object with complex generic ivars # moved composite types move their non-shareable parts properly ``` To run those tests in the same process, I wrote a simple harness in https://github.com/eregon/ractor-shim/blob/main/test/run_tests.rb Full reproduction steps: ``` git clone --branch ruby3.5-segfault-repro git@github.com:eregon/ractor-shim.git cd ractor-shim ruby test/run_tests.rb ``` Result: ``` Running test from line 1941: <internal:ractor>:743: [BUG] Object is missing entry in generic_fields_tbl ruby 3.5.0dev (2025-11-01T19:14:42Z master 48c7f349f6) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0012 p:0003 s:0076 e:000075 l:y n:0001 METHOD <internal:ractor>:743 c:0011 p:0008 s:0069 e:000068 l:y n:0001 METHOD <internal:ractor>:330 c:0010 p:0045 s:0062 E:000648 l:n n:---- EVAL /home/eregon/code/ractor-shim/test/test_ractor.rb:1946 [FINISH] c:0009 p:---- s:0056 e:000055 l:y n:---- CFUNC :eval c:0008 p:0014 s:0048 e:000047 l:n n:---- BLOCK test/run_tests.rb:128 [FINISH] c:0007 p:---- s:0045 e:000044 l:y n:---- CFUNC :catch c:0006 p:0124 s:0040 e:000039 l:y n:0001 METHOD test/run_tests.rb:127 c:0005 p:0013 s:0024 E:001ca0 l:y n:0001 METHOD test/run_tests.rb:167 c:0004 p:1134 s:0016 e:000015 l:y n:0001 TOP /home/eregon/code/ractor-shim/test/test_ractor.rb:1941 [FINISH] c:0003 p:---- s:0012 e:000011 l:y n:---- CFUNC :require_relative c:0002 p:0107 s:0007 E:000cd8 l:n n:---- EVAL test/run_tests.rb:192 [FINISH] c:0001 p:0000 s:0003 E:0002d0 l:y n:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test/run_tests.rb:192:in '<main>' test/run_tests.rb:192:in 'require_relative' /home/eregon/code/ractor-shim/test/test_ractor.rb:1941:in '<top (required)>' test/run_tests.rb:167:in 'assert_equal' test/run_tests.rb:127:in 'generic_assert' test/run_tests.rb:127:in 'catch' test/run_tests.rb:128:in 'block in generic_assert' test/run_tests.rb:128:in 'eval' /home/eregon/code/ractor-shim/test/test_ractor.rb:1946:in '<compiled>' <internal:ractor>:330:in 'send' <internal:ractor>:743:in 'send' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/eregon/prefix/ruby-master/bin/ruby(rb_print_backtrace+0x14) [0x5630e371cb50] /home/eregon/code/ruby/vm_dump.c:1099 /home/eregon/prefix/ruby-master/bin/ruby(rb_vm_bugreport) /home/eregon/code/ruby/vm_dump.c:1444 /home/eregon/prefix/ruby-master/bin/ruby(rb_bug_without_die_internal+0x73) [0x5630e2fc554b] /home/eregon/code/ruby/error.c:1097 /home/eregon/prefix/ruby-master/bin/ruby(rb_bug) /home/eregon/code/ruby/error.c:1115 /home/eregon/prefix/ruby-master/bin/ruby(rb_imemo_fields_owner+0x0) [0x5630e2fa752b] /home/eregon/code/ruby/variable.c:1258 /home/eregon/prefix/ruby-master/bin/ruby(rb_obj_fields) /home/eregon/code/ruby/variable.c:1252 /home/eregon/prefix/ruby-master/bin/ruby(rb_shape_too_complex_p+0x0) [0x5630e31798f2] /home/eregon/code/ruby/variable.c:1812 /home/eregon/prefix/ruby-master/bin/ruby(imemo_fields_set) /home/eregon/code/ruby/variable.c:1766 /home/eregon/prefix/ruby-master/bin/ruby(generic_field_set) /home/eregon/code/ruby/variable.c:1813 /home/eregon/prefix/ruby-master/bin/ruby(RB_BUILTIN_TYPE+0x0) [0x5630e2fe8096] /home/eregon/code/ruby/gc.c:1900 /home/eregon/prefix/ruby-master/bin/ruby(rbimpl_RB_TYPE_P_fastpath) ./include/ruby/internal/value_type.h:352 /home/eregon/prefix/ruby-master/bin/ruby(RB_TYPE_P) ./include/ruby/internal/value_type.h:379 /home/eregon/prefix/ruby-master/bin/ruby(RBASIC_SHAPE_ID) ./shape.h:145 /home/eregon/prefix/ruby-master/bin/ruby(object_id0) /home/eregon/code/ruby/gc.c:1902 /home/eregon/prefix/ruby-master/bin/ruby(object_id0) /home/eregon/code/ruby/gc.c:1888 /home/eregon/prefix/ruby-master/bin/ruby(rb_gc_obj_id_moved+0x72) [0x5630e2fe8d52] /home/eregon/code/ruby/gc.c:2178 /home/eregon/prefix/ruby-master/bin/ruby(RB_IMMEDIATE_P+0x0) [0x5630e30943d0] /home/eregon/code/ruby/ractor.c:1977 /home/eregon/prefix/ruby-master/bin/ruby(RB_SPECIAL_CONST_P) ./include/ruby/internal/special_consts.h:329 /home/eregon/prefix/ruby-master/bin/ruby(rb_type) ./include/ruby/internal/value_type.h:227 /home/eregon/prefix/ruby-master/bin/ruby(rb_obj_exivar_p) /home/eregon/code/ruby/shape.h:422 /home/eregon/prefix/ruby-master/bin/ruby(move_leave) /home/eregon/code/ruby/ractor.c:1979 /home/eregon/prefix/ruby-master/bin/ruby(obj_traverse_replace_i+0x282) [0x5630e3097852] /home/eregon/code/ruby/ractor.c:1896 /home/eregon/prefix/ruby-master/bin/ruby(rb_obj_traverse_replace+0x46) [0x5630e3097f93] /home/eregon/code/ruby/ractor.c:1920 /home/eregon/prefix/ruby-master/bin/ruby(ractor_move) /home/eregon/code/ruby/ractor.c:1995 /home/eregon/prefix/ruby-master/bin/ruby(ractor_prepare_payload) /home/eregon/code/ruby/ractor_sync.c:787 /home/eregon/prefix/ruby-master/bin/ruby(ractor_basket_new) /home/eregon/code/ruby/ractor_sync.c:803 /home/eregon/prefix/ruby-master/bin/ruby(ractor_send0) /home/eregon/code/ruby/ractor_sync.c:1210 /home/eregon/prefix/ruby-master/bin/ruby(ractor_send) /home/eregon/code/ruby/ractor_sync.c:1219 /home/eregon/prefix/ruby-master/bin/ruby(ractor_port_send) /home/eregon/code/ruby/ractor_sync.c:150 /home/eregon/prefix/ruby-master/bin/ruby(builtin_inline_class_743) /home/eregon/code/ruby/ractor.rb:744 /home/eregon/prefix/ruby-master/bin/ruby(vm_pop_frame+0x0) [0x5630e31b148e] /home/eregon/code/ruby/vm_insnhelper.c:7550 /home/eregon/prefix/ruby-master/bin/ruby(vm_exec_core) /home/eregon/code/ruby/insns.def:1677 /home/eregon/prefix/ruby-master/bin/ruby(vm_exec_loop+0x52) [0x5630e31a1e0a] /home/eregon/code/ruby/vm.c:2769 /home/eregon/prefix/ruby-master/bin/ruby(rb_vm_exec) /home/eregon/code/ruby/vm.c:2745 /home/eregon/prefix/ruby-master/bin/ruby(rb_f_eval+0x163) [0x5630e31bc783] /home/eregon/code/ruby/vm_eval.c:2026 /home/eregon/prefix/ruby-master/bin/ruby(vm_cfp_consistent_p+0x0) [0x5630e3198f0d] /home/eregon/code/ruby/vm_insnhelper.c:3915 /home/eregon/prefix/ruby-master/bin/ruby(vm_call_cfunc_with_frame_) /home/eregon/code/ruby/vm_insnhelper.c:3917 /home/eregon/prefix/ruby-master/bin/ruby(vm_sendish+0x15f) [0x5630e3196d7f] /home/eregon/code/ruby/vm_insnhelper.c:6108 /home/eregon/prefix/ruby-master/bin/ruby(vm_exec_core+0x86) [0x5630e31b0e86] /home/eregon/code/ruby/insns.def:902 /home/eregon/prefix/ruby-master/bin/ruby(vm_exec_loop+0x52) [0x5630e31a1e0a] /home/eregon/code/ruby/vm.c:2769 /home/eregon/prefix/ruby-master/bin/ruby(rb_vm_exec) /home/eregon/code/ruby/vm.c:2745 /home/eregon/prefix/ruby-master/bin/ruby(catch_i+0xf7) [0x5630e31a6a07] /home/eregon/code/ruby/vm.c:1823 /home/eregon/prefix/ruby-master/bin/ruby(vm_catch_protect+0x118) [0x5630e319a6f8] /home/eregon/code/ruby/vm_eval.c:2634 /home/eregon/prefix/ruby-master/bin/ruby(rb_catch_obj+0x4a) [0x5630e319aa4f] /home/eregon/code/ruby/vm_eval.c:2660 /home/eregon/prefix/ruby-master/bin/ruby(rb_f_catch) /home/eregon/code/ruby/vm_eval.c:2610 /home/eregon/prefix/ruby-master/bin/ruby(vm_cfp_consistent_p+0x0) [0x5630e3198f0d] /home/eregon/code/ruby/vm_insnhelper.c:3915 /home/eregon/prefix/ruby-master/bin/ruby(vm_call_cfunc_with_frame_) /home/eregon/code/ruby/vm_insnhelper.c:3917 /home/eregon/prefix/ruby-master/bin/ruby(vm_sendish+0x15f) [0x5630e3196d7f] /home/eregon/code/ruby/vm_insnhelper.c:6108 /home/eregon/prefix/ruby-master/bin/ruby(vm_exec_core+0x147) [0x5630e31b0f47] /home/eregon/code/ruby/insns.def:854 /home/eregon/prefix/ruby-master/bin/ruby(vm_exec_loop+0x52) [0x5630e31a1e0a] /home/eregon/code/ruby/vm.c:2769 /home/eregon/prefix/ruby-master/bin/ruby(rb_vm_exec) /home/eregon/code/ruby/vm.c:2745 /home/eregon/prefix/ruby-master/bin/ruby(require_internal+0x10b2) [0x5630e303fe62] /home/eregon/code/ruby/load.c:1353 /home/eregon/prefix/ruby-master/bin/ruby(rb_require_string_internal+0x6e) [0x5630e303ff6e] /home/eregon/code/ruby/load.c:1464 /home/eregon/prefix/ruby-master/bin/ruby(vm_cfp_consistent_p+0x0) [0x5630e3198f0d] /home/eregon/code/ruby/vm_insnhelper.c:3915 /home/eregon/prefix/ruby-master/bin/ruby(vm_call_cfunc_with_frame_) /home/eregon/code/ruby/vm_insnhelper.c:3917 /home/eregon/prefix/ruby-master/bin/ruby(vm_sendish+0x15f) [0x5630e3196d7f] /home/eregon/code/ruby/vm_insnhelper.c:6108 /home/eregon/prefix/ruby-master/bin/ruby(vm_exec_core+0x86) [0x5630e31b0e86] /home/eregon/code/ruby/insns.def:902 /home/eregon/prefix/ruby-master/bin/ruby(vm_exec_loop+0x52) [0x5630e31a1e0a] /home/eregon/code/ruby/vm.c:2769 /home/eregon/prefix/ruby-master/bin/ruby(rb_vm_exec) /home/eregon/code/ruby/vm.c:2745 /home/eregon/prefix/ruby-master/bin/ruby(rb_ec_exec_node+0xd9) [0x5630e2fc9d99] /home/eregon/code/ruby/eval.c:283 /home/eregon/prefix/ruby-master/bin/ruby(ruby_run_node+0x80) [0x5630e2fce470] /home/eregon/code/ruby/eval.c:321 /home/eregon/prefix/ruby-master/bin/ruby(rb_main+0x21) [0x5630e2fc7180] ./main.c:42 /home/eregon/prefix/ruby-master/bin/ruby(main) ./main.c:62 /lib64/libc.so.6(__libc_start_call_main+0x78) [0x7fc19cb8b448] /lib64/libc.so.6(__libc_start_main+0x8b) [0x7fc19cb8b50b] [0x5630e2fc71c5] -- Other runtime information ----------------------------------------------- ... ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:123172] [Ruby Bug#21560] RUBY_MN_THREADS=1 causes large performance regression in Puma 7
by schneems (Richard Schneeman) 01 Nov '25

01 Nov '25

Issue #21560 has been reported by schneems (Richard Schneeman). ---------------------------------------- Bug #21560: RUBY_MN_THREADS=1 causes large performance regression in Puma 7 https://bugs.ruby-lang.org/issues/21560 * Author: schneems (Richard Schneeman) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## Expected Running a webserver with `RUBY_MN_THREADS=1` will increase performance or keep it the same. ## Actual - Before: 22919.85 Requests/sec - After: 2287.13 Requests/sec ## Reproduction Tracking this at https://github.com/puma/puma/issues/3720. I would like to get a smaller reproduction, but until then here's how we're able to induce the failure: Prepare puma: ``` $ git clone https://github.com/puma/puma $ cd puma $ git checkout v7.0.0.pre1 $ rake compile ``` Boot the server to deliver a "hello world" response: ``` $ bundle exec ruby -Ilib bin/puma -w 1 -t1 --preload test/rackup/hello.ru ``` Exercise the server with `wrk` (brew install wrk): ``` $ wrk -H 'Host: tfb-server' -H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' -H 'Connection: keep-alive' --latency -d 15 -c 16 --timeout 8 -t 12 http://localhost:9292 ``` ### Results Before: ``` $ bundle exec ruby -Ilib bin/puma -w 1 -t1 --preload test/rackup/hello.ru ``` ``` $ wrk -H 'Host: tfb-server' -H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' -H 'Connection: keep-alive' --latency -d 15 -c 16 --timeout 8 -t 12 http://localhost:9292 Running 15s test @ http://localhost:9292 12 threads and 16 connections Thread Stats Avg Stdev Max +/- Stdev Latency 786.74us 1.45ms 45.57ms 90.62% Req/Sec 1.92k 188.55 4.20k 83.22% Latency Distribution 50% 386.00us 75% 523.00us 90% 2.11ms 99% 4.63ms 344638 requests in 15.04s, 25.23MB read Requests/sec: 22919.85 Transfer/sec: 1.68MB ``` After: ``` $ env RUBY_MN_THREADS=1 bundle exec ruby -Ilib bin/puma -w 1 -t1 --preload test/rackup/hello.ru ``` ``` $ wrk -H 'Host: tfb-server' -H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' -H 'Connection: keep-alive' --latency -d 15 -c 16 --timeout 8 -t 12 http://localhost:9292 Running 15s test @ http://localhost:9292 12 threads and 16 connections Thread Stats Avg Stdev Max +/- Stdev Latency 28.89ms 40.82ms 129.37ms 78.94% Req/Sec 207.34 64.09 252.00 70.70% Latency Distribution 50% 212.00us 75% 56.77ms 90% 99.48ms 99% 127.01ms 34365 requests in 15.03s, 2.52MB read Requests/sec: 2287.13 Transfer/sec: 171.45KB ``` (Notice the dramatic drop in requests per second). -- https://bugs.ruby-lang.org/

8 12

[ruby-core:123642] [Ruby Bug#13671] Regexp with lookbehind and case-insensitivity raises RegexpError only on strings with certain characters
by nagachika (Tomoyuki Chikanaga) 01 Nov '25

01 Nov '25

Issue #13671 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED to 3.2: REQUIRED, 3.3: DONE, 3.4: REQUIRED ruby_3_3 commit:f0feca1a8495eba2706a7914f0c4f8128c281366. ---------------------------------------- Bug #13671: Regexp with lookbehind and case-insensitivity raises RegexpError only on strings with certain characters https://bugs.ruby-lang.org/issues/13671#change-115026 * Author: dschweisguth (Dave Schweisguth) * Status: Closed * Assignee: duerst (Martin Dürst) * ruby -v: 2.4.1 * Backport: 3.2: REQUIRED, 3.3: DONE, 3.4: REQUIRED ---------------------------------------- Here is a test program: ~~~ ruby def test(description) begin yield puts "#{description} is OK" rescue RegexpError puts "#{description} raises RegexpError" end end test("ass, case-insensitive, special") { /(?<!ass)/i =~ '✨' } test("bss, case-insensitive, special") { /(?<!bss)/i =~ '✨' } test("as, case-insensitive, special") { /(?<!as)/i =~ '✨' } test("ss, case-insensitive, special") { /(?<!ss)/i =~ '✨' } test("ass, case-sensitive, special") { /(?<!ass)/ =~ '✨' } test("ass, case-insensitive, regular") { /(?<!ass)/i =~ 'x' } ~~~ Running the test program with Ruby 2.4.1 (macOS) gives ~~~ ass, case-insensitive, special raises RegexpError bss, case-insensitive, special raises RegexpError as, case-insensitive, special is OK ss, case-insensitive, special is OK ass, case-sensitive, special is OK ass, case-insensitive, regular is OK ~~~ The RegexpError is "invalid pattern in look-behind: /(?<!ass)/i (RegexpError)" Side note: in the real code in which I found this error I was able to work around the error by using (?i) after the lookbehind instead of //i. Running the test program with Ruby 2.3.4 does not report any RegexpErrors. I think this is a regression, although I might be wrong and it might be saving me from an incorrect result with certain strings. ---Files-------------------------------- test.rb (531 Bytes) -- https://bugs.ruby-lang.org/

1 0