wailsapp/wails · warning
error fixing handler for signal %d, please report this issue
Error message
error fixing handler for signal %d, please report this issue to https://github.com/wailsapp/wails: %s\n
What it means
Same fix_signal/SA_ONSTACK routine, compiled into Wails v3's GTK3-legacy Linux path (linux_cgo_gtk3.go): it rewrites handlers for SIGCHLD, SIGHUP, and friends so handlers run on an alternate signal stack, needed because Go's small stacks cannot host C handlers. The stderr message means sigaction failed for one signal and includes errno; the process continues.
Source
Thrown at v3/pkg/application/linux_cgo_gtk3.go:210
// This is a fundamental Go runtime limitation that cannot be fully resolved here.
#include <errno.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>
static void fix_signal(int signum) {
struct sigaction st;
if (sigaction(signum, NULL, &st) < 0) {
goto fix_signal_error;
}
st.sa_flags |= SA_ONSTACK;
if (sigaction(signum, &st, NULL) < 0) {
goto fix_signal_error;
}
return;
fix_signal_error:
fprintf(stderr, "error fixing handler for signal %d, please "
"report this issue to "
"https://github.com/wailsapp/wails: %s\n",
signum, strerror(errno));
}
static void install_signal_handlers() {
#if defined(SIGCHLD)
fix_signal(SIGCHLD);
#endif
#if defined(SIGHUP)
fix_signal(SIGHUP);
#endif
#if defined(SIGINT)
fix_signal(SIGINT);
#endif
#if defined(SIGQUIT)
fix_signal(SIGQUIT);
#endifView on GitHub (pinned to 0e754b1b40)
Solutions
- Confirm it is benign: the app continues; only the alternate-stack behavior for that one signal is lost
- Adjust the sandbox/seccomp policy to permit sigaction for the process
- Build with the default GTK4 stack (linux_cgo.c path) or a newer v3 version where the signal-fix logic is shared and hardened
- Capture the full line (signal number + errno) and report to https://github.com/wailsapp/wails if it correlates with missing crash stacks
Defensive patterns
Strategy: fallback
Prevention
- Run once outside the sandbox to confirm the environment causes the sigaction failure
- Migrate off the legacy GTK3 build (-tags gtk3) to the default GTK4 path
- Preserve the full stderr line (signal + errno) when reporting upstream
When it happens
Trigger: sigaction returning EPERM/EINVAL under a restrictive sandbox (Docker seccomp, gVisor, Android-likes); building with a toolchain/kernel combination where a listed signal constant exists at compile time but is invalid at runtime; running under ptrace-based supervisors.
Common situations: v3 apps packaged into distroless/minimal containers; CI smoke tests under constrained runners; the message appearing at every startup without other symptoms.
Related errors
- error fixing handler for signal %d, please report this issue
- error fixing handler for signal %d, please report this issue
- Unknown menu type: %v
- It's not possible to use the deprecated Assets and AssetsHan
- Unknown menu type for newMenuItemImpl: %v
AI-assisted analysis of wailsapp/wails@0e754b1b40 (2026-08-15).
Data as JSON: /api/errors/56de154c33aa28e3.
Report an issue: GitHub.