ergoplatform / ergoplatform/sigma-rust
Panic with error message on OOM in Wasm
- Dominant language
- Rust
- Stars
- 78
- Forks
- 63
- Avg merge
- 22h 5m
- Merged PRs (30d)
- 3
Description
Although `wasm32` has a 4GB memory limit due to i32 use for pointer in wasm-bindgen glue code, the actual limit is 2GB - https://github.com/rustwasm/wasm-bindgen/issues/2957, and the manifestation of hitting this limit is accessing a random memory. Like the following message:
```
TypeError [ERR_ENCODING_INVALID_ENCODED_DATA]: The encoded data was not valid for encoding utf-8
at new NodeError (node:internal/errors:387:5)
at TextDecoder.decode (node:internal/encoding:433:15)
at getStringFromWasm0 (.../node_modules/ergo-lib-wasm-nodejs/ergo_lib_wasm.js:50:30)
...
errno: 12,
code: 'ERR_ENCODING_INVALID_ENCODED_DATA'
}
An error occurred while extracting data from transaction: TypeError [ERR_ENCODING_INVALID_ENCODED_DATA]: The encoded data was not valid for encoding utf-8
```
because a negative (i32) pointer is passed to functions like `getStringFromWasm0` in the wasm-bindgen glue code.
Contributor guide
Research direction
Start with the wasm-bindgen glue entry point getStringFromWasm0, shown at node_modules/ergo-lib-wasm-nodejs/ergo_lib_wasm.js:50, and reproduce the reported out-of-memory behavior. Trace how the negative i32 pointer reaches that function and define completion as handling the memory-limit case without the misleading UTF-8 error or panic.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, wasm
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100