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

[ruby-core:120736] [Ruby master Feature#21047] Change `*nil` to not call `nil.to_a`, for consistency with `**nil`
by jeremyevans0 (Jeremy Evans) 19 Jan '25

19 Jan '25

Issue #21047 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21047: Change `*nil` to not call `nil.to_a`, for consistency with `**nil` https://bugs.ruby-lang.org/issues/21047 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- In Ruby 3.3, we started accepting `**nil` for keyword splats. This does not call `nil.to_hash`, unlike other uses of `**` for splatting. This made `**nil` handling inconsistent with `*nil` handling, as `*nil` historically has called `nil.to_a`. I propose we make them consistent, by having `*nil` not call `nil.to_a`. Advantage: In addition to more consistent behavior with `**nil`, making `*nil` not call `nil.to_a` opens up new a optimization opportunity, since it allows `*nil` to be optimized to not allocate an array, similar to how `**nil` is already optimized to not allocate a hash. Disadvantage: Minor backwards compatibility breakage, though it is very unlikely any code other than test code will break, because overriding `nil.to_a` to return anything other than the empty array would likely break any large Ruby application. I've submitted a pull request to implement this: https://github.com/ruby/ruby/pull/12597 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111121] [Ruby master Bug#19165] Method (with no param) delegation with *, **, and ... is slow
by matsuda (Akira Matsuda) 16 Jan '25

16 Jan '25

Issue #19165 has been reported by matsuda (Akira Matsuda). ---------------------------------------- Bug #19165: Method (with no param) delegation with *, **, and ... is slow https://bugs.ruby-lang.org/issues/19165 * Author: matsuda (Akira Matsuda) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-12-01T08:05:41Z master 4e68b59431) +YJIT [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I found that method delegation via Forwardable is much slower than normal method call when delegating a method that does not take parameters. Here's a benchmark that explains what I mean. ``` require 'forwardable' require 'pp' require 'benchmark/ips' class Obj extend Forwardable attr_accessor :other def initialize @other = Other.new end def foo_without_splat @other.foo end def foo_with_splat(*) @other.foo(*) end def foo_with_splat_with_name(*args) @other.foo(*args) end def foo_with_splat_and_double_splat(*, **) @other.foo(*, **) end def foo_with_triple_dots(...) @other.foo(...) end delegate :foo => :@other end class Other def foo() end end o = Obj.new Benchmark.ips do |x| x.report 'simple call' do o.other.foo end x.report 'delegate without splat' do o.foo_without_splat end x.report 'delegate with splat' do o.foo_with_splat end x.report 'delegate with splat with name' do o.foo_with_splat_with_name end x.report 'delegate with splat and double splat' do o.foo_with_splat_and_double_splat end x.report 'delegate with triple dots' do o.foo_with_triple_dots end x.report 'delegate via forwardable' do o.foo end end (result) simple call 38.918M (± 0.9%) i/s - 194.884M delegate without splat 31.933M (± 1.6%) i/s - 159.611M delegate with splat 10.269M (± 1.6%) i/s - 51.631M delegate with splat with name 9.888M (± 1.0%) i/s - 49.588M delegate with splat and double splat 4.117M (± 0.9%) i/s - 20.696M delegate with triple dots 4.169M (± 0.9%) i/s - 20.857M delegate via forwardable 9.204M (± 2.1%) i/s - 46.295M ``` It shows that Method delegation with a splat is 3-4 times slower (regardless of whether the parameter is named or not), and delegation with a triple-dot literal is 9-10 times slower than a method delegation without an argument. This may be because calling a method taking a splat always assigns an Array object even when no actual argument was given, and calling a method taking triple-dots assigns five Array objects and two Hash objects (this is equivalent to `*, **`). Are there any chance reducing these object assignments and making them faster? My concern is that the Rails framework heavily uses this kind of method delegations, and presumably it causes unignorable performance overhead. -- https://bugs.ruby-lang.org/

6 8

[ruby-core:120716] [Ruby master Bug#18613] Voluntary wanted: Some signal-related tests fail on FreeBSD 13
by hs (Hideki Sakamoto) 16 Jan '25

16 Jan '25

Issue #18613 has been updated by hs (Hideki Sakamoto). File patch-test_io_console_test__io__console.rb added File patch-test_ruby_test__thread__queue.rb added File patch-test_ruby_test__thread.rb added I apologize if my comment on the closed ticket is inappropriate. By the way, these bugs seem to have been fixed in FreeBSD 13.4 (or 13.3). I applied the attached patch to the Ruby 3.4.1 source and tried "make test-all" dozens of times in FreeBSD 13.4(while checking #21045), but the error no longer reappeared. <pre> % tar xf ruby-3.4.1.tar.xz % cd ruby-3.4.1/ % patch < patch-test_io_console_test__io__console.rb % patch < patch-test_ruby_test__thread.rb % patch < patch-test_ruby_test__thread__queue.rb % ./configure % make % make test-all </pre> While not a direct reference, a bug report similar to this bug has been reported in FreeBSD Bugzilla – [Bug 277429](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277429) and appears to have been fixed in 13.3. ---------------------------------------- Bug #18613: Voluntary wanted: Some signal-related tests fail on FreeBSD 13 https://bugs.ruby-lang.org/issues/18613#change-111549 * Author: mame (Yusuke Endoh) * Status: Feedback * Assignee: knu (Akinori MUSHA) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Some tests fail randomly on FreeBSD 13. http://rubyci.s3.amazonaws.com/freebsd13/ruby-master/log/20220216T143001Z.f… ``` 1) Error: TestThread#test_signal_at_join: Timeout::Error: execution of assert_separately expired timeout (120 sec) pid 30743 killed by SIGABRT (signal 6) (core dumped) | /usr/home/chkbuild/chkbuild/tmp/build/20220216T143001Z/ruby/test/ruby/test_thread.rb:1390:in `test_signal_at_join' ``` http://rubyci.s3.amazonaws.com/freebsd13/ruby-master/log/20220308T023001Z.f… ``` 1) Failure: TestThreadQueue#test_thr_kill [/usr/home/chkbuild/chkbuild/tmp/build/20220308T023001Z/ruby/test/ruby/test_thread_queue.rb:175]: only 169/250 done in 60 seconds. ``` http://rubyci.s3.amazonaws.com/freebsd13/ruby-master/log/20220304T163001Z.f… ``` 1) Failure: TestIO_Console#test_intr [/usr/home/chkbuild/chkbuild/tmp/build/20220304T163001Z/ruby/test/io/console/test_io_console.rb:387]: <"25"> expected but was <"-e:12:in `p': \e[1mexecution expired (\e[1;4mTimeout::Error\e[m\e[1m)\e[m">. ``` All of the tests is related to signals. I guess something around signals has changed in FreeBSD 13, but I'm unsure. The failure occurs at high frequency in CI, but rarely does on my FreeBSD shell. We need to investigate what happens. @knu is the platform maintainer for FreeBSD but he is busy. Contribution who is familiar with FreeBSD is welcome. To make it easy to monitor the CI results, I tentatively skipped the three tests on FreeBSD https://github.com/ruby/ruby/commit/17e09f033c4d3b786672ba16d2c5d935482a2fad . If you investigate the issue on FreeBSD, please delete test/excludes/TestThread.rb and test/excludes/TestThreadQueue.rb, and remove the guard in test/io/console/test_io_console.rb. ---Files-------------------------------- patch-test_io_console_test__io__console.rb (508 Bytes) patch-test_ruby_test__thread__queue.rb (276 Bytes) patch-test_ruby_test__thread.rb (337 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120703] [Ruby master Feature#21041] Enum class
by dsisnero (Dominic Sisneros) 15 Jan '25

15 Jan '25

Issue #21041 has been reported by dsisnero (Dominic Sisneros). ---------------------------------------- Feature #21041: Enum class https://bugs.ruby-lang.org/issues/21041 * Author: dsisnero (Dominic Sisneros) * Status: Open ---------------------------------------- Enumerations (Enums) represent a critical abstraction in modern software design, offering significant advantages in type safety, code readability, and system-wide consistency. Most contemporary programming ecosystems—including Java, C#, Python, and Kotlin—provide native enum support, recognizing their fundamental value in representing finite, well-defined sets of values. Beyond basic type definition, enums are increasingly central to interoperability across serialization frameworks. Industry-standard specifications like OpenAPI, Protocol Buffers, and gRPC leverage enums as a canonical way to define constrained value sets, enabling robust code generation and cross-platform compatibility. Implementing a comprehensive Enum class would: - Standardize constant representation - Facilitate seamless code portability - Enable automatic code generation for documentation and client libraries - Enhance type safety and compile-time validation - Improve developer productivity through clear, self-documenting code structures By adopting a robust enum implementation, we can align our development practices with contemporary software engineering principles, reducing complexity and increasing overall system reliability. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120696] [Ruby master Bug#21040] String#next! method does not mutate $& variable
by radarek 15 Jan '25

15 Jan '25

Issue #21040 has been reported by radarek (Radosław Bułat). ---------------------------------------- Bug #21040: String#next! method does not mutate $& variable https://bugs.ruby-lang.org/issues/21040 * Author: radarek (Radosław Bułat) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `String#next!` method should mutate string and return mutated version. For some reason, using it on `$&` does not mutate it but still returns new version. Steps to reproduce (2 different ways): ```ruby "123".gsub(/./){$&.next!} # returns "234" as expected "123".gsub(/./){$&.next!;$&} # returns "123" but should be "234" "123".gsub(/./){_1.next!;_1} # returns "234" as expected "123"[/./] puts $&. # prints 1 puts $&.next! # prints 2 puts $& # prints 1 but should be 2 ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120223] [Ruby master Bug#20950] Use-after-free in ep in Proc#dup for ifunc procs
by peterzhu2118 (Peter Zhu) 15 Jan '25

15 Jan '25

Issue #20950 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #20950: Use-after-free in ep in Proc#dup for ifunc procs https://bugs.ruby-lang.org/issues/20950 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: WONTFIX, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/12319 ifunc proc has the ep allocated in the data of the TypedData object. If an ifunc proc is duplicated, the ep points to the ep of the source object. If the source object is freed, then the ep of the duplicated object now points to a freed memory region. If we try to use the ep we could crash. For example, the following script crashes: ```ruby p = { a: 1 }.to_proc 100.times do p = p.dup GC.start p.call rescue ArgumentError end ``` This commit changes ifunc proc to also duplicate the ep when it is duplicated. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120058] [Ruby master Bug#20924] IO#readline ignores the limit argument when the encoding is UTF-32LE and the limit would split a character
by javanthropus (Jeremy Bopp) 15 Jan '25

15 Jan '25

Issue #20924 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20924: IO#readline ignores the limit argument when the encoding is UTF-32LE and the limit would split a character https://bugs.ruby-lang.org/issues/20924 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.4.0dev (2024-11-28T12:38:16Z master 3af1a04741) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'tempfile' Tempfile.open(binmode: true, encoding: 'utf-32le') do |f| f.write('0123456789') f.rewind # A limit that would truncate a character becomes completely ignored f.readline(3).bytesize # => 40; should be 4 end Tempfile.open(binmode: true, encoding: 'utf-32le') do |f| f.write('0123456789') f.rewind # A limit on character boundaries is respected f.readline(4).bytesize # => 4 end Tempfile.open(encoding: 'utf-8:utf-32le') do |f| f.write('0123456789') f.rewind # A limit that would truncate a character becomes completely ignored f.readline(3).bytesize # => 40; should be 4 end Tempfile.open(encoding: 'utf-8:utf-32le') do |f| f.write('0123456789') f.rewind # A limit on character boundaries is respected f.readline(4).bytesize # => 4 end ``` This doesn't happen with UTF-32BE. This also doesn't happen in Ruby 3.3, but it does happen in 3.4-dev and Ruby 3.0 - 3.2. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120048] [Ruby master Bug#20921] Use-after-free in constant cache
by peterzhu2118 (Peter Zhu) 15 Jan '25

15 Jan '25

Issue #20921 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #20921: Use-after-free in constant cache https://bugs.ruby-lang.org/issues/20921 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: DONTNEED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/12203 When we create a cache entry for a constant, the following sequence of events could happen: - vm_track_constant_cache is called to insert a constant cache. - In vm_track_constant_cache, we first look up the ST table for the ID of the constant. Assume the ST table exists because another iseq also holds a cache entry for this ID. - We then insert into this ST table with the iseq_inline_constant_cache. - However, while inserting into this ST table, it allocates memory, which could trigger a GC. Assume that it does trigger a GC. - The GC frees the one and only other iseq that holds a cache entry for this ID. - In remove_from_constant_cache, it will appear that the ST table is now empty because there are no more iseq with cache entries for this ID, so we free the ST table. - We complete GC and continue our st_insert. However, this ST table has been freed so we now have a use-after-free. This issue is very hard to reproduce, because it requires that the GC runs at a very specific time. However, we can make it show up by applying this patch which runs GC right before the st_insert to mimic the st_insert triggering a GC: ```diff diff --git a/vm_insnhelper.c b/vm_insnhelper.c index 3cb23f06f0..a93998136a 100644 --- a/vm_insnhelper.c +++ b/vm_insnhelper.c @@ -6338,6 +6338,10 @@ vm_track_constant_cache(ID id, void *ic) rb_id_table_insert(const_cache, id, (VALUE)ics); } + if (id == rb_intern("MyConstant")) rb_gc(); + st_insert(ics, (st_data_t) ic, (st_data_t) Qtrue); } ``` And if we run this script: ```ruby Object.const_set("MyConstant", "Hello!") my_proc = eval("-> { MyConstant }") my_proc.call my_proc = eval("-> { MyConstant }") my_proc.call ``` We can see that ASAN outputs a use-after-free error: ``` ==36540==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000049528 at pc 0x000102f3ceac bp 0x00016d607a70 sp 0x00016d607a68 READ of size 8 at 0x606000049528 thread T0 #0 0x102f3cea8 in do_hash st.c:321 #1 0x102f3ddd0 in rb_st_insert st.c:1132 #2 0x103140700 in vm_track_constant_cache vm_insnhelper.c:6345 #3 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #4 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #5 0x1030bc1e0 in vm_exec_core insns.def:263 #6 0x1030b55fc in rb_vm_exec vm.c:2585 #7 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 #8 0x102a82588 in rb_ec_exec_node eval.c:281 #9 0x102a81fe0 in ruby_run_node eval.c:319 #10 0x1027f3db4 in rb_main main.c:43 #11 0x1027f3bd4 in main main.c:68 #12 0x183900270 (<unknown module>) 0x606000049528 is located 8 bytes inside of 56-byte region [0x606000049520,0x606000049558) freed by thread T0 here: #0 0x104174d40 in free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54d40) #1 0x102ada89c in rb_gc_impl_free default.c:8183 #2 0x102ada7dc in ruby_sized_xfree gc.c:4507 #3 0x102ac4d34 in ruby_xfree gc.c:4518 #4 0x102f3cb34 in rb_st_free_table st.c:663 #5 0x102bd52d8 in remove_from_constant_cache iseq.c:119 #6 0x102bbe2cc in iseq_clear_ic_references iseq.c:153 #7 0x102bbd2a0 in rb_iseq_free iseq.c:166 #8 0x102b32ed0 in rb_imemo_free imemo.c:564 #9 0x102ac4b44 in rb_gc_obj_free gc.c:1407 #10 0x102af4290 in gc_sweep_plane default.c:3546 #11 0x102af3bdc in gc_sweep_page default.c:3634 #12 0x102aeb140 in gc_sweep_step default.c:3906 #13 0x102aeadf0 in gc_sweep_rest default.c:3978 #14 0x102ae4714 in gc_sweep default.c:4155 #15 0x102af8474 in gc_start default.c:6484 #16 0x102afbe30 in garbage_collect default.c:6363 #17 0x102ad37f0 in rb_gc_impl_start default.c:6816 #18 0x102ad3634 in rb_gc gc.c:3624 #19 0x1031406ec in vm_track_constant_cache vm_insnhelper.c:6342 #20 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #21 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #22 0x1030bc1e0 in vm_exec_core insns.def:263 #23 0x1030b55fc in rb_vm_exec vm.c:2585 #24 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 #25 0x102a82588 in rb_ec_exec_node eval.c:281 #26 0x102a81fe0 in ruby_run_node eval.c:319 #27 0x1027f3db4 in rb_main main.c:43 #28 0x1027f3bd4 in main main.c:68 #29 0x183900270 (<unknown module>) previously allocated by thread T0 here: #0 0x104174c04 in malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54c04) #1 0x102ada0ec in rb_gc_impl_malloc default.c:8198 #2 0x102acee44 in ruby_xmalloc gc.c:4438 #3 0x102f3c85c in rb_st_init_table_with_size st.c:571 #4 0x102f3c900 in rb_st_init_table st.c:600 #5 0x102f3c920 in rb_st_init_numtable st.c:608 #6 0x103140698 in vm_track_constant_cache vm_insnhelper.c:6337 #7 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #8 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #9 0x1030bc1e0 in vm_exec_core insns.def:263 #10 0x1030b55fc in rb_vm_exec vm.c:2585 #11 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 #12 0x102a82588 in rb_ec_exec_node eval.c:281 #13 0x102a81fe0 in ruby_run_node eval.c:319 #14 0x1027f3db4 in rb_main main.c:43 #15 0x1027f3bd4 in main main.c:68 #16 0x183900270 (<unknown module>) ``` This commit fixes this bug by adding a inserting_constant_cache_id field to the VM, which stores the ID that is currently being inserted and, in remove_from_constant_cache, we don't free the ST table for ID equal to this one. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120031] [Ruby master Bug#20915] Segfault with `TracePoint#parameters` and aliased C method
by viralpraxis (Iaroslav Kurbatov) 15 Jan '25

15 Jan '25

Issue #20915 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #20915: Segfault with `TracePoint#parameters` and aliased C method https://bugs.ruby-lang.org/issues/20915 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: 3.3.6 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I'm getting a segfault in the following example ```ruby C = Class.new do alias_method :new_to_s, :to_s end TracePoint.new(:c_call, &:parameters).enable { C.new.new_to_s } ``` Ruby: `MRI 3.3.6`, also `ruby 3.4.0dev (2024-11-27T19:36:50Z master 7dd2afbe3a) +PRISM [x86_64-linux]` The root cause of the issue lies in the `rb_tracearg_parameters` function within the `RUBY_EVENT_C_RETURN` branch. It seems like if invoked method is aliased to C function `rb_method_entry_without_refinements(..., trace_arg->called_id, ...)`. Specifically, when the invoked method is an alias for a C function, `rb_method_entry_without_refinements(..., trace_arg->called_id, ...)` may return NULL. In that case we can fallback to `trace_arg->id`. Output: ``` [BUG] Segmentation fault at 0x0000000000000010 ruby 3.4.0dev (2024-11-27T19:36:50Z master 7dd2afbe3a) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0022 e:000021 METHOD <internal:trace_point>:333 [FINISH] c:0004 p:0006 s:0018 e:000016 BLOCK test.rb:5 [FINISH] c:0003 p:0003 s:0014 e:000013 METHOD <internal:trace_point>:265 c:0002 p:0021 s:0006 e:000005 EVAL test.rb:5 [FINISH] c:0001 p:0000 s:0003 E:001470 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:5:in '<main>' <internal:trace_point>:265:in 'enable' test.rb:5:in 'block in <main>' <internal:trace_point>:333:in 'parameters' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x0000609a79ce6f16 RBP: 0x00007ffd98dc9030 RSP: 0x00007ffd98dc9020 RAX: 0x0000000000000000 RBX: 0x0000609a7b40bdf0 RCX: 0x000000000000b6d1 RDX: 0x0000000000000000 RDI: 0x0000000000000000 RSI: 0x0000000000000b6d R8: 0x0000000000000000 R9: 0x000076e90ee24aa0 R10: 0x0000000000000001 R11: 0x0000000000000010 R12: 0x0000000000000002 R13: 0x0000000000000000 R14: 0x0000609a7b40be08 R15: 0x000076e90effeef8 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- ./ruby(0x609a79e219f7) [0x609a79e219f7] ./ruby(0x609a79e2214b) [0x609a79e2214b] ./ruby(0x609a7a02e998) [0x609a7a02e998] ./ruby(0x609a79d61811) [0x609a79d61811] /lib/x86_64-linux-gnu/libc.so.6(0x76e90f845320) [0x76e90f845320] ./ruby(0x609a79ce6f16) [0x609a79ce6f16] ./ruby(rb_tracearg_parameters+0x1a1) [0x609a79e25db2] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:943 ./ruby(tracepoint_attr_parameters+0x21) [0x609a79e26252] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:1121 ./ruby(0x609a79df8f0b) [0x609a79df8f0b] ./ruby(0x609a79df9904) [0x609a79df9904] ./ruby(0x609a79df9983) [0x609a79df9983] ./ruby(0x609a79e0147e) [0x609a79e0147e] ./ruby(0x609a79e15d9c) [0x609a79e15d9c] ./ruby(0x609a79e09991) [0x609a79e09991] ./ruby(0x609a79e091bd) [0x609a79e091bd] ./ruby(0x609a79e0ad1f) [0x609a79e0ad1f] ./ruby(0x609a79e0ba2b) [0x609a79e0ba2b] ./ruby(rb_funcall_with_block_kw) [0x609a79e0c7ef] ./ruby(0x609a79d8d877) [0x609a79d8d877] ./ruby(0x609a79df3832) [0x609a79df3832] ./ruby(0x609a79e13238) [0x609a79e13238] ./ruby(0x609a79e13888) [0x609a79e13888] ./ruby(rb_proc_call_with_block_kw) [0x609a79ce3b6a] ./ruby(rb_proc_call_with_block) [0x609a79ce3bcf] ./ruby(tp_call_trace+0x8d) [0x609a79e2641c] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:1188 ./ruby(exec_hooks_body+0x114) [0x609a79e245d7] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:354 ./ruby(exec_hooks_protected+0x166) [0x609a79e24838] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:401 ./ruby(rb_exec_event_hooks+0x12d) [0x609a79e249e2] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:446 ./ruby(0x609a79ddbefe) [0x609a79ddbefe] ./ruby(0x609a79deef34) [0x609a79deef34] ./ruby(0x609a79def260) [0x609a79def260] ./ruby(0x609a79def38d) [0x609a79def38d] ./ruby(0x609a79def7d4) [0x609a79def7d4] ./ruby(0x609a79df243b) [0x609a79df243b] ./ruby(0x609a79df0646) [0x609a79df0646] ./ruby(0x609a79df2c0d) [0x609a79df2c0d] ./ruby(0x609a79df2ee7) [0x609a79df2ee7] ./ruby(0x609a79df30e9) [0x609a79df30e9] ./ruby(0x609a79df580a) [0x609a79df580a] ./ruby(0x609a79dfd8dd) [0x609a79dfd8dd] ./ruby(0x609a79e15d9c) [0x609a79e15d9c] ./ruby(0x609a79e12a8c) [0x609a79e12a8c] ./ruby(0x609a79e12c48) [0x609a79e12c48] ./ruby(0x609a79e12c86) [0x609a79e12c86] ./ruby(0x609a79e0cc8c) [0x609a79e0cc8c] ./ruby(rb_yield) [0x609a79e0cce0] ./ruby(rb_ensure) [0x609a79c20ea4] ./ruby(tracepoint_enable_m+0x1a5) [0x609a79e26c05] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:1414 ./ruby(0x609a79df8fd7) [0x609a79df8fd7] ./ruby(0x609a79df9904) [0x609a79df9904] ./ruby(0x609a79df99d1) [0x609a79df99d1] ./ruby(0x609a79e01583) [0x609a79e01583] ./ruby(0x609a79e15d9c) [0x609a79e15d9c] ./ruby(rb_iseq_eval_main) [0x609a79e16bcb] ./ruby(0x609a79c1f112) [0x609a79c1f112] ./ruby(ruby_run_node) [0x609a79c1f283] ./ruby(0x609a79c1aae4) [0x609a79c1aae4] ./ruby(0x609a79c1ab45) [0x609a79c1ab45] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x7a) [0x76e90f82a1ca] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x76e90f82a28b] ../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 [0x609a79c1a9c5] -- Other runtime information ----------------------------------------------- * Loaded script: test.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120006] [Ruby master Bug#20909] Backport String indexing bug fixes
by nobu (Nobuyoshi Nakada) 15 Jan '25

15 Jan '25

Issue #20909 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20909: Backport String indexing bug fixes https://bugs.ruby-lang.org/issues/20909 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- commit:02b70256b5171d4b85ea7eeab836d3d7cfb3dbfc commit:6b4f8945d600168bf530d21395da8293fbd5e8ba -- https://bugs.ruby-lang.org/

3 2