Skip to content

x/sys/windows: debugger on windows/arm64 errors with "syscall.Syscall15: nosplit stack over 792 byte limit" #78317

@AlexxIT

Description

@AlexxIT

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugReportIssues describing a possible bug in the Go implementation.FixPendingIssues that have a fix which has not yet been reviewed or submitted.OS-Windowscompiler/runtimeIssues related to the Go compiler and/or runtime.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status
    Done

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions