test_ctypes fails in test_ulonglong on sparc buildbots

[bitdancer]

BPO	8314
Nosy	@loewis, @theller, @mdickinson, @pitrou, @vstinner, @bitdancer, @florentx, @serhiy-storchaka
Files	sparc.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2010-04-05.12:18:04.120>
labels = ['type-bug', 'tests']
title = 'test_ctypes fails in test_ulonglong on sparc buildbots'
updated_at = <Date 2018-12-12.16:09:05.437>
user = 'https://github.com/bitdancer'

bugs.python.org fields:

activity = <Date 2018-12-12.16:09:05.437>
actor = 'BreamoreBoy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Tests']
creation = <Date 2010-04-05.12:18:04.120>
creator = 'r.david.murray'
dependencies = []
files = ['16798']
hgrepos = []
issue_num = 8314
keywords = ['patch', 'buildbot']
message_count = 13.0
messages = ['102371', '102372', '102373', '102528', '102531', '102532', '102625', '102984', '103315', '103884', '133125', '221723', '331683']
nosy_count = 9.0
nosy_names = ['loewis', 'theller', 'mark.dickinson', 'pitrou', 'vstinner', 'Arfrever', 'r.david.murray', 'flox', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue8314'
versions = ['Python 2.7', 'Python 3.6']

[bitdancer]

======================================================================
FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 68, in test_ulonglong
    self.check_type(c_ulonglong, 42)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 0L != 42

[bitdancer]

The ubuntu and debian sparc buildbots show the same failure, none of the other buildbots do.

[florentx]

This bug is already reported here:
http://bugs.python.org/issue8142#msg101134

[mdickinson]

It's surprising that test_ulonglong fails, while test_longlong passes: can the Linux Sparc ABI really be treating these two types differently?

Maybe more information could be gained by supplying a more interesting test value than 42---some 8-byte value with all bytes different, for example.

In any case, this seems likely to be a libffi bug somewhere; maybe we could bring it up on the libffi mailing list. If we can translate the failing Python code into failing C code first that would probably increase the chances of getting a good answer. Without access to Sparc hardware, I don't see much other way of making progress here.

[loewis]

I have just studied the issue in detail; v8.S is indeed missing support for unsigned long long. Here is a patch.

[loewis]

Committed as r79892.

[theller]

Martin, you should probably post your patch to upstream libffi.

[pitrou]

It should be ported to py3k, the sparc buildbots still fail there.

[vstinner]

Committed as r79892.

Commited to py3k (r80106), but blocked in 3.1 (r80107) because Python 3.1 uses libffi 3.0.5.

[mdickinson]

I was going to say that I think that this issue can be closed now...

... but the src/sparc/v8.S file still looks wrong to me: Martin fixed one missing FFI_TYPE_UINT64 case, but it looks to me as though there's another one, in ffi_call_v8. The code starting at line 68 in that file looks like:

cmp	%i3, FFI_TYPE_INT
be,a	done
st	%o0, [%i4]	! (delay)

cmp	%i3, FFI_TYPE_FLOAT
be,a	done
st	%f0, [%i4+0]	! (delay)

cmp	%i3, FFI_TYPE_DOUBLE
be,a	double
st	%f0, [%i4+0]	! (delay)

cmp	%i3, FFI_TYPE_SINT8
be,a	sint8
sll	%o0, 24, %o0	! (delay)

cmp	%i3, FFI_TYPE_UINT8
be,a	uint8
sll	%o0, 24, %o0	! (delay)

cmp	%i3, FFI_TYPE_SINT16
be,a	sint16
sll	%o0, 16, %o0	! (delay)

cmp	%i3, FFI_TYPE_UINT16
be,a	uint16
sll	%o0, 16, %o0	! (delay)

cmp	%i3, FFI_TYPE_SINT64
be,a	longlong
st	%o0, [%i4+0]	! (delay)

done:
ret
restore

Shouldn't there should be another block here for FFI_TYPE_UINT64, essentially identical to the FFI_TYPE_SINT64 block? Or am I missing something?

I don't know why this omission doesn't cause buildbot failures; perhaps it's because the compiled test function (e.g., tf_Q in _ctypes_test.c) just happens to already have placed the correct values in the right locations ([%i4 + 0] and [%i4 + 4]) already, before transferring them to o0 and o1.

I've asked about this on the libffi-discuss mailing list, as a follow-up to Victor's report there.

[Arfrever]

There seems to be also a problem with src/sparc/v9.S.
https://bugs.gentoo.org/show_bug.cgi?id=362065

FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py", line 72, in test_ulonglong
    self.check_type(c_ulonglong, 10955412242170339782)
  File "/var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 10955412241121898851L != 10955412242170339782L

[BreamoreBoy]

Can this be closed as "out of date"?

[serhiy-storchaka]

Starting from 3.7 Python always uses system libffi. 3.4 and 3.5 are in security bugfix only mode. So this issue is only for 2.7 and 3.6.