During compilation, we write keyword default values into the iseq, so we
should mark it to ensure it does not get GC'd.

This might fix issues on ASAN like
http://ci.rvm.jp/logfiles/brlog.trunk_asan.20240927-194923

    ==805257==ERROR: AddressSanitizer: use-after-poison on address 0x7b7e5e3e2828 at pc 0x5e09ac4822f8 bp 0x7ffde56b0140 sp 0x7ffde56b0138
    READ of size 8 at 0x7b7e5e3e2828 thread T0
    #0 0x5e09ac4822f7 in RB_BUILTIN_TYPE include/ruby/internal/value_type.h:191:30
    #1 0x5e09ac4822f7 in rbimpl_RB_TYPE_P_fastpath include/ruby/internal/value_type.h:352:19
    #2 0x5e09ac4822f7 in gc_mark gc/default.c:4488:9
    #3 0x5e09ac51011e in rb_iseq_mark_and_move iseq.c:361:17
    ruby#4 0x5e09ac4b85c4 in rb_imemo_mark_and_move imemo.c:386:9
    ruby#5 0x5e09ac467544 in rb_gc_mark_children gc.c:2508:9
    ruby#6 0x5e09ac482c24 in gc_mark_children gc/default.c:4673:5
    ruby#7 0x5e09ac482c24 in gc_mark_stacked_objects gc/default.c:4694:9
    ruby#8 0x5e09ac482c24 in gc_mark_stacked_objects_all gc/default.c:4732:12
    ruby#9 0x5e09ac48c7f9 in gc_marks_rest gc/default.c:5755:9
    ruby#10 0x5e09ac48c7f9 in gc_marks gc/default.c:5870:9
    ruby#11 0x5e09ac48c7f9 in gc_start gc/default.c:6517:13

fill_lines is passed -1 for offset, which causes it to read the -1 index
of traces. This is not valid memory as -1 is reading before the trace
global variable in rb_print_backtrace. This code comes from commit
99d1f5f, where there used to be special
handling for the -1 index.

We can see this error in ASAN:

    ==71037==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00010157abf8 at pc 0x00010116f3b8 bp 0x00016f92c3b0 sp 0x00016f92c3a8
    READ of size 8 at 0x00010157abf8 thread T0
        #0 0x10116f3b4 in debug_info_read addr2line.c:1945
        #1 0x10116cc90 in fill_lines addr2line.c:2497
        #2 0x101169dbc in rb_dump_backtrace_with_lines addr2line.c:2635
        #3 0x100e56788 in rb_print_backtrace vm_dump.c:825
        ruby#4 0x100e56db4 in rb_vm_bugreport vm_dump.c:1155
        ruby#5 0x100734dc4 in rb_bug_without_die error.c:1085
        ruby#6 0x100734ae4 in rb_bug error.c:109

[Bug #20921]

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

    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
        ruby#4 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424
        ruby#5 0x1030bc1e0 in vm_exec_core insns.def:263
        ruby#6 0x1030b55fc in rb_vm_exec vm.c:2585
        ruby#7 0x1030fe0ac in rb_iseq_eval_main vm.c:2851
        ruby#8 0x102a82588 in rb_ec_exec_node eval.c:281
        ruby#9 0x102a81fe0 in ruby_run_node eval.c:319
        ruby#10 0x1027f3db4 in rb_main main.c:43
        ruby#11 0x1027f3bd4 in main main.c:68
        ruby#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
        ruby#4 0x102f3cb34 in rb_st_free_table st.c:663
        ruby#5 0x102bd52d8 in remove_from_constant_cache iseq.c:119
        ruby#6 0x102bbe2cc in iseq_clear_ic_references iseq.c:153
        ruby#7 0x102bbd2a0 in rb_iseq_free iseq.c:166
        ruby#8 0x102b32ed0 in rb_imemo_free imemo.c:564
        ruby#9 0x102ac4b44 in rb_gc_obj_free gc.c:1407
        ruby#10 0x102af4290 in gc_sweep_plane default.c:3546
        ruby#11 0x102af3bdc in gc_sweep_page default.c:3634
        ruby#12 0x102aeb140 in gc_sweep_step default.c:3906
        ruby#13 0x102aeadf0 in gc_sweep_rest default.c:3978
        ruby#14 0x102ae4714 in gc_sweep default.c:4155
        ruby#15 0x102af8474 in gc_start default.c:6484
        ruby#16 0x102afbe30 in garbage_collect default.c:6363
        ruby#17 0x102ad37f0 in rb_gc_impl_start default.c:6816
        ruby#18 0x102ad3634 in rb_gc gc.c:3624
        ruby#19 0x1031406ec in vm_track_constant_cache vm_insnhelper.c:6342
        #20 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356
        ruby#21 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424
        ruby#22 0x1030bc1e0 in vm_exec_core insns.def:263
        ruby#23 0x1030b55fc in rb_vm_exec vm.c:2585
        ruby#24 0x1030fe0ac in rb_iseq_eval_main vm.c:2851
        ruby#25 0x102a82588 in rb_ec_exec_node eval.c:281
        ruby#26 0x102a81fe0 in ruby_run_node eval.c:319
        ruby#27 0x1027f3db4 in rb_main main.c:43
        ruby#28 0x1027f3bd4 in main main.c:68
        ruby#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
        ruby#4 0x102f3c900 in rb_st_init_table st.c:600
        ruby#5 0x102f3c920 in rb_st_init_numtable st.c:608
        ruby#6 0x103140698 in vm_track_constant_cache vm_insnhelper.c:6337
        ruby#7 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356
        ruby#8 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424
        ruby#9 0x1030bc1e0 in vm_exec_core insns.def:263
        ruby#10 0x1030b55fc in rb_vm_exec vm.c:2585
        ruby#11 0x1030fe0ac in rb_iseq_eval_main vm.c:2851
        ruby#12 0x102a82588 in rb_ec_exec_node eval.c:281
        ruby#13 0x102a81fe0 in ruby_run_node eval.c:319
        ruby#14 0x1027f3db4 in rb_main main.c:43
        ruby#15 0x1027f3bd4 in main main.c:68
        ruby#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.

Co-Authored-By: Alan Wu <alanwu@ruby-lang.org>

When searching for native extensions, if the name does not end in ".so"
then we create a new string and append ".so" so it. If the native extension
is in static_ext_inits, then we could trigger a GC in the rb_filesystem_str_new_cstr.
This could cuase the GC to free lookup_name since we don't use the local
variable anymore.

This bug was caught in this ASAN build:
http://ci.rvm.jp/results/trunk_asan@ruby-sp1/5479182

    ==435614==ERROR: AddressSanitizer: use-after-poison on address 0x715a63022da0 at pc 0x5e7463873e4e bp 0x7fff383c8b00 sp 0x7fff383c82c0
    READ of size 14 at 0x715a63022da0 thread T0
        #0 0x5e7463873e4d in __asan_memcpy (/tmp/ruby/build/trunk_asan/ruby+0x214e4d) (BuildId: 607411c0626a2f66b4c20c02179b346aace20898)
        #1 0x5e7463b50a82 in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10
        #2 0x5e7463b50a82 in ruby_nonempty_memcpy /tmp/ruby/src/trunk_asan/include/ruby/internal/memory.h:671:16
        #3 0x5e7463b50a82 in str_enc_new /tmp/ruby/src/trunk_asan/string.c:1035:9
        ruby#4 0x5e74639b97dd in search_required /tmp/ruby/src/trunk_asan/load.c:1126:21
        ruby#5 0x5e74639b97dd in require_internal /tmp/ruby/src/trunk_asan/load.c:1274:17
        ruby#6 0x5e74639b83c1 in rb_require_string_internal /tmp/ruby/src/trunk_asan/load.c:1401:22
        ruby#7 0x5e74639b83c1 in rb_require_string /tmp/ruby/src/trunk_asan/load.c:1387:12

	Fix use-after-free in constant cache

	[Bug #20921]

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

	    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
	        ruby#4 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424
	        ruby#5 0x1030bc1e0 in vm_exec_core insns.def:263
	        ruby#6 0x1030b55fc in rb_vm_exec vm.c:2585
	        ruby#7 0x1030fe0ac in rb_iseq_eval_main vm.c:2851
	        ruby#8 0x102a82588 in rb_ec_exec_node eval.c:281
	        ruby#9 0x102a81fe0 in ruby_run_node eval.c:319
	        ruby#10 0x1027f3db4 in rb_main main.c:43
	        ruby#11 0x1027f3bd4 in main main.c:68
	        ruby#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
	        ruby#4 0x102f3cb34 in rb_st_free_table st.c:663
	        ruby#5 0x102bd52d8 in remove_from_constant_cache iseq.c:119
	        ruby#6 0x102bbe2cc in iseq_clear_ic_references iseq.c:153
	        ruby#7 0x102bbd2a0 in rb_iseq_free iseq.c:166
	        ruby#8 0x102b32ed0 in rb_imemo_free imemo.c:564
	        ruby#9 0x102ac4b44 in rb_gc_obj_free gc.c:1407
	        ruby#10 0x102af4290 in gc_sweep_plane default.c:3546
	        ruby#11 0x102af3bdc in gc_sweep_page default.c:3634
	        ruby#12 0x102aeb140 in gc_sweep_step default.c:3906
	        ruby#13 0x102aeadf0 in gc_sweep_rest default.c:3978
	        ruby#14 0x102ae4714 in gc_sweep default.c:4155
	        ruby#15 0x102af8474 in gc_start default.c:6484
	        ruby#16 0x102afbe30 in garbage_collect default.c:6363
	        ruby#17 0x102ad37f0 in rb_gc_impl_start default.c:6816
	        ruby#18 0x102ad3634 in rb_gc gc.c:3624
	        ruby#19 0x1031406ec in vm_track_constant_cache vm_insnhelper.c:6342
	        #20 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356
	        ruby#21 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424
	        ruby#22 0x1030bc1e0 in vm_exec_core insns.def:263
	        ruby#23 0x1030b55fc in rb_vm_exec vm.c:2585
	        ruby#24 0x1030fe0ac in rb_iseq_eval_main vm.c:2851
	        ruby#25 0x102a82588 in rb_ec_exec_node eval.c:281
	        ruby#26 0x102a81fe0 in ruby_run_node eval.c:319
	        ruby#27 0x1027f3db4 in rb_main main.c:43
	        ruby#28 0x1027f3bd4 in main main.c:68
	        ruby#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
	        ruby#4 0x102f3c900 in rb_st_init_table st.c:600
	        ruby#5 0x102f3c920 in rb_st_init_numtable st.c:608
	        ruby#6 0x103140698 in vm_track_constant_cache vm_insnhelper.c:6337
	        ruby#7 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356
	        ruby#8 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424
	        ruby#9 0x1030bc1e0 in vm_exec_core insns.def:263
	        ruby#10 0x1030b55fc in rb_vm_exec vm.c:2585
	        ruby#11 0x1030fe0ac in rb_iseq_eval_main vm.c:2851
	        ruby#12 0x102a82588 in rb_ec_exec_node eval.c:281
	        ruby#13 0x102a81fe0 in ruby_run_node eval.c:319
	        ruby#14 0x1027f3db4 in rb_main main.c:43
	        ruby#15 0x1027f3bd4 in main main.c:68
	        ruby#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.

	Co-Authored-By: Alan Wu <alanwu@ruby-lang.org>