CC @golang/compiler, @golang/windows.

I grabbed the built binaries from a couple GitHub Actions repro/no-repro runs, but dockerd.exe is 31 MB compressed (25 MB max on GitHub), so I'll have to find some storage to host these if that is necessary to reasonably poke at this. They're currently up at failure, success but I don't know what the retention period is.

For now, I ran go tool objdump on the top two funcs: https://gist.github.com/dagood/374b949bf8e9bf636cb9e027f79db698. Not a clean diff, but maybe there's something easy to spot here.

@dagood

Interestingly CreateAcceleratorTableW also reports ERROR_NOACCESS in #64729 . :-)

Perhaps it is something related to garbage collector.

Alex

Thanks for the pointer @alexbrainman. The issue #64729 has the same failure mode as this one, and an easier reproducer. I'm pretty sure that the root cause in both cases is the same as in CL 549256): one of the parameter's memory is not correctly aligned. In fact, ERROR_NOACCESS can be returned when the kernel detects a STATUS_DATATYPE_MISALIGNMENT error.

For this particular issue, the problem is in the winio.FileBasicInfo definition:

type FileBasicInfo struct {
	CreationTime, LastAccessTime, LastWriteTime, ChangeTime windows.Filetime
	FileAttributes                                          uint32
	_                                                       uint32 // padding
}

The Go compiler uses an alignment of 4 bytes, as windows.Filetime is a struct containing two uint32 values. On the other hand, the C compiler uses an alignment of 8 bytes, as FileBasicInfo defines the time properties using LARGE_INTEGER, which is a uint64.

This is not the first time that windows.Filetime causes alignment issues, and it's a difficult generic fix unless #19057 is approved.

The solution here, if I'm not wrong, is to apply the same fix as in https://go-review.googlesource.com/c/go/+/549256 (attn @bcmills). To avoid making a breaking change in go-winio, I would suggest doing something like this:

// SetFileBasicInfo sets times and attributes for a file.
func SetFileBasicInfo(f *os.File, bi *FileBasicInfo) error {
        var tmp = struct {
	      CreationTime, LastAccessTime, LastWriteTime, ChangeTime uint64
	      FileAttributes                                          uint32
	      _                                                       uint32 // padding
        }{bi.CreationTime, bi.LastAccessTime, bi.LastWriteTime, bi.ChangeTime, bi.FileAttributes} // This doesn't compile, but you get the idea.

	if err := windows.SetFileInformationByHandle(
		windows.Handle(f.Fd()),
		windows.FileBasicInfo,
		(*byte)(unsafe.Pointer(&tmp)),
		uint32(unsafe.Sizeof(tmp)),
	); err != nil {
		return &os.PathError{Op: "SetFileInformationByHandle", Path: f.Name(), Err: err}
	}
	runtime.KeepAlive(f)
	return nil
}

@dagood, could you fork go-winio, apply the suggested changes, update moby's go.mod and re-run the tests to see if this solves the issue?

Nice, that works! Thanks. Specifically, tried this:

	merge := func(t windows.Filetime) uint64 {
		return *(*uint64)(unsafe.Pointer(&t))
	}
	biAligned := struct {
		CreationTime, LastAccessTime, LastWriteTime, ChangeTime uint64
		FileAttributes                                          uint32
		_                                                       uint32 // padding
	}{
		merge(bi.CreationTime), merge(bi.LastAccessTime), merge(bi.LastWriteTime), merge(bi.ChangeTime),
		bi.FileAttributes,
		0,
	}

	if err := windows.SetFileInformationByHandle(
		windows.Handle(f.Fd()),
		windows.FileBasicInfo,
		(*byte)(unsafe.Pointer(&biAligned)),
		uint32(unsafe.Sizeof(biAligned)),

I suppose we can't say 100% conclusively that this is the cause just because CI passes (adding a fmt call causes it to pass, too) but the logic certainly makes sense. 🙂 I didn't notice the alignment effect of syscall.Filetime -> int64 in that CL--was focused on the _ uint32 (which was already present here) and the bad uintptr.

So, I suppose this was caused by the location of bi happening to be misaligned rather than aligned when built by go1.22rc1... and as far as I know, this could be caused by a huge variety of perfectly fine changes, so there isn't much point tracking that down.

Perhaps go-winio can also add tests that check the alignment of the structs as Go sees them vs. the actual C headers (or at least vs. hand-written values derived from the docs).

Closing: not a Go bug.

So, I suppose this was caused by the location of bi happening to be misaligned rather than aligned when built by go1.22rc1... and as far as I know, this could be caused by a huge variety of perfectly fine changes, so there isn't much point tracking that down.

Reading the nice 1.22 release notes, it looks like it's probably related to this:

... this change adjusts the size class boundaries of the memory allocator ...

A consequence of this change is that some objects' addresses that were previously always aligned to a 16 byte (or higher) boundary will now only be aligned to an 8 byte boundary. Some programs that use assembly instructions that require memory addresses to be more than 8-byte aligned and rely on the memory allocator's previous alignment behavior may break, but we expect such programs to be rare. Such programs may be built with GOEXPERIMENT=noallocheaders to revert to the old metadata layout and restore the previous alignment behavior, but package owners should update their assembly code to avoid the alignment assumption, as this workaround will be removed in a future release.

The numbers aren't quite the same, but it's the same pattern: this was code that relied on Go using 8 byte (or higher) alignment even though the struct itself only specifies 4 byte alignment.

Mentioning in this thread in case anyone finds this issue later without context, or if anyone already here was interested.