runtime: gc does not work with wasmexport and "void" functions

[ajwerner]

Go version

go version devel go1.24-c208b91 Fri Sep 20 13:54:44 2024 +0000 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/ajwerner/.cache/go-build'
GOENV='/home/ajwerner/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/ajwerner/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/ajwerner/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/ajwerner/sdk/gotip'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/ajwerner/sdk/gotip/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.24-c208b91 Fri Sep 20 13:54:44 2024 +0000'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/ajwerner/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/ajwerner/src/wasmexport-test/go-runner/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build899058900=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I attempted to use the new functionality introduced in #65199 which allows for greatly reducing the cost to call a go function compiled to webassembly. At first it worked great, but then I noticed it failing whenever it needed to grow the stack. I also notice that if you just call runtime.GC, similar bad stuff happens.

Consider the following program:

//go:build wasm

package main

import (
	"runtime"
)

func main() {
}

//go:wasmexport void-gc
func voidGc() {
	runtime.GC()
}

//go:wasmexport not-void-gc
func notVoidGc() int32 {
	runtime.GC()
	return 0
}

You can compile this program like:

GOOS=wasip1 GOARCH=wasm gotip build -buildmode=c-shared -o test.wasm ./test_wasm.go

Then you can have a runner program like:

package main

import (
	"context"
	_ "embed"
	"log"
	"os"

	"github.com/tetratelabs/wazero"
	"github.com/tetratelabs/wazero/imports/wasi_snapshot_preview1"
)

//go:embed test.wasm
var wasm []byte

func main() {
	ctx := context.Background()
	r := wazero.NewRuntime(ctx)
	defer r.Close(ctx) // This closes everything this Runtime created.
	wasi_snapshot_preview1.MustInstantiate(ctx, r)
	mod, err := r.InstantiateWithConfig(ctx, wasm, wazero.NewModuleConfig().
		WithStartFunctions("_initialize").
		WithArgs("arg0").
		WithStderr(os.Stderr).
		WithStdout(os.Stdout).
		WithSysNanosleep())
	if err != nil {
		log.Panicln(err)
	}
	_, err = mod.ExportedFunction("void-gc").Call(ctx)
	if err != nil {
		log.Panicln(err)
	}
}

which can be run with go run ./main.go

go run ./main.go

What did you see happen?

I saw the runtime crash inside wasm, see output. I'll note that in my initial issue, I was not calling runtime.GC, I just happened to see similar failures inside things like growstack and background gc assist. I also noticed that if I add a return value to the entrypoint function, the problems seem to go away.

What did you expect to see?

I expected to not see it crash.

[ajwerner]

@johanbrandhorst this one is likely to interest you.

[gabyhelp]

Related Issues and Documentation

• runtime: macOS-only segfault on 1.14+ with "split stack overflow" #39079 (closed)
• runtime: wasm runtime crashes under certain/undefined conditions #38574 (closed)
• cmd/compile: uncaught RuntimeError: memory access out of bounds #38093 (closed)
• cmd/link: don't resolve WebAssembly imports at link-time #29108
• wasm: does not return memory to the OS #59061 (closed)
• runtime: wasm: fatal error: all goroutines are asleep - deadlock! #41310 (closed)
• syscall/js: nanotime and walltime not compatible with wasm_exec.js #35205 (closed)
• wasm callback loop handling: TypeError: "`target` argument of Reflect.get must be an object, got (void 0)" #28448 (closed)
• wasm: Handling EPIPE from WASM seems impossible? #59099
• runtime: wasm GC causes stop the world for a very long time #54444

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[johanbrandhorst]

CC @golang/wasm @cherrymui