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

Comment From: gabyhelp

Related Issues

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

Comment From: JunyangShao

@golang/compiler

Comment From: 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.

Comment From: 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?

Comment From: roffe

i guess this will just get burried like all the other cgo problems people report

Comment From: randall77

We bury lots of non-cgo problems too :)

But on the serious side, we're not working on this because we don't have enough information to make any progress on it. Hence the "WaitingForInfo" label. Without a reproducer, there's not much we can do.

Comment From: cherrymui

Fyne OpenGL GUI

Some GUI library requires running on the main thread. Are you making calls to it always from the main thread? Do you use runtime.LockOSThread (if not, you may want to)?

Comment From: gopherbot

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)