summaryrefslogtreecommitdiff
path: root/include/ruby/io.h
diff options
context:
space:
mode:
authorKJ Tsanaktsidis <ktsanaktsidis@zendesk.com>2024-05-29 06:17:24 +1000
committerGitHub <noreply@github.com>2024-05-28 13:17:24 -0700
commitb6c07acedb3ca56471754a082b3db20bb863c92e (patch)
tree08e33e8f3347f0b45b62ca2fc3a89975d2a628c3 /include/ruby/io.h
parent1c991f3bf40c2e506a819732dd0c4afe5d3c5f46 (diff)
Backport bug #20493 to Ruby 3.3 (#10798)
Inline RB_VM_SAVE_MACHINE_CONTEXT into BLOCKING_REGION 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 'include/ruby/io.h')
0 files changed, 0 insertions, 0 deletions