Add segfault test on osx-64+libffi=3.4 (bpo-44556)

[mbargull]

refs:

• https://bugs.python.org/issue44556
• Python 3.10.0 crashes on MacOS x86_64 #522
• Rebuild for python310 llvmlite-feedstock#58 (comment)

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[mbargull]

If all goes as planned, this fails only for osx-64 with libffi=3.4.

TODOs:

1. Debug CPython 3.10 + libffi 3.4 to see why this fails and patch, rebuild.
2. Pin libffi=3.3 on osx-64 at least and rebuild.

Re 1.: I don't have the resources/time to do so.
Re 2.: Should we do that globally in conda-forge-pinning (i.e., stop/revert the libffi=3.4 migration (on osx-64 at least))?

[ihnorton]

It might be worth printing out the cpuinfo on the test-runner. I can't reproduce this on osx-x64 / macOS 10.14.6 / MacBook Pro (Retina, 15-inch, Mid 2015) (Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz).

Details

environment

# This file may be used to create an environment using:
# $ conda create --name <env> --file <this file>
# platform: osx-64
bzip2=1.0.8=hc929b4f_4
ca-certificates=2021.10.8=h033912b_0
libffi=3.4.2=h0d85af4_5
libzlib=1.2.11=h9173be1_1013
ncurses=6.2=h2e338ed_4
openssl=3.0.0=h0d85af4_2
pip=21.3.1=pyhd8ed1ab_0
py-cpuinfo=8.0.0=pypi_0
python=3.10.0=h38b4d05_2_cpython
python_abi=3.10=2_cp310
readline=8.1=h05e3726_0
setuptools=59.1.1=pypi_0
sqlite=3.36.0=h23a322b_2
tk=8.6.11=h5dbffcc_1
tzdata=2021e=he74cb21_0
wheel=0.37.0=pyhd8ed1ab_1
xz=5.2.5=haf1e3a3_1
zlib=1.2.11=h9173be1_1013

cpu

>>> import cpuinfo
>>> cpuinfo.get_cpu_info()
{'python_version': '3.10.0.final.0 (64 bit)', 'cpuinfo_version': [8, 0, 0], 'cpuinfo_version_string': '8.0.0', 'arch': 'X86_64', 'bits': 64, 'count': 8, 'arch_string_raw': 'x86_64', 'vendor_id_raw': 'GenuineIntel', 'brand_raw': 'Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz', 'hz_advertised_friendly': '2.2000 GHz', 'hz_actual_friendly': '2.2000 GHz', 'hz_advertised': [2200000000, 0], 'hz_actual': [2200000000, 0], 'l2_cache_size': 262144, 'stepping': 1, 'model': 70, 'family': 6, 'flags': ['1gbpage', 'abm', 'acpi', 'aes', 'apic', 'avx', 'avx1.0', 'avx2', 'bmi1', 'bmi2', 'clflush', 'clfsh', 'cmov', 'cx16', 'cx8', 'de', 'ds', 'ds_cpl', 'dscpl', 'dtes64', 'dts', 'em64t', 'erms', 'est', 'f16c', 'fma', 'fpu', 'fpu_csds', 'fxsr', 'ht', 'htt', 'ibrs', 'invpcid', 'l1df', 'lahf', 'lahf_lm', 'lzcnt', 'mca', 'mce', 'mdclear', 'mmx', 'mon', 'monitor', 'movbe', 'msr', 'mtrr', 'osxsave', 'pae', 'pat', 'pbe', 'pcid', 'pclmulqdq', 'pdcm', 'pge', 'pni', 'popcnt', 'pse', 'pse36', 'rdrand', 'rdrnd', 'rdtscp', 'rdwrfsgs', 'seglim64', 'sep', 'smep', 'ss', 'ssbd', 'sse', 'sse2', 'sse3', 'sse4.1', 'sse4.2', 'sse4_1', 'sse4_2', 'ssse3', 'stibp', 'syscall', 'tm', 'tm2', 'tpr', 'tsc', 'tsc_thread_offset', 'tscdeadline', 'tsci', 'tsctmr', 'vme', 'vmx', 'x2apic', 'xd', 'xsave', 'xtpr'], 'l2_cache_line_size': 256, 'l2_cache_associativity': 6}

The environment in <details> above has libffi 3.4.2 h0d85af4_5 but I also tried with libffi 3.4.2 he49afe7_4 as in the failing test run on CI.

[jakirkham]

Marcel you read my mind 😂

[jakirkham]

As Marcel said above, this demonstrates the issue with libffi 3.4 and python 3.10 on macOS x86_64. This is also tracked upstream ( https://bugs.python.org/issue44556 ).

So currently conda-forge-pinning has libffi 3.3 pinned. However there is a libffi 3.4 migrator in progress.

Something that is a little unclear is whether issues like this will crop up with libffi 3.4 that are not python related. Thus far this seems pretty localized.

In any event, it seems worth discussing whether we continue with this migrator, whether we modify it (say to cover both 3.3 & 3.4), or whether we revert it and wait for a less troublesome version of libffi. Thoughts?

cc @conda-forge/core

[akrherz]

Peanut gallery here, can something quick/easy be done to get a version of python3.10 + libffi=3.3 available for OSX-64 from conda-forge? Presently, it is not possible it seems

$ mamba create -n test python=3.10 libffi=3.3
Encountered problems while solving:
  - package python-3.10.0-h1248fe1_1_cpython requires libffi >=3.4.2,<3.5.0a0, but none of the providers can be installed

Then the troublesome packages could at least pin down libffi ?

[beckermr]

Let's hold off on big decisions here just a bit. @erykoff is working on something related and may have a fix.

[jakirkham]

Let's hold off on big decisions here just a bit. @erykoff is working on something related and may have a fix.

Just saw that.

xref: #522 (comment)