Skip to content

[move-vm] Adding negative FV tests for bytecode and runtime verifier #17147

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 4 commits into from
Jul 25, 2025

Conversation

wrwg
Copy link
Contributor

@wrwg wrwg commented Jul 23, 2025

Description

This adds a number of negatiive tests (wrong code) which are run in two ways: one with bytecode verifier enabled where we expect it to be caught in the verifier, one with bytecode verifier disabled where we expect it to be checked by paranoid mode.

One challenge with these tests is that in order to hit paranoid mode, they need to be written such that the issue is reached in an execution path, and not just by loading module code. This is why most tests are triggered via scripts supported by a helper module.

This also changes the way how the verifier is disabled by using a configuration option. The failpoints used before can't be used with parallel test execution.

How Has This Been Tested?

These are tests

Type of Change

  • New feature
  • Bug fix
  • Breaking change
  • Performance improvement
  • Refactoring
  • Dependency update
  • Documentation update
  • Tests

Which Components or Systems Does This Change Impact?

  • Validator Node
  • Full Node (API, Indexer, etc.)
  • Move/Aptos Virtual Machine
  • Aptos Framework
  • Aptos CLI/SDK
  • Developer Infrastructure
  • Move Compiler
  • Other (specify)

Copy link
Contributor Author

wrwg commented Jul 23, 2025

Copy link
Contributor

@vineethk vineethk left a comment

Choose a reason for hiding this comment

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

Minor comments. Great to have these!


pub type VMResult<T> = ::std::result::Result<T, VMError>;
pub type BinaryLoaderResult<T> = ::std::result::Result<T, PartialVMError>;
pub type PartialVMResult<T> = ::std::result::Result<T, PartialVMError>;

static STABLE_TEST_DISPLAY: Lazy<Mutex<bool>> = Lazy::new(|| Mutex::new(false));
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not OnceCell? I think it is designed exactly for this kind of config

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

wrwg and others added 4 commits July 25, 2025 13:31
This adds a number of tests (wrong code) which are run in two ways: one with bytecode verifier enabled where expect it to be caught in the verifier, one with bytecode verifier disabled where we expect it to be called by paranoid mode. One bug was discovered this far by this approach, where paranoid mode seems to miss a check (#17137).

Also changes the way how the verifier is disabled by using a configuration option. The failpoints used before can't be used with parallel test execution.
@wrwg wrwg enabled auto-merge (squash) July 25, 2025 20:32

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Copy link
Contributor

✅ Forge suite compat success on 8e7acd6f8692b1bf870e8232cb95eab97ab5b270 ==> 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a

Compatibility test results for 8e7acd6f8692b1bf870e8232cb95eab97ab5b270 ==> 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a (PR)
1. Check liveness of validators at old version: 8e7acd6f8692b1bf870e8232cb95eab97ab5b270
compatibility::simple-validator-upgrade::liveness-check : committed: 8317.94 txn/s, latency: 4057.56 ms, (p50: 4400 ms, p70: 4600, p90: 4700 ms, p99: 5000 ms), latency samples: 275400
2. Upgrading first Validator to new version: 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 2492.55 txn/s, latency: 13543.08 ms, (p50: 14900 ms, p70: 15400, p90: 15900 ms, p99: 16000 ms), latency samples: 93220
3. Upgrading rest of first batch to new version: 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 2460.06 txn/s, latency: 13710.92 ms, (p50: 15100 ms, p70: 15600, p90: 16100 ms, p99: 16200 ms), latency samples: 92980
4. upgrading second batch to new version: 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 4309.83 txn/s, latency: 7899.30 ms, (p50: 8700 ms, p70: 9000, p90: 9500 ms, p99: 9800 ms), latency samples: 150840
5. check swarm health
Compatibility test for 8e7acd6f8692b1bf870e8232cb95eab97ab5b270 ==> 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a passed
Test Ok

Copy link
Contributor

✅ Forge suite realistic_env_max_load success on 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a

two traffics test: inner traffic : committed: 11415.05 txn/s, submitted: 11415.26 txn/s, expired: 0.21 txn/s, latency: 3302.28 ms, (p50: 3300 ms, p70: 3300, p90: 3600 ms, p99: 4500 ms), latency samples: 4340460
two traffics test : committed: 99.98 txn/s, latency: 850.37 ms, (p50: 800 ms, p70: 900, p90: 900 ms, p99: 2400 ms), latency samples: 1720
Latency breakdown for phase 0: ["MempoolToBlockCreation: max: 2.663, avg: 2.573", "ConsensusProposalToOrdered: max: 0.165, avg: 0.163", "ConsensusOrderedToCommit: max: 0.250, avg: 0.210", "ConsensusProposalToCommit: max: 0.413, avg: 0.373"]
Max non-epoch-change gap was: 1 rounds at version 4187010 (avg 0.00) [limit 4], 1.16s no progress at version 4187010 (avg 0.07s) [limit 15].
Max epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 0.70s no progress at version 1964263 (avg 0.70s) [limit 16].
Test Ok

Copy link
Contributor

✅ Forge suite framework_upgrade success on 8e7acd6f8692b1bf870e8232cb95eab97ab5b270 ==> 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a

Compatibility test results for 8e7acd6f8692b1bf870e8232cb95eab97ab5b270 ==> 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a (PR)
Upgrade the nodes to version: 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1557.77 txn/s, submitted: 1561.53 txn/s, failed submission: 3.76 txn/s, expired: 3.76 txn/s, latency: 1904.04 ms, (p50: 1800 ms, p70: 2100, p90: 2400 ms, p99: 3800 ms), latency samples: 140820
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1656.37 txn/s, submitted: 1661.55 txn/s, failed submission: 5.18 txn/s, expired: 5.18 txn/s, latency: 1848.65 ms, (p50: 1800 ms, p70: 1900, p90: 2400 ms, p99: 3800 ms), latency samples: 147200
5. check swarm health
Compatibility test for 8e7acd6f8692b1bf870e8232cb95eab97ab5b270 ==> 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a passed
Upgrade the remaining nodes to version: 2d532f539aaf7b71f1632e5d37b6e37e0ad3a92a
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1706.61 txn/s, submitted: 1712.30 txn/s, failed submission: 5.70 txn/s, expired: 5.70 txn/s, latency: 1812.86 ms, (p50: 1800 ms, p70: 2000, p90: 2300 ms, p99: 2700 ms), latency samples: 149740
Test Ok

@wrwg wrwg merged commit e1b13f2 into main Jul 25, 2025
92 of 106 checks passed
@wrwg wrwg deleted the wrwg/fv-tests branch July 25, 2025 21:19
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.

3 participants