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.
this can lead to some REALLY fun debugging because various code bytes/instructions get skipped, leading to wrong inputs into wrong opcodes and all sorts 💯
* wren/primitive: Remove duplicated declaration introduced in 9f64c05fa.
* wren/primitive: Allow RETURN_ERROR_FMT to have any number of arguments.
* wren/vm: Remove extra validateApiSlot in wrenGetVariable.
(The slot validation is guaranted by setSlot later in the function.)
* wren/primitive: Use RETURN_ERROR_FMT in validateFn.
* Optimize Random.sample(_, _) for performance
* Make tests treat random samples as unordered
* Test all sample sizes possible
* Tweak random sampling algorithm for performance
hashBits() is used to generate a hash code from the same 64 bits used
to represent a Wren number as a double. When building a map containing
a large number of integer keys, it's important for this to do a good
job scattering the bits across the 32-bit key space.
Alas, it does not. Worse, the benchmark to test this happens to stop
just before the performance falls off a cliff, so this was easy to
overlook.
This replaces it with the hash function V8 uses, which has much better
performance across the numeric range.
The intent of the assert is to ensure that insertEntry() is not called
with an empty entries array because that would cause you to get into a
code path where the entry output parameter is not set. But the assert
didn't correctly check that.
Fix#635.
