You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is basically a duplicate of the frozen issue #9240
It is not possible to call Win32 API functions that spawn new threads because the callback wrapper generated by syscall.NewCallback does not perform the needed steps to set up the call stack as needed by the Go runtime for a new thread unless "C" is imported.
Attempting to call such functions will cause the new thread to hang forever.
This can be easily reproduced with the following simple test program:
package main
import (
//"C" // Uncomment this and it works"fmt""syscall"
)
funcThreadProc(puintptr) uintptr {
fmt.Println("FOO")
return0
}
funcmain() {
modkernel32:=syscall.MustLoadDLL("kernel32.dll")
procCreateThread:=modkernel32.MustFindProc("CreateThread")
r1, _, _:=procCreateThread.Call(0, 0, syscall.NewCallback(ThreadProc), 0, 0, 0)
h:=syscall.Handle(r1)
syscall.WaitForSingleObject(h, syscall.INFINITE)
syscall.CloseHandle(h)
}
I'm re-raising this as we burned may hours over the past few days identifying why Windows callbacks weren't working, which turned out to be this issue.
At the very least syscall.NewCallback(..) should have a warning about this issue, but ideally we should fix this.
@rsc suggestion of always enabling "C" under Windows seems reasonable, if its an option.
The text was updated successfully, but these errors were encountered:
Sorry yes it Is I read, #9240 and the last thing was "gopherbot added the FrozenDueToAge label on Jun 25 2016" so I assumed it has been frozen without resolution, which is not the case. I'll add the repoduction case and info to #6751.
This is basically a duplicate of the frozen issue #9240
It is not possible to call Win32 API functions that spawn new threads because the callback wrapper generated by syscall.NewCallback does not perform the needed steps to set up the call stack as needed by the Go runtime for a new thread unless "C" is imported.
Attempting to call such functions will cause the new thread to hang forever.
This can be easily reproduced with the following simple test program:
I'm re-raising this as we burned may hours over the past few days identifying why Windows callbacks weren't working, which turned out to be this issue.
At the very least
syscall.NewCallback(..)
should have a warning about this issue, but ideally we should fix this.@rsc suggestion of always enabling "C" under Windows seems reasonable, if its an option.
The text was updated successfully, but these errors were encountered: