FIX: targets/wasm: coerce memory offsets to unsigned before typed array and DataView access

[felipegenef]

Hi TinyGo team, hope you are all doing well.

While stress testing a fairly large TinyGo WASM project that does sustained cross-module payload transfers, I started running into intermittent crashes once the Go heap became large enough for some memory offsets to cross the signed 32-bit boundary.

After tracing the issue through the JS bridge, it looks like a few pointer and length values are still being treated as signed i32 values inside wasm_exec.js.

WASM linear memory addresses are conceptually unsigned 32-bit values, but the bridge receives them as i32 parameters. In JavaScript, values with bit 31 set become negative numbers. When those values are forwarded directly into APIs like Uint8Array or DataView, browsers reject them with errors like:

RangeError: Start offset is outside the bounds of the buffer

For example, an offset such as 0x80000010 arrives in JS as -2147483632, and the typed array constructor throws immediately.

In asyncify-instrumented builds, this later propagates into:

RuntimeError: unreachable

because the exception surfaces during resumed execution.

The issue was a bit tricky to reproduce consistently since it only starts happening once the heap grows large enough, but under sustained memory pressure or large allocation workloads it became very reliable in my application.

This patch adds >>>= 0 coercions before affected values are passed into typed array or DataView constructors. The coercion simply reinterprets the bit pattern as an unsigned 32-bit integer without changing the underlying value.

Patched sites:

• loadSlice (array, len)
• loadString (ptr, len)
• syscall/js.valueLoadString (slice_ptr, slice_len)
• syscall/js.copyBytesToGo (ret_addr, dest_addr, dest_len)
• syscall/js.copyBytesToJS (ret_addr, src_addr, src_len)
• random_get (bufPtr, bufLen)
• fd_write (iovs_ptr, iovs_len, nwritten_ptr)

One interesting detail is that stringVal already contained a value_ptr >>>= 0 coercion, so there was already some awareness of this issue in one part of the bridge. This patch extends the same handling consistently to the remaining affected paths.

The changes are intentionally very small and localized. There should be no behavioral difference for applications whose heaps stay below the signed 32-bit boundary.

I was able to reproduce the crash consistently before the patch and could no longer reproduce it afterwards under the same stress conditions.

My guess is that this may affect other large or long-running TinyGo WASM applications as well, especially ones dealing with large payloads or sustained heap growth.

Thanks for taking a look.

[eliasnaur]

I think it's more better to perform the coercion as soon as possible, and not in helper functions. So I suggest removing these lines and add coercion to all top-level functions instead.

See comment on copyBytesToJS for my motivation.

[eliasnaur]

Ditto.

[eliasnaur]

This is an example of why coercing should be performed first: the coercion done by loadSlice is both redundant and insufficient because you're using the unsigned values elsewhere.

[felipegenef]

Hey @eliasnaur, thanks for the feedback!

I've updated the patch, removed the coercions from loadSlice and loadString and moved them to the top of each import function instead.

While going through all the top level functions I also noticed a few that were missed in the original patch: runtime.getRandomData, syscall/js.valueGet, valueSet, valueDelete, valueCall, valueInvoke, valueNew, and valuePrepareString. Those are covered now too.

Let me know what you think!

[eliasnaur]

LGTM, but let an actual expert take another look.