cmd/compile: <autogenerated>:1:0: invalid instruction: 00000 (/home/xxx/main.go:8) MOVQ $0, "".n+2147483680(SP)

[limpo1989]

What version of Go are you using (go version)?

go version go1.10.2 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

go build main.go

What did you see instead?

# command-line-arguments
<autogenerated>:1:0: invalid instruction: 00000 (/home/xxx/main.go:8) MOVQ    $0, "".n+2147483680(SP)
<autogenerated>:1:0: invalid instruction: 00003 (/home/xxx/main.go:8) MOVUPS  X0, "".err+2147483688(SP)

cat main.go

package main

type aa struct {
        // 1024 * 1024 * 255 is ok.
        I [1024 * 1024 * 256]int
}

// change to pointer receiver is no compiler error.
// func(a *aa) Write(p []byte) (n int, err error) 
func (a aa) Write(p []byte) (n int, err error) {
        return
}

func main() {
}

[bcmills]

CC: @dr2chase @randall77

[josharian]

If this works on any recent release, it’d be super helpful if someone wanted to bisect.

[randall77]

I don't think we ever expect this to work. You're putting a 2GB object on the stack. We limit stacks to 1GB.
We could go through heroics to make this work by modifying the calling convention to keep big arguments and return values on the heap and pass pointers to them around. Seems like a lot more work than benefit.

We could obviously use a better error message. We should detect bad cases like this earlier in compilation, before we try to make a stack frame so big that instructions can't address it.

[bcmills]

I don't think we ever expect this to work. You're putting a 2GB object on the stack. We limit stacks to 1GB.

If I'm reading correctly it's only 256MiB, and it works in the playground: https://play.golang.org/p/IpWRtSqV26f

[limpo1989]

@bcmills your code is running amd64p32 architecture .
sizeof(int) == 4
256MB * 4 = 1024MB

[bcmills]

Ah, oops. I had missed that the array was int rather than byte.

[josharian]

I thought we had a check for large stack frames already: const maxStackSize = 1 << 30 in pgen.go. I’m on my phone, but maybe someone could check why that isn’t triggering.

[randall77]

@josharian Looks like the stack size check is for the frame of the function itself. It does not include the size of the arguments, which would be part of the parent function. So we would fail if there were a call to Write, but compiling Write itself doesn't hit the maxStackSize check.

[gopherbot]

Change https://golang.org/cl/115036 mentions this issue: cmd/compile: reject large argument areas