golang/go

runtime: `SIGSEGV` with a c-shared library and called from C#

Open

#78883 opened on Apr 21, 2026

View on GitHub
 (21 comments) (2 reactions) (0 assignees)Go (133,883 stars) (19,008 forks)batch import
BugReportNeedsInvestigationcompiler/runtimehelp wanted

Description

Go version

go version go1.26.2 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/egon/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/egon/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2252078435=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/egon/Code/gist/dotnet-repro/go.mod'
GOMODCACHE='/home/egon/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/egon/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/snap/go/11127'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/egon/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/snap/go/11127/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.26.2'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

We hit an SIGSEV when running building a Go library with c-shared and then calling it from C#. The issue seems difficult to trigger under normal workflows, but I've managed to narrow the issue down to a reproducer that heavily triggers C# GC and calls Go library in a busy loop.

https://gist.github.com/egonelbre/18432be81e1a4e18887e1590ead6f496

AI analysis seems to point that the issue is that Go installs its own sigaltstack and then C# triggers a signal due to it's own GC, which then arrives at a sigaltstack that has been freed.

I'm still trying to find a workaround, but I have not found one yet. Installing a custom larger sigaltstack seems to improve things, but it still seems to crash.

What did you see happen?

The failure looks like

[dotnet-repro] mode=signal workers=32 iters=1000000 interval=50µs gc=True pid=4300
timeout: the monitored command dumped core
./run.sh: line 35:  4299 Segmentation fault      timeout 60 env LD_LIBRARY_PATH=. DOTNET_CLI_HOME=/tmp "$DOTNET_BIN"
exit=139
=== SIGSEGV on attempt 1 — reproduced

What did you expect to see?

No SIGSEGV.

Alternatively, if there's a workaround, it would be nice to have some documentation on how to correctly set it up.

Contributor guide

Tech stack
gocsharp
Domain
backend
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
5
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
Go runtime internalscgosignal handlingC# interop
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
15
Research direction
Investigate the Go runtime's signal handling, specifically the sigaltstack installation and cleanup (e.g., in runtime/signal unix.go and runtime/os linux.go). Reproduce the crash using the provided gist (https://gist.github.com/egonelbre/18432be81e1a4e18887e1590ead6f496). Determine if C#'s GC triggers signals that land on a freed sigaltstack. Check if there are any pending changes or discussions in the linked comments (21 comments) that suggest a fix or workaround.