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/eval.c b/eval.c
index aa0eae0872..6424aed1dc 100644
--- a/eval.c
+++ b/eval.c
@@ -70,7 +70,7 @@ ruby_setup(void)
     if (GET_VM())
         return 0;
 
-    ruby_init_stack((void *)&state);
+    ruby_init_stack(&state);
 
     /*
      * Disable THP early before mallocs happen because we want this to
@@ -79,7 +79,7 @@ ruby_setup(void)
 #if defined(__linux__) && defined(PR_SET_THP_DISABLE)
     prctl(PR_SET_THP_DISABLE, 1, 0, 0, 0);
 #endif
-    Init_BareVM();
+    Init_BareVM(&state);
     Init_heap();
     rb_vm_encoded_insn_data_table_init();
     Init_vm_objects();