write_point_cloud segfaults unconditionally (SIGSEGV) on aarch64 Linux under Docker Desktop for Mac (Apple Silicon virtualization)

[IljaKan]

Describe the bug

o3d.io.write_point_cloud() segfaults (SIGSEGV) on every call, unconditionally, when running the official manylinux_2_31_aarch64 wheel inside a Docker container on Docker Desktop for Mac (Apple Silicon). This reproduces with pure synthetic data — no real files, no concurrency, no other load.

Writing crashes; reading/constructing geometry does not. Everything up to the write call runs fine.

Environment

• Open3D version: 0.18.0 (pip)
• OS: Debian GNU/Linux 13 (trixie), inside a python:3.11-slim base image
• Python: 3.11.15
• Container platform: linux/arm64 (native — no explicit emulation requested)
• Host: macOS 26.5.2, Apple Silicon (arm64)
• Docker: Docker Desktop, server version 29.6.1
• Install method: pip install open3d inside the container (resolves to the aarch64 wheel)

To Reproduce

Minimal script, no external files or data needed:

import open3d as o3d
import numpy as np

pcd = o3d.geometry.PointCloud()
pcd.points = o3d.utility.Vector3dVector(np.random.rand(10, 3).astype(np.float32))
o3d.io.write_point_cloud("/tmp/tiny.ply", pcd)  # segfaults here
print("this line is never reached")

Run inside a container on Docker Desktop for Mac with default (native ARM64) platform:

docker run --rm python:3.11-slim bash -c "
  pip install -q open3d numpy
  python3 -c \"
import open3d as o3d, numpy as np
pcd = o3d.geometry.PointCloud()
pcd.points = o3d.utility.Vector3dVector(np.random.rand(10,3).astype(np.float32))
o3d.io.write_point_cloud('/tmp/tiny.ply', pcd)
print('OK')
\"
"

Result: process exits with code 139 (SIGSEGV), no Python traceback, no stderr output beyond an unrelated onnxruntime-style cpuinfo warning we see elsewhere in the same environment (not from open3d itself, but suggests CPU-feature-detection may be unreliable in this virtualized ARM64 environment generally).

Expected behavior

write_point_cloud should either succeed or raise a Python exception — not crash the interpreter with an unhandled signal.

What I've isolated so far

• Reproduces with both write_ascii=True and the binary default — format is not the differentiator.
• Reproduces with as few as 10 points and with real ~27k-point clouds from an actual pipeline.
• Reproduces with a single process, zero concurrency, writing to both a plain container filesystem path (/tmp) and a bind-mounted host volume — so it isn't specific to any particular filesystem/mount type.
• Does not reproduce under --platform linux/amd64 (x86_64, run via Rosetta 2 emulation on the same Mac) — same script, same container base image, only the platform flag changed, and pip install then resolves a different (x86_64) wheel that works correctly. This strongly suggests the bug is specific to the aarch64 wheel's native code (possibly in the bundled TBB, given a CPU-vendor-detection warning we see elsewhere in the same environment from an unrelated library using the cpuinfo project — worth checking if Open3D's aarch64 build links a similar CPU-dispatch mechanism).

Workaround

Forcing platform: linux/amd64 (x86_64 emulation via Rosetta 2) in the container config avoids the bug entirely, at the cost of running the whole container under CPU emulation instead of natively.