Pass down "stack start" variables from closer to the top of the stack

The implementation of `native_thread_init_stack` for the various
threading models can use the address of a local variable as part of the
calculation of the machine stack extents:

* pthreads uses it as a lower-bound on the start of the stack, because
  glibc (and maybe other libcs) can store its own data on the stack
  before calling into user code on thread creation.
* win32 uses it as an argument to VirtualQuery, which gets the extent of
  the memory mapping which contains the variable

However, the local being used for this is actually allocated _inside_
the `native_thread_init_stack` frame; that means the caller might
allocate a VALUE on the stack that actually lies outside the bounds
stored in machine.stack_{start,end}.

A local variable from one level above the topmost frame that stores
VALUEs on the stack must be drilled down into the call to
`native_thread_init_stack` to be used in the calculation. This probably
doesn't _really_ matter for the win32 case (they'll be in the same
memory mapping so VirtualQuery should return the same thing), but
definitely could matter for the pthreads case.

[Bug #20001]

1 files changed, 2 insertions, 2 deletions

diff --git a/vm.c b/vm.c
index 37d631116a..945e7b91f7 100644
--- a/vm.c
+++ b/vm.c
@@ -4174,7 +4174,7 @@ rb_vm_set_progname(VALUE filename)
 extern const struct st_hash_type rb_fstring_hash_type;
 
 void
-Init_BareVM(void)
+Init_BareVM(void *local_in_parent_frame)
 {
     /* VM bootstrap: phase 1 */
     rb_vm_t * vm = ruby_mimmalloc(sizeof(*vm));
@@ -4204,7 +4204,7 @@ Init_BareVM(void)
     th_init(th, 0, vm);
 
     rb_ractor_set_current_ec(th->ractor, th->ec);
-    ruby_thread_init_stack(th);
+    ruby_thread_init_stack(th, local_in_parent_frame);
 
     // setup ractor system
     rb_native_mutex_initialize(&vm->ractor.sync.lock);