Go: runtime: wasm: all goroutines asleep and no JavaScript callback pending - deadlock

[bradfitz]

I've seen a few trybot flakes on wasm like:

https://storage.googleapis.com/go-build-log/fd762fcb/js-wasm_280bcf2c.log (from wasm-unrelated https://go-review.googlesource.com/c/go/+/123779)

ok      math/bits   1.768s
ok      math/cmplx  1.762s
ok      math/rand   4.233s
ok      mime    1.705s
ok      mime/multipart  6.236s
ok      mime/quotedprintable    3.097s
ok      net 2.596s
error: all goroutines asleep and no JavaScript callback pending - deadlock!
FAIL    net/http    15.608s
2018/07/13 22:17:40 Failed: exit status 1

[gopherbot]

Change https://golang.org/cl/123936 mentions this issue: syscall/js: show goroutine stack traces on deadlock

[neelance]

@bradfitz Please post a link here if you see it happening again, so I can check the stack traces.

[xudongzheng]

I think I ran into the same issue with https://play.golang.org/p/Ymt6QgfYH93. Not sure if I'm underestimating the complexity of the fix.

[gopherbot]

Change https://golang.org/cl/127515 mentions this issue: syscall/js: run callback function in goroutine

[neelance]

@xudongzheng Your issue is unrelated to the flake above. Please see https://tip.golang.org/pkg/syscall/js/#NewCallback on why it happens.

[kaskavalci]

I get this error when I'm doing a http request within a callback function. Apparently RoundTrip function hangs while waiting for an answer. Network tab in browser shows successful request and response correctly.

fatal error: all goroutines are asleep - deadlock!
VM5521 wasm_exec.js:45 
VM5521 wasm_exec.js:45 goroutine 1 [chan receive]:
VM5521 wasm_exec.js:45 main.main()
VM5521 wasm_exec.js:45  /Users/kaskavalci/gow/test/wasm/main.go:117 +0x11
VM5521 wasm_exec.js:45 
VM5521 wasm_exec.js:45 goroutine 5 [select]:
VM5521 wasm_exec.js:45 net/http.(*Transport).RoundTrip(0x467860, 0xc0b4400, 0x0, 0x0, 0x0)
VM5521 wasm_exec.js:45  /usr/local/Cellar/go/1.11/libexec/src/net/http/roundtrip_js.go:149 +0x44

[agnivade]

@kaskavalci - You have successfully repeated the issue in https://github.com/golang/go/issues/26382#issuecomment-409898574. See the comment above.

[kaskavalci]

Oh 🤦‍♂️
For someone who is looking for a quick answer, just wrap your request in a go-routine because

A blocking callback should therefore explicitly start a new goroutine.

example := func(i []js.Value) {
    go func() {
        fmt.Println(http.Get("http://localhost:9276/"))
    }()
}
js.Global().Set("example", js.NewCallback(example))
select {}

[FiloSottile]

@gopherbot please file this to be considered for backport to 1.11.

[gopherbot]

Backport issue(s) opened: #27425 (for 1.11).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[neelance]

@bradfitz Is there a way to search the trybot logs for this flake?

[josharian]

https://github.com/aclements/go-misc/tree/master/greplogs

[neelance]

According to the logs, the last time this happened was on 2018/07/19. I'd say we can close this.

[danaugrs]

I'm getting a similar error after upgrading from Go 1.12 to 1.13:

fatal error: all goroutines are asleep - deadlock!

even though there should be a callback (requestAnimationFrame) pending.

[FiloSottile]

@danaugrs Please open a new issue, we don't track closed issues, and that's a pretty generic error.

[danaugrs]

@FiloSottile I figured it out, the problem was reading from the channel of a time.Timer inside the requestAnimationFrame callback. The behavior must have changed from 1.12 to 1.13 but I'm not sure which is correct. I'll open an issue if it turns out to be a blocker for me.

[WeiChieh-Chen]

if use goroutine, how return value to frontend ?