FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) [SPARC/64-bit] #50279
Comments
|
Greetings, I have downloaded and compiled Python 3.1b1 on Solaris 10 Update 6 Included below are the initial details, is there something more I can Regards, ./python Lib/test/regrtest.py -v test_ctypes ====================================================================== Traceback (most recent call last):
File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
self.check_type(c_longdouble, 3.14)
File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: First differing element 1:
0.0
3.14
- (-3, 0.0)
+ (-3, 3.14)Ran 328 tests in 3.853s FAILED (failures=1)
test test_ctypes failed -- Traceback (most recent call last):
File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
self.check_type(c_longdouble, 3.14)
File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: First differing element 1:
0.0
3.14
- (-3, 0.0)
+ (-3, 3.14)1 test failed: The test code (from Python-3.1b1/Lib/ctypes/test/test_callbacks.py) and ealier in the same file [software@specula] 64-bit SPARC % gcc -v [software@specula] 64-bit SPARC % cat /etc/release Build Procedure Python 3.1b1 ## Note PKGS_PREFIX=/pkgs/64-bit and PKGS_RELEASE=/pkgs/64-bit/release gtar fxv <path>/Python-3.1b1.tar.bz2 # The CPPFLAGS & LDFLAGS are used by setup.py in external modules builds echo "crypt cryptmodule.c" >> Modules/Setup.local ## Solaris does not gmake |
illumino
mannequin
added
tests
|
I get a nearly identical failure building Python 2.6.2 on a SPARC64 # ./python ./Lib/test/test_ctypes.py ====================================================================== Traceback (most recent call last):
File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
self.check_type(c_longdouble, 3.14)
File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: (-3, 0.0) != (-3, 3.1400000000000001)Ran 319 tests in 1.951s FAILED (failures=1)
Traceback (most recent call last):
File "./Lib/test/test_ctypes.py", line 12, in <module>
test_main()
File "./Lib/test/test_ctypes.py", line 9, in test_main
run_unittest(unittest.TestSuite(suites))
File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/test/test_support.py",
line 722, in run_unittest
_run_suite(suite)
File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/test/test_support.py",
line 705, in _run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
self.check_type(c_longdouble, 3.14)
File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: (-3, 0.0) != (-3, 3.1400000000000001) |
|
The following script (based on an extract of test_callbacks.py) Could this be an issue with libffi? #!/bin/env python import sys
from ctypes import *
class Callback:
functype = CFUNCTYPE
def callback(self, *args):
self.got_args = args
return args[-1]
def check_type(self, typ, arg):
print "typ=%s" % (typ,)3.14 else "WORKED", result, self.got_args) 3.14 else "WORKED", result, self.got_args) 3.14 else "WORKED", result, self.got_args) 3.14 else "WORKED", result, self.got_args) 3.14 else "WORKED", result, self.got_args) 3.14 else "WORKED", result, self.got_args) 3.14 else "WORKED", result, self.got_args) 3.14 else "WORKED", result, self.got_args) 3.14 else "WORKED", result, self.got_args) callback = Callback()
callback.check_type(c_longdouble, 3.14)
# callback.check_type(c_longdouble, -3.14)
|
|
Turns out the problem is really in the Sparc version of libffi -- the I've attached a patch which I'm sure could be improved (there's By the way, I noticed that one of the test cases in the script I added |
|
Sorry for the internet lifetime I've been away. I have tested the patch provided against the released 3.1 distribution The patch was rejected by GNU patch, but applying by hand (copy/paste) Like the patch's author I can't say if this right approach to take, that Regards, And sorry for the delay. |
|
Closed bpo-9143 as a duplicate of this one. |
|
I believe this can be closed as a very similar change was done in r59626. |
|
Mark, the rev #s are not being translated correctly. Better to use the 10 digit hex #. Can you find the commit again? We have a SPARC Solaris 10 buildbot Peter or Clifford, can either of you report current status? |
|
Terry r59626 in the file's revision history refers to eefd521f19ce which I assume is what you're after. FWIW I get that on Windows 8.1 by right clicking on the file, select TortoiseHg, then Revision History. |
|
Terry, I no longer have easy access to SPARC64 systems (they are in boxes), so Peter |
|
The patch doesn't look anything like the current code. Is this issue still relevant? |
|
The 2014 patch to our copies of libffi eefd521f19ce included patches from 2009 forward, including at least one about long double alignment on sparc. If there are any problems now on current Solaris, they are likely to be different, and someone will find and report them. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: