Title: test_ctypes fails in test_ulonglong on sparc buildbots
Type: behavior Stage: needs patch
Components: Tests Versions: Python 3.6, Python 2.7
Status: open Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, flox, loewis, mark.dickinson, pitrou, r.david.murray, serhiy.storchaka, theller, vstinner
Priority: normal Keywords: buildbot, patch

Created on 2010-04-05 12:18 by r.david.murray, last changed 2018-12-12 16:09 by BreamoreBoy.

File name Uploaded Description Edit
sparc.diff loewis, 2010-04-07 11:00
Messages (13)
msg102371 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-04-05 12:18
FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/", line 68, in test_ulonglong
    self.check_type(c_ulonglong, 42)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 0L != 42
msg102372 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-04-05 12:18
The ubuntu and debian sparc buildbots show the same failure, none of the other buildbots do.
msg102373 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2010-04-05 12:20
This bug is already reported here:
msg102528 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-04-07 09:43
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.
msg102531 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-04-07 11:00
I have just studied the issue in detail; v8.S is indeed missing support for unsigned long long. Here is a patch.
msg102532 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-04-07 11:03
Committed as r79892.
msg102625 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2010-04-08 16:26
Martin, you should probably post your patch to upstream libffi.
msg102984 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-12 22:21
It should be ported to py3k, the sparc buildbots still fail there.
msg103315 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-04-16 12:12
> Committed as r79892.

Commited to py3k (r80106), but blocked in 3.1 (r80107) because Python 3.1 uses libffi 3.0.5.
msg103884 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-04-21 18:43
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)

	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)

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.
msg133125 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-04-06 13:12
There seems to be also a problem with src/sparc/v9.S.

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/", 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/", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 10955412241121898851L != 10955412242170339782L
msg221723 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-27 20:41
Can this be closed as "out of date"?
msg331683 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-12-12 09:07
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.
Date User Action Args
2018-12-12 16:09:05BreamoreBoysetnosy: - BreamoreBoy
2018-12-12 09:07:39serhiy.storchakasetnosy: + serhiy.storchaka

messages: + msg331683
versions: + Python 3.6, - Python 3.4, Python 3.5
2014-06-27 20:41:50BreamoreBoysetnosy: + BreamoreBoy

messages: + msg221723
versions: + Python 3.4, Python 3.5
2011-04-06 13:17:09Arfreversetversions: + Python 2.7, - 3rd party
2011-04-06 13:12:49Arfreversetnosy: + Arfrever

messages: + msg133125
versions: + 3rd party, - Python 2.7
2010-04-21 18:43:45mark.dickinsonsetmessages: + msg103884
2010-04-16 12:12:17vstinnersetstatus: pending -> open
nosy: + vstinner
messages: + msg103315

2010-04-12 22:21:30pitrousetstatus: closed -> pending
2010-04-12 22:21:14pitrousetnosy: + pitrou
messages: + msg102984
2010-04-08 16:26:17thellersetmessages: + msg102625
2010-04-07 11:03:07loewissetstatus: open -> closed
resolution: fixed
messages: + msg102532
2010-04-07 11:00:04loewissetfiles: + sparc.diff

nosy: + loewis
messages: + msg102531

keywords: + patch
2010-04-07 09:43:57mark.dickinsonsetnosy: + mark.dickinson
messages: + msg102528
2010-04-05 12:20:49floxsetnosy: + flox
messages: + msg102373
2010-04-05 12:19:00r.david.murraysetmessages: + msg102372
2010-04-05 12:18:04r.david.murraycreate