-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure that memory expansion (grow_memory) aborts on failure #177
Comments
We have discussed options of disallowing The WebAssembly spec Section 7.2 Implementation Limitations lists many more things. There are some subtle things involving recursion. |
In order to ensure non-determinism, I don't think we want OOG. It sounds strange that if we have sufficient gas for a given memory write, some clients may still throw an OOG because they are temporarily low on "physical" memory. |
The option to bound Wasm memory with gas would involve the honest majority of miners keeping the gas limit low enough so that their clients can easily handle any amount of Wasm memory that is within the gas limit. EVM uses a similar mechanism. |
It is not only the gas limit, but a combination of gas limit and gas price. There are two ways to cause memory allocation systematically fail while still not running out of gas: The variable in option b) can be influenced by the miners without a hard fork, while a) requires a hard fork. |
I mentioned in the Gitter channel that long before most systems run out of virtual memory they will thrashing so badly as to be useless. So I'm not sure this problem that is going to happen in practice. |
While the metering "spec" calls for prepending
grow_memory
with a gas check, thegrow_memory
opcode can still return a failure when enough gas is present, but not enough memory is available.@d1m0 has suggested this is an issue.
I propose that instead of only injecting a gas check,
grow_memory
should be wrapped in a special check which causes a panic (or OOG) on the client.I'm not sure what is the best behaviour (panic, OOG or something else?), but likely leaving it alone is wrong, because that gives an opportunity to the contract developer to check for the return value of
grow_memory
and create diverging behaviours.The text was updated successfully, but these errors were encountered: