Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
limpo1989 opened this issue May 23, 2018 · 10 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@limpo1989
Copy link

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
Copy link
Contributor

bcmills commented May 23, 2018

CC: @dr2chase @randall77

@bcmills bcmills changed the title <autogenerated>:1:0: invalid instruction: 00000 (/home/xxx/main.go:8) MOVQ $0, "".n+2147483680(SP) cmd/compile: <autogenerated>:1:0: invalid instruction: 00000 (/home/xxx/main.go:8) MOVQ $0, "".n+2147483680(SP) May 23, 2018
@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 23, 2018
@bcmills bcmills added this to the Go1.11 milestone May 23, 2018
@josharian
Copy link
Contributor

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

@randall77
Copy link
Contributor

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
Copy link
Contributor

bcmills commented May 23, 2018

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
Copy link
Author

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

@bcmills
Copy link
Contributor

bcmills commented May 23, 2018

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

@josharian
Copy link
Contributor

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
Copy link
Contributor

@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.

@randall77 randall77 self-assigned this May 29, 2018
@randall77 randall77 added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 29, 2018
@gopherbot
Copy link

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

@gopherbot
Copy link

Change https://golang.org/cl/115195 mentions this issue: cmd/compile: include callee args section when checking frame too large

gopherbot pushed a commit that referenced this issue Jun 2, 2018
The stack frame includes the callee args section. At the point where
we were checking the frame size, that part of the frame had not been
computed yet. Move the check later so we can include the callee args size.

Fixes #20780
Update #25507

Change-Id: Iab97cb89b3a24f8ca19b9123ef2a111d6850c3fe
Reviewed-on: https://go-review.googlesource.com/115195
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
@golang golang locked and limited conversation to collaborators May 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants