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

Comments

Projects
None yet
5 participants
@limpo1989
Copy link

commented May 23, 2018

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

This comment has been minimized.

Copy link
Member

commented May 23, 2018

@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 this to the Go1.11 milestone May 23, 2018

@josharian

This comment has been minimized.

Copy link
Contributor

commented May 23, 2018

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

@randall77

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Author

commented May 23, 2018

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

@bcmills

This comment has been minimized.

Copy link
Member

commented May 23, 2018

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

@josharian

This comment has been minimized.

Copy link
Contributor

commented May 23, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 29, 2018

@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

@gopherbot

This comment has been minimized.

Copy link

commented May 29, 2018

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

@gopherbot gopherbot closed this in d15d055 May 29, 2018

@gopherbot

This comment has been minimized.

Copy link

commented May 29, 2018

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

cmd/compile: include callee args section when checking frame too large
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.