SIGSEGV: segmentation violation on acr purge
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- azure, docker, go
- Domain
- authentication, cli, cloud
Research direction
Start by inspecting auth/oras/client.go:32 and the login path in cmd/acr/login.go:111, using the provided stack trace and long-running purge reproduction. Verify the sporadic authentication failure and nil-pointer path, then confirm that acr login and the purge loop continue without a segmentation violation.
Written by the indexing model from the issue text.
Description
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
- Use a workload-identity to create a 24h valid token
- Login via
acr login registryname.azurecr.io -u 00000000-0000-0000-0000-000000000000 --password-stdin < /acr/docker-token.txt - Continuously call
acr -r registryname purge --filter "${repo}:^(?i)(feature|renovate|task|fix|hotfix|update|local-SNAPSHOT|development|)" --ago 30d --untaggedin a while loop for a few hours...
Expected behavior
The purge command successfully continues to purge until all repos in the list it loops over are processed
Screenshots
Initially I just got the following error repeatedly, which got me into investigating the authentication part... introduced a token refresh and such kind of things... but no change
Error: error resolving authentication: acr.BaseClient#GetAcrAccessToken: Failure responding to request: StatusCode=401 -- Original Error: autorest/azure: error response cannot be parsed: {"" '\x00' '\x00'} error: EOF
So in the end I took the plunge and added a retry mechanism to my script and added the -d debug switch on the retry. Then I came with a proper stack trace where it goes belly up... seems to be coming from the underlying azure-cli client being used.
acr login registryname.azurecr.io -u 00000000-0000-0000-0000-000000000000 --password-stdin < /acr/docker-token.txt -d
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7e2d11]
goroutine 1 [running]:
github.com/Azure/acr-cli/auth/oras.NewClient({{{0x7ffd16e92a6b, 0x24}, {0xc000294000, 0x42f}, {0x0, 0x0}, {0x0, 0x0}}, 0x0, 0x1})
/go/src/github.com/Azure/acr-cli/auth/oras/client.go:32 +0x2b1
main.runLogin({{0x7ffd16e92a49, 0x1e}, {0x7ffd16e92a6b, 0x24}, {0xc000294000, 0x42f}, {0x0, 0x0, 0x0}, 0x1, ...})
/go/src/github.com/Azure/acr-cli/cmd/acr/login.go:111 +0x3f8
main.newLoginCmd.func1(0xc000184600?, {0xc000156aa0?, 0x4?, 0x975bce?})
/go/src/github.com/Azure/acr-cli/cmd/acr/login.go:56 +0x5d
github.com/spf13/cobra.(*Command).execute(0xc0001d6f08, {0xc000156a50, 0x5, 0x5})
/go/src/github.com/Azure/acr-cli/vendor/github.com/spf13/cobra/command.go:985 +0xaca
github.com/spf13/cobra.(*Command).ExecuteC(0xc0001d6608)
/go/src/github.com/Azure/acr-cli/vendor/github.com/spf13/cobra/command.go:1117 +0x3ff
github.com/spf13/cobra.(*Command).Execute(...)
/go/src/github.com/Azure/acr-cli/vendor/github.com/spf13/cobra/command.go:1041
main.main()
/go/src/github.com/Azure/acr-cli/cmd/acr/main.go:12 +0x4a
Any relevant environment information
- OS: mcr.microsoft.com/acr/acr-cli Docker image
- Version 0.13 / 0.14
Additional context
The error happens sporadically... sometimes after 2h sometimes after 6h. We're looping over an ACR with ~4TB of data.
- Dominant language
- Go
- Stars
- 71
- Forks
- 52
- Avg merge
- 8d 10h
- Merged PRs (30d)
- 4
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/acr-cli
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Proposal: Add Minimum and Maximum Retention Policies to Acr PurgePossibly taken @gildardogmsft claimed this 8 days ago. Openenhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
Azure/acr-cli#670 · 2 reactions ·
Maintainers usually reply within 1 day
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Azure/acr-cli#644 · 3 comments ·
Maintainers usually reply within 1 day
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 52/100
Azure/acr-cli#621 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
automation models
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
bug llm-stack needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
P3 Type: Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
grpc/grpc-go#9483 · 2 comments ·
Maintainers usually reply within 2 days
-
needs-area needs-kind needs-priority needs-status needs-triage
Difficulty 2/5 Under an hour Newbie friendliness 85/100
cncf/automation#736 ·
Maintainers usually reply within 1 day
-
Signing PIN can't be collected in-TUI: gpg helper never opts into credential handling, and the PIN pattern misses ssh-keygen's wordingPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
jesseduffield/lazygit#6094 · 1 comment ·
Maintainers usually reply within 1 day