dep init: panic: runtime error: slice bounds out of range

[eparis]

checkout github.com/kubernetes/kubernetes @ db2dc78e6398ba673e68e94bd17d28a97dd4a902
run godep restore to make GOPATH == what's in vendor
inside kubernetes rm -rf vendor Godeps
inside $GOPATH/src/github.com/chai2010/gettext-go make sure that https://github.com/chai2010/gettext-go/pull/7 has been applied
dep init from version 21f357a

$ dep init
panic: runtime error: slice bounds out of range

goroutine 1 [running]:
panic(0x7a3fc0, 0xc420012120)
    /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).unselectLast(0xc420ac4a50, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    /storage/gopath/src/github.com/golang/dep/vendor/github.com/sdboyer/gps/solver.go:1130 +0x68e
github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).backtrack(0xc420ac4a50, 0xc4204ab2a0)
    /storage/gopath/src/github.com/golang/dep/vendor/github.com/sdboyer/gps/solver.go:881 +0x13e
github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).solve(0xc420ac4a50, 0x0, 0x0, 0xc421378ff0)
    /storage/gopath/src/github.com/golang/dep/vendor/github.com/sdboyer/gps/solver.go:371 +0x791
github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).Solve(0xc420ac4a50, 0x25, 0xc4200100a8, 0x11, 0xc420154ff0)
    /storage/gopath/src/github.com/golang/dep/vendor/github.com/sdboyer/gps/solver.go:317 +0x8e
main.(*initCommand).Run(0x9f41c8, 0xc42000c380, 0x0, 0x0, 0x0, 0x0)
    /storage/gopath/src/github.com/golang/dep/init.go:153 +0x102f
main.main()
    /storage/gopath/src/github.com/golang/dep/main.go:101 +0x68b

[sdboyer]

iiiiinteresting.

github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).unselectLast(0xc420ac4a50, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)

This means an internal bookkeeping bug in the solver. ...except that there doesn't appear to be a slice access on that line.

[davecheney]

Almost certain that
https://github.com/golang/dep/blob/master/vendor/github.com/sdboyer/gps/selection.go#L58
was inlined into unselectLast.

On Fri, Jan 27, 2017 at 4:24 PM, sam boyer [e-mail] wrote:

iiiiinteresting.

github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).unselectLast(0xc420ac4a50, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)

This means an internal bookkeeping bug in the solver. ...except that there
doesn't appear to be a slice access on that line.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/dep/issues/171#issuecomment-275591649, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA9v5MvZsj5oU2_eHeo01DIpRqZgCks5rWX-FgaJpZM4Lu9I_
.

[sdboyer]

derp. totally. thanks :)

[davecheney]

roll on the dev.inline branch, which will solve this (we all hope)

On Fri, Jan 27, 2017 at 4:38 PM, sam boyer [e-mail] wrote:

derp. totally. thanks :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/dep/issues/171#issuecomment-275592973, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA361xh7inogKxXz5wJ49DGS2-G4iks5rWYLBgaJpZM4Lu9I_
.

[eparis]

I put some printf's to dig around a bit. In fact it is popDep not pushDep that was panicing.

 func (s *selection) popDep(id ProjectIdentifier) (dep dependency) {
-       deps := s.deps[id.ProjectRoot]
+       deps, ok := s.deps[id.ProjectRoot]
+       if !ok {
+               fmt.Printf("unable to find s.deps[%v]\n", id)
+               return dependency{}
+       }

Gave me:

unable to find s.deps[{k8s.io/kubernetes }]

[sdboyer]

That also makes more sense than a slice bounds error on an append :) Doesn't change anything about the inlining observation, of course.

I'm pretty sure I see the problem here. likely related to the fix for #116, which allowed project-level cyclic dependencies involving the root project. I'm pretty sure I didn't encounter this because the additional test case I wrote didn't cause the solver to backtrack through such cycles.

k8s @ db2dc78e6398ba673e68e94bd17d28a97dd4a902 does have such a project-level cycle, right? (a k8s package imports a package from a dep, which itself transitively imports some package back in k8s)

If so, this is a relief, because it points away from a "bookkeeping bug" in normal operation of the solving algorithm. That would be a much more concerning correctness issue. Instead, I think the cause here is a basic choice to push the root project into the selected list, but not the deps map, when preparing the algorithm. That's a more basic structural question with an easier fix.

[sdboyer]

This should now be fixed upstream - we'll get it in to dep with the next gps update.