index out of range

[ganglio]

Hello there,

I'm experiencing the following error while executing:

dep ensure -update

Output:

panic: runtime error: index out of range

goroutine 1 [running]:
github.com/golang/dep/vendor/github.com/sdboyer/gps.(*unselected).remove(0xc420198c60, 0xc4204cd020,0x1e, 0x0, 0x0, 0xc4204c5790, 0x1, 0x1, 0x0, 0x0, ...)
        /Users/robertot/Devel/cuddles/src/github.com/golang/dep/vendor/github.com/sdboyer/gps/selection.go:190 +0x3e1
github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).unselectLast(0xc4201a4000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /Users/robertot/Devel/cuddles/src/github.com/golang/dep/vendor/github.com/sdboyer/gps/solver.go:1159 +0x6c9
github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).backtrack(0xc4201a4000, 0xc4201578a0)
        /Users/robertot/Devel/cuddles/src/github.com/golang/dep/vendor/github.com/sdboyer/gps/solver.go:904 +0x166
github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).solve(0xc4201a4000, 0x0, 0x0, 0xc4201a0390)
        /Users/robertot/Devel/cuddles/src/github.com/golang/dep/vendor/github.com/sdboyer/gps/solver.go:371 +0x787
github.com/golang/dep/vendor/github.com/sdboyer/gps.(*solver).Solve(0xc4201a4000, 0x29, 0xc4200100b6, 0x7, 0xc420141830)
        /Users/robertot/Devel/cuddles/src/github.com/golang/dep/vendor/github.com/sdboyer/gps/solver.go:317 +0x8e
main.(*ensureCommand).Run(0xc42013d880, 0xc420157730, 0xc420010410, 0x0, 0x0, 0x0, 0x0)
        /Users/robertot/Devel/cuddles/src/github.com/golang/dep/cmd/dep/ensure.go:144 +0x31b
main.main()
        /Users/robertot/Devel/cuddles/src/github.com/golang/dep/cmd/dep/main.go:96 +0x64f

I have a pretty simple manifest:

{
    "dependencies": {
        "github.com/ganglio/goes": {
            "branch": "develop"
        },
        "go get gopkg.in/kataras/iris.v6": {
            "branch": "master"
        },
        "github.com/streadway/amqp": {
            "branch": "master"
        },
        "k8s.io/apimachinery": {
            "revision": "7080e31e90e981181435294bca96c80a37db8941"
        },
        "k8s.io/client-go": {
            "branch": "master"
        }
    }
}

and no lock file.

Any idea?

The version I'm on is 9a24cac

Thanks!

[zbintliff]

Seems to be an issue with the downstream dep gps: https://github.com/sdboyer/gps/blob/master/selection.go#L190

While I don't know much about that package it seems like there needs to be a check on the bimodalIdentifier to check the size of the projectList

[kirs]

I'm getting the same issue. It prevents me from using dep ensure

[sdboyer]

hi folks, thanks for the issue report. yep, this is def a bug in gps (the solver engine that powers basically everything dep does). this one does actually look pretty straightforward - if the lengths differ on those slices, then we don't even need to make it into the loop to know they're not a match.

side note -

go get gopkg.in/kataras/iris.v6

This isn't a valid project name - dep really shouldn't even let you run with it in the list. Did you hand-write it in, or run a command and dep wrote it for you?

[ganglio]

I wrote it by hand after the error and before the issue report. Sorry about that. It's unrelated to the issue, tho.

[sdboyer]

For sure, definitely unrelated to the issue. It just confirms to me that we need some validation there. It's part of a bigger set of feedback we need to provide to the user, probably (generally, constraints that aren't going to be used b/c there are no corresponding imports)

[zbintliff]

#280 Has the fix

[sdboyer]

This should now be fixed - if someone could confirm, that'd be great.

[kirs]

Thanks for fixing it! I confirm that it doesn't panic with runtime error: index out of range anymore.

I can't make it work with kubernetes/client-go yet, but I'm sure must be the package issue.

[kirs]

Unless @ganglio reports that they still experience the problem, I think it's safe to close the issue.

[sdboyer]

I'll close it then, and @ganglio can reopen if need be :)

@kirs is there an issue open for the problem you're experiencing there? maybe #170 or #171?

[sdboyer]

also...makes me think it'd be useful if we had a fully separate integration test, perhaps even protected by a build tag, that we use to assess the init/ensure-ability of certain larger projects.

[jfcorsini]

@ganglio , what is the version of you git? I was having this problem with git 1.9 (yeah, that old) and I just updated to 2.11 and the problems disappeared. Maybe that can help :)

[ganglio]

@sdboyer thanks for fixing it. It does seem to work now.
@jfcorsini I'm using 1.9.1 bit it didn't seem to be that the problem.