segmentation fault on multi-image build with bake

[orgads]

Contributing guidelines

• I've read the contributing guidelines and wholeheartedly agree

I've found a bug and checked that ...

• ... the documentation does not mention anything about my problem
• ... there are no open or closed issues that are related to my problem

Description

Building a multiarch image with bake where passing contexts causes segmentation fault.

Expected behaviour

It should work

Actual behaviour

Segmentation fault.

Buildx version

github.com/docker/buildx 0.19.3+ds1 0.19.3+ds1-4

Confirmed to crash also on 0.13.1 and 0.29.1 from docker-ce repo.

Docker info

Client:
 Version:    27.5.1+dfsg3
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  0.19.3+ds1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.32.4-3
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 25
  Running: 18
  Paused: 0
  Stopped: 7
 Images: 79
 Server Version: 27.5.1+dfsg3
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1.7.24~ds1-10
 runc version: 1.3.2+ds1-1
 init version: 
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.87.2-microsoft-standard-WSL2
 Operating System: Debian GNU/Linux forky/sid
 OSType: linux
 Architecture: x86_64
 CPUs: 28
 Total Memory: 31.16GiB
 Name: IL-ORGADS-NEW
 ID: ade50a3a-44af-40af-b718-5dfc3eb3bdd5
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Builders list

NAME/NODE        DRIVER/ENDPOINT                   STATUS    BUILDKIT         PLATFORMS
multiarch*       docker-container                                             
 \_ multiarch0    \_ unix:///var/run/docker.sock   running   v0.25.1          linux/amd64 (+3), linux/arm64, linux/arm (+2), linux/ppc64le, (4 more)
default          docker                                                       
 \_ default       \_ default                       running   v0.0.0+unknown   linux/amd64 (+3), linux/arm64, linux/arm (+2), linux/ppc64le, (4 more)

Configuration

platforms_val = ["linux/amd64", "linux/arm64"]

target "base" {
  dockerfile-inline = "FROM scratch"
  platforms = platforms_val
}

target "default" {
  dockerfile-inline = "FROM scratch"
  platforms = platforms_val
  contexts = {
    "base" = "target:base",
  }
}

Build logs

docker buildx bake
[+] Building 0.1s (3/3)                                                                                                            docker-container:multiarch
 => [internal] load local bake definitions                                                                                                               0.0s
 => => reading ./docker-bake.hcl 267B / 267B                                                                                                             0.0s
 => [base internal] load build definition from Dockerfile                                                                                                0.0s
 => => transferring dockerfile: 49B                                                                                                                      0.0s
 => [base internal] load .dockerignore                                                                                                                   0.0s
 => => transferring context: 85B                                                                                                                         0.0s
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x1116855]

goroutine 237 [running]:
github.com/docker/buildx/build.waitContextDeps({0x2ea89c8, 0xc000231900}, 0x0, 0xc000883500, 0xc000236e10)
        github.com/docker/buildx/build/build.go:1031 +0xc95
github.com/docker/buildx/build.BuildWithResultHandler.func3.4()
        github.com/docker/buildx/build/build.go:417 +0x27e
golang.org/x/sync/errgroup.(*Group).Go.func1()
        golang.org/x/sync/errgroup/errgroup.go:78 +0x50
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 1
        golang.org/x/sync/errgroup/errgroup.go:75 +0x93

Additional info

No response

[tonistiigi]

This was fixed in #3511 . The case for setting build context to nil result is still not supported in buildkit side but no client-side panic now. If there is use case for setting build context to nil then we can continue discussing in a separate buildkit issue.