Skip to content
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

podman images --filter "dangling=true" crashes on no untagged images #2246

Closed
ktdreyer opened this issue Jan 30, 2019 · 6 comments

Comments

Projects
None yet
4 participants
@ktdreyer
Copy link
Contributor

commented Jan 30, 2019

/kind bug

Description

podman images --filter "dangling=true" crashes if I have no untagged images. If I have untagged images, it works, and if I have no untagged images, it crashes.

Steps to reproduce the issue:

This works:

$ podman images --filter "dangling=true"
REPOSITORY   TAG      IMAGE ID       CREATED      SIZE
<none>       <none>   dd4d6e73afd4   4 days ago   554 MB
<none>       <none>   874bd536f188   4 days ago   554 MB
<none>       <none>   2cacf0e48eb4   4 days ago   554 MB
<none>       <none>   e95c077a02d7   4 days ago   554 MB

So I delete all the untagged ones:

$ podman rmi $(podman images -q --filter "dangling=true")
dd4d6e73afd4ff88def4abbf3e52e79ff05d0070a110eaf17bf5b374125cfe88
874bd536f18853bbd4074d4a1e7c11436686f1250d7c40e8cf57eadc2304a22c
2cacf0e48eb4fa67604370debb65a6cabb8310149f399e61493af8e62dffca5c
673d206610bb91a0dd9335253f0b9326f58b5cc1ef2ee4dd7e6328cdb1eb8a19
e024a6b12894041fde45aa4f9f56f099b45ab58175cbe9894334b3e547f58606
e95c077a02d705f91a392e1f2825ba567dd9df90504eee041bf845f941a05fbf

Then I run with --filter "dangling=true" again:

podman images --filter "dangling=true"
panic: runtime error: index out of range

goroutine 1 [running]:
main.generateImagesOutput(0x1589760, 0xc0000b4048, 0xc0000f8300, 0xc00041e700, 0xb, 0x10, 0x0, 0x0, 0x0, 0xc0004f9680, ...)
	/builddir/build/BUILD/libpod-82e80110c3f2d8728745c47e340f3bee4d408846/_build/src/github.com/containers/libpod/cmd/podman/images.go:354 +0x34e
main.imagesCmd(0xc00015a840, 0x0, 0x0)
	/builddir/build/BUILD/libpod-82e80110c3f2d8728745c47e340f3bee4d408846/_build/src/github.com/containers/libpod/cmd/podman/images.go:211 +0x622
github.com/containers/libpod/vendor/github.com/urfave/cli.HandleAction(0x11e3160, 0x1447388, 0xc00015a840, 0x0, 0xc0002427e0)
	/builddir/build/BUILD/libpod-82e80110c3f2d8728745c47e340f3bee4d408846/_build/src/github.com/containers/libpod/vendor/github.com/urfave/cli/app.go:501 +0xc8
github.com/containers/libpod/vendor/github.com/urfave/cli.Command.Run(0x13a9a5d, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x13c9fed, 0x1c, 0x0, ...)
	/builddir/build/BUILD/libpod-82e80110c3f2d8728745c47e340f3bee4d408846/_build/src/github.com/containers/libpod/vendor/github.com/urfave/cli/command.go:165 +0x459
github.com/containers/libpod/vendor/github.com/urfave/cli.(*App).Run(0xc0001a6c40, 0xc0000ba040, 0x4, 0x4, 0x0, 0x0)
	/builddir/build/BUILD/libpod-82e80110c3f2d8728745c47e340f3bee4d408846/_build/src/github.com/containers/libpod/vendor/github.com/urfave/cli/app.go:259 +0x6bb
main.main()
	/builddir/build/BUILD/libpod-82e80110c3f2d8728745c47e340f3bee4d408846/_build/src/github.com/containers/libpod/cmd/podman/main.go:273 +0x15a6

Describe the results you expected:
podman should exit successfully when there are no untagged images.

Additional information you deem important (e.g. issue happens only occasionally):
Crash reproduces 100% for me in my environment.

Output of podman version:

Version:       1.0.0
Go Version:    go1.11.4
Git Commit:    "49780a1cf10d572edc4e1ea3b8a8429ce391d47d"
Built:         Mon Jan 14 13:38:17 2019
OS/Arch:       linux/amd64

Output of podman info:

host:
  BuildahVersion: 1.6-dev
  Conmon:
    package: podman-1.0.0-1.git82e8011.fc29.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: 49780a1cf10d572edc4e1ea3b8a8429ce391d47d'
  Distribution:
    distribution: fedora
    version: "29"
  MemFree: 9155424256
  MemTotal: 16689291264
  OCIRuntime:
    package: runc-1.0.0-67.dev.git12f6a99.fc29.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: d164d9b08bf7fc96a931403507dd16bced11b865
      spec: 1.0.1-dev
  SwapFree: 8413769728
  SwapTotal: 8413769728
  arch: amd64
  cpus: 8
  hostname: carbon
  kernel: 4.20.4-200.fc29.x86_64
  os: linux
  rootless: true
  uptime: 2h 55m 4.74s (Approximately 0.08 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/kdreyer/.config/containers/storage.conf
  ContainerStore:
    number: 1
  GraphDriverName: vfs
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/kdreyer/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 14
  RunRoot: /run/user/1000

Additional environment details (AWS, VirtualBox, physical, etc.):
Fedora 29 on my laptop

@baude baude self-assigned this Jan 30, 2019

@baude

This comment has been minimized.

Copy link
Collaborator

commented Jan 30, 2019

@baude

This comment has been minimized.

Copy link
Collaborator

commented Jan 30, 2019

@ktdreyer Im not able to exactly reproduce on my machine, but I was able to trip it elsewise. Would you be willing to try a patch against master?

@carlwgeorge

This comment has been minimized.

Copy link

commented Feb 5, 2019

I'm able to reproduce it with podman-1.0.0-1.git82e8011.fc29.x86_64 on Fedora 29. What's that patch? I can try it as well.

baude added a commit to baude/libpod that referenced this issue Feb 8, 2019

do not crash when displaying dangling images
the previous method required a populated image template to create
the headers and always selected the first image in the slice. when
dealing with dangling images, they are not populated and therefore
would panic.

Resolves: containers#2246

Signed-off-by: baude <bbaude@redhat.com>
@baude

This comment has been minimized.

Copy link
Collaborator

commented Feb 8, 2019

if someone wants to try -> #2297

@carlwgeorge

This comment has been minimized.

Copy link

commented Feb 11, 2019

That pull request didn't apply cleanly to 1.0.0, but I was able to massage it a bit and backport it as a patch for the Fedora 29 package in a copr repo. I'm happy to confirm that it does resolve the problem. Thanks!

@baude

This comment has been minimized.

Copy link
Collaborator

commented Feb 11, 2019

ty for the confirmation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.