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

Created on 2017-03-13 13:50 by ishcherb, last changed 2018-03-11 22:20 by ned.deily. This issue is now closed.

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 (12)
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.
msg312200 - (view) Author: Iryna Shcherbina (ishcherb) * Date: 2018-02-15 11:00
PR 1559 fixes the issue in Fedora builds on arm64. The issue is no longer reproducible with Python 3.7.
msg312963 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-02-26 21:53
Vinay, should this backported to 3.6?  Otherwise, can the issue be closed?
msg312964 - (view) Author: Charalampos Stratakis (cstratak) * Date: 2018-02-26 22:02
The bug is still present on the 3.6 branch.
msg312982 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-02-27 08:48
> Vinay, should this back-ported to 3.6?

Yes, I think it should be.
msg313625 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-03-11 22:20
OK, PR 1559 (in 3.7.0) for Issue30353 has been backported to 3.6 in PR 5954 for release in 3.6.5.  So based on msg312200, I'm going to assume the problem is no longer reproducible in 3.6 and close this issue.  If not, please reopen.
Date User Action Args
2018-03-11 22:20:58ned.deilysetstatus: open -> closed
resolution: fixed
messages: + msg313625

stage: resolved
2018-02-27 08:48:58vinay.sajipsetmessages: + msg312982
2018-02-26 22:02:22cstrataksetmessages: + msg312964
2018-02-26 21:53:40ned.deilysetmessages: + msg312963
versions: + Python 3.7
2018-02-15 11:00:04ishcherbsetmessages: + msg312200
2017-05-19 09:39:43erik.braysetpull_requests: + pull_request1760
2017-04-24 13:14:28yan12125setnosy: + yan12125
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