runtime: crash/hang on startup in buildmode=c-shared amd64 DLL when run on ARM64 windows 11. #60996
Labels
arch-arm64
compiler/runtime
Issues related to the Go compiler and/or runtime.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Windows
Milestone
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes. Confirmed behavior with go1.21rc2 also.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Pre-reqs:
Steps to reproduce as follows:
mindll.go
compile it
c_call.c
Compile it (no CFGuard)
ccall_nocfg.bat
Run ccall_nocfg.bat for a while, runs fine, no issues.
Compile caller with CFGuard on
ccall_withcfg.bat
Run ccall_withcfg.bat, process crashes/hangs quite quickly, anywhere from 5th to 20th run. Then keeps crashing throughout, every 5-20 runs or so.
What did you expect to see?
The C process and Go DLL running reliably 100%
What did you see instead?
The process hanging/crashing after LoadLibrary and/or at first DLL function call (Fred) every 5-20 runs.
Workarounds (& why they are workarounds)
Notes
This behavior does not happen when a minimal C-DLL is substituted for the Go DLL above, regardless of whether or not the test C DLL has control flow guard enabled or disabled.
There is only one Go runtime in the process as the 'mothership' is either a python or C exe.
I am not freeing or attempting to unload the Go DLL at all.
The process briefly hangs then suddenly exits and no errors, stacktraces or anything are printed. Also nothing in the Windows event log, which seems to imply that Go is eating the exception and calling ExitProcess?
I see support for CFG itself IN go was deemed not-useful here cmd/compile: add control flow integrity options #35940 however interactions with CFG when GO is a DLL do possibly still need to be addressed.
(Speculation) perhaps this issue is similar to that of runtime: TLS slot index over 64 and crash #59213 however this issue is still present in Go 1.21rc2
The text was updated successfully, but these errors were encountered: