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: internal compiler error: bad type: chan struct { v [65536]byte } #49767

Closed
burik666 opened this issue Nov 23, 2021 · 6 comments
Closed
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@burik666
Copy link

burik666 commented Nov 23, 2021

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

$ go version
go version go1.17.2 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/app/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2607095789=/tmp/go-build -gno-record-gcc-switches"

What did you do?

main.go

package main

func main() {
    ch := make(chan struct{ v [65536]byte })
    close(ch)
}

go build

What did you expect to see?

# t
./main.go:4:13: channel element type too large (>64kB)

What did you see instead?

# t
./main.go:4:12: internal compiler error: bad type: chan struct { v [65536]byte }
@heschi
Copy link
Contributor

heschi commented Nov 24, 2021

cc @danscales @randall77 @mdempsky

@heschi heschi added this to the Go1.18 milestone Nov 24, 2021
@heschi heschi added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 24, 2021
@griesemer
Copy link
Contributor

griesemer commented Nov 29, 2021

See #49771 for the possible remedies.

@gopherbot
Copy link

gopherbot commented Nov 30, 2021

Change https://golang.org/cl/367955 mentions this issue: cmd/compile: report channel size errors correctly for -G=3

gopherbot pushed a commit that referenced this issue Dec 2, 2021
First, we need to set base.Pos in varDecl() and typeDecl(), so it will
be correct if we need to report type size errors while converting types.
Changed error calls in types/sizes.go to use Errorf, not ErrorfAt, since
we want to use base.Pos (which will set from t.Pos(), if that is
available).

Second, we need to add an extra call CalcSize(t1.Elem()) in the
TCHANARGS case of CalcSize(). We can use CalcSize() rather than
CheckSize(), since we know the top-level recursive type will have been
calculated by the time we process the fake TCHANARGS type. In -G=0 mode,
the size of the channel element has often been calculated because of
some other processing (but not in the case of #49767). But in -G=3 mode,
we just calculate sizes during the single noder2 pass, so we are more
likely to have not gotten to calculating the size of the element yet,
depending on the order of processing of the deferredTypeStack.

Fixes the tests fixedbugs/issue{42058a,42058b}.go that were
disabled for -G=3 mode.

Had to add exceptions in stdlib_test.go for go/types and types2, because
the types2 typechecker does not know about type size limits.

Fixes #49814
Fixes #49771
Updates #49767

Change-Id: I77d058e8ceff68a58c4c386a8cf46799c54b04c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/367955
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
@danscales
Copy link
Contributor

danscales commented Dec 2, 2021

One part of my change https://golang.org/cl/367955 could be backported to 1.17 to fix this issue in 1.17. But the issue doesn't seem serious enough to require a backport. Let me know if anyone disagrees.

@griesemer
Copy link
Contributor

griesemer commented Dec 14, 2021

@danscales Is there anything left to do with this issue?

@danscales
Copy link
Contributor

danscales commented Dec 14, 2021

No, I don't think we need to backport the fix to 1.17 (since even though it is an internal compiler error, it gives a pretty good indication of what the problem is anyway). So, I'll close this. People can feel free to re-open if they really think we should backport to 1.17.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants