runtime: panic 'exitsyscall: syscall frame is no longer valid' in go tool #24656
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
|
Another crash in the same environment: |
|
Hello there @mappu, thank you for filing this issue! Could you please provide a minimal reproduction that's runnable for anyone? That helps a lot in prognosis/diagnosis of the issue affecting you, and makes bug fixing faster. Thank you! |
odeke-em
added
the
WaitingForInfo
|
Is the |
ianlancetaylor
added
NeedsInvestigation
ianlancetaylor
changed the title
|
@ianlancetaylor yes, it was. I tried to reproduce this today on a different machine. I got some different failures instead. The basic steps to reproduce:
First attempt: Go binary segfaulted, but with qemu displaying some warnings. Second attempt: the process hung and must be stopped. Third attempt: This time a crash in Go Fourth attempt: Go binary segfaulted, again with the qemu failures. Fives attempt: Go binary segfaulted, but no qemu failure messages. Go works reliably when running on a real machine. I think these issues in |
|
Thanks for the info. It's not out of scope but I don't know who is going to be able to fix it. |
|
FWIW I can reproduce this without docker. It appears that go1.11 arm and arm64 binaries cannot be run under qemu user emulation (this is a "regression", since 1.10 binaries work). On a I know we don't guarantee that Go binaries work under qemu user emulation mode, but it was nice to be able to use it... |
|
Can you find out why it is failing? The stack trace indicates that the |
|
Tracing says Command and full trace: |
|
Thanks. So the problem seems to be that QEMU does not permit us to set the signal handler for signal 64. That seems like a bug in QEMU. And what has changed is probably that we used to simply ignore the result of |
|
I think we re-discovered this issue from 2013 (or it went away and now it's back): https://groups.google.com/d/topic/golang-nuts/MqKTX_XIOKE/discussion |
|
I think you're right. Perhaps someone could actually report it to QEMU. |
|
I think they're aware. From here: https://git.qemu.org/?p=qemu.git;a=blob;f=linux-user/signal.c;h=a3022c2f04e83ddf370d30905e51b6fa62c1f23d;hb=HEAD#l77 I couldn't find a bug in their tracker, but I found a thread where someone was complaining about not being able to run Go binaries: https://lists.gnu.org/archive/html/qemu-discuss/2016-03/msg00002.html Also it appears that we had workarounds in place for this issue in the past: https://codereview.appspot.com/124900043/ Either we add the signal 64 workaround back or we declare once and for all that running Go binaries under qemu-user is not supported and it's not supposed to work (until they change the way they handle signals). |
|
Change https://golang.org/cl/111176 mentions this issue: |
|
I've verified that, with the change linked above applied on tip, Go binaries no longer crash at start-up under |
|
Thanks, let's do that, I guess. |
gopherbot
pushed a commit
that referenced
this issue
May 4, 2018
The Go runtime registers a handler for every signal. This prevents Go binaries from working on QEMU in user-emulation mode, since the hacky way QEMU implements signals on Linux assumes that no-one uses signal 64 (SIGRTMAX). In the past, we had a workaround in the runtime to prevent crashes on start-up when running on QEMU: golang.org/cl/124900043 golang.org/cl/16853 but it went lost during the 1.11 dev cycle. More precisely, the test for SIGRTMAX was dropped in CL 18150 when we stopped testing the result of sigaction in the Linux implementation of setsig. That change was made to avoid a stack split overflow because code started calling setsig from nosplit functions. Then in CL 99077 we started testing the result of sigaction again, this time using systemstack to avoid to stack split overflow. When this test was added back, we did not bring back the test of SIGRTMAX. As a result, Go1.10 binaries work on QEMU, while 1.11 binaries immediately crash on startup. This change restores the QEMU workaround. Updates #24656 Change-Id: I46380b1e1b4bf47db7bc7b3d313f00c4e4c11ea3 Reviewed-on: https://go-review.googlesource.com/111176 Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
As far as I can tell, this is fixed, so closing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?go version go1.9.2 linux/armDoes this issue reproduce with the latest release?
Unsure.
It barely reproduces under the in-use version, either. This is mostly an FYI.
What operating system and processor architecture are you using (
go env)?A little bit strange one: Docker container
'arm32v7/golang:1.9.2-stretchon x86_64 host. That's an armhf rootfs where every binary executes under qemu-user.What did you do?
Compile a Go program.
It may be notable that the target source code was hosted on a Docker mapped volume,
What did you expect to see?
No error
What did you see instead?
The Go compiler crashed with the following message:
The text was updated successfully, but these errors were encountered: