Commits on Sep 18, 2020

1. Fix stack corruption caused by Fn call primitives …

   Excerpt from @munificent on the nature of the bug:
   
   In runInterpreter, for performance, the vm caches an IP pointing into some bytecode.
   
   All primitives except for `.call`, do not touch Wren's own callstack. They run a little C code and return, so the array of CallFrames, their IPs, and the IP cached inside run() are not affected at all.
   
   While runInterpreter() is running, the IP in the top CallFrame is not updated, so it gets out of sync. This is deliberate, since storing to a field is slow, but it means the value of that field is stale and doesn't represent where execution actually is at that point in time.
   
   To get that field in sync, we use STORE_FRAME(), which stores the local IP value back into the IP field for the top CallFrame. The interpreter is careful to always call STORE_FRAME() before executing any code that pushes a new CallFrame onto the stack.
   
   In particular, if you look around, you'll see that every place the interpreter calls wrenCallFunction() is preceded by a STORE_FRAME(). That is, except for the call to wrenCallFunction() in the call_fn() primitive. That's the bug.
   
   The .call() method on Fn is special because it does modify the Wren call stack and the C code for that primitive directly calls wrenCallFunction(). When that happens, the correct IP for the current function, which lives only in runInterpreter()'s local variable gets discarded and you're left with a stale IP in the CallFrame.
   
   Giving the function call primitives a different method type and having the case for that method type call STORE_FRAME() before invoking the primitive fixes the bug.

   

   ruby0x1 committed Sep 18, 2020
   Configuration menu

   • View commit details
   • Copy full SHA for 48a6a5f
   • Browse repository at this point

   Copy the full SHA

   48a6a5f View commit details

   Browse the repository at this point in the history