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
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