WebAssembly / WebAssembly/spec

Inconsistencies with memory and table max limits in core spec, js-api spec and tests

Open
#1,864 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
WebAssembly
Stars
3.5k
Forks
539
Avg merge
2d 1h
Merged PRs (30d)
13

Description

Current status:

After the memory64 update, the spec says that (link):

  • table limits must be within range 2^addrtype - 1, i.e. for table32 up to 2^32 - 1, for table64 up to 2^64 - 1;
  • memory limits must be within range 2^(addrtype - 16), i.e. for memory32 up to 2^16 pages, for memory64 up to 2^48 pages.
    This means that we should throw CompileErrors if the limits are exceeded.

After the memory64 update, the js-api says that (link):
Regarding tables:

  • throw a CompileError if "The maximum size of a table is 10,000,000." is exceeded;
  • throw a CompileError if "The maximum number of table entries in any table initialization is 10,000,000." is exceeded;
  • throw a RuntimeError if "The maximum size of a table is 10,000,000." is exceeded;

Regarding memories:

  • throw a RuntimeError if for memory32 2^16 pages is exceeded;
  • throw a RuntimeError if for memory64 2^18 pages is exceeded;

After the memory64 update, the spec tests say that (link):
Regarding tables:

  • table32 with max size 2^32 - 1 is still valid, if exceeded throw CompileError;
  • throw CompileError for table32 with initial size 2^32;
  • table64 with max size 2^64 - 1 is still valid;

Regarding memories:

  • memory32 with max size 2^16 pages is still valid, if exceeded throw CompileError;
  • memory64 with max size 2^16 pages is still valid;
  • throw CompileError for memory64 with initial or max size 2^48 + 1.

After the memory64 update, the js-api test limits.any.js tests:
Regarding tables:

  • instantiation fails if the initial table size is 10,000,000 + 1;
  • instantiation succeeds if the max size is 10,000,000 + 1;
  • growing table fails, INCORRECT (Wasm function in line 228 returns wasmI32Const(-1) by default);

Regarding memories:

  • no memory tests!

Proposed changes:
  1. js-api spec: PR
    a) remove sentence to throw CompileError if "The maximum size of a table is 10,000,000.", as these tables are valid
    b) remove sentence to throw CompileError if "The maximum number of table entries in any table initialization is 10,000,000.", as these tables are valid
    c) adjust sentence to throw RuntimeError if "The maximum size of a table is 10,000,000.". It's unclear if it's both initial and max size of the table.

  2. spec tests:
    a) add tests for table32 with 2^32 - 1 and table64 with 2^64 - 1 initial page size is still valid PR;
    b) add test that memory32 with initial size 2^16 pages is still valid PR;
    c) add test that memory64 with initial OR max size 2^48 pages is still valid PR and PR;

  3. js-api limits.any.js:
    a) fix table grow function in testDynamicLimit()
    b) add tests for memory instantiation (initial and max size are OOB or just in bounds)
    c) add tests for memory64 or table64

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing the core and JS API limit sections with the related cases in test/core and limits.any.js. Review the referenced PRs and the incorrect testDynamicLimit() behavior before changing anything; done means the documented limits and tests consistently cover in-bounds and out-of-bounds table and memory cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, wasm
Domain
compilers, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.