panic: runtime error: invalid memory address or nil pointer dereference in BuildWithResultHandler

[djs55]

In a Docker Desktop test on Windows I saw a Dockerfile

# syntax=docker/dockerfile:1
FROM alpine:3.16
RUN --network=host

and a build log

docker.exe buildx build --no-cache -t tag .
#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 105B done
#1 DONE 0.0s
#2 [internal] load .dockerignore
#2 transferring context: 2B done
#2 DONE 0.1s
#3 resolve image config for docker.io/docker/dockerfile:1
#3 ...
#4 [auth] docker/dockerfile:pull token for registry-1.docker.io
#4 DONE 0.0s
#3 resolve image config for docker.io/docker/dockerfile:1
#3 DONE 1.3s
#5 docker-image://docker.io/docker/dockerfile:1@sha256:9ba7531bd80fb0a858632727cf7a112fbfd19b17e94c4e84ced81e24ef1a0dbc
#5 resolve docker.io/docker/dockerfile:1@sha256:9ba7531bd80fb0a858632727cf7a112fbfd19b17e94c4e84ced81e24ef1a0dbc 0.0s done
#5 sha256:1e8a16826fd1c80a63fa6817a9c7284c94e40cded14a9b0d0d3722356efa47bd 2.37kB / 2.37kB done
#5 sha256:1328b32c40fca9bcf9d70d8eccb72eb873d1124d72dadce04db8badbe7b08546 0B / 9.94MB 0.1s
#5 sha256:9ba7531bd80fb0a858632727cf7a112fbfd19b17e94c4e84ced81e24ef1a0dbc 2.00kB / 2.00kB done
#5 sha256:ad87fb03593d1b71f9a1cfc1406c4aafcb253b1dabebf569768d6e6166836f34 528B / 528B done
#5 sha256:1328b32c40fca9bcf9d70d8eccb72eb873d1124d72dadce04db8badbe7b08546 9.94MB / 9.94MB 0.3s done
#5 extracting sha256:1328b32c40fca9bcf9d70d8eccb72eb873d1124d72dadce04db8badbe7b08546 0.1s done
#5 DONE 0.5s
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x1094a18]
       
goroutine 28 [running]:
github.com/docker/buildx/build.BuildWithResultHandler.func4.1()
	/src/build/build.go:900 +0x4d8
golang.org/x/sync/errgroup.(*Group).Go.func1()
	/src/vendor/golang.org/x/sync/errgroup/errgroup.go:75 +0x64
created by golang.org/x/sync/errgroup.(*Group).Go
	/src/vendor/golang.org/x/sync/errgroup/errgroup.go:72 +0xa5

The test expected the error "network.host is not allowed" to be printed.

This is with

docker buildx version
github.com/docker/buildx v0.9.1 ed00243a0ce2a0aee75311b06e32d33b44729689

[crazy-max]

I got the expected behavior with latest v0.10.0-rc3 and 0.9.1 on WSL:

$ docker buildx build --no-cache -t tag .
...
#9 [auth] library/alpine:pull token for registry-1.docker.io
#9 DONE 0.0s

#8 [internal] load metadata for docker.io/library/alpine:3.16
#8 DONE 2.0s
ERROR: failed to solve: failed to load LLB: network.host is not allowed

And same on Windows:

> docker.exe buildx build --no-cache -t tag .
[+] Building 1.6s (7/7) FINISHED
 => [internal] load build definition from Dockerfile                                                               0.0s
 => => transferring dockerfile: 31B                                                                                0.0s
 => [internal] load .dockerignore                                                                                  0.1s
 => => transferring context: 2B                                                                                    0.0s
 => resolve image config for docker.io/docker/dockerfile:1                                                         0.6s
 => CACHED docker-image://docker.io/docker/dockerfile:1@sha256:9ba7531bd80fb0a858632727cf7a112fbfd19b17e94c4e84ce  0.0s
 => [internal] load build definition from Dockerfile                                                               0.0s
 => [internal] load .dockerignore                                                                                  0.0s
 => [internal] load metadata for docker.io/library/alpine:3.16                                                     0.6s
ERROR: failed to solve: failed to load LLB: network.host is not allowed

What's the output of docker buildx ls? Are you using a container builder?

[jedevc]

The logic in BuildWithResultHandler is racy. It's possible for the function on https://github.com/docker/buildx/blob/v0.9.1/build/build.go#L1033 to return an error, but it completes the WaitGroup before it exits.

If this happens in the wrong order, I think we skip over the https://github.com/docker/buildx/blob/v0.9.1/build/build.go#L890-L894 check to see if the context is errored, because the error hasn't been returned yet (even though the WaitGroup is terminated). That means that res is nil - the expected behavior here should be that we need to fix the faulty logic that could be skipped over depending on how quickly the function returns.

Not quite sure the best way to do that - one idea would be to create a single error group for each provided opt, that way we don't need to have wait groups.

[djs55]

@crazy-max sorry I should have also said that it seems intermittent -- I've seen 2 nightly test failures -- and it might also depend on enabling ECI (the sysbox runtime). Perhaps the different runtime alters the timing and makes the race manifest more frequently.