Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

LLVMMemoryCopyFillLowering: in-bounds `memory.fill`/`memory.copy` trap on a 4 GiB memory

Abierto
  • ¿Algo no está bien?
#9,257 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
62/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cpp, wasm
Área
compilers

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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:

https://github.com/WebAssembly/binaryen/blob/1d7748aa4ef48ac93f90712c2437ef88c6441389/src/passes/LLVMMemoryCopyFillLowering.cpp#L213-L225

__memory_copy has the same computation:

https://github.com/WebAssembly/binaryen/blob/1d7748aa4ef48ac93f90712c2437ef88c6441389/src/passes/LLVMMemoryCopyFillLowering.cpp#L123-L130

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.

Lenguaje dominante
WebAssembly
Estrellas
8.7k
Forks
897
Merge medio
2 d 4 h
PR fusionados (30 d)
103

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de WebAssembly/binaryen

Todos los issues de WebAssembly/binaryen

Issues similares

Más issues de Compilers

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.