While I was pondering about #2051 I recalled that the current wasm executor doesn't restore the stack pointer global. So I am writing it here for making sure that we solve this problem.

Basically, at the moment we are trying to reuse the same wasm instance for multiple invocations and trying to restore it after we done with each invocation. We are trying to restore the memory contents after execution, however, we are not restoring global variables and tables. The latter is OK since we don't perform any changes to it (at the moment of writing).
However, some globals are actually changes: the stack pointer.

The stack pointer is usually used as something like this:

1. At the start of execution it is always* equals 0.
2. Call into the runtime is performed.
3. When throughout execution any function requires to place some data on stack, a stack frame is allocated, meaning the value of the stack pointer is decreased (stacks grow downwards in wasm). Before the function returns it increases the stack pointer to the last value.
4. When the last function returns, the function should* return the stack pointer to 0.

There is one big catch to the above though:

* - this is the case only if the execution returned successfully.

In other words, if execution of the runtime trapped then the stack pointer won't get back to its initial value. This doesn't completely corrupt the wasm instance, but rather effectively decrease the amount of stack space available. This is also non-deterministic, since:

• if you restart the node, it will get back to normal
• the trap can happen while execution of RPC

The solution for this is to reset all global values to their initial states.

The test case I think would be:

1. Write a runtime function that allocates considerable amount of stack space, let's say a bit more than half of the available space (by default it is set to 1MB), and then traps if some input parameter equals to some specific value.
2. Call into this runtime function so that it traps. This should fail and consume a little bit more than half of the available stack space.
3. Call into the same function but it should not trap. If the bug is present this should fail as well, otherwise it should succeed.