cmd/compile: program compiles to wasm but is invalid: go:wasmexport: integer too large

[davidmdm]

Go version

go1.24.2 darwin/arm64

Output of go env in your module/workspace:

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE='on'
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN='/Users/davidmdm/go/bin'
GOCACHE='/Users/davidmdm/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/davidmdm/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/s1/hqn8jdf97bj_xvlp070s_mh00000gn/T/go-build3338415171=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/davidmdm/Documents/coding/yokecd/examples/go.mod'
GOMODCACHE='/Users/davidmdm/go/pkg/mod'
GONOPROXY='github.com/davidmdm/*'
GONOSUMDB='github.com/davidmdm/*'
GOOS='darwin'
GOPATH='/Users/davidmdm/go'
GOPRIVATE='github.com/nestoca/*,github.com/davidmdm/*'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/davidmdm/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.2.darwin-arm64'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/Users/davidmdm/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='go1.24.2+auto'
GOTOOLDIR='/Users/davidmdm/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.2.darwin-arm64/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.24.2'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I compiled a program to wasm using GOOS=wasip1 GOARCH=wasm and when I tried to execute it with wazero and wasmtime found that the program was invalid.

I have managed to create a minimal reproduction.

Create a new directory and run the following script.

(It seems to only fail if I import the external-secret project and use a wasm export in combination)

set -x

go mod init temp

go get github.com/external-secrets/external-secrets@v0.15.1
go mod tidy

cat <<EOF >main.go
package main

import _ "github.com/external-secrets/external-secrets/apis/externalsecrets/v1beta1"

func main() {}

//go:wasmexport malloc
func malloc(size uint32) uint32 {
	return 0
}
EOF

GOOS=wasip1 GOARCH=wasm go build -o ./temp.wasm .

wazero compile ./temp.wasm || wasmtime compile ./temp.wasm
EOF

GOOS=wasip1 GOARCH=wasm go build -o ./temp.wasm .

wazero compile ./temp.wasm || wasmtime compile ./temp.wasm

What did you see happen?

Both wazero and wasmtime fail to compile the wasm binary produced by the above program.

Wazero:

error compiling wasm binary: invalid function[51716] export["malloc"]: read i32 immediate: overflows a 32-bit integer

Wasmtime:

Error: WebAssembly translation error

Caused by:
    Invalid input WebAssembly code at offset 45267909: invalid var_i32: integer too large

What did you expect to see?

Binary produced by Go Toolchain compiles successfully and can be executed successfully.

[ldemailly]

can you reduce it to whichever github.com/external-secrets/external-secrets does in init/globals ?
(I assume the problem doesn't occur without

import _ "github.com/external-secrets/external-secrets/apis/externalsecrets/v1beta1"

)

[gabyhelp]

Related Issues

• runtime: give clear error when a wasmexport function is called before module initialization #71240 (closed)
• unknown ptrSize for $GOARCH "wasm" #40543 (closed)
• cmd/test2json: 'exec format error' for os/exec when exec is set to go_js_wasm_exec #32442 (closed)
• cmd/link: don't resolve WebAssembly imports at link-time #29108
• cmd/go: go test for GOOS=js GOARCH=wasm looks for wasm_exec.js in the old misc/wasm/ path instead of lib/wasm/ #71767 (closed)
• wasm/misc: getInt64 won't work in JavaScript #29786 (closed)
• cmd/link: regression on building an app with `GOOS=wasip1 GOARCH=wasm` #65786 (closed)
• can't load package: package main #40313 (closed)
• cmd/compile: uncaught RuntimeError: memory access out of bounds #38093 (closed)
• misc/wasm: Go's WASM running slow in Node v19 #59748

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

[dmitshur]

CC @golang/wasm.

[Zxilly]

Can you share the WAT format code of function[51716]?

[davidmdm]

@Zxilly as a bit of a high level end user, I am not all too familiar with the tooling for doing that. I can try later today. But the script above should produce the offending binary for you.

[davidmdm]

@Zxilly I have tried running wasm2wat on the binary but get a similar error:

wasm2wat ./temp.wasm -o ./temp.wat
2b2bbc1: error: unable to read i32 leb128: i32.const value

Running in verbose mode does not seem to give us more information:

    ...
    OnGlobalGetExpr(index: 0)
    OnI32ConstExpr(16 (0x10))
    OnBinaryExpr("i32.sub" (107))
    OnGlobalSetExpr(index: 0)
    OnGlobalGetExpr(index: 0)
    OnLocalGetExpr(index: 0)
    OnStoreExpr(opcode: "i32.store" (54), memidx: 0, align log2: 2, offset: 0)
    OnGlobalGetExpr(index: 0)
    OnI32ConstExpr(8 (0x8))
    OnBinaryExpr("i32.sub" (107))
    OnGlobalSetExpr(index: 0)
    OnGlobalGetExpr(index: 0)
    OnI64ConstExpr(3657695233 (0xda040001))
    OnStoreExpr(opcode: "i64.store" (55), memidx: 0, align log2: 3, offset: 0)
    OnI32ConstExpr(0 (0x0))
    OnCallExpr(func_index: 51750)
    OnIfExpr(sig: void)
2b2bbc1: error: unable to read i32 leb128: i32.const value

[Zxilly]

I've reproduce the problem and got the binary, thanks.

[Zxilly]

I wrote a patch to try to fix this issue, but I'm not quite sure if I'm doing it right.

cc @cherrymui

[gopherbot]

Change https://go.dev/cl/663995 mentions this issue: cmd/internal/obj/wasm: use i64 for large return addr

[cherrymui]

Thanks for the report. This looks similar (and probably related) to #64856. When it have more than 32K of functions, a number of places in the code don't handle that many functions well. One difference is that this is signed integer overflow, i.e. more than 32K but not 64K. The CL above may be part of the fix, but it is probably not enough, especially once we get to more than 64K functions, it would certainly be not enough. I'll continue looking into it, along with #64856.