Hide Forgot
Description of problem: test_rect (test.test_cmath.CMathTests) ... ok test_specific_values (test.test_cmath.CMathTests) ... FAIL test_user_object (test.test_cmath.CMathTests) ... test test_cmath failed -- Traceback (most recent call last): File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 352, in test_specific_values msg=error_message) File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 112, in rAssertAlmostEqual '{!r} and {!r} are not sufficiently close'.format(a, b)) AssertionError: acos0200: acos(complex(1.620686051868302e+308, 1.0308426226285283e+308)) Expected: complex(0.5665082609382622, -710.5420687424156) Received: complex(0.5665082609382622, -inf) Received value insufficiently close to expected value. ok ====================================================================== FAIL: test_specific_values (test.test_cmath.CMathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 352, in test_specific_values msg=error_message) File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 112, in rAssertAlmostEqual '{!r} and {!r} are not sufficiently close'.format(a, b)) AssertionError: acos0200: acos(complex(1.620686051868302e+308, 1.0308426226285283e+308)) Expected: complex(0.5665082609382622, -710.5420687424156) Received: complex(0.5665082609382622, -inf) Received value insufficiently close to expected value. Version-Release number of selected component (if applicable): python-2.7.2-5.2.fc16 Steps to Reproduce: 1. ppc-koji build --scratch dist-f16 python-2.7.2-5.2.fc16.src.rpm Actual results: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=311458
I accidentally added my notes on this to bug 757021, rather than here, so I'll repeat the information here.
Attachment 541076 [details] is a debugging patch to capture the extent of the problem. It hacks up test_cmath so that test_specific_values shows all failing cases (and ultimately "succeeds"), rather than aborting on the first failed case, so that we can see the extent of the problem. Attachment 541077 [details] is the log from running "python -m test.test_cmath" with the patch. Summarizing that log, and comparing against cmath_testcases.txt: * 3 of the 20 tests for "acos() near infinity" fail due to the imaginary component of the result being unexpectedly either "+/-inf" * 4 of the 20 tests for "acosh() near infinity" fail due to the real component of the result being unexpectedly "inf" * 4 of the 20 tests for "asin() near infinity" fail due to the imaginary component of the result being unexpectedly either "+/-inf" * 4 of the 20 tests for "asinh() near infinity" fail due to the real component of the result being unexpectedly either "+/-inf" * 4 of the 20 tests for "atan() near infinity" fail due to the imaginary component of the result being unexpectedly either "+/-0.0" * 4 of the 20 tests for "atanh() near infinity" fail due to the real component of the result being unexpectedly either "+/-0.0" * 4 of the 20 tests for "log() near infinity" fail due to the real component of the result being unexpectedly either "inf" * 4 of the 20 tests for "log10() near infinity" fail due to the real component of the result being unexpectedly either "inf" * both of the 2 tests for "sqrt() with input whose abs value overflows" fail, one expectedly collapsing to (inf, -0.0), the other to (0.0, -inf) This is out of 1885 tests within test_specific_values (__main__.CMathTests)
Attachment 541092 [details] is a crude patch to log all calls to "hypot (3)" from Modules/cmathmodule.c Attachment 541093 [details] is a log from running "python -m test.test_cmath" with that patch, and shows the calls to hypot() interleaved with the cmath test cases. Python's "complex" type uses a pair of C "double" values internally (real and imag), which on ppc64 should be standard IEEE754. ppc64's glibc has an optimized implementation of "hypot" (in libm): sysdeps/powerpc/fpu/e_hypot.c All of the failing Python test cases involve a call to hypot(). When examining the results in comment #2, a comparison of calls to hypot with the failing test cases, reveals that all of the failing cases are preceded by a call to hypot that returns "inf".
Python's math.hypot() is a thin wrapper around hypot(3); a Python "float" uses a C "double" internally. Attachment 541097 [details] is a Python script to exercise hypot(3). It calls hypot() for all of the x,y pairs that fail within the Python test case on ppc64. On x86_64, with glibc-2.14-5.x86_64 (and python-2.7.1-7.fc15.x86_64), all results are non-infinite, with exponent e+307 or e+308 (see attachment 541102 [details] for the results on this box). On ppc64, with glibc-2.14.90-19.ppc64 (and python-2.7.2-4.2.fc16.ppc64), all results are "inf".
Filed in upstream bug tracker for CPython as: http://bugs.python.org/issue13534
Filed in glibc's bug tracker as: http://sourceware.org/bugzilla/show_bug.cgi?id=13472
as there's already a upstream fix available, can you add that to the f16 glibc git branch, please ? It affects only powerpc, so an update on the primary archs won't be necessary, we just need the git commit.
I was hoping to start to throttle back the updates now that I'm starting to get a handle on things in glibc-land. There's a small handful that I've got queued for the next update, I'll make sure this one gets added.
glibc-2.14.90-24.fc16.4 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/glibc-2.14.90-24.fc16.4
glibc-2.14.90-24.fc16.4 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.