This error occurs in a specific environment - running a Go 1.26 application in a debugger on windows/arm64.
Application:
package main
import (
"golang.org/x/sys/windows"
)
var (
kernel32 = windows.NewLazyDLL("kernel32.dll")
procGetConsoleScreenBufferInfo = kernel32.NewProc("GetConsoleScreenBufferInfo")
)
func main() {
// This is dumb code, the condition won't even be true.
if kernel32.Name == "" {
procGetConsoleScreenBufferInfo.Call() // the problematic line
}
}
If you run this application in a debugger on windows/arm64, it will crash with an error. The main function won't even be called.
syscall.Syscall15: nosplit stack over 792 byte limit
syscall.Syscall15<1>
grows 288 bytes, calls syscall.syscalln<1>
grows 48 bytes, calls runtime.cgocall<1>
grows 112 bytes, calls runtime.entersyscall<1>
...
The full text of the error (about 90 lines) is similar to this issue - #69813
What causes the error
- Go toolchain 1.26 and later, this does not occur in version 1.25.
windows/arm64 build, this does not occur on windows/amd64 build.
- Debugger, there won't be any problems if you just run the binary.
- The presence of the line
procGetConsoleScreenBufferInfo.Call(), this does not occur if you comment it out.
- Using
import "golang.org/x/sys/windows". This is not repeated if you use import syscall (syscall.NewLazyDLL).
As you can see from my example, there’s no need for the code to actually run. The main thing is that the code gets into the binary.
How I came to this
I use windows/arm64 for development. And the zerolog library in my app. It has zerolog.ConsoleWriter. Which uses the go-colorable library.
When I upgraded to Go 1.26, my debugger started crashing with an error. While investigating the cause, I realized that the error occurs with go-colorable@v0.1.14. However, there is no error in go-colorable@v0.1.13. The difference lies precisely in the switch from import syscall to import "golang.org/x/sys/windows" - diff.
Possible solutions
- Using the older version of Go 1.25 for compilation
- Using an older version of the library
go-colorable@v0.1.13
Debugger version
> dlv version
Delve Debugger
Version: 1.26.0
Build: 0b1c520a8af69b60d74152238bc162739d269f4e
This error occurs in a specific environment - running a Go 1.26 application in a debugger on
windows/arm64.Application:
If you run this application in a debugger on
windows/arm64, it will crash with an error. Themainfunction won't even be called.The full text of the error (about 90 lines) is similar to this issue - #69813
What causes the error
windows/arm64build, this does not occur onwindows/amd64build.procGetConsoleScreenBufferInfo.Call(), this does not occur if you comment it out.import "golang.org/x/sys/windows". This is not repeated if you useimport syscall(syscall.NewLazyDLL).As you can see from my example, there’s no need for the code to actually run. The main thing is that the code gets into the binary.
How I came to this
I use
windows/arm64for development. And the zerolog library in my app. It has zerolog.ConsoleWriter. Which uses the go-colorable library.When I upgraded to Go 1.26, my debugger started crashing with an error. While investigating the cause, I realized that the error occurs with
go-colorable@v0.1.14. However, there is no error ingo-colorable@v0.1.13. The difference lies precisely in the switch fromimport syscalltoimport "golang.org/x/sys/windows"- diff.Possible solutions
go-colorable@v0.1.13Debugger version