solver: avoid dereferencing nil res.Metadata

I saw this:
    panic: assignment to entry in nil map

    goroutine 3173 [running]:
    github.com/moby/buildkit/exporter/oci.(*imageExporterInstance).Export(0xc42094ac40, 0xecac60, 0xc4211ca690, 0xed12c0, 0xc42000fca8, 0x0, 0x0, 0x0, 0x0, 0x0)
    	/go/src/github.com/moby/buildkit/exporter/oci/export.go:113 +0x156
    github.com/moby/buildkit/solver/llbsolver.(*Solver).Solve.func2(0xecac60, 0xc4211ca690, 0xc4202207c0, 0x0)
    	/go/src/github.com/moby/buildkit/solver/llbsolver/solver.go:132 +0x7d
    github.com/moby/buildkit/solver/llbsolver.inVertexContext(0xecac60, 0xc4211ca690, 0xe2ec38, 0x1d, 0xc420d43400, 0x0, 0x0)
    	/go/src/github.com/moby/buildkit/solver/llbsolver/solver.go:203 +0x1f6
    github.com/moby/buildkit/solver/llbsolver.(*Solver).Solve(0xc4203f7dc0, 0xecac60, 0xc420deb830, 0xc4203ed200, 0x19, 0xc4202ff840, 0x0, 0x0, 0x0, 0x0, ...)
    	/go/src/github.com/moby/buildkit/solver/llbsolver/solver.go:131 +0x761
    github.com/moby/buildkit/control.(*Controller).Solve(0xc42017e870, 0xecac60, 0xc420deb830, 0xc4201edd40, 0xc42017e870, 0x1, 0x1)
    	/go/src/github.com/moby/buildkit/control/control.go:207 +0x4b8
    github.com/moby/buildkit/api/services/control._Control_Solve_Handler.func1(0xecac60, 0xc420deb800, 0xde2180, 0xc4201edd40, 0xecac60, 0xc420deb800, 0xed67a0, 0x1595288)
    	/go/src/github.com/moby/buildkit/api/services/control/control.pb.go:810 +0x86
    github.com/moby/buildkit/vendor/github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc.OpenTracingServerInterceptor.func1(0xecac60, 0xc420deb800, 0xde2180, 0xc4201edd40, 0xc4202ff9e0, 0xc4202ffa00, 0x0, 0x0, 0xebbea0, 0xc420188310)
    	/go/src/github.com/moby/buildkit/vendor/github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc/server.go:57 +0x2ba
    main.unaryInterceptor.func1(0xecaba0, 0xc4206afe40, 0xde2180, 0xc4201edd40, 0xc4202ff9e0, 0xc4202ffa00, 0x0, 0x0, 0x0, 0x0)
    	/go/src/github.com/moby/buildkit/cmd/buildkitd/main.go:330 +0x15f
    github.com/moby/buildkit/api/services/control._Control_Solve_Handler(0xd76a00, 0xc42017e870, 0xecac60, 0xc420deb530, 0xc42028d030, 0xc420450760, 0x0, 0x0, 0x34, 0x3)
    	/go/src/github.com/moby/buildkit/api/services/control/control.pb.go:812 +0x167
    github.com/moby/buildkit/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc420244700, 0xed39c0, 0xc420694000, 0xc420671680, 0xc420497650, 0x152cef8, 0x0, 0x0, 0x0)
    	/go/src/github.com/moby/buildkit/vendor/google.golang.org/grpc/server.go:1011 +0x4fc
    github.com/moby/buildkit/vendor/google.golang.org/grpc.(*Server).handleStream(0xc420244700, 0xed39c0, 0xc420694000, 0xc420671680, 0x0)
    	/go/src/github.com/moby/buildkit/vendor/google.golang.org/grpc/server.go:1249 +0x1318
    github.com/moby/buildkit/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc42063e0f0, 0xc420244700, 0xed39c0, 0xc420694000, 0xc420671680)
    	/go/src/github.com/moby/buildkit/vendor/google.golang.org/grpc/server.go:680 +0x9f
    created by github.com/moby/buildkit/vendor/google.golang.org/grpc.(*Server).serveStreams.func1
    	/go/src/github.com/moby/buildkit/vendor/google.golang.org/grpc/server.go:678 +0xa1

Which was due to `res, err := s.Bridge(j).Solve(ctx, req)` having `res.Metadata
== nil`. There are several paths in `llbBridge.Solve()` where this can be the
case, plus a case where this comes from a frontend which should not be allowed
to crash the daemon.

Likely introduced by d70d816dee or 6be1257f5d.

Signed-off-by: Ian Campbell <ijc@docker.com>
docker-18.09
Ian Campbell 2018-08-03 16:02:26 +01:00
parent e57eed420c
commit f7937f1989
1 changed files with 3 additions and 0 deletions

View File

@ -105,6 +105,9 @@ func (s *Solver) Solve(ctx context.Context, id string, req frontend.SolveRequest
inp := exporter.Source{ inp := exporter.Source{
Metadata: res.Metadata, Metadata: res.Metadata,
} }
if inp.Metadata == nil {
inp.Metadata = make(map[string][]byte)
}
if res := res.Ref; res != nil { if res := res.Ref; res != nil {
workerRef, ok := res.Sys().(*worker.WorkerRef) workerRef, ok := res.Sys().(*worker.WorkerRef)
if !ok { if !ok {