all: tests deadlocked on js/wasm #28975
Labels
arch-wasm
WebAssembly issues
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Testing
An issue that has been verified to require only test changes, not just a test failure.
Milestone
Comments
bcmills
added
Testing
|
Another occurrence in https://storage.googleapis.com/go-build-log/42eb47c6/js-wasm_835acff9.log. Not obvious to me which test it's stuck in. |
|
Ian - your link is a failure in the runtime though. I have tried to reproduce this locally. Ran it around 20-30 times, but not a single failure. The only wasm code inside net/http is roundtrip_js.go. And that appears only in the first log file. The rest just seem to be random failures throughout the net/http tests. Could this be some bug in the runtime which is manifesting when tests are running concurrently ? Only @ianlancetaylor's log contains some runtime code (lock_js.go) which was added in the synchronous callback commit. So that might be a possible suspect. |
|
Another one from database/sql - https://storage.googleapis.com/go-build-log/bee9282d/js-wasm_ac9891a1.log |
agnivade
changed the title
|
Change https://golang.org/cl/153558 mentions this issue: |
|
Here are all instances of the issue: It started happening right after 6dd70fc, so yes, this is a likely culprit. I couldn't reproduce it locally, but I know that this error occurs if the timeout callback for notetsleepg gets invoked too early. If this happens, then notetsleepg does not continue, but no callback is scheduled any more. I found one possible explanation: https://go-review.googlesource.com/c/go/+/153558 |
gopherbot
pushed a commit
that referenced
this issue
Jan 2, 2019
A notetsleepg may get stuck if its timeout callback gets invoked exactly on its deadline due to low precision of nanotime. This change fixes the comparison so it also resolves the note if the timestamps are equal. Updates #28975 Change-Id: I045d2f48b7f41cea0caec19b56876e9de01dcd6c Reviewed-on: https://go-review.googlesource.com/c/153558 Run-TryBot: Richard Musiol <neelance@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
Another deadlock, this time in |
|
Still happening - https://storage.googleapis.com/go-build-log/ddc59a58/js-wasm_937abd88.log. This time in net/http. |
|
|
|
The |
|
I'm sorry to hear that. Any advise on how to approach such an issue? I have one guess that I can try to attack in the next few days, but then we would need to wait and see if it helps or not. Would that still be possible with a post-commit builder? |
|
Change https://golang.org/cl/167119 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Mar 14, 2019
TryBot is sometimes running into deadlocks on js/wasm. We haven't been able to reproduce them yet. This workaround is an experiment to resolve these deadlocks by retrying a missed timeout event. A timeout event is scheduled by Go to be woken by JavaScript after a certain amount of time. The checkTimeouts function then checks which notes to wake by comparing their deadline to nanotime. If this check fails erroneously then the note may stay asleep forever, causing a deadlock. This may or may not be the reason of the observed deadlocks. Updates #28975. Change-Id: I46b9d4069307142914f0e7b3acd4e65578319f0b Reviewed-on: https://go-review.googlesource.com/c/go/+/167119 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
Previously failed https://storage.googleapis.com/go-build-log/ff5a8b05/js-wasm_511c1514.log now passes. |
|
According to greplogs there has been no test failure due to a deadlock for two weeks. Seems like the workaround works fine. Closing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Spotted in https://storage.googleapis.com/go-build-log/44ffce80/js-wasm_95702758.log.
Seems to have deadlocked in
TestTimeoutHandlerRace, but there were a lot of goroutines running.CC @neelance @bradfitz
The text was updated successfully, but these errors were encountered: