Fix data race on heap_pages.sorted in rb_gc_register_mark_objectHEADmaster

rb_gc_register_mark_object() called rb_gc_impl_pointer_to_heap_p()
without holding the VM lock. The lookup bsearches over
objspace->heap_pages.sorted, but another ractor allocating heap pages
mutates the darray (rb_darray_insert_without_gc() may realloc it) while
holding only the VM lock, so a lock-free reader can see a freed buffer
or shifting elements and crash.

This was observed as a SIGSEGV in TestDateParseRactor#test_date_ractor
(https://ci.rvm.jp/results/trunk@ruby-sp3/6376053): Date._parse lazily
compiles its regexps and registers them via rb_gc_register_mark_object()
while another ractor is running:

  TestDateParseRactor#test_date_ractor
  [/tmp/ruby/src/trunk/test/date/test_date_ractor.rb:23]:
  pid 2314823 killed by SIGSEGV (signal 11) (core dumped)

  -:14: [BUG] Segmentation fault at 0x00005572f0a47eb8
  ruby 4.1.0dev (2026-06-12T03:56:20Z master fe5d317d74) +PRISM [x86_64-linux]

  -- C level backtrace information (excerpt) --
  libruby.so.4.1(ptr_in_page_body_p+0x0) [0x7ab6a0db0c8c]
      /usr/include/x86_64-linux-gnu/bits/stdlib-bsearch.h:31
  libruby.so.4.1(bsearch) /usr/include/x86_64-linux-gnu/bits/stdlib-bsearch.h:33
  libruby.so.4.1(heap_page_for_ptr) gc/default/default.c:2760
  libruby.so.4.1(is_pointer_to_heap) gc/default/default.c:2787
  libruby.so.4.1(rb_gc_impl_pointer_to_heap_p)
  libruby.so.4.1(rb_gc_register_mark_object)
  date_core.so(regcomp+0x26) [0x7ab6864183a6]
  date_core.so(date__parse)
  date_core.so(date_s__parse+0xa) [0x7ab68640f902]
  date_core.so(date_s_parse)

Take the VM lock around the lookup. All writers of heap_pages.sorted
already run under the VM lock (or the VM barrier), so this is
sufficient, and the lock is recursive so the nested locking in
rb_vm_register_global_object() is fine.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions