LLVMMemoryCopyFillLowering: in-bounds `memory.fill`/`memory.copy` trap on a 4 GiB memory
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 62/100
Direzione di ricerca
The bug is in src/passes/LLVMMemoryCopyFillLowering.cpp: the generated __memory_fill bounds check (around lines 213-225) and __memory_copy (around lines 123-130) compute the memory size in bytes with i32 arithmetic, which wraps to 0 at 65536 pages. Reproduce with the WAT in the issue using wasm-opt --llvm-memory-copy-fill-lowering, then run the output to confirm the unreachable trap. Done when the bounds check is done in i64 and the 65536-page module no longer traps, with the existing bulk-memory lowering tests still passing.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Repro
(module
(memory 65536)
(func (export "f")
(memory.fill (i32.const 0) (i32.const 0) (i32.const 1))))
$ wasm-opt in.wat --enable-bulk-memory --llvm-memory-copy-fill-lowering -o out.wasm
$ wasmtime run --invoke f in.wat
$ wasmtime run --invoke f out.wasm
Error: failed to run main module `out.wasm`
Caused by:
0: failed to invoke `f`
1: error while executing at wasm backtrace:
0: 0x44 - <unknown>!<wasm function 1>
1: 0x32 - <unknown>!<wasm function 0>
2: wasm trap: wasm `unreachable` instruction executed
f returns normally. After --llvm-memory-copy-fill-lowering, f traps (unreachable).
In pseudocode, the generated __memory_fill checks:
if (dst + size > memory.size << 16) trap // i32: 65536 << 16 = 0
With 65535 pages it does not trap.
Cause
The memory size in bytes is computed in i32, which wraps to 0 for 65536 pages:
__memory_copy has the same computation:
The pass header excludes pointer overflow, but this access does not overflow; only the computed memory size does.
Possible fix
Do the bounds check in i64.
Question
I'm not familiar with how this pass is used in practice. It seems to work as a polyfill for targets without bulk memory, so I'm not sure whether a module with a 65536-page memory actually reaches it.
- Lingua principale
- WebAssembly
- Stelle
- 8.7k
- Fork
- 897
- Merge medio
- 2g 4h
- PR unite (30g)
- 103
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di WebAssembly/binaryen
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
WebAssembly/binaryen#9135 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 76/100
WebAssembly/binaryen#9018 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
WebAssembly/binaryen#9260 · 5 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
WebAssembly/binaryen#9249 ·
I maintainer di solito rispondono entro 1 giorno
-
Memory64Lowering: table.get/table.set keep i64 index on lowered table64, output fails validationAperta
Difficoltà 3/5 Mezza giornata Idoneità per principianti 66/100
WebAssembly/binaryen#9245 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di WebAssembly/binaryen
Issue simili
-
bug priority: P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
arrays asr pass enhancement format I/O low priority
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno
-
bug grammar sev-0
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100