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);
	#endif

View on GitHub (pinned to 0e754b1b40)

Solutions

  1. Confirm it is benign: the app continues; only the alternate-stack behavior for that one signal is lost
  2. Adjust the sandbox/seccomp policy to permit sigaction for the process
  3. Build with the default GTK4 stack (linux_cgo.c path) or a newer v3 version where the signal-fix logic is shared and hardened
  4. 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

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


AI-assisted analysis of wailsapp/wails@0e754b1b40 (2026-08-15). Data as JSON: /api/errors/56de154c33aa28e3. Report an issue: GitHub.