- ruby-core - ml.ruby-lang.org

[ruby-core:120745] [Ruby master Bug#14582] Unable to use `method__entry` and `method_return` tracing probes since 2.5
by jacobcarlborg (Jacob Carlborg) 20 Jan '25

20 Jan '25

Issue #14582 has been updated by jacobcarlborg (Jacob Carlborg). I'm really interested in using DTrace on Ruby as well. One of the major advantages of DTrace is that it's always available and doesn't require any code changes or restarts of the system that is being instrumented. But with the current way that USDT probes are implemented in Ruby it defeats many of the advantages of DTrace. ---------------------------------------- Bug #14582: Unable to use `method__entry` and `method_return` tracing probes since 2.5 https://bugs.ruby-lang.org/issues/14582#change-111578 * Author: guilhermereiscampos (Guilherme Reis Campos) * Status: Open * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Hi, I am trying to use dtrace/systemtap probes and not being able to use it after the 2.5. The 2.4 version works fine. I was hoping this was fixed on 2.6-preview, but apparently not (just downloaded dev and tested). I tried on OSX using dtrace and also on ubuntu (vagrant). ``` # test.rb class Foo def bar 100.times { "Bar" } end end foo = Foo.new foo.bar # test.stp probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__entry") # you will need to change this to your ruby path of your version. { printf("%s => %s.%s in %s:%d\n", thread_indent(1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__return") { printf("%s <= %s.%s in %s:%d\n", thread_indent(-1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } ``` dtrace was something similar to it. I was expecting to see this output: ``` # lots of calls # .... # then: 4090 ruby(9667): <= Gem::Specification.unresolved_deps in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/specification.rb:1298 4095 ruby(9667): => MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:197 4100 ruby(9667): => MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:247 4104 ruby(9667): <= MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:251 4109 ruby(9667): <= MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:204 4283 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 4303 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 0 ruby(9667): => Foo.bar in test.rb:3 16 ruby(9667): <= Foo.bar in test.rb:5 ``` (The output above is 2.4) my ruby (all versions that I tested) was install with rb-env: ``` RUBY_CONFIGURE_OPTS='--enable-dtrace --disable-install-doc' rbenv install 2.5.0 ``` I am happy to provide details if required. I'd also be happy to fix it if I have guidance. Thanks, -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120303] [Ruby master Bug#20965] `it` vs `binding.local_variables`
by zverok (Victor Shepelev) 20 Jan '25

20 Jan '25

Issue #20965 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20965: `it` vs `binding.local_variables` https://bugs.ruby-lang.org/issues/20965 * Author: zverok (Victor Shepelev) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED ---------------------------------------- `it` is not available in the list of `binding.local_varaibles`, **unlike** numbered parameters: ```ruby p(proc { binding.local_variables }.call) # [] p(proc { |x| binding.local_variables }.call) # [:x] p(proc { _1; binding.local_variables }.call) # [:_1] p(proc { vars = binding.local_variables; _1; vars }.call) # [:_1, :vars] p(proc { it; binding.local_variables }.call) # [] ``` I wonder if it is deliberate or accidental. -- https://bugs.ruby-lang.org/

6 9

[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) 14 Jan '25

14 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) 14 Jan '25

14 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) 14 Jan '25

14 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