fail with "panic: unexpected call to os.Exit(0) during test"

[hajimehoshi]

I am not sure this is an issue in wasmbrowsertest, but let me share the issue.

https://github.com/hajimehoshi/ebiten/actions/runs/10651026325/job/29523110919

panic: unexpected call to os.Exit(0) during test

goroutine 1 [running]:
os.Exit(0x0)
	/opt/hostedtoolcache/go/1.20.14/x64/src/os/proc.go:67 +0x8
main.main()
	_testmain.go:382 +0x55
http://127.0.0.1:46659/wasm_exec.js:353:23 Uncaught
TypeError: Cannot read properties of undefined (reading 'exports')
    at syscall/js.valueCall (http://127.0.0.1:46659/wasm_exec.js:354:24)
    at http://127.0.0.1:46659/ebiten.wasm:wasm-function[1465]:0x121713
    at http://127.0.0.1:46659/ebiten.wasm:wasm-function[1442]:0x11eb3f
    at http://127.0.0.1:46659/ebiten.wasm:wasm-function[1610]:0x130cc0
    at http://127.0.0.1:46659/ebiten.wasm:wasm-function[1606]:0x12f808
    at http://127.0.0.1:46659/ebiten.wasm:wasm-function[1992]:0x17b444
    at http://127.0.0.1:46659/ebiten.wasm:wasm-function[2080]:0x18a753
    at http://127.0.0.1:46659/ebiten.wasm:wasm-function[2672]:0x228baf
    at http://127.0.0.1:46659/ebiten.wasm:wasm-function[3082]:0x29567c
    at http://127.0.0.1:46659/ebiten.wasm:wasm-function[3089]:0x298969
exit with status 2
FAIL	github.com/hajimehoshi/ebiten/v2	25.578s

[hajimehoshi]

Specifying -test.paniconexit0=false explicitly fixed the issue, but I was wondering why...

[agnivade]

@hajimehoshi - It seems like calling os.Exit(0) from within your tests is incorrect: https://tip.golang.org/doc/go1.16#go-test

Is the question about why is there an Uncaught TypeError: Cannot read properties of undefined, or why does the panic happen? Because the latter seems expected, and the uncaught error seems like a side effect of the os.Exit. Preventing the os.Exit(0) should prevent this altogether, unless you want me to investigate about the uncaught error?

[hajimehoshi]

The test failed even without calling os.Exit(0) in my packages

https://github.com/hajimehoshi/ebiten/actions/runs/10651168008/job/29523427131

panic: unexpected call to os.Exit(0) during test

goroutine 1 [running]:
os.Exit(0x0)
	/opt/hostedtoolcache/go/1.20.14/x64/src/os/proc.go:67 +0x8
main.main()
	_testmain.go:54 +0x53
http://127.0.0.1:32895/wasm_exec.js:535:10 Uncaught
Error: Go program has already exited
    at globalThis.Go._resume (http://127.0.0.1:32895/wasm_exec.js:536:11)
    at http://127.0.0.1:32895/wasm_exec.js:264:14
exit with status 2

Is the question about why is there an Uncaught TypeError: Cannot read properties of undefined, or why does the panic happen?

My question is why the panic happens. The panic started to happen wihtout changing anything on my side so this was mysterious. I am not sure where is the culprit is, but I wanted to share this situation.

Isn't the flag -test.paniconexit0 false by default by the way?

[hajimehoshi]

you want me to investigate about the uncaught error?

If you have any insights, I'd be happy if you could invetigate this. Otherwise, we can close this issue. -test.paniconexit0=false suppress this issue anyway.

[agnivade]

My question is why the panic happens. The panic started to happen wihtout changing anything on my side so this was mysterious.

The panic must happen from an os.Exit(0) call somewhere. There is nowhere I call os.Exit from within wasmbrowsertest. Only in cleanEnv there is a possibility, but it's not part of a test.

Nevertheless, I'll take a look at the exception when I get some time.

[hajimehoshi]

https://cs.opensource.google/go/go/+/master:src/testing/testing.go;l=440;drc=239666cd7343d46c40a5b929c8bec8b532dbe83f;bpv=0;bpt=1

This value is false by default so os.Exit(0) should not cause this issue by default, IIUC.

[Zxilly]

Is wasm_exec.js version matched correctly? This has changed a bit in 1.23.

[hajimehoshi]

The current Go version's wasm_exec.js should be used.

[Zxilly]

I'm wondering if this problem still exists with the latest codebase and Go versions? I suspect it may be a runtime issue.
Is there a command that will allow me to reproduce this error immediately?

[hajimehoshi]

AFAIR, This happens only in GitHub Actions, so it is pretty tricky to reproduce the issue.

[Zxilly]

This does make things much more troublesome now, and I shouldn't have much time to work on this lately.

Does using the go_js_wasm_exec script that comes with go trigger this issue? If it does, please create an issue in golang/go