8000 fix: use pwasm-utils 0.18 for more correct stack accounting by matklad · Pull Request #6051 · near/nearcore · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

fix: use pwasm-utils 0.18 for more correct stack accounting #6051

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

Merged
merged 6 commits into from
Jan 14, 2022

Conversation

matklad
Copy link
Contributor
@matklad matklad commented Jan 12, 2022

This forward-ports the change from 1.23.1

We upgrade our version of pwasm-utils -- the old one severely
undercounted stack usage in some cases. As this is a protocol change, we
keep the old implementation around

Test Plan

  • added test for stack overflow behavior for the bad case
  • added test for protocol upgrade related to stack overflow
  • fuzzed new pwasm utils implementation locally, confirmed that it only
    differs for calls which stack overflow

This forward-ports the change from 1.23.1

We upgrade our version of pwasm-utils -- the old one severely
undercounted stack usage in some cases. As this is a protocol change, we
keep the old implementation around

Test Plan
=========

* added test for stack overflow behavior for the bad case
* added test for protocol upgrade related to stack overflow
* fuzzed new pwasm utils implementation locally, confirmed that it only
  differs for calls which stack overflow
@@ -128,6 +128,9 @@ pub enum ProtocolFeature {
/// Make block producers produce chunks for the same block they would later produce to avoid
/// network delays
SynchronizeBlockChunkProduction,
/// Change the algorithm to count WASM stack usage to avoid undercounting in
/// some cases.
CorrectStackLimit,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we ever need to correct the algorithm again, it'll be hard to come up with a name for it ^^

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This name we can retroactively change in the future, as it is not serialized anywhere, so tried not to over-thing this )

@@ -31,6 +31,8 @@ pub struct VMLimitConfig {
/// See <https://wiki.parity.io/WebAssembly-StackHeight> to find out
/// how the stack frame cost is calculated.
pub max_stack_height: u32,
#[serde(default = "StackLimiterVersion::v0")]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comment - that we have different stack limiter versions (due to the bugs/issues / different pwasm version etc)

#[derive(Debug, Clone, Copy, Hash, PartialEq, Eq)]
pub enum StackLimiterVersion {
V0,
V1,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you comment on how they differ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, good call, added some comments.

@@ -181,7 +184,8 @@ impl ProtocolFeature {
| ProtocolFeature::LimitContractFunctionsNumber
| ProtocolFeature::BlockHeaderV3
| ProtocolFeature::AliasValidatorSelectionAlgorithm => 49,
ProtocolFeature::SynchronizeBlockChunkProduction => 50,
ProtocolFeature::SynchronizeBlockChunkProduction
| ProtocolFeature::CorrectStackLimit => 50,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't we use a new protocol version for this? (or was it already deployed somehow?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that was deployed as a part of 1.23.1: https://github.com/near/nearcore-ghsa-62f6-rgx9-xcw2/pull/1

let Type::Function(ref _func_ty) =
types.get(*type_idx as usize).ok_or(PrepareError::Instantiate)?;

// TODO: Function type check with Env
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

optional: I'm not a fan of 'orphaned' TODOs ;-) we should either have a github/jira issue that is tracking it (if this is a lot more complex fix), or author name + additional info on why this is complex enough that we're not fixing it in this PR.

// TODO: Function type check with Env
/*

let ext_func = env
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you need this code?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I agree that it's better to just remove wishful-thinking comments from this module. In general, every time I open this file I want to refactor it.

I'd rather not do that in the PR though, as the goal here is to change a bit of the behavior we want to change, and to hold everything else constant.

// Support for old protocol versions, where we incorrectly didn't
// account for many locals of the same type.
//
// See `test_stack_instrumentation_protocol_upgrade` test.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, there's a cool trick to make such links to tests checkable (ie, the test fails if it doesn't actually touch the relevant code): https://docs.rs/cov-mark/latest/cov_mark/.

I am still on the fence where maintaining such coverage marks helps overall.

@near-bulldozer near-bulldozer bot merged commit 5de73b0 into near:master Jan 14, 2022
posvyatokum pushed a commit that referenced this pull request Jan 14, 2022
This forward-ports the change from 1.23.1

We upgrade our version of pwasm-utils -- the old one severely
undercounted stack usage in some cases. As this is a protocol change, we
keep the old implementation around

Test Plan
=========

* added test for stack overflow behavior for the bad case
* added test for protocol upgrade related to stack overflow
* fuzzed new pwasm utils implementation locally, confirmed that it only
  differs for calls which stack overflow
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0