Closed akorchyn closed 1 month ago
@akorchyn Thank you for your contribution! Your pull request is now a part of the Race of Sloths! Weekly streak is on the road, smart strategy! Secure your streak with another PR!
[
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 71.59%. Comparing base (
0e7df47
) to head (5f856a4
). Report is 1 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@akhi3030 can you re-add to the merge queue?
🥁 Score it!
@frol, please score the PR with @race-of-sloths score [1/2/3/5/8/13]
. The contributor deserves it.
If no scoring is provided within 24 hours, this PR will be scored as 2 🦥
@race-of-sloths score 8
The fix seems reasonable. We do indeed have a problem where each individual invocation of the runtime will operate with a brand new Engine
, but where we also kind-of need to use the original engine with which a loaded-and-cached module has been created.
It might make a ton of sense to re-use the same engine for everything, but since the engine holds onto things like all the types it has ever seen, that would lead to eventually unbounded memory growth. The reason why we're seeing type mismatches here is exactly because the module instance most likely references types by indices into engine somewhere...
Thank you. However, I still feel weird about how these engines differ. As we load from cache with the engine from the State and the Module::deserialize seems to be clone Arc under the hood, so they should be the same (inside the Engine and inside the State), but it's not really true :( Maybe there is some issue on the library level ...
Resolves: #12062
This PR resolves the issue with the wasmtime function type incompatibility. To understand the issue, I highly recommend my investigation comments on the issue itself: https://github.com/near/nearcore/issues/12062
To be honest, I'm not sure it's a proper fix as I guess the root cause of the issue is somewhere outside of the file that leads to running under different engines/settings, leading to instantiating failures. It's a bit weird that the WasmtimeVM instance and Module instance could be different somehow as wasmtime::Engine is an arc wrapper. And module seems to clone it inside which should be still the same instance.
I could reproduce the issue only by tweaking the code manually by recreating an engine before the linking. It means that something more complex happens and we need a test on that
But this fix resolves an issue reported by #12062: https://github.com/near/near-workspaces-rs/actions/runs/10835958697/job/30200440749
CC @race-of-sloths