Note that the dll and proc instantiation should probably be outside the function, something like:

var (
	dllCrypt  = syscall.NewLazyDLL("Crypt32.dll")
	dllKernel = syscall.NewLazyDLL("Kernel32.dll")

	procDecryptData = dllCrypt.NewProc("CryptUnprotectData")
	procLocalFree   = dllKernel.NewProc("LocalFree")
)

// chrome < 80 https://chromium.googlesource.com/chromium/src/+/76f496a7235c3432983421402951d73905c8be96/components/os_crypt/os_crypt_win.cc#82
func DPApi(data []byte) ([]byte, error) {
	var outBlob dataBlob
	r, _, err := procDecryptData.Call(uintptr(unsafe.Pointer(NewBlob(data))), 0, 0, 0, 0, 0, uintptr(unsafe.Pointer(&outBlob)))
	if r == 0 {

But, it looks like a compiler bug nevertheless.

Error message looks the same as #44355.

Thanks for the detailed issue. I think you're right that this is a duplicate of #44355. I'll close this in lieu of that issue.

I think this is an interesting case to mention there though.

Issue #44355 is pretty narrow: it should only affect inlinable functions that explicitly name all of their result parameters as blank (i.e., _), and then contain a single return statement. Are there any functions like that in consideration here?

It would be great to have a standalone reproducer for this issue. Ideally one that can be built from Linux (e.g., using GOOS=windows is fine, but without requiring cgo).

(FWIW, "Value live at entry" is a pretty generic catch-all failure that happens later in the compiler when almost anything goes wrong in the frontend and we didn't catch it sooner to give a more descriptive error report. So I don't recommend using that alone to deduplicate issues.)

Windows reproducer (based on the initial cause in https://github.com/moonD4rk/HackBrowserData/blob/6a11361e1dbf0c3e455ccb06a4f31d073f7d8e8e/core/decrypt/decrypt_windows.go):

package decrypt

import (
	"syscall"
	"unsafe"
)

type dataBlob struct {
	cbData uint32
	pbData *byte
}

func (b *dataBlob) ToByteArray() []byte {
	d := make([]byte, b.cbData)
	copy(d, (*[1 << 30]byte)(unsafe.Pointer(b.pbData))[:])
	return d
}

var dllKernel = syscall.NewLazyDLL("Kernel32.dll")

func Call(data []byte) ([]byte, error) {
	procLocalFree := dllKernel.NewProc("LocalFree")
	var outBlob dataBlob
	defer procLocalFree.Call(uintptr(unsafe.Pointer(outBlob.pbData)))
	return outBlob.ToByteArray(), nil
}

Thanks @egonelbre! Further minimized, and confirmed it reproduces on Linux with GOOS=windows:

package decrypt

import (
	"syscall"
	"unsafe"
)

var dllKernel = syscall.NewLazyDLL("Kernel32.dll")

func Call() {
	procLocalFree := dllKernel.NewProc("LocalFree")
	defer procLocalFree.Call(uintptr(unsafe.Pointer(nil)))
}

Notably, it doesn't reproduce with -gcflags=-N.

/cc @cuonglm

Oh, in the fix for #24491, we only fixed direct function calls. We forgot that for method calls, there's a receiver argument that needs to be passed through the wrapper function too.

@gopherbot Backport to Go 1.16. Compiler crash on valid Windows code that compiled with Go 1.15.

@mdempsky I think you have to say "please" or the gopherbot won't listen to you. A somewhat questionable design decision...

@gopherbot Please backport to Go 1.16.

Compiler crash on valid Windows code that compiled with Go 1.15.

Backport issue(s) opened: #44463 (for 1.15), #44464 (for 1.16).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

Change https://golang.org/cl/294849 mentions this issue: cmd/compile: fix mishandling of unsafe-uintptr arguments with call method in go/defer

Change https://golang.org/cl/296489 mentions this issue: [release-branch.go1.16] cmd/compile: fix mishandling of unsafe-uintptr arguments with call method in go/defer

Reopening because the fix is incomplete in the presence of non-open-coded defers.

It looks like it only worked for open-coded defers because open-coded defers already keep their arguments alive past the deferred call:

Failing test case using open-coded defer: https://play.golang.org/p/9SEiOeaLmCS

Passing test case using heap-allocated defer: https://play.golang.org/p/BWEQuC5EowK

Issue with open-coded defers reported as #44623.

As for CL 296489, I think the issue was that when we rewrite t.M(...) into T.M(t, ...), we lose the escape analysis tags. This wasn't an issue for the existing code, because it happens after escape analysis tags are needed; but with CL 296489, the escape analysis tags were still needed within the generated wrapper so it would know to insert the keepalives.

Two possible options I see are:

1. When we create the signature type for method expressions (e.g., T.M), we need to preserve the method's escape analysis tags. (I think there's an outstanding issue still about this too.) Caution: We need to be careful about the receiver argument's tags.
2. Instead of rewriting method calls into a function calls with method expressions when wrapping them, we could keep the original method call. This requires extending the wrapCall logic to also pass the receiver argument through the closure.

I was initially thinking 2 would be the easier and safer option; but if option 1 isn't too invasive, I think that might be better actually.

As for a test case, locally I've just added:

       func() {
               s := &S{}
               for {
                       defer s.test("defer method loop", uintptr(setup()), uintptr(setup()), uintptr(setup()), uintptr(setup()))
                       break
               }
       }()
       <-done

It would probably make sense to add a similar variant for normal deferred calls too. (On the upside, these are at least already handled correctly.)

@mdempsky FYI, the fix in CL 296569 is the 2nd.

@mdempsky I'm leaning to doing 2nd option for now, so the fix and the backports CL will be in synced. Then we can refactoring to 1st option later.

Change https://golang.org/cl/296490 mentions this issue: cmd/compile: fix mishandling of unsafe-uintptr arguments with call method in go/defer

Change https://golang.org/cl/296769 mentions this issue: [release-branch.go1.16] cmd/compile: fix mishandling of unsafe-uintptr arguments with call method in go/defer