-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: build -gcflags all="-N -l" nil pointer dereference #46386
Comments
I can reproduce this even without The good news is that it never crashes the tip compiler (or at least is significantly less frequent there, I could never make it crash). Can you reproduce this on tip? |
Looks like there is an interface type that the compiler thinks is an empty interface, but still has a method. That looks bad. The type is an empty interface with a It's basically
(But that by itself doesn't reproduce the problem - there's something more to it.) I'm pretty sure this is not a problem at tip. Looks like @danscales fixed it (probably by accident) at https://go-review.googlesource.com/c/go/+/307209 The empty interface check changed from:
to
I think "fixed it" is probably too strong - maybe it is just papering over an invariant that should hold but doesn't. |
Shorter reproducible:
|
If I add this code to
Then
|
@randall77 and still problem at tip |
@cuonglm I'm not able to reproduce with your test case. Can you give more details on repro'ing? I'm using Go 1.16.3, and trying to run A bit more broadly, typecheck has certainly had issues with interface cycles in the past, and it sounds like this isn't a regression in behavior. If we can get a reliable repro, that would be great. But for the time being, I think it makes sense to leave this for Go 1.18 and revisit iff it's still an issue after switching to types2. |
@mdempsky you have to use Without
isn't appeared in |
@cuonglm I see, thanks. I can repro with |
@mdempsky problem also happens with types2. With
Interesting that using |
Change https://golang.org/cl/323649 mentions this issue: |
Change https://golang.org/cl/326029 mentions this issue: |
While processing signatset, the entry is deleted immediately after being pushed to signatslice. Then calling writeType may add the same type to signatset again. That would add more works, though not a big impact to the performace, since when writeType is guarded by s.Siggen() check. Instead, we should keep the entry in signatset, so written type will never be added again. This change does not affect compiler performace, but help debugging issue like one in #46386 easier. Change-Id: Iddafe773885fa21cb7003ba27ddf9554fc3f297d Reviewed-on: https://go-review.googlesource.com/c/go/+/326029 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
What version of Go are you using (
go version
)?Reproduced on two developer machines, one Ubuntu and one Mac.
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?Two outputs, one Ubuntu and one Mac:
go env
OutputWhat did you do?
Archive.zip
I've attached as small of an example as I can get - the error seems to be extremely picky to whitespace - sometimes adding or removing a comment breaks things. I cannot reproduce the error with all code in one file.
The go:noinline are part of debugging what turned out to be a display glitch in GoLand's debugger, trying to create a minimal example in order to reproduce that bug, however now it just breaks the Go compiler.
The gcflags in the following example are what GoLand uses when producing an executable for debugging.
go build -gcflags all="-N -l" *.go
What did you expect to see?
Successful compilation
What did you see instead?
The text was updated successfully, but these errors were encountered: