summaryrefslogtreecommitdiff
path: root/spec/ruby/core/string/unpack/comment_spec.rb
diff options
context:
space:
mode:
authorKJ Tsanaktsidis <ktsanaktsidis@zendesk.com>2024-05-18 18:37:49 +0900
committerKJ Tsanaktsidis <kj@kjtsanaktsidis.id.au>2024-05-19 12:08:35 +0900
commit7afc16aa48beb093b06eb978bc430f90dd771690 (patch)
tree7e81f84267c9f94109d22dc8d31b85b4ba1b8afe /spec/ruby/core/string/unpack/comment_spec.rb
parentad636033e2fdafb417873a3cb8667351033307b1 (diff)
Inline RB_VM_SAVE_MACHINE_CONTEXT into BLOCKING_REGIONHEADmaster
There's an exhaustive explanation of this in the linked redmine bug, but the short version is as follows: blocking_region_begin can spill callee-saved registers to the stack for its own use. That means they're not saved to ec->machine by the call to setjmp, since by that point they're already on the stack and new, different values are in the real registers. ec->machine's end-of-stack pointer is also bumped to accomodate this, BUT, after blocking_region_begin returns, that points past the end of the stack! As far as C is concerned, that's fine; the callee-saved registers are restored when blocking_region_begin returns. But, if another thread triggers GC, it is relying on finding references to Ruby objects by walking the stack region pointed to by ec->machine. If the C code in exec; subsequently does things that use that stack memory, then the value will be overwritten and the GC might prematurely collect something it shouldn't. [Bug #20493]
Diffstat (limited to 'spec/ruby/core/string/unpack/comment_spec.rb')
0 files changed, 0 insertions, 0 deletions