-
Notifications
You must be signed in to change notification settings - Fork 18k
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: "fatal: systemstack called from unexpected goroutine" on Android #51001
Comments
This happened in a TryBot in https://storage.googleapis.com/go-build-log/f1e11825/android-amd64-emu_262486a5.log:
Marking as release-blocker because this affects TryBot runs. Since |
This may or may not be OS-specific. There is another failure in the builder logs since February, but on
|
|
@golang/runtime This is a second class port, but because it's a trybot, this is a release blocker. Should we consider removing this as a trybot? Is that bringing us enough value? |
Change https://go.dev/cl/407615 mentions this issue: |
I've mailed CL 407615 that makes android-amd64-emu a post-submit builder only (in the main repo) while investigation of this issue is underway. If submitted, this issue can be unmarked as a release-blocker for Go 1.19. |
Curiously, this does not appear to be arch-specific: we've seen these failures on both
|
The first failure shows If I recall correctly, Android applies a seccomp syscall filter to (all?) processes. I wonder if we are violating this filter on the throw path, resulting in truncation of the stack trace. seccomp with mode SECCOMP_RET_TRAP sends a SIGTRAP on violation. |
@golang/android do you know if the Android seccomp filters apply to processes on our builders, and if so which one? |
No repros of this on 25 gomotes all weekend. I did find #53250, plus several no context SIGSEGVs in the runtime test, like:
(Some where in the standard runtime test rather the -cpu variant) |
This isn't a first-class port, so dropping release-blocker. |
This port is still run as a default TryBot until/unless CL 407615 is merged. IMO known failures on TryBots should still block releases, since they still add testing noise for anyone who uses TryBots on a pending change. |
In the interest of decoupling this issue from the Android TryBots in general, I've filed #53377 (as a release-blocker) to decide whether to remove the TryBots or fix their known failure modes. |
Summarizing the known failures with this pattern on Android:
So it looks like this bug was probably introduced sometime in 2021..? |
Rolling forward to 1.20. |
Found new dashboard test flakes for:
2022-08-22 14:48 android-arm64-corellium go@6bdca820 runtime (log)
2022-08-25 19:17 android-arm64-corellium go@f64f12f0 runtime (log)
2022-09-27 18:26 android-arm64-corellium go@17078f58 runtime (log)
|
Found new dashboard test flakes for:
2022-10-06 02:38 android-arm64-corellium go@2e054128 runtime (log)
|
Seems no new failure for some time. |
Note that the rate of testing is much lower now because of the freeze. (6 months is a good window size for checking failure rates.) |
Still none after the tree reopened. Maybe fixed? |
Change https://go.dev/cl/465156 mentions this issue: |
I had initially added known issues fairly aggressively in order to use them to reduce noise in 'greplogs -triage'. Now that we are using 'watchflakes' for triage, that noise reduction is no longer important (the failures are already clustered to their respective known issues), and having greyed-out cells on the dashboard makes new regressions too easy to miss. Concretely: - golang/go#42212 is mostly specific to x/net at this point (as golang/go#57841) - There have been no failures matching golang/go#51001 since October. - golang/go#52724 has been so rare lately that we hadn't yet added a 'watchflakes' pattern for it. - There have been no failures matching golang/go#51443 since May. - There have been no failures matching golang/go#53116 or golang/go#53093 since I enabled 'watchflakes' for the builder in December. - The linux-amd64-perf builder seems to be passing consistently for x/benchmarks and x/tools, so there is no need to refer to golang/go#53538 to explain failures on it. Change-Id: Ia16db2a23e5fa037a299f1f56fb26f1cf84521e1 Reviewed-on: https://go-review.googlesource.com/c/build/+/465156 Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Run-TryBot: Bryan Mills <[email protected]> Auto-Submit: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
greplogs --dashboard -md -l -e '^fatal: systemstack called from unexpected goroutine' --since=2021-01-01
2022-02-02T21:12:39-53d6a72/android-amd64-emu
2021-10-08T16:26:20-59d4e92-99c1b24/android-amd64-emu
I'll also note that
badsystemstackMsg
seems to be missing a final newline as of CL 93659 (CC @aclements @randall77). 😅The text was updated successfully, but these errors were encountered: