Repository navigation
Lots of warnings when building macos x86_64, then it crashes when using the wheel #219
Description
After #217, which was merged the macos x86_64 wheels crash. I see many warnings during the build like
ld: warning: reducing alignment of section __TEXT,__text \
from 0x10000 to 0x1000 because it exceeds segment maximum alignment
When using the wheel in numpy/numpy#30049, there is a segfault. I can reproduce locally on a macbook M1 (arm64) by
arch -x86_64 bash
python3.12 -m venv /tmp/venv312x86_64
. /tmp/venv312x86_64/bin/activate
cd numpy
python -m pip install -r requirements/build_requirements.txt
python -m pip install scipy-openblas64-0.3.30.0.4
spin build --clean --with-scipy-openblas=64 -- -Dpkg_config_path=$PWD/.openblas
spin python -- -c "import numpy"
Then in the console app (launcher -> console) I see this log for Python:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000112443740
Exception Codes: 0x0000000000000002, 0x0000000112443740
Termination Reason: Namespace SIGNAL, Code 10 Bus error: 10
Terminating Process: exc handler [92470]
VM Region Info: 0x112443740 is in 0x111e88000-0x114ab1000; bytes after start: 6010688 bytes before end: 40294591
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
VM_ALLOCATE (reserved) 10f004000-111004000 [ 32.0M] rw-/rwx SM=NUL reserved VM address space (unallocated)
GAP OF 0xe84000 BYTES
---> __TEXT 111e88000-114ab1000 [ 44.2M] r-x/rwx SM=COW /tmp/*/libscipy_openblas64_.dylib
__DATA 114ab1000-114ad8000 [ 156K] rw-/rwx SM=COW /tmp/*/libscipy_openblas64_.dylib
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libscipy_openblas64_.dylib 0x112443790 dcopy_k_NEHALEM + 80
1 _umath_linalg.cpython-312-darwin.so 0x10dfd5d2c copy(long*, double*, long*, double*, long*) + 20 (umath_linalg.cpp:802) [inlined]
I think the two things are connected?
Are we missing a compiler flag maybe because of cross-compilation?
Activity
ffgan commentedon Oct 23, 2025
We can directly switch to macos-intel, but it will cause the CI to be slightly slower. Since I don't have Mac hardware on hand, I may not be able to assist you with more testing. If there are other modifications needed, please feel free to @ me directly.
rgommers commentedon Oct 26, 2025
Rather than debugging this, I'd switch to
macos-15-intel, that's way easier and the instances being slower isn't all that interesting.rgommers commentedon Oct 26, 2025
(never cross build when you can do a native build)
mattip commentedon Oct 26, 2025
Switching to macos-15-intel is failing in #223, which is "better" than creating a faulty wheel.
mattip commentedon Oct 30, 2025
Closing - reverted to using gfortran-11 on a macos-14 image with xcode 15.4 cleared the crashes.
rgommers commentedon Oct 30, 2025
Great, thanks Matti!