runtime: deadlock when calling a windows DLL with a callback

[jagobagascon]

What version of Go are you using (go version)?

$ go version
go version go1.19.1 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GO111MODULE=

set GOARCH=amd64

set GOBIN=

set GOCACHE=C:\Users\aritz\AppData\Local\go-build

set GOENV=C:\Users\aritz\AppData\Roaming\go\env

set GOEXE=.exe

set GOEXPERIMENT=

set GOFLAGS=

set GOHOSTARCH=amd64

set GOHOSTOS=windows

set GOINSECURE=

set GOMODCACHE=C:\Users\aritz\go\bin\pkg\mod

set GONOPROXY=github.com/saltosystems/*

set GONOSUMDB=github.com/saltosystems/*

set GOOS=windows

set GOPATH=C:/Users/aritz/go/bin

set GOPRIVATE=github.com/saltosystems/*

set GOPROXY=https://proxy.golang.org,direct

set GOROOT=C:\Program Files\Go

set GOSUMDB=sum.golang.org

set GOTMPDIR=

set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64

set GOVCS=

set GOVERSION=go1.19.1

set GCCGO=gccgo

set GOAMD64=v1

set AR=ar

set CC=gcc

set CXX=g++

set CGO_ENABLED=1

set GOMOD=C:\projects\bluetooth\go.mod

set GOWORK=

set CGO_CFLAGS=-g -O2

set CGO_CPPFLAGS=

set CGO_CXXFLAGS=-g -O2

set CGO_FFLAGS=-g -O2

set CGO_LDFLAGS=-g -O2

set PKG_CONFIG=pkg-config

set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\msys64\tmp\go-build3399795984=/tmp/go-build -gno-record-gcc-switches

What did you do?

I'm working on a library to call WinRT APIs on Windows, and I was trying to remove the need for CGO by replacing all calls to malloc and free by HeapAlloc and HeapFree (kernel32.dll).

Some APIs require callbacks to pass information back to the caller, and we were using CGO to allocate memory into the heap, and have the callbacks defined in C. So we may wait indefinitely for the callback to be called

This was working fine with CGO+malloc. But as soon as we switched to HeapAlloc without CGO, we are getting a fatal error: all goroutines are asleep - deadlock! error.

The problem seems related to #6751, but for some reason it is still failing for me.

This is a bit hard to reproduce, so I created this repo that includes two applications: https://github.com/jagobagascon/go-deadlock-example

They both scan for BLE devices (so you need bluetooth for it to work, if this is a problem I could probably find some other API wher it fails).
But one of them depends on the old malloc+CGO based WinRT API, and the other is pointing to a branch that calls the HeapAlloc function instead (no CGO required).

What did you expect to see?

Changing malloc for HeapAlloc should not cause a deadlock.

What did you see instead?

The same code fails when using HeapAlloc instead of malloc.

Related issues

Maybe #6751

[jagobagascon]

Just to add a bit more context. The PR that replaces malloc for HeapAlloc in the WinRT library is this: saltosystems/winrt-go#60

Apart from that, both applications that I added as example should behave exactly the same.

[prattmic]

I agree that this is related to #6751. We look for deadlocks in checkdead, which claims to account for callbacks from syscall.NewCallback. However from my quick look it seems that it will only account for them if a callback has been called at least once prior to checkdead (thus initializing extraMs).

This needs a closer look.

[jagobagascon]

Hi! This is a friendly ping to check the status of this issue.

We are really looking forward to get rid of CGO in our project and this is blocking us from doing it. We found out that adding a goroutine that stays alive during the execution of our callbacks fixes the issue:

go func() {
	<-time.After(24 * 365 * time.Hour)
}()

But to be honest I would like to avoid using that as a workaround.

[jkroepke]

There is an alternative solution?

However from my quick look it seems that it will only account for them if a callback has been called at least once prior to checkdead (thus initializing extraMs).

Do I need a go routine only until the callback was called once?