Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GOROOT=C:\Program Files\Go
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set CGO_CFLAGS=-g -O2
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
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.
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.
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).