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

The canonical copy of fix_signal in v3/pkg/application/linux_cgo.c, used by the default GTK4/WebKitGTK build: it adds SA_ONSTACK to inherited handlers (SIGCHLD, SIGHUP, SIGINT, SIGTERM, etc.) so that GTK/C code receiving a signal does not run on Go's growable stack, which would corrupt the runtime. The stderr message reports a sigaction failure with errno; execution proceeds, but that signal's handler runs on the normal stack, risking runtime corruption if it fires.

Source

Thrown at v3/pkg/application/linux_cgo.c:83

}

// ============================================================================
// Signal handling
// ============================================================================

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));
}

void install_signal_handlers(void) {
#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

Relax the container/sandbox policy so sigaction succeeds (e.g. default Docker seccomp allows it; custom profiles may not)
Verify the warning disappears with the app run outside the sandbox to confirm the environment as cause
If it persists outside sandboxes, collect signal number + errno and file an issue at https://github.com/wailsapp/wails
Monitor for real signal-delivery problems (hangs on SIGCHLD from child processes) since alternate-stack handling is what was lost

Defensive patterns

Strategy: fallback

Prevention

Use a seccomp profile that allows sigaction for GUI apps
Watch for follow-on symptoms (child-process SIGCHLD handling) since alternate-stack delivery is lost
File an issue at https://github.com/wailsapp/wails with the exact signal number and errno if it recurs in normal environments

When it happens

Trigger: sigaction failing under seccomp-restricted containers (EPERM) or with an invalid signal number (EINVAL); a supervisor having set SA_RESTORER/flags combos the kernel rejects on rewrite; unusual libc/kernel pairings in minimal images.

Common situations: v3 GTK4 apps in hardened Docker images; Flatpak/sandbox environments; NixOS with nonstandard glibc; message seen at startup alongside otherwise normal operation.

Related errors

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