dep panics when ^C hit during dep ensure

[davecheney]

What version of Go (go version) and dep (git describe --tags) are you using?

go 1.9

What dep command did you run?

dep ensure

What did you expect to see?

no panic

What did you see instead?

lucky(~/src/stash.atlassian.com/scm/kube/roz) % dep ensure
^CSignal received: waiting for 1 ops to complete...
panic: shouldn't be possible unable to deduce repository and source type for: "k8s.io/apimachinery/pkg/apis/meta/v1"

goroutine 1 [running]:
github.com/golang/dep/internal/gps.(solver).selectRoot(0xc42022f200, 0xc420304c80, 0x23)
/home/dfc/src/github.com/golang/dep/internal/gps/solver.go:502 +0xabb
github.com/golang/dep/internal/gps.(solver).Solve(0xc42022f200, 0x2e, 0xaaf2c0, 0xb06a18, 0xc42001a092)
/home/dfc/src/github.com/golang/dep/internal/gps/solver.go:348 +0x72
main.(ensureCommand).Run(0xc420108f20, 0xc42005b200, 0xc42000c080, 0x0, 0x0, 0x0, 0x0)
/home/dfc/src/github.com/golang/dep/cmd/dep/ensure.go:148 +0x361
main.(Config).Run(0xc420072e40, 0xc420072e40)
/home/dfc/src/github.com/golang/dep/cmd/dep/main.go:159 +0x874
main.main()
/home/dfc/src/github.com/golang/dep/cmd/dep/main.go:44 +0x1fc

[jmank88]

if err != nil {
  // TODO(sdboyer) this could well happen; handle it with a more graceful error
  panic(fmt.Sprintf("shouldn't be possible %s", err))
}

https://github.com/golang/dep/blob/master/internal/gps/solver.go#L592

[adamo57]

I could take a look at this this weekend

[sdboyer]

@davecheney thanks for the bug report!

@adamo57 awesome! so, some guidance on this. i think there are two, interrelated problems:

1. the error here probably _should_ have been a context.Canceled, given that the action precipitating it was a Ctrl-C (which we manage via context), but it wasn't, i suspect because our error reporting isn't passing that back in a sane way. i _think_ the best general solution there is to change the outermost SourceMgr methods to check with the sm.supervsr on egress and replace any error that might have emerged from the underlying calls with a context.Canceled.
2. we generally don't differentiate well between errors in the solver. in particular, we don't check to see if the error that's coming back is a context.Canceled. the canary panics in the solver - of which this is one, though i later realized it was a valid error case, thus the TODO - are important checkpoints, because solver invariants should render them unreachable during any normal progression of states (hence, "canary). however, context-based cancellations, by definition, disrupt the normal progression of states; pretty much any canary panic can be hit with the wrong Ctrl-C interleaving. pretty much all of those cases need to be revisited in order to be made more sophisticated in their handling of errors , at minimum so that if a context.Canceled comes through, we pass it back instead of panicking.

[adamo57]

@sdboyer Hi, im looking at this now and i'm having some trouble understanding the flow of things here. Where does the SourceMgr come into this? I am still trying to wrap my head around this projects structure as a whole, so as much clarification as possible would be appreciated :)

[sdboyer]

almost every call that goes to the bridge - sm.b - will end up in the SourceMgr.

On September 16, 2017 6:22:56 PM EDT, Adam Ouellette [e-mail] wrote:

@sdboyer Hi, im looking at this now and i'm having some trouble
understanding the flow of things here. Where does the SourceMgr come
into this?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/golang/dep/issues/1060#issuecomment-329998381

[cihangir]

I had a similar issue with dep init

➜  dep git:(master) go version
go version go1.8.1 darwin/amd64

➜  dep git:(master) git describe --tags
v0.3.0-339-g418356b

➜  koding git:(master) dep init
^CSignal received: waiting for 1 ops to complete...
panic: canary - shouldn't be possible this SourceMgr has been released, its methods can no longer be called

goroutine 1 [running]:
github.com/golang/dep/internal/gps.(*solver).unselectLast(0xc420493600, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    /Users/cihangir/Documents/koding/koding/go/src/github.com/golang/dep/internal/gps/solver.go:1284 +0x71c
github.com/golang/dep/internal/gps.(*solver).backtrack(0xc420493600, 0xc42504eb60)
    /Users/cihangir/Documents/koding/koding/go/src/github.com/golang/dep/internal/gps/solver.go:1026 +0x166
github.com/golang/dep/internal/gps.(*solver).solve(0xc420493600, 0x0, 0x0, 0xc4202c9110)
    /Users/cihangir/Documents/koding/koding/go/src/github.com/golang/dep/internal/gps/solver.go:498 +0x787
github.com/golang/dep/internal/gps.(*solver).Solve(0xc420493600, 0x19, 0x16ea480, 0xc420283440, 0xc42000c077)
    /Users/cihangir/Documents/koding/koding/go/src/github.com/golang/dep/internal/gps/solver.go:443 +0xb1
main.(*initCommand).Run(0xc42014db9a, 0xc420015770, 0xc42000c340, 0x0, 0x0, 0x0, 0x0)
    /Users/cihangir/Documents/koding/koding/go/src/github.com/golang/dep/cmd/dep/init.go:186 +0x8a1
main.(*Config).Run(0xc420072fc0, 0xc420072fc0)
    /Users/cihangir/Documents/koding/koding/go/src/github.com/golang/dep/cmd/dep/main.go:159 +0x891
main.main()
    /Users/cihangir/Documents/koding/koding/go/src/github.com/golang/dep/cmd/dep/main.go:45 +0x253

[sdboyer]

@cihangir yep, that's definitely the same one. a bunch of slightly different stack traces are possible, but it's all the same underlying problem.

[sdboyer]

@adamo57 is that enough info? anything else i can do to help?

[adamo57]

@sdboyer should be enough, ill look at it tonight

[davecheney]

Thanks!

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

Closed #1060 https://github.com/golang/dep/issues/1060 via #1230
https://github.com/golang/dep/pull/1230.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/dep/issues/1060#event-1313265983, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAAcA6-XJuXe9pll_pLbQrMgF-4h3ho8ks5swWVigaJpZM4PCLrh
.