This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: `test_longdouble` fails on Mac when using system libffi (version 3.1)
Type: crash Stage: resolved
Components: ctypes, macOS, Tests Versions: Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: Maxime Belanger, amaury.forgeotdarc, belopolsky, hynek, meador.inge, ned.deily, ronaldoussoren
Priority: normal Keywords:

Created on 2015-02-27 06:57 by Maxime Belanger, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (4)
msg236729 - (view) Author: Maxime Belanger (Maxime Belanger) Date: 2015-02-27 06:57

We're compiling a custom version of Python 2.7.9 for the Mac (building on OS X 10.9 with Xcode 6.1), and we're instructing Python to use a vanilla copy of `libffi` (that we've also compiled ourselves) using the `--with-system-ffi` flag. We're running the regression test suite for sanity purposes and we've noticed this error in `test_ctypes`'s `test_longdouble` method:

FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks)
Traceback (most recent call last):
  File "../Python.framework/Versions/2.7/lib/python2.7/ctypes/test/", line 88, in test_longdouble
    self.check_type(c_longdouble, 3.14)
  File "../Python.framework/Versions/2.7/lib/python2.7/ctypes/test/", line 24, in check_type
    self.assertEqual(result, arg)
AssertionError: 0.0 != 3.14

I'm reasonably convinced this is caused by the version of `libffi` we're using. It seems that if the `--with-system-ffi` flag isn't set, an internal version of `libffi` is used instead. However, given that version 3.1 is said to be the version Python 2.7.9 is "tracking", this feels like a bug to me. Also, it seems that trying to hit this code path in production code could trigger a crash.
msg236730 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2015-02-27 07:24
Is there a reason you can't use the Python-supplied version of libffi?  That's what the standard builds for installers do.  I believe it is the case that there are OS X-specific changes in the Python local version that do not exist in the upstream and/or system versions but I've not familiar with the differences myself; it's not been a high priority issue to test with them.
msg236764 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2015-02-27 15:25
On OSX the internal copy of libffi that's used is based on the one in PyObjC, which in turn is based on the version of libffi on (IIRC with some small patches that fix minor issues found by the PyObjC testsuite).
msg379418 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2020-10-23 09:06
Closing as out of date:

- python 2 issue
- I don't get this error when using the system libffi (bpo-41100)
Date User Action Args
2022-04-11 14:58:13adminsetgithub: 67722
2020-10-23 11:10:04iritkatrielsetstatus: open -> closed
2020-10-23 09:06:19ronaldoussorensetresolution: out of date
messages: + msg379418
stage: resolved
2015-02-27 15:25:21ronaldoussorensetmessages: + msg236764
2015-02-27 07:24:47ned.deilysetmessages: + msg236730
2015-02-27 07:09:19SilentGhostsetnosy: + ronaldoussoren, amaury.forgeotdarc, belopolsky, ned.deily, meador.inge, hynek
components: + macOS
2015-02-27 06:57:30Maxime Belangercreate