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.

Sign up for GitHub

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

Jump to bottom

cmd/compile: crash with map[interface{}]interface{} with nil #12536

Closed
robpike opened this issue Sep 8, 2015 · 3 comments
Closed

cmd/compile: crash with map[interface{}]interface{} with nil #12536

robpike opened this issue Sep 8, 2015 · 3 comments
Labels
FrozenDueToAge
Milestone
Go1.5.2

Comments

@robpike
Copy link
Contributor

robpike commented Sep 8, 2015

Reported on golang-nuts, this program crashes the compiler in 1.5

package main

import "fmt"

func main() {
    // This compiles and runs correctly
    foo := map[interface{}]interface{}{
        nil:  0,
        true: 1,
    }

    // But if you swap the keys around, it panics
    /*
        foo := map[interface{}]interface{}{
            nil:  0,
            true: 1,
        }
    */
    fmt.Println(len(foo))
}
@bits01
Copy link

bits01 commented Sep 8, 2015

Playground example that shows the crash:
https://play.golang.org/p/B8aRUyVvFW

And the crash trace:

panic: interface conversion: interface is nil, not bool

goroutine 1 [running]:
cmd/compile/internal/gc.keydup(0xc8201a42d0, 0xc820087f90)
    /usr/local/go/src/cmd/compile/internal/gc/typecheck.go:2882 +0x6f1
cmd/compile/internal/gc.typecheckcomplit(0xc820088528)
    /usr/local/go/src/cmd/compile/internal/gc/typecheck.go:3073 +0x1d31
cmd/compile/internal/gc.typecheck1(0xc820088d00, 0x4)
    /usr/local/go/src/cmd/compile/internal/gc/typecheck.go:841 +0x6aad
cmd/compile/internal/gc.typecheck(0xc82019eea8, 0x4, 0x5f6512)
    /usr/local/go/src/cmd/compile/internal/gc/typecheck.go:202 +0x939
cmd/compile/internal/gc.typecheckas(0xc82019eea0)
    /usr/local/go/src/cmd/compile/internal/gc/typecheck.go:3320 +0xae
cmd/compile/internal/gc.typecheck1(0xc8200899d8, 0x2)
    /usr/local/go/src/cmd/compile/internal/gc/typecheck.go:2055 +0x490b
cmd/compile/internal/gc.typecheck(0xc82017f400, 0x2, 0x0)
    /usr/local/go/src/cmd/compile/internal/gc/typecheck.go:202 +0x939
cmd/compile/internal/gc.typechecklist(0xc82017f400, 0x2)
    /usr/local/go/src/cmd/compile/internal/gc/typecheck.go:43 +0x3e
cmd/compile/internal/gc.Main()
    /usr/local/go/src/cmd/compile/internal/gc/lex.go:396 +0x20ab
cmd/compile/internal/amd64.Main()
    /usr/local/go/src/cmd/compile/internal/amd64/galign.go:127 +0x58d
main.main()
    /usr/local/go/src/cmd/compile/main.go:26 +0x189

@ianlancetaylor ianlancetaylor added this to the Go1.5.2 milestone Sep 8, 2015
@gopherbot
Copy link
Contributor

CL https://golang.org/cl/14400 mentions this issue.

@gopherbot
Copy link
Contributor

CL https://golang.org/cl/16965 mentions this issue.

aclements pushed a commit that referenced this issue Nov 17, 2015
@randall77 @aclements
[release-branch.go1.5] cmd/compile/internal/gc: handle weird map lite…
095710b 
…rals in key dedup

We compute whether two keys k1 and k2 in a map literal are duplicates by
constructing the expression OEQ(k1, k2) and calling the constant
expression evaluator on that expression, then extracting the boolean
result.

Unfortunately, the constant expression evaluator can fail for various
reasons.  I'm not really sure why it is dying in the case of 12536, but
to be safe we should use the result only if we get a constant back (if
we get a constant back, it must be boolean).  This probably isn't a
permanent fix, but it should be good enough for 1.5.2.

A permanent fix would be to ensure that the constant expression
evaluator can always work for map literal keys, and if not the compiler
should generate an error saying that the key isn't a constant (or isn't
comparable to some specific other key).

This patch has the effect of allowing the map literal to compile when
constant eval of the OEQ fails.  If the keys are really equal (which the
map impl will notice at runtime), one will overwrite the other in the
resulting map.  Not great, but better than a compiler crash.

Fixes #12536

Change-Id: Ic151a5e3f131c2e8efa0c25c9218b431c55c1b30
Reviewed-on: https://go-review.googlesource.com/14400
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/16965
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
@golang golang locked and limited conversation to collaborators Nov 16, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.5.2
Development

No branches or pull requests
4 participants
@ianlancetaylor @robpike @gopherbot @bits01