Skip to content

qemu: uncaught target signal 11 (Segmentation fault) - core dumped - When running AMD64 Python PyArrow code on Mac #26036

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

Open
Ark-kun opened this issue May 1, 2025 · 6 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. macos MacOS (OSX) related needs-info Need info from reporter remote Problem is in podman-remote triaged Issue has been triaged

Comments

@Ark-kun
Copy link

Ark-kun commented May 1, 2025

Issue Description

Not sure Is this issue with Podman, Python or Pyarrow.

Trying to run container image that was built for AMD64 on a Mac. Importing pyarrow crashes the process. apache/arrow#46276

After that I need to manually kill the podman process using kill -9. Normal kill does not work.

Steps to reproduce the issue

Steps to reproduce the issue

  1. podman run --arch amd64 python:3.11-slim bash -c 'pip install pyarrow==20.0.0; python -c "import pyarrow"'

Describe the results you received

% podman run --arch amd64 python:3.11-slim bash -c 'pip install pyarrow==20.0.0; python -c "import pyarrow"'
Collecting pyarrow==20.0.0
  Downloading pyarrow-20.0.0-cp311-cp311-manylinux_2_28_x86_64.whl.metadata (3.3 kB)
Downloading pyarrow-20.0.0-cp311-cp311-manylinux_2_28_x86_64.whl (42.3 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 42.3/42.3 MB 29.1 MB/s eta 0:00:00
Installing collected packages: pyarrow
Successfully installed pyarrow-20.0.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

[notice] A new release of pip is available: 24.0 -> 25.1
[notice] To update, run: pip install --upgrade pip
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

Describe the results you expected

I expect to see no segfaults.
I expect podman process to not become stuck where it cannot be killed using kill.

podman info output

% podman info
Client:
  APIVersion: 5.4.0
  BuildOrigin: brew
  Built: 1739290083
  BuiltTime: Tue Feb 11 08:08:03 2025
  GitCommit: ""
  GoVersion: go1.23.6
  Os: darwin
  OsArch: darwin/arm64
  Version: 5.4.0
host:
  arch: arm64
  buildahVersion: 1.39.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.12-3.fc41.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: '
  cpuUtilization:
    idlePercent: 99.54
    systemPercent: 0.19
    userPercent: 0.27
  cpus: 6
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: coreos
    version: "41"
  eventLogger: journald
  freeLocks: 2020
  hostname: localhost.localdomain
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.12.9-200.fc41.aarch64
  linkmode: dynamic
  logDriver: journald
  memFree: 406183936
  memTotal: 8295780352
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.13.1-1.fc41.aarch64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.13.1
    package: netavark-1.13.1-1.fc41.aarch64
    path: /usr/libexec/podman/netavark
    version: netavark 1.13.1
  ociRuntime:
    name: crun
    package: crun-1.19.1-1.fc41.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.19.1
      commit: 3e32a70c93f5aa5fea69b50256cca7fd4aa23c80
      rundir: /run/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20241211.g09478d5-1.fc41.aarch64
    version: |
      pasta 0^20241211.g09478d5-1.fc41.aarch64-pasta
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: unix:///run/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.3.1-1.fc41.aarch64
    version: |-
      slirp4netns version 1.3.1
      commit: e5e368c4f5db6ae75c2fce786e31eef9da6bf236
      libslirp: 4.8.0
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.5.5
  swapFree: 0
  swapTotal: 0
  uptime: 14h 8m 27.00s (Approximately 0.58 days)
  variant: v8
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 28
    paused: 0
    running: 7
    stopped: 21
  graphDriverName: overlay
  graphOptions:
    overlay.additionalImageStores:
    - /usr/lib/containers/storage
    overlay.imagestore: /usr/lib/containers/storage
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 63466319872
  graphRootUsed: 34005262336
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 183
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 5.4.0
  BuildOrigin: Fedora Project
  Built: 1739232000
  BuiltTime: Mon Feb 10 16:00:00 2025
  GitCommit: ""
  GoVersion: go1.23.5
  Os: linux
  OsArch: linux/ar

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

@Ark-kun Ark-kun added the kind/bug Categorizes issue or PR as related to a bug. label May 1, 2025
@github-actions github-actions bot added macos MacOS (OSX) related remote Problem is in podman-remote labels May 1, 2025
@ninja-quokka
Copy link
Collaborator

Hi @Ark-kun

I can't reproduce this on my M1 Macbook running Podman 5.4.2 or when building from main branch.

On a mac the container operation is actually ran inside a Fedora CoreOS VM and Rosetta is used for binary translation.

When the VM is created we attach the Apple Rosetta device, inside the VM we mount the device and configure binfmt_misc to use Apples Rosetta translation layer for any x86_64 binaries.

Using your example I can test this:

podman run --rm -d --arch amd64 python:3.11-slim bash -c 'pip install pyarrow==20.0.0; python -c "import pyarrow" && sleep 1000'
podman machine ssh
[core@localhost ~]$ ps -elf |grep rosetta
4 S core        2773    2771  0  80   0 - 44712 do_wai 13:10 ?        00:00:00 /mnt/rosetta /usr/bin/bash -c pip install pyarrow==20.0.0; python -c "import pyarrow" && sleep 1000

When running a container with the --arch flag Podman is configured to pull the container image with the matching arch, binaries inside that pulled image will be compiled for that arch. When the binary is ran, if the binary files magic number matches the x86_64 bitmask we configure in /proc/sys/fs/binfmt_misc/rosetta then the binary will be ran through Apples Rosetta binary translation

You can verify if Rosetta is enable(default) by checking:
podman machine inspect --format {{.Rosetta}}

Please let me know what you think.

@ninja-quokka ninja-quokka added the triaged Issue has been triaged label May 1, 2025
@Ark-kun
Copy link
Author

Ark-kun commented May 1, 2025

I'm on M4 Macbook. Pretty new, latest updates. Although, company-issued.

% podman machine inspect --format {{.Rosetta}}
false

I'm not sure why Rosetta is turned off here.

I think I've installed Podman myself (judging by dates) via Homebrew.
I'm very new to Podman and I have not done any tinkering or config changes. Just podman machine start and things like podman build/run/push/tag.

@jakecorrenti
Copy link
Member

jakecorrenti commented May 1, 2025

Hi @Ark-kun, installing Podman from Homebrew is an unsupported method. Can you try removing the current installation and install via the pkg installer or build from source? You can find the pkg installer in our Releases page.

@arixmkii
Copy link
Contributor

arixmkii commented May 2, 2025

I have Rosetta acceleration operational with Homebrew version (same with selfbuilt versions) on M4 Pro. I had to install Rosetta specifically, because it was not installed out of the box on a fresh OS install.

@Ark-kun do you have Rosetta installed on your laptop? You might need to delete and recreate podman machine after installing Rosetta.

@baude
Copy link
Member

baude commented May 2, 2025

please install the latest release from upstream. could you also provide which podman | xargs file and podman machine ls ? if you are running the applehv provider, then everything should be in order. also cannot reproduce.

@baude baude added the needs-info Need info from reporter label May 2, 2025
Copy link

github-actions bot commented May 2, 2025

A reviewer has determined we need more information to understand the reported issue. A comment on what is missing should be provided. Be certain you:

  • provide an exact reproducer where possible
  • verify you have provided all relevant information - minimum is podman info
  • answer any follow up questions

If no response to the needs-info is provided in 30 days, this issue may be closed by our stale bot.

For more information on reporting issues on this repository, consult our issue guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. macos MacOS (OSX) related needs-info Need info from reporter remote Problem is in podman-remote triaged Issue has been triaged
Projects
None yet
Development

No branches or pull requests

5 participants