wails: fatal error: non-Go code set up signal handler without SA_ONSTACK flag

Description

First off, I’m not sure if this is a bug in Wails. It could totally be in my own app! However, I’m not using cgo in my code or my go.mod dependencies (edit: except for sqlite, but that’s not new – and I’ve never seen this before until using Wails).

This is a similar to https://github.com/wailsapp/wails/issues/1570, but I’m not using gRPC at all.

My program was running under wails dev, and while I wasn’t interacting with it, it crashed:

signal 11 received but handler not on signal stack
fatal error: non-Go code set up signal handler without SA_ONSTACK flag

runtime stack:
runtime.throw({0x2330cad?, 0xc00009c000?})
        /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0xc000763618 sp=0xc0007635e8 pc=0x44dbfd
runtime.sigNotOnStack(0xb)
        /usr/local/go/src/runtime/signal_unix.go:1020 +0x65 fp=0xc000763638 sp=0xc000763618 pc=0x465305
runtime.adjustSignalStack(0xb, 0xc000780000, 0xc?)
        /usr/local/go/src/runtime/signal_unix.go:581 +0x156 fp=0xc000763698 sp=0xc000763638 pc=0x464156
runtime.sigtrampgo(0xb, 0xc0007639b0, 0xc000763880)
        /usr/local/go/src/runtime/signal_unix.go:469 +0x13b fp=0xc000763710 sp=0xc000763698 pc=0x463e3b
runtime.sigtramp()
        /usr/local/go/src/runtime/sys_linux_amd64.s:359 +0x46 fp=0xc000763760 sp=0xc000763710 pc=0x484b46

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        /usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc0000aafe8 sp=0xc0000aafe0 pc=0x482ea1

goroutine 1 [syscall, 7 minutes, locked to thread]:
runtime.cgocall(0x1f2b240, 0xc0006b5b08)
        /usr/local/go/src/runtime/cgocall.go:158 +0x5c fp=0xc0006b5ae0 sp=0xc0006b5aa8 pc=0x41149c
github.com/wailsapp/wails/v2/internal/frontend/desktop/linux._Cfunc_gtk_main()
        _cgo_gotypes.go:1068 +0x45 fp=0xc0006b5b08 sp=0xc0006b5ae0 pc=0xd21f65
github.com/wailsapp/wails/v2/internal/frontend/desktop/linux.(*Frontend).RunMainLoop(0xc000b89c80)
        /home/matt/go/pkg/mod/github.com/wailsapp/wails/v2@v2.2.0/internal/frontend/desktop/linux/frontend.go:57 +0x1c fp=0xc0006b5b18 sp=0xc0006b5b08 pc=0xd2499c
github.com/wailsapp/wails/v2/internal/frontend/devserver.(*DevWebServer).RunMainLoop(0xc000187ef0)
        <autogenerated>:1 +0x34 fp=0xc0006b5b30 sp=0xc0006b5b18 pc=0xe03514
github.com/wailsapp/wails/v2/internal/app.(*App).Run(0xc000586780)
        /home/matt/go/pkg/mod/github.com/wailsapp/wails/v2@v2.2.0/internal/app/app_dev.go:30 +0x72 fp=0xc0006b5b98 sp=0xc0006b5b30 pc=0xe0ddf2
github.com/wailsapp/wails/v2/pkg/application.(*Application).Run(0xc00028dbc0)
        /home/matt/go/pkg/mod/github.com/wailsapp/wails/v2@v2.2.0/pkg/application/application.go:69 +0x169 fp=0xc0006b5c10 sp=0xc0006b5b98 pc=0xe10bc9
github.com/wailsapp/wails/v2.Run(0xc000164d80)
        /home/matt/go/pkg/mod/github.com/wailsapp/wails/v2@v2.2.0/wails.go:14 +0x33 fp=0xc0006b5c50 sp=0xc0006b5c10 pc=0xe10d53
.
.
.

Full stack trace is 700 lines. Let me know if you want me to provide it.

When this happened, my program did stop, but the CLI command kept running. I had to send it a signal to stop wails dev:

^C
Caught quit
Development mode exited

If Wails is useful to you or your company, please consider sponsoring the project:
https://github.com/sponsors/leaanthony

To Reproduce

Sadly, I don’t know how to reproduce this. It has only happened this one time, and it is not the first time I have run these exact same functions on the exact same inputs. If it happens again I will let you know…

UPDATE: Put this right inside main():

go func() {
	time.Sleep(5 * time.Second)
	var t *time.Time
	log.Println(t.Unix())
}()

Expected behaviour

Not crash 😃

Screenshots

No response

Attempted Fixes

No response

System Details

$ wails doctor
Wails CLI v2.2.0

Scanning system - Please wait (this may take a long time)...Done.

System
------
OS:             Pop!_OS
Version:        22.04
ID:             pop
Go Version:     go1.19.1
Platform:       linux
Architecture:   amd64

Wails
------
Version:                v2.2.0
Package Manager:        apt

Dependency      Package Name            Status          Version
----------      ------------            ------          -------
*docker         docker.io               Available       20.10.12-0ubuntu4
gcc             build-essential         Installed       11.3.0
libgtk-3        libgtk-3-dev            Installed       3.24.33-1ubuntu2
libwebkit       libwebkit2gtk-4.0-dev   Installed       2.38.2-0ubuntu0.22.04.2
npm             npm                     Installed       8.5.1~ds-1
*nsis           nsis                    Available       3.08-2
pkg-config      pkg-config              Installed       0.29.2

* - Optional Dependency

Diagnosis
---------
Your system is ready for Wails development!
Optional package(s) installation details: 
  - docker: sudo apt install docker.io
  - nsis: sudo apt install nsis



If Wails is useful to you or your company, please consider sponsoring the project:
https://github.com/sponsors/leaanthony

Additional context

Sorry this isn’t the most helpful report. Let me know if you need more info!

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 15 (15 by maintainers)

Most upvoted comments

I believe multiple signal handlers within Go are just fine. The SA_STACK issue appears to be very specific: it’s when a signal handler is created in C without the SA_STACK flag and then a signal is triggered by whatever means. I believe it’s extremely unlikely (but not impossible) that it’s within a Wails dependency on Linux as we’ve only had this reported once before in the history of the project. I’d fully expect this to be a common issue on GitHub if it was in gtk or WebKit. I’m going to do some due diligence around scanning the WebKit and gtk code though to check their signal handlers.

What does ldd show for you?

Not in Wails, but maybe in gtk/webkit. We can try adding a signal handler like they do in the Magick library and see if that helps. If we set it up in the Run() method then that should be late enough to override any previous handlers in C but early enough to catch any user-code errors.

I think we can do something here though. If we install a signal handler we may be able to override the existing C signal handler and just propagate that back through to Go. What seems weird to me is that the C signal handler is eating the Go signal. I would have thought that would only have been dealt with by Go

Thanks for the update. I can reproduce with a bog-standard default template. So firstly, I don’t think this is a show-stopper as such because a nil dereference has happened anyway so it’s going to go boom. What do you think is the expected behaviour here? It would be good if we can get it to call back to Go’s handler. I can only assume there’s a standard way of dealing with this scenario and my guess at this point is to include a signal handler in C that overrides the existing one created by the library (I think it’s gtk2webkit) with the SA_ONSTACK flag. I’ll need to do a bit more digging.