-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIGSEGV when cache-from and cache-to are different locations in the same S3 bucket #5584
Labels
Comments
cc @bpaquet |
bpaquet
added a commit
to bpaquet/buildkit
that referenced
this issue
Dec 15, 2024
see moby#5584. Seems this is a regression related to moby#4551, which happen when buildkit need to export a S3 layer directly from a downloaded S3 layer. With the new wrapper, there is no exception, and buildkit download and re upload them without any issue. Checksum and size of layers are identical.
bpaquet
added a commit
to bpaquet/buildkit
that referenced
this issue
Dec 15, 2024
see moby#5584. Seems this is a regression related to moby#4551, which happen when buildkit need to export a S3 layer directly from a downloaded S3 layer. With the new wrapper, there is no exception, and buildkit download and re upload them without any issue. Checksum and size of layers are identical.
bpaquet
added a commit
to bpaquet/buildkit
that referenced
this issue
Dec 15, 2024
see moby#5584. Seems this is a regression related to moby#4551, which happen when buildkit need to export a S3 layer directly from a downloaded S3 layer. With the new wrapper, there is no exception, and buildkit download and re upload them without any issue. Checksum and size of layers are identical. Signed-off-by: Bertrand Paquet <[email protected]>
To reproduce it Dockerfile
@parisBrentas Thx for the report. FYI this is not really expected to use the same directory for manifests and blob, even if it should cause any trouble in practice :) |
bpaquet
added a commit
to bpaquet/buildkit
that referenced
this issue
Dec 17, 2024
see moby#5584. Seems this is a regression related to moby#4551, which happen when buildkit need to export a S3 layer directly from a downloaded S3 layer. With the new wrapper, there is no exception, and buildkit download and re upload them without any issue. Checksum and size of layers are identical. Signed-off-by: Bertrand Paquet <[email protected]>
bpaquet
added a commit
to bpaquet/buildkit
that referenced
this issue
Jan 14, 2025
see moby#5584. Seems this is a regression related to moby#4551, which happen when buildkit need to export a S3 layer directly from a downloaded S3 layer. With the new wrapper, there is no exception, and buildkit download and re upload them without any issue. Checksum and size of layers are identical. Signed-off-by: Bertrand Paquet <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Running a build command where the cache-from and cache-to point to different locations in the same S3 bucket and the cache-from location contains a complete match causes build to fail with a SIGSEGV.
I've included what I believe is the relevant information below. Please let me know if you need anything else.
Command used
Below is the command used, with the env and project names changed
/usr/bin/docker buildx build --build-arg AGENT_VERSION=7.56.2 --cache-from type=s3,blobs_prefix=cache/docker/env-a/project-a/,manifests_prefix=cache/docker/env-a/project-a/,region=eu-west-2,bucket=gha-cache --cache-to type=s3,blobs_prefix=cache/docker/env-b/project-a/,manifests_prefix=cache/docker/env-b/project-a/,region=eu-west-2,bucket=gha-cache,mode=max --file dockerfiles/project-a/Dockerfile --iidfile /tmp/docker-build-push-SVUVoD/iidfile --tag 123456789.dkr.ecr.eu-west-2.amazonaws.com/services/project-a:7.56.2 --load --metadata-file /tmp/docker-build-push-SVUVoD/metadata-file .
My actual build uses two cache-from directives, one for env-a and one for env-b. This is just a minimum reproduction.
Environment
The build happens in Github Actions ubuntu-latest.
Buildkit version is v0.18.1.
Here is the debug output from the docker/setup-buildx-action@v3 action.
Logs
The error is
and it gets emitted from
The cache-to location in the bucket contains some of the layers but no manifest file. My guess would be that the connection to the bucket closes after the cache is read but before the cache can finish being written.
Here's the buildkit logs
Here's the relevant parts from the build process
The text was updated successfully, but these errors were encountered: