"out of bounds memory access" in runtime.alloc / hashmapStringGet

[jakebailey]

When running the TypeScript Go port (modified to remove JSON calls that aren't currently working in tinygo), I'm seeing this error when running the binary:

wazero:

error instantiating wasm binary: module[main] function[_start] failed: wasm error: out of bounds memory access
wasm stack trace:
	main.runtime.alloc(i32,i32) i32
		0x816c: /usr/local/lib/tinygo/src/runtime/gc_blocks.go:409:5
	main.runtime.hashmapStringGet(i32,i32,i32,i32,i32) i32
		0xe447: /usr/local/lib/tinygo/src/runtime/hashmap.go:518:35 (inlined)
		        /usr/local/lib/tinygo/src/runtime/arch_tinygowasm_malloc.go:1074:90
	main.github.com/microsoft/typescript-go/internal/scanner.GetIdentifierToken(i32,i32) i32
		0x1b9928: /home/jabaile/work/TypeScript-go/internal/scanner/scanner.go:1936:6 (inlined)
		          /home/jabaile/work/TypeScript-go/internal/core/compileroptions_stringer_generated.go:892:12 (inlined)
		          /home/jabaile/work/TypeScript-go/internal/scanner/scanner.go:26:19 (inlined)

wasmtime:

Error: failed to run main module `./tsgo-tinygo.wasm`

Caused by:
    0: failed to invoke command default
    1: error while executing at wasm backtrace:
           0: 0xa4ea - runtime.alloc
                           at /usr/local/lib/tinygo/src/runtime/gc_blocks.go:409:5
           1: 0x107c5 - runtime.hashmapStringGet
                           at /usr/local/lib/tinygo/src/runtime/hashmap.go:518:35
           2: 0x1bbca6 - github.com/microsoft/typescript-go/internal/scanner.GetIdentifierToken
           3: 0x1cfa32 - (*github.com/microsoft/typescript-go/internal/binder.Binder).checkContextualIdentifier
                           at /home/jabaile/work/TypeScript-go/internal/binder/binder.go:1175:52              - (*github.com/microsoft/typescript-go/internal/binder.Binder).bind
                           at /home/jabaile/work/TypeScript-go/internal/binder/binder.go:603:30
           4: 0x1cc198 - main!(*github.com/microsoft/typescript-go/internal/binder.Binder).bind$bound
           5: 0x11a41d - github.com/microsoft/typescript-go/internal/ast.visit
           6: 0x1138e2 - (*github.com/microsoft/typescript-go/internal/ast.PropertyAccessExpression).ForEachChild
                           at /home/jabaile/work/TypeScript-go/internal/ast/ast.go:5814:14              - (Go interface method)
                           at <Go interface method>
           7: 0x1115a2 - (*github.com/microsoft/typescript-go/internal/ast.Node).ForEachChild

The repro for this takes a bit to get to (time wise, long clone, long build):

$ git clone --branch jabaile/tinygo --recurse-submodules git@github.com:microsoft/typescript-go.git
$ GOOS=wasip1 GOARCH=wasm tinygo build -o tsgo-tinygo.wasm ./cmd/tsgo

$ wazero run -mount=/:/ -env-inherit ./tsgo-tinygo.wasm -p $PWD/_submodules/TypeScript/src/compiler --singleThreaded
# or
$ WASMTIME_BACKTRACE_DETAILS=1 wasmtime run --dir=/ --env PWD="$PWD" --env PATH="$PATH" -W max-wasm-stack=1048576 ./tsgo-tinygo.wasm -p $PWD/_submodules/TypeScript/src/compiler --singleThreaded

[dgryski]

Can you try running with a larger stack size to see if it's stack-overflow-related memory corruption?

[dgryski]

Also if this binary works on when compiled for native but not on wasm that would also be useful to know.

[jakebailey]

I asked wasmtime for a max stack size of 1073741824, and still got the error. IIRC wazero has a default stack limit on the order of 250MB, same as 32-bit Go programs do by default, so I think does itself show that the stack limit isn't the problem.

The binary works when run natively (plain go build), yes, as well as when using Go to build the wasm to run instead of tinygo.

[aykevl]

IIRC wazero has a default stack limit on the order of 250MB, same as 32-bit Go programs do by default, so I think does itself show that the stack limit isn't the problem.

TinyGo has its own internal stack management in linear memory, which for wasm is 64kB by default. That's usually enough, but not always (and can result in weird bugs). Hence why it's important to check.

The binary works when run natively (plain go build), yes, as well as when using Go to build the wasm to run instead of tinygo.

What about when you use just tinygo build? No -target=wasm or anything, just build a native binary using TinyGo for your current OS. Things are often easier to debug when running TinyGo programs outside WebAssembly.

[jakebailey]

What about when you use just tinygo build? No -target=wasm or anything, just build a native binary using TinyGo for your current OS. Things are often easier to debug when running TinyGo programs outside WebAssembly.

Ah, it does in fact crash there. But, I don't think it's the same crash given the Wasm binary doesn't complain about GC/heap size?

GC Warning: Failed to expand heap by 137438969860 KiB
GC Warning: Failed to expand heap by 137438953476 KiB
GC Warning: Out of Memory! Heap size: 478 MiB. Returning NULL!
panic: runtime error at 0x000000000053e2e1: caught signal SIGSEGV
[1]    823859 segmentation fault (core dumped)  ./tsgo-tinygo -p $PWD/_submodules/TypeScript/src/compiler --singleThreaded

The Boehm PR crashes too, but differently too:

panic: runtime error at 0x00000000005477bf: caught signal SIGSEGV
[1]    826061 segmentation fault (core dumped)  ./tsgo-tinygo-boehm -p $PWD/_submodules/TypeScript/src/compiler