Skip to content
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: A QEMU signaling fix causes Go binaries to fail on startup. #33746

joshkunz opened this issue Aug 20, 2019 · 4 comments


Copy link

commented Aug 20, 2019

tl;dr: In anticipation of a future QEMU work-around, Go should hide runtime rt_sigaction failures for SIGRTMAX - 1, like it already does for SIGRTMAX.

QEMU user mode emulation has a bug where it will not correctly deliver the SIGRTMIN + 1 signal. This is because SIGRTMIN + 1 is a glibc reserved signal, and it is caught in the emulator's glibc. To get around this issue there is a patch to map SIGRTMIN + 1 to SIGRTMAX - 1, a signal that is typically unused. QEMU already has a similar work-around, mapping SIGRTMIN to SIGRTMAX which is also a signal reserved by glibc.

On startup, the Go attempts to register signal handlers for all signals, but it silently hides failures for SIGRTMIN, SIGRTMIN + 1 (the glibc reserved signals), and SIGRTMAX (the QEMU mapped signal for SIGRTMIN). If the QEMU patch is submitted, go programs running under QEMU will fail to run, due to panics when trying to register a handler for SIGRTMAX - 1.

If Go decides to preemptively fix this issue, the patch is simple: just ignore failures for signal 63 in addition to 64. I will follow up this issue with a patch shortly.


This comment has been minimized.

Copy link

commented Aug 20, 2019

@dsnet who I mentioned this to previously.


This comment has been minimized.

Copy link

commented Aug 20, 2019


This comment has been minimized.

Copy link

commented Aug 21, 2019

Change mentions this issue: runtime: avoid panicking on sigaction failure for SIGRTMAX-1


This comment has been minimized.

Copy link

commented Aug 23, 2019

Is there a more robust way to handle this issue? From the signal(7) manpage

   Real-time signals
   Starting with version 2.2, Linux supports real-time signals as
   originally defined in the POSIX.1b real-time extensions (and now
   included in POSIX.1-2001).  The range of supported real-time signals
   is defined by the macros SIGRTMIN and SIGRTMAX.  POSIX.1-2001
   requires that an implementation support at least _POSIX_RTSIG_MAX (8)
   real-time signals.

   The Linux kernel supports a range of 33 different real-time signals,
   numbered 32 to 64.  However, the glibc POSIX threads implementation
   internally uses two (for NPTL) or three (for LinuxThreads) real-time
   signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably
   (to 34 or 35).  Because the range of available real-time signals
   varies according to the glibc threading implementation (and this
   variation can occur at run time according to the available kernel and
   glibc), and indeed the range of real-time signals varies across UNIX
   systems, programs should never refer to real-time signals using hard-
   coded numbers, but instead should always refer to real-time signals
   using the notation SIGRTMIN+n, and include suitable (run-time) checks
   that SIGRTMIN+n does not exceed SIGRTMAX.

Which says values 63 and 64 that qemu ends up using in the common case when SIGRTMAX==64 shouldn't be hardcoded.

I'm bringing it up because currently Go programs compiled for linux/mips (mips mipsle mips64 mips64le) fail on startup running in qemu user mode on most architectures (amd64 etc.) due to a related issue. The go compiler hardcodes that realtime signals go up to 128 on linux/mips (implicitly that SIGRTMAX==128 on linux/mips and on startup sigaction on 65 and above fail on amd64 etc. It would be nice to have a solution general enough to allow mips programs to run under qemu user mode as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
6 participants
You can’t perform that action at this time.