wasm trap: out of bounds memory access error

[rajatjindal]

Imp note: I have used claude to debug this issue and it helped me identify this root cause.

Runtime on: Macos Sonoma Version 14.6.1. M2 Pro, ARM
Golang: go version go1.25.5 darwin/arm64
build command used: tinygo build -target=wasi -buildmode=c-shared -no-debug -o main.wasm .

I was testing why a sample spin example was not working with tinygo-v0.40.1, but worked with tinygo-v0.39.0, and with help from claude, it pointed to this commit: 82decca

The error I was getting with v0.40.1 was: wasm trap out of bounds memory access.

Once I reverted this change on my local setup, and ran my app again. it worked this time.

I am attaching the wasm file generated with both the versions (incase its helpful) (I could not attach the wasm files here).

Although I was able to test and reproduce this issue with spin, please let me know if reproducing this using just tinygo and/or wasmtime is needed and I will try my best to provide a repro using that.

Thank you for your help as always.

[slowteetoe]

Same issue with a different (trivial) app, using wasip1 target

Macos Tahoe 26.3
go version go1.25.4 darwin/arm64
tinygo build -target=wasip1 -buildmode=c-shared -no-debug -o main.wasm

tiny-go-v0.39.0 works
tiny-go-v0.40.0 works
tiny-go-v0.40.1 fails

❯ tinygo version
tinygo version 0.40.1 darwin/arm64 (using go version go1.25.4 and LLVM version 20.1.1)

❯ spin build --up
Building component scaling-spin with `tinygo build -target=wasip1 -buildmode=c-shared -no-debug -o main.wasm .`
Finished building all Spin components
Logging component stdio to ".spin/logs/"

Serving http://127.0.0.1:3000
Available Routes:
  scaling-spin: http://127.0.0.1:3000 (wildcard)
2026-02-15T17:30:09.310819Z ERROR spin_trigger_http::server: Error processing request: error while executing at wasm backtrace:
    0:  0x10031 - main!runtime.growHeap
    1:   0x63d0 - main!runtime.alloc.llvm.10329922066743253423
    2:   0xc581 - main!realloc
    3:  0x53c29 - main!canonical_abi_realloc
    4:  0x68e5f - wit-component:adapter:wasi_snapshot_preview1!allocate_stack
    5:  0x6760d - wit-component:adapter:wasi_snapshot_preview1!random_get
    6:  0x6a9a2 - wit-component:shim!adapt-wasi_snapshot_preview1-random_get
    7:   0x156b - main!arc4random
    8:   0xc7ed - main!_initialize

Caused by:
    wasm trap: out of bounds memory access

[eliasnaur]

From the stack trace it seems that initializing the random number generator in the WASI environment allocates memory. That's unfortunate, because #5133 assumed that the generator wouldn't allocate and therefore could be initialized before the heap.

I can't say whether the generator can be changed to not allocate, otherwise the initialization order should be swapped again, unfortunately.

[deadprogram]

See #5199 as a way to address this on wasm targets based on @eliasnaur comment.

[deadprogram]

Labeled to close this on next release.

[rajatjindal]

Hi @deadprogram, thank you for the quick fix. do you know when will be the next scheduled release for tinygo? is there a way we can have a patch release before the next scheduled release incase the scheduled release is still a few days out?

many thanks
Rajat Jindal

[deadprogram]

Hi @deadprogram, thank you for the quick fix. do you know when will be the next scheduled release for tinygo? is there a way we can have a patch release before the next scheduled release incase the scheduled release is still a few days out?

many thanks Rajat Jindal

Please feel free to contact me via email if you want to discuss in more detail, @rajatjindal