runtime/cgo: signal arrived during external code execution

[roffe]

Go version

go1.24.0

Output of go env in your module/workspace:

set AR=ar
set CC=gcc
set CGO_CFLAGS=-IC:\Users\roffe\go\src\github.com\roffe\txlogger\vcpkg\packages\libusb_x86-windows\lib -IC:\local\Canlib\INC -IC:\local\CANUSB\include
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_ENABLED=1
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-LC:\local\Canlib\Lib\MS -LC:\local\CANUSB\libs
set CXX=g++
set GCCGO=gccgo
set GO111MODULE=
set GOAMD64=v1
set GOARCH=amd64
set GOAUTH=netrc
set GOBIN=
set GOCACHE=C:\Users\roffe\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=
set GOENV=C:\Users\roffe\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\roffe\AppData\Local\Temp\go-build1362998156=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=NUL
set GOMODCACHE=C:\Users\roffe\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\roffe\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\go
set GOSUMDB=sum.golang.org
set GOTELEMETRY=off
set GOTELEMETRYDIR=C:\Users\roffe\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.24.0
set GOWORK=
set PKG_CONFIG=pkg-config

What did you do?

call a Windows DLL file and after a few minutes of running the software crashes. it can call the DLL hundreds of thousands of times some times before the crash happens. meaning it must be a race somewhere in CGO?

What did you see happen?

stacktrace.txt

What did you expect to see?

not a stack trace and application crash

[gabyhelp]

Related Issues

• cgo: program calling function defined in .dll causes panic #30675 (closed)
• Error when calling go DLL from go using cgo #36157 (closed)
• There was a panic when golang built the DLL and then used golang to call the DLL #49184 (closed)
• "Exception 0xc0000005", "runtime: unknown pc" on program exit with loaded windows dll #42593 (closed)
• Go build dll on Windows cause random panic. #34168 (closed)
• cmd/link: loading c-shared into Go program crashes on Windows #22192
• Compilation finished with exit code 2 for go 1.18.1 #53950 (closed)
• Go DLL with net package cause random panic #54644 (closed)
• cmd/cgo: crash when function received string with chinese characters #29653 (closed)
• cmd/link: panic opening c-shared DLL on windows #26084 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[JunyangShao]

@golang/compiler

[mknyszek]

In triage, we're looking at your stack trace and it looks a bit like there's a crash on the C side of things (in the DLL) and the Go side of things catches the OS-level exception thrown here. It doesn't really know what to do with it, because it's a crash on the C side, and there's no way at that point to get a stack trace.

We could possibly have a better error message here, but without a reproducer or additional information, I'm not sure we can do much to help.

[roffe]

In triage, we're looking at your stack trace and it looks a bit like there's a crash on the C side of things (in the DLL) and the Go side of things catches the OS-level exception thrown here. It doesn't really know what to do with it, because it's a crash on the C side, and there's no way at that point to get a stack trace.

We could possibly have a better error message here, but without a reproducer or additional information, I'm not sure we can do much to help.

I've played around some more, and it seems the DLL works fine without crashing if i do not run Fyne OpenGL GUI in the same application ( which also uses CGO )

May it be that the DLL crashes due to the go runtime getting corrupted or something due to multiple CGO things happening at the same time?

I can run the same code that crashes but in a separate application that i talk to over GRPC then there is no problem.

It's not very likely the DLL that is the actual problem as the DLL is used in production by thousands of companies in for example the automotive & robotics industry and i can run the same calls from a C++ project without crashes.

To reproduce it one needs to have a CANBUS adapter and set up a local CAN network that you can send and receive big amount of frames on, it's not reproducible in just code without the correct external hardware.

is it possible it's not the CANlib DLL that is crashing but just any of the C calls? I'm having a hard time figuring out where exactly it's actually crashing. is it the first entry in the stack trace that is the offender and everything after is just extra info?