Title: test_ctypes test_pass_by_value fails on arm64 (aarch64) architecture
Type: Stage:
Components: ctypes, Tests Versions: Python 3.6
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Chi Hsuan Yen, cstratak, ishcherb, ned.deily, vinay.sajip
Priority: normal Keywords:

Created on 2017-03-13 13:50 by ishcherb, last changed 2017-05-19 09:39 by erik.bray.

File name Uploaded Description Edit
Python3.6.1rc1_build_log.txt ishcherb, 2017-03-13 13:48
Pull Requests
URL Status Linked Edit
PR 1559 erik.bray, 2017-05-19 09:39
Messages (7)
msg289539 - (view) Author: Iryna Shcherbina (ishcherb) * Date: 2017-03-13 13:48
I am trying to build Python 3.6.1rc1 on Fedora, and have the following test failing on arm64 (aarch64) architecture:

FAIL: test_pass_by_value (ctypes.test.test_structures.StructureTestCase)
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.6.1rc1/Lib/ctypes/test/", line 413, in test_pass_by_value
    self.assertEqual(s.first, 0xdeadbeef)
AssertionError: 195948557 != 3735928559

The build log is attached.
The test was added in this commit [1] as a fix for bpo-29565.

Any idea what this can be related to?

msg289589 - (view) Author: Iryna Shcherbina (ishcherb) * Date: 2017-03-14 14:23
Hi Vinay, I have added you to the nosy list as you are the author of the fix for bpo-29565, and would like to ask you for insights or ideas on why the test would fail only on one architecture (arm64)?
msg289595 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2017-03-14 15:05
The test checks that a structure passed by value is indeed passed by value - something that is architecture-dependent, as calling conventions differ across architectures.

If the test fails, this indicates that the structure isn't being passed by value - a pointer to the structure is probably passed, which is pass-by-reference rather than pass-by-value. This indicates that a change to ctypes or libffi is needed to fix this. See the changes made in Modules/_ctypes/libffi_msvc/ffi.c for bpo-29565 - probably, analogous changes need to be made to the corresponding code for arm64.
msg289669 - (view) Author: Charalampos Stratakis (cstratak) * Date: 2017-03-15 12:29
Since this newly added assertion [0] fails for aarch64 shouldn't this be considered a regression?

And taking into account the timeframe, a release blocker for 3.6.1?
msg289670 - (view) Author: Charalampos Stratakis (cstratak) * Date: 2017-03-15 12:29
msg289674 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2017-03-15 13:32
I don't think it's a regression. It's catching an error that was there, but wasn't tested for before.

If it should be a release blocker - that should not be for any reversion of the change to the test, but for implementing the pass-by-value functionality correctly.
msg290065 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2017-03-23 22:40
Technically speaking, we do not officially support arm64 in our release process as we have no arm64 buildbots nor an identified core developer for the platform; see PEP 11 for the policy details.  So there is no place to test a fix if there was one identified.  That said, it would be good to fix the problem if someone is willing to provide a fix and test it or determine that the issue here is a libffi problem.  It would be even better if we could make arm64 an officially supported platform as outlined.
Date User Action Args
2017-05-19 09:39:43erik.braysetpull_requests: + pull_request1760
2017-04-24 13:14:28Chi Hsuan Yensetnosy: + Chi Hsuan Yen
2017-03-23 22:40:03ned.deilysetmessages: + msg290065
2017-03-15 13:33:29vinay.sajipsetnosy: + ned.deily
2017-03-15 13:32:35vinay.sajipsetmessages: + msg289674
2017-03-15 12:29:54cstrataksetmessages: + msg289670
2017-03-15 12:29:12cstrataksetnosy: + cstratak
messages: + msg289669
2017-03-14 15:05:59vinay.sajipsetmessages: + msg289595
2017-03-14 14:23:19ishcherbsetmessages: + msg289589
2017-03-13 17:13:57ishcherbsetnosy: + vinay.sajip
2017-03-13 13:50:54ishcherbcreate