After checking a local rr recording, it's clear that the canary was
written there when YJIT was using a temporary malloc region, and then
later handed to the new Ruby thread. Previously, the VM stack was
uninitialized, so it can have stale values in it, like the canary.
Though unlikely, this can happen without YJIT too. Initialize the stack
if we're spawning canaries.
Added by alanwu (Alan Wu) about 1 year ago
Initialize VM stack if VM_CHECK_MODE
Lately there has been a few flaky YJIT CI failures where a new Ruby
thread is finding the canary on the VM stack. For example:
https://github.com/ruby/ruby/actions/runs/8287357784/job/22679508482#step:14:109
After checking a local rr recording, it's clear that the canary was
written there when YJIT was using a temporary malloc region, and then
later handed to the new Ruby thread. Previously, the VM stack was
uninitialized, so it can have stale values in it, like the canary.
Though unlikely, this can happen without YJIT too. Initialize the stack
if we're spawning canaries.