Python 3.10.0 crashes on MacOS x86_64

[akrherz]

• I read the conda-forge documentation and could not find the solution for my problem there.

Issue: Two conda-forge repos having strange crashes within CI on MacOS with python 3.10.0

Note: I am not a mac user, but am just attempting to help conda-forge repos get green CI builds :)

Examples of CI crashes: conda-forge/magics-feedstock#106 and conda-forge/shapely-feedstock#92

I do have an old mac that I am able to reproduce the shapely crashes and have gotten some iterative feedback here along with lldb output: shapely/shapely#1227

Does anybody here have interest / mac experience to help figure out what is wrong? Thanks!

[dopplershift]

I'll add to this (because I think they are related) the Abort trap: 6 (the same as the error from Magics) that we're seeing in conda-forge/rtree-feedstock#41 and conda-forge/python-libarchive-c-feedstock#29. I'll note that the last two appear to have the aborts coming out of libffi, which is also where Shapely is crashing.

[dopplershift]

So something is definitely broken about ctypes in the conda-forge build. Shapely builds and runs tests fine on my system with Homebrew Python 3.10; more importantly, if I copy _ctypes.cpython-310-darwin.so from the Homebrew Python 3.10 into my conda-forge one, Shapely's tests run without crashing. It should be noted that a difference between the two is that Homebrew's _ctypes is linked to /usr/lib/libffi.dylib.

[dopplershift]

I took the Python recipe and did a local build where I removed libffi from host. Running conda build for all four of rtree, python-libarchive-c, shapely, and magics worked fine (tests completed) using my local build of Python.

Is there any particular reason to avoid the macOS copy of libffi? This Python issue would seem to indicate that using the system copy for macos is the norm.

[xhochy]

Pinging @isuruf and @erykoff here as they have had to experience a lot of issues with libffi on macOS.

One important difference to note here is that these issues only seem to happen on osx-64 where we historically have build with conda-forge's libffi already for the last releases. Only osx-arm64 now also uses the c-f libffi, too.

[jakirkham]

Actually this raises a question that is unclear (at least to me). Is this occurring with macOS ARM or x86?

Edit: If it is ARM related, this comment ( libffi/libffi#571 (comment) ) and related issue may be of interest

[erykoff]

I will investigate. What is notable is that the issue above to get python to work with both system and forge libffi was first put in 3.10 and then backported. But 3.9 isn’t exhibiting this problem.

[erykoff]

Interesting, I was unable to replicate the segfault with the shapely py3.10 build on osx-arm64. So it may be limited to x86 (or possibly macos<11). I will try to replicate locally on x86/macos 10.14.

[dopplershift]

For completeness, my tests locally were done on macOS 11.6.1.

[akrherz]

My reproducer is on macOS 10.13.6 🐄 and I have not seen this issue reproduced on arm64

[jakirkham]

Retitled the issue to indicate this is an x86_64 issue

[erykoff]

I have been digging, and haven't figured out what's going wrong. Within shapely itself it crashes when the c++ throws an error, but only then (that is, successful ctypes calls work just fine). (I don't know if that's a clue or a coincidence). However, I have also been able to replicate the crash running on my M1 macbook when trying it in x86 rosetta translation. So that does make debugging marginally easier.

[jakirkham]

Do you have the gdb or lldb backtrace? Maybe worth sharing here