Wizer truncates data segment count to 10000, resulting in out-of-bounds indices
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Reproduce the issue with a WebAssembly file containing more than 10,000 data segments, then trace Wizer's data-count and naming-section handling. Confirm the fix preserves the full data-segment count, keeps indices consistent, and produces output accepted by wasm-dis and wasm-opt.
Written by the indexing model from the issue text.
Description
I am running wizer on a large wasm file with 80390 data segments (I can provide it on request). The file output by wizer does preserve my data segments but the count value is truncated to 10000, resulting in a malformed wasm file according to tools like wasm-dis and wasm-opt since the naming section is still referring to the old indices.
Before:
0x11a8c | 09 c4 a6 05 | element section
0x11a90 | 01 | 1 count
0x11a91 | 00 | element table[None]
0x11a92 | 41 01 | i32_const value:1
0x11a94 | 0b | end
0x11a95 | e3 81 02 | 32995 items [indices]
... 32995 lines removed ...
0x26dd4 | 0c 03 | data count section
0x26dd6 | 86 f4 04 | data count 80390
0x26dd9 | 0a fa ef ca | code section
| 06
0x26dde | 95 f8 02 | 48149 count
After:
0x11a78 | 09 c4 a6 05 | element section
0x11a7c | 01 | 1 count
0x11a7d | 00 | element table[None]
0x11a7e | 41 01 | i32_const value:1
0x11a80 | 0b | end
0x11a81 | e3 81 02 | 32995 items [indices]
... 32995 lines removed ...
0x26dc0 | 0c 02 | data count section
0x26dc2 | 90 4e | data count 10000
0x26dc4 | 0a fa ef ca | code section
| 06
0x26dc9 | 95 f8 02 | 48149 count
Causing tools like wasm-dis to output this warning:
warning: data index out of bounds in name section: .rodata.10000 at index 10000
And wasm-opt to fail more explosively with this:
wasm-opt: /b/s/w/ir/cache/builder/emscripten-releases/binaryen/src/wasm/wasm.cpp:1833: void wasm::Module::updateDataSegmentsMap(): Assertion `dataSegmentsMap.size() == dataSegments.size()' failed.
Since the resulting file still contains up to this:
0x267d509 | 85 f4 04 0d | Naming { index: 80389, name: ".rodata.80389" }
| 2e 72 6f 64
| 61 74 61 2e
| 38 30 33 38
| 39
I guess there might be a bug that it doesn't rewrite the indices, but I would question why there is such a small limit to begin with.
- Dominant language
- Rust
- Stars
- 1.1k
- Forks
- 64
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bytecodealliance/wizer
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bytecodealliance/wizer#130 ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
bytecodealliance/wizer#153 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
bytecodealliance/wizer#125 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 32/100
bytecodealliance/wizer#105 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
bytecodealliance/wizer#98 · 8 comments ·
All issues in bytecodealliance/wizer
Similar issues
-
Change output crossing a compactsize boundary leaves the fee slightly below the requested feerateOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
bitcoindevkit/bdk_wallet#578 ·
Maintainers usually reply within 8 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
521xueweihan/HelloGitHub#3832 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
canonical/opentelemetry-collector-operator#409 ·
Maintainers usually reply within 1 day