New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bradfitz opened this Issue Jul 14, 2018 · 13 comments

Comments

Projects
None yet
10 participants
@bradfitz
Copy link
Member

bradfitz commented Jul 14, 2018

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

@bradfitz bradfitz added this to the Go1.11 milestone Jul 14, 2018

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Jul 14, 2018

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

gopherbot pushed a commit that referenced this issue Jul 19, 2018

syscall/js: show goroutine stack traces on deadlock
When using callbacks, it is not necessarily a deadlock if there is no
runnable goroutine, since a callback might still be pending. If there
is no callback pending, Node.js simply exits with exit code zero,
which is not desired if the Go program is still considered running.
This is why an explicit check on exit is used to trigger the "deadlock"
error. This CL makes it so this is Go's normal "deadlock" error, which
includes the stack traces of all goroutines.

Updates #26382

Change-Id: If88486684d0517a64f570009a5ea0ad082679a54
Reviewed-on: https://go-review.googlesource.com/123936
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@neelance

This comment has been minimized.

Copy link
Member

neelance commented Jul 28, 2018

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

@xudongzheng

This comment has been minimized.

Copy link
Contributor

xudongzheng commented Aug 2, 2018

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

This comment has been minimized.

Copy link

gopherbot commented Aug 2, 2018

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

@neelance

This comment has been minimized.

Copy link
Member

neelance commented Aug 2, 2018

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

@andybons andybons modified the milestones: Go1.11, Go1.11.1 Aug 25, 2018

@kaskavalci

This comment has been minimized.

Copy link

kaskavalci commented Aug 29, 2018

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

This comment has been minimized.

Copy link
Member

agnivade commented Aug 29, 2018

@kaskavalci - You have successfully repeated the issue in #26382 (comment). See the comment above.

@kaskavalci

This comment has been minimized.

Copy link

kaskavalci commented Aug 29, 2018

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 FiloSottile modified the milestones: Go1.11.1, Go1.12 Aug 31, 2018

@FiloSottile

This comment has been minimized.

Copy link
Member

FiloSottile commented Aug 31, 2018

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

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Aug 31, 2018

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

This comment has been minimized.

Copy link
Member

neelance commented Oct 21, 2018

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

@josharian

This comment has been minimized.

@neelance

This comment has been minimized.

Copy link
Member

neelance commented Oct 23, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment