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: unexpected error about conflicting package heights #25568

Closed
ysmolski opened this issue May 25, 2018 · 8 comments
Closed

cmd/compile: unexpected error about conflicting package heights #25568

ysmolski opened this issue May 25, 2018 · 8 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone

Comments

@ysmolski
Copy link
Member

ysmolski commented May 25, 2018

While trying to remove use of perl from test/fixedbugs/bug345.go, I have encountered following behaviour about conflicting package heights.

cd go/test
go tool compile -e -D . -I . fixedbugs/bug345.dir/io.go
go tool compile -e -D . -I . fixedbugs/bug345.dir/main.go
fixedbugs/bug345.dir/main.go:9:2: internal compiler error: conflicting package heights 4 and 0 for path "io"

goroutine 1 [running]:
runtime/debug.Stack(0x0, 0x0, 0x0)
	/Users/thorn/golang/src/runtime/debug/stack.go:24 +0xa7
cmd/compile/internal/gc.Fatalf(0x18bdf99, 0x31, 0xc000333038, 0x3, 0x3)
	/Users/thorn/golang/src/cmd/compile/internal/gc/subr.go:182 +0x1f7
cmd/compile/internal/gc.iimport(0xc000086730, 0xc00006cbd0)
	/Users/thorn/golang/src/cmd/compile/internal/gc/iimport.go:156 +0xc71
cmd/compile/internal/gc.importfile(0xc000333578, 0x0)
	/Users/thorn/golang/src/cmd/compile/internal/gc/main.go:1128 +0xb63
cmd/compile/internal/gc.(*noder).importDecl(0xc00032a090, 0xc00006f6e0)
	/Users/thorn/golang/src/cmd/compile/internal/gc/noder.go:285 +0x7c
cmd/compile/internal/gc.(*noder).decls(0xc00032a090, 0xc0003485c0, 0x4, 0x4, 0xc0000622f8, 0xc00033170d, 0xc000024500)
	/Users/thorn/golang/src/cmd/compile/internal/gc/noder.go:261 +0x174
cmd/compile/internal/gc.(*noder).node(0xc00032a090)
	/Users/thorn/golang/src/cmd/compile/internal/gc/noder.go:239 +0xbd
cmd/compile/internal/gc.parseFiles(0xc000088060, 0x1, 0x1, 0x2)
	/Users/thorn/golang/src/cmd/compile/internal/gc/noder.go:57 +0x36f
cmd/compile/internal/gc.Main(0x18c42e0)
	/Users/thorn/golang/src/cmd/compile/internal/gc/main.go:468 +0x1c38
main.main()
	/Users/thorn/golang/src/cmd/compile/main.go:51 +0x96

https://github.com/golang/go/blob/master/test/fixedbugs/bug345.dir/io.go
https://github.com/golang/go/blob/master/test/fixedbugs/bug345.dir/main.go

I am not sure if it's a bug or expected feature.

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

go version devel +30b6bc30b2 Thu May 24 22:08:00 2018 +0000 darwin/amd64

OARCH="amd64"
GOBIN=""
GOCACHE="/Users/thorn/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/thorn/go"
GORACE=""
GOROOT="/Users/thorn/golang"
GOTMPDIR=""
GOTOOLDIR="/Users/thorn/golang/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/km/50gy6_q557v6_7vxbf9b29v00000gn/T/go-build645753215=/tmp/go-build -gno-record-gcc-switches -fno-common"
@ysmolski ysmolski added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 25, 2018
@ysmolski
Copy link
Member Author

@griesemer, could you give me some hint, if this looks like a bug in a compiler or rather wrong usage of the compiler?

@neild
Copy link
Contributor

neild commented May 25, 2018

This is a bug triggered by https://go-review.googlesource.com/c/go/+/106797. I thought there was an existing issue filed for it, but I'm not finding one.

@ysmolski
Copy link
Member Author

@neild thanks for pointing to that. adding "-iexport=false" affects the problem but does not "fixes" it at all. Since the rest of stdlib was compiled with -iexport=true, the tested package cannot be compiled. I am a little lost here now. Not sure if that is a bug that should be fixed..

ping @mdempsky

@griesemer
Copy link
Contributor

@ysmolsky This is a bug if it appears when all involved source is compiled with the latest compiler version (tip) - which I assume is the case.

@ysmolski
Copy link
Member Author

ysmolski commented May 29, 2018

Yes, if I run the same sequence of commands with the commit prior CL 106797 I see the desired output from the compiler:

../test/fixedbugs/bug345.dir/main.go:9:2: inconsistent definition for type io.Writer during import
	interface { Write([]byte) (int, error) } (in "bufio")
	interface { WrongWrite() } (in "io")

I have verified that bisecting leads to CL 106797 as a bad commit

@griesemer
Copy link
Contributor

@ysmolsky I can reproduce it but as is this is not a bug after all: You are providing additional compiler flags (-D, -I) and they are set relative to the current (test) directory. For one, it doesn't appear that those paths can be relative (at least it doesn't work for me) though that is unrelated: In your command line you're not providing the correct path for -D. Furthermore, you don't need -I here. (You also don't need -D if you do everything in bug345.dir).

That is, what happens is that you don't get the correct "io" packages here.

I get correct behavior if I choose one of two options:

A) Do everything in the local directory:

  1. cd $GOROOT/test/fixedbugs/bug345.dir
  2. go tool compile io.go
  3. go tool compile main.go
    => expected error messages

B) Do everything in the go/test directory, without or with correct -D argument:

  1. cd $GOROOT/test
  2. go tool compile fixedbugs/bug345.dir/io.go
  3. go tool compile fixedbugs/bug345.dir/main.go
    => expected error messages

Or provide a -D as in:
3) go tool compile -D $GOROOT/test/fixedbugs/bug345.dir fixedbugs/bug345.dir/main.go
=> expected error messages

Thus I think this is working as intended. (Feel free to re-open if you disagree.)

@griesemer
Copy link
Contributor

PS: That said, perhaps the compiler should exit with a better error message rather than an internal compiler error. I filed #25635 as a follow-up .

@ysmolski
Copy link
Member Author

@griesemer thank you for insights. I will try to convert a go test avoiding triggering this panic error.

@golang golang locked and limited conversation to collaborators May 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Development

No branches or pull requests

5 participants