Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: panic 'exitsyscall: syscall frame is no longer valid' in go tool #24656
What version of Go are you using (
@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:
Go binary segfaulted, but with qemu displaying some warnings.
the process hung and must be stopped.
This time a crash in Go
Go binary segfaulted, again with the qemu failures.
Go binary segfaulted, but no qemu failure messages.
Go works reliably when running on a real machine. I think these issues in
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).
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...
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):
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:
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).
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 <email@example.com>