Description

We are seeing an intermittent native crash in a long-running Wails v3 Linux GTK3 application. The app exits with code 2 and is restarted by a watchdog. This is not a Go panic; it is a SIGSEGV during cgo execution.

The crash consistently points to Wails' Linux GTK3 asset server request cleanup path:

SIGSEGV: segmentation violation
PC=0x7ff98072495e m=22 sigcode=1 addr=0x28
signal arrived during cgo execution

goroutine 127163 [syscall]:
runtime.cgocall(...)
github.com/wailsapp/wails/v3/internal/assetserver/webview._Cfunc_g_object_unref(0x3d639b50)
    _cgo_gotypes.go:306
github.com/wailsapp/wails/v3/internal/assetserver/webview.(*request).Close.func1(...)
    github.com/wailsapp/wails/v3@v3.0.0-alpha.97/internal/assetserver/webview/request_linux_gtk3.go:80
github.com/wailsapp/wails/v3/internal/assetserver/webview.(*request).Close(...)
    github.com/wailsapp/wails/v3@v3.0.0-alpha.97/internal/assetserver/webview/request_linux_gtk3.go:80
github.com/wailsapp/wails/v3/internal/assetserver/webview.(*requestFinalizer).close(...)
    github.com/wailsapp/wails/v3@v3.0.0-alpha.97/internal/assetserver/webview/request_finalizer.go:36
github.com/wailsapp/wails/v3/pkg/application.(*webViewAssetRequest).Close(...)
    github.com/wailsapp/wails/v3@v3.0.0-alpha.97/pkg/application/application.go:330
github.com/wailsapp/wails/v3/internal/assetserver.(*AssetServer).processWebViewRequest(...)
    github.com/wailsapp/wails/v3@v3.0.0-alpha.97/internal/assetserver/assetserver_webview.go:59

Environment

• Wails: v3.0.0-alpha.97
• Backend: Go application built with Linux GTK3 tags
• OS: UOS / Linux amd64
• WebKitGTK: system WebKitGTK 4.x
• Packaging: deb/rpm application, long-running desktop process

Observed behavior

The application runs for a long time, then exits unexpectedly:

2026/06/09 19:56:30 app exited: pid=375961, exit_code=2, err=exit status 2
2026/06/09 19:56:34 app started: /opt/cogeye/cogeye-client

The stderr log starts with SIGSEGV, and the crash is in g_object_unref while closing a WebKitURISchemeRequest.

Expected behavior

Closing a WebKit URI scheme request should not crash the process. If cleanup needs to touch GTK/WebKit/GObject state, it should happen on the GTK main context or otherwise follow WebKitGTK thread/lifetime requirements.

Suspected cause

In internal/assetserver/webview/request_linux_gtk3.go, request.Close() calls:

C.g_object_unref(C.gpointer(r.req))

This can be reached from Wails' assetserver processing goroutine. Since WebKitURISchemeRequest is a GObject/WebKit object, releasing it off the GTK main context may be unsafe and can intermittently crash.

Local workaround tested

We patched Wails locally to schedule the unref on the GTK main context:

static gboolean cogeye_g_object_unref_on_main(gpointer data) {
    if (data != NULL) {
        g_object_unref(data);
    }
    return G_SOURCE_REMOVE;
}

static void cogeye_g_object_unref_async(gpointer obj) {
    if (obj != NULL) {
        g_main_context_invoke(NULL, cogeye_g_object_unref_on_main, obj);
    }
}

Then changed:

C.g_object_unref(C.gpointer(r.req))

to:

C.cogeye_g_object_unref_async(C.gpointer(r.req))

Could maintainers confirm whether WebKitURISchemeRequest cleanup should be dispatched to the GTK main context, or suggest the correct lifecycle/threading fix for Wails v3 GTK3?

Notes

This is separate from the WebKitGTK permission-request issue for getUserMedia.