Opened 11 years ago
Closed 8 years ago
#11705 closed enhancement (fixed)
Port Sage to SUSE Linux Power 7 (ppc64).
Reported by: | William Stein | Owned by: | David Kirkby |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | porting | Keywords: | sd32 sd35.5 |
Cc: | Leif Leonhardy, Benjamin Jones, Paul Zimmermann, Mariah Lennox, Jean-Pierre Flori | Merged in: | |
Authors: | Paul Zimmermann, Jeroen Demeyer | Reviewers: | Jean-Pierre Flori, François Bissey |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #12829, #12832, #14098, #14151 | Stopgaps: |
Description (last modified by )
Port Sage so that it builds and passes its full test suite on the new IBM Power 7 architecture running SUSE Linux.
This is the only test failure with sage-5.12.beta1:
sage -t devel/sage/sage/functions/special.py ********************************************************************** File "devel/sage/sage/functions/special.py", line 853, in sage.functions.special.elliptic_j.inverse_jacobi Failed example: P = plot(inverse_jacobi('sn', x, 0.5), 0, 1, plot_points=20) Expected nothing Got: <BLANKLINE> ;;; ;;; Stack overflow. ;;; Jumping to the outermost toplevel prompt ;;; <BLANKLINE> ********************************************************************** File "devel/sage/sage/functions/special.py", line 1014, in sage.functions.special.elliptic_j.EllipticKC Failed example: elliptic_f(RR(pi/2), 0.5) Expected: 1.85407467730137 Got: <BLANKLINE> ;;; ;;; Stack overflow. ;;; Jumping to the outermost toplevel prompt ;;; <BLANKLINE> sage172 ********************************************************************** File "devel/sage/sage/functions/special.py", line 1023, in sage.functions.special.elliptic_j.EllipticKC.__init__ Failed example: elliptic_f(RR(pi/2), 0.5) Expected: 1.85407467730137 Got: <BLANKLINE> ;;; ;;; Stack overflow. ;;; Jumping to the outermost toplevel prompt ;;; <BLANKLINE> sage174 ********************************************************************** 3 items had failures: 1 of 3 in sage.functions.special.elliptic_j.EllipticKC 1 of 3 in sage.functions.special.elliptic_j.EllipticKC.__init__ 1 of 6 in sage.functions.special.elliptic_j.inverse_jacobi [96 tests, 3 failures, 5.19 s]
Attachments (1)
Change History (193)
comment:1 Changed 11 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 11 years ago by
comment:3 Changed 11 years ago by
Description: | modified (diff) |
---|
comment:4 Changed 11 years ago by
fbissey -- do you want an account on skynet, so you can help us with porting to SUSE on a nice new "IBM Power 750 Express server" that we have?
comment:5 Changed 11 years ago by
This is the computer we have access to: http://www-03.ibm.com/systems/power/hardware/750/index.html
comment:6 Changed 11 years ago by
Cc: | Leif Leonhardy added |
---|
comment:7 Changed 11 years ago by
We are getting 13 power755 locally but they'll go live at the end of September - I am currently installing a power720 that is meant to be a deployment server. Got a BlueGene?/L and BlueGene?/P as well but that would be another exercise :)
The big pity as far as I am concerned is that there is no Gentoo-prefix for linux-ppc otherwise I could have been up and running faster.
We currently have some power5 575 some of which are running suse 9 and that's awful, the latest gcc I have been able to compile is 4.2.4.
comment:8 follow-up: 9 Changed 11 years ago by
I notice in the build logs that you have gcc-4.6.1 on that box. Is it a manual install of gcc?
comment:9 Changed 11 years ago by
Replying to fbissey:
I notice in the build logs that you have gcc-4.6.1 on that box. Is it a manual install of gcc?
Yes. Here is some info about the machine. If you want an account on it, send me an email and I can arrange it.
wstein@silius:~/silius/sage-4.7.1> cat /etc/issue Welcome to SUSE Linux Enterprise Server 11 SP1 (ppc64) - Kernel \r (\l). wstein@silius:~/silius/sage-4.7.1> uname -a Linux silius 2.6.32.43-0.4-ppc64 #1 SMP 2011-07-14 14:47:44 +0200 ppc64 ppc64 ppc64 GNU/Linux wstein@silius:~/silius/sage-4.7.1> gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.1/ppc64-Linux-power7-suse/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.1/lto-wrapper Target: powerpc64-unknown-linux-gnu Configured with: /usr/local/gcc-4.6.1/src/gcc-4.6.1/configure --enable-languages=c,c++,fortran --with-gnu-as --with-gnu-as=/usr/local/binutils-2.21/ppc64-Linux-power7-suse-gcc-4.3.4-suse/bin/as --with-gnu-ld --with-ld=/usr/local/binutils-2.21/ppc64-Linux-power7-suse-gcc-4.3.4-suse/bin/ld --with-gmp=/usr/local/mpir-2.4.0/ppc64-Linux-power7-suse-gcc-4.3.4-suse --with-mpfr=/usr/local/mpfr-3.0.1/ppc64-Linux-power7-suse-mpir-2.4.0-gcc-4.3.4-suse --with-mpc=/usr/local/mpc-0.9/ppc64-Linux-power7-suse-mpir-2.4.0-mpfr-3.0.1-gcc-4.3.4-suse --prefix=/usr/local/gcc-4.6.1/ppc64-Linux-power7-suse Thread model: posix gcc version 4.6.1 (GCC)
comment:10 Changed 11 years ago by
comment:11 Changed 11 years ago by
Cc: | Benjamin Jones added |
---|
comment:12 Changed 11 years ago by
Keywords: | sd32 added |
---|
comment:13 Changed 11 years ago by
I was trying to find a way to run the install of maxima through gdb and I got this
fbissey@silius:~/sage-4.7.2.alpha2> ./sage -gdb ---------------------------------------------------------------------- | Sage Version 4.7.2.alpha2, Release Date: 2011-08-24 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- ********************************************************************** * * * Warning: this is a prerelease version, and it may be unstable. * * * ********************************************************************** /home/fbissey/sage-4.7.2.alpha2/local/bin/sage-ipython GNU gdb (GDB) SUSE (7.3-0.6.1) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "ppc64-suse-linux". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/fbissey/sage-4.7.2.alpha2/local/bin/python...done. Missing separate debuginfo for /lib64/ld64.so.1 Try: zypper install -C "debuginfo(build-id)=9ad9cc2ebe9a93396712a1da1902ce1791d7a01a" Missing separate debuginfo for /lib64/power7/libpthread.so.0 Try: zypper install -C "debuginfo(build-id)=b5b6fe2d9c6386464baf451c855d26e32ac8e25f" [Thread debugging using libthread_db enabled] Missing separate debuginfo for /lib64/libdl.so.2 Try: zypper install -C "debuginfo(build-id)=0c5e22422f5abdea4081987ec9b7d276a7674246" Missing separate debuginfo for /lib64/libutil.so.1 Try: zypper install -C "debuginfo(build-id)=d05c063f9c3e2eaf208254f15783e80352551d5d" Missing separate debuginfo for /lib64/power7/libm.so.6 Try: zypper install -C "debuginfo(build-id)=0b0eca877c00501c95ef08f9f692405bfbfed207" Missing separate debuginfo for /lib64/power7/libc.so.6 Try: zypper install -C "debuginfo(build-id)=68ff029e9f430bd7351521dab154f400b384ff30" Python 2.6.4 (r264:75706, Sep 12 2011, 02:12:11) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. Setting permissions of DOT_SAGE directory so only you can read and write it. Detaching after fork from child process 59250. Detaching after fork from child process 59251. Missing separate debuginfo for /lib64/libcrypt.so.1 Try: zypper install -C "debuginfo(build-id)=5f55a2213c780d5f9d3ce2cd6a9ef1d4e63b8739" Detaching after fork from child process 59253. sage: install_package(maxima-5.25.1) --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) /home/fbissey/sage-4.7.2.alpha2/<ipython console> in <module>() /home/fbissey/sage-4.7.2.alpha2/local/lib/python2.6/site-packages/sage/structure/element.so in sage.structure.element.Element.__getattr__ (sage/structure/element.c:2794)() /home/fbissey/sage-4.7.2.alpha2/local/lib/python2.6/site-packages/sage/structure/parent.so in sage.structure.parent.getattr_from_other_class (sage/structure/parent.c:2940)() /home/fbissey/sage-4.7.2.alpha2/local/lib/python2.6/site-packages/sage/structure/parent.so in sage.structure.parent.raise_attribute_error (sage/structure/parent.c:2709)() AttributeError: 'sage.rings.real_mpfr.RealLiteral' object has no attribute 'gen'
I have created a spkg with the latest maxima in case that would make a difference but unsurprisingly it doesn't.
comment:14 Changed 11 years ago by
Benjamin posted a test log in #11708, let's analyse it:
sage -t -long -force_lib devel/sage/doc/en/numerical_sage/cvxopt.rst ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/doc/en/numerical_sage/cvxopt.rst", line 129: sage: print sol['x'] # ... below since can get -00 or +00 depending on architecture Expected: [ 1.00e...00] [ 1.00e+00] Got: [ 9.85e-01] [ 9.91e-01] <BLANKLINE> **********************************************************************
Rather large numerical noise and some formatting noise which is more curious.
There are multiples instances of these errors in that test:
sage -t -long -force_lib devel/sage/doc/en/bordeaux_2008/elliptic_curves.rst *** Warning: new stack size = 1098912 (1.048 Mbytes). ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/doc/en/bordeaux_2008/elliptic_curves.rst", line 299: sage: E.integral_points(both_signs=True) # about a minute Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_10[3]>", line 1, in <module> E.integral_points(both_signs=True) # about a minute###line 299: sage: E.integral_points(both_signs=True) # about a minute File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 5452, in integral_points w1, w2 = self.period_lattice().basis() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 2861, in period_lattice self._period_lattice = PeriodLattice_ell(self) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/period_lattice.py", line 231, in __init__ self._ei = self.f2.roots(AA,multiplicities=False) File "polynomial_element.pyx", line 4850, in sage.rings.polynomial.polynomial_element.Polynomial.roots (sage/rings/polynomial/polynomial_element.c:31255) File "real_roots.pyx", line 4115, in sage.rings.polynomial.real_roots.real_roots (sage/rings/polynomial/real_roots.c:36162) File "real_mpfi.pyx", line 277, in sage.rings.real_mpfi.RealIntervalField (sage/rings/real_mpfi.c:2982) File "real_mpfi.pyx", line 441, in sage.rings.real_mpfi.RealIntervalField_class.__init__ (sage/rings/real_mpfi.c:3124) OverflowError: value too large to convert to int ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/doc/en/bordeaux_2008/elliptic_curves.rst", line 177: sage: L = E.padic_lseries(5) Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_4[3]>", line 1, in <module> L = E.padic_lseries(Integer(5))###line 177: sage: L = E.padic_lseries(5) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/padics.py", line 159, in padic_lseries normalize = normalize, use_eclib=use_eclib) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/padic_lseries.py", line 199, in __init__ self._modular_symbol = E.modular_symbol(sign=+1, use_eclib = use_eclib, normalize=normalize) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 1243, in modular_symbol M = ell_modular_symbols.ModularSymbolSage(self, sign, normalize=normalize) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_modular_symbols.py", line 629, in __init__ self._find_scaling_L_ratio() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_modular_symbols.py", line 310, in _find_scaling_L_ratio l1 = self.__lalg__(D) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_modular_symbols.py", line 362, in __lalg__ lv = ED.lseries().L_ratio() # this is L(ED,1) divided by the Neron period omD of ED File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/lseries_ell.py", line 686, in L_ratio omega = self.__E.period_lattice().basis()[0] File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 2861, in period_lattice self._period_lattice = PeriodLattice_ell(self) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/period_lattice.py", line 231, in __init__ self._ei = self.f2.roots(AA,multiplicities=False) File "polynomial_element.pyx", line 4850, in sage.rings.polynomial.polynomial_element.Polynomial.roots (sage/rings/polynomial/polynomial_element.c:31255) File "real_roots.pyx", line 4141, in sage.rings.polynomial.real_roots.real_roots (sage/rings/polynomial/real_roots.c:36556) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/rings/qqbar.py", line 761, in polynomial_root return AlgebraicReal(ANRoot(poly, interval, multiplicity)) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/rings/qqbar.py", line 4417, in __init__ self._interval = self.refine_interval(interval, 64) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/rings/qqbar.py", line 4528, in refine_interval return self._real_refine_interval(interval, prec) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/rings/qqbar.py", line 4621, in _real_refine_interval raise ValueError, "Refining interval that does not bound unique root!" ValueError: Refining interval that does not bound unique root! **********************************************************************
Two potentially separate issues in mpfi and qqbar.py
sage -t -long -force_lib devel/sage/sage/structure/sage_object.pyx ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/structure/sage_object.pyx", line 1103: sage: sage.structure.sage_object.unpickle_all() # (4s on sage.math, 2011) Expected: Successfully unpickled ... objects. Failed to unpickle 0 objects. Got: * unpickle failure: load('/home/bjones/.sage/temp/silius/20398/dir_2/pickle_jar/_class__sage_coding_linear_code_LinearCode__.sobj') * unpickle failure: load('/home/bjones/.sage/temp/silius/20398/dir_2/pickle_jar/_class__sage_crypto_mq_sr_SR_gf2__.sobj') * unpickle failure: load('/home/bjones/.sage/temp/silius/20398/dir_2/pickle_jar/_class__sage_homology_chain_complex_ChainComplex__.sobj') * unpickle failure: load('/home/bjones/.sage/temp/silius/20398/dir_2/pickle_jar/_type__sage_coding_binary_code_BinaryCode__.sobj') * unpickle failure: load('/home/bjones/.sage/temp/silius/20398/dir_2/pickle_jar/_type__sage_matrix_matrix_mod2_dense_Matrix_mod2_dense__.sobj') Failed: _class__sage_coding_linear_code_LinearCode__.sobj _class__sage_crypto_mq_sr_SR_gf2__.sobj _class__sage_homology_chain_complex_ChainComplex__.sobj _type__sage_coding_binary_code_BinaryCode__.sobj _type__sage_matrix_matrix_mod2_dense_Matrix_mod2_dense__.sobj Successfully unpickled 582 objects. Failed to unpickle 5 objects. ********************************************************************** 1 items had failures: 1 of 7 in __main__.example_25 ***Test Failed*** 1 failures.
picklejar failure should be checked against the same error on arm. Possibly a deeper python problem.
sage -t -long -force_lib devel/sage/sage/structure/parent.pyx ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/structure/parent.pyx", line 1783: sage: K.coerce_embedding() Expected: Generic morphism: From: Number Field in a with defining polynomial x^3 + x^2 + 1 To: Real Lazy Field Defn: a -> -1.465571231876768? Got: Generic morphism: From: Number Field in a with defining polynomial x^3 + x^2 + 1 To: Real Lazy Field Defn: a -> 0 ********************************************************************** 1 items had failures: 1 of 7 in __main__.example_39 ***Test Failed*** 1 failures.
That's more than large numerical noise, that has to be wrong.
sage -t -long -force_lib devel/sage/sage/matrix/matrix_double_dense.pyx ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/matrix/matrix_double_dense.pyx", line 1766: sage: Q Expected: [ -0.359210604054 0.569326179705 0.368048420509 0.641385845805] [ 0.179605302027 -0.144590775798 0.925041158846 -0.301884576418] [ 0.179605302027 -0.704880032016 0.0774617736597 0.681825307224] [ 0.898026510134 0.397624633445 -0.0532812182975 0.180566192161] Got: [ -0.359210604054 0.569326179705 0.146859067236 0.724753652911] [ 0.179605302027 -0.144590775798 0.973039543327 0.00543048428303] [ 0.179605302027 -0.704880032016 -0.141642164231 0.671433967908] [ 0.898026510134 0.397624633445 -0.107535848925 0.154528570726] ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/matrix/matrix_double_dense.pyx", line 1771: sage: R Expected: [ -5.56776436283 2.6940795304 -2.6940795304] [ 0 -3.56958477752 3.56958477752] [ 0 0 -9.93013661299e-16] [ 0 0 0] Got: [ -5.56776436283 2.6940795304 -2.6940795304] [ 0 -3.56958477752 3.56958477752] [ 0 0 9.81879219451e-16] [ 0 0 0] ********************************************************************** 1 items had failures: 2 of 40 in __main__.example_31 ***Test Failed*** 2 failures.
Some numerical noise but something else is badly wrong in the first one.
sage -t -long -force_lib devel/sage/sage/matrix/matrix2.pyx ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/matrix/matrix2.pyx", line 7722: sage: M.round(10) Expected: [-2.4494897428 0.0 0.0] [-3.6742346142 0.7071067812 0.0] [-4.8989794856 1.4142135624 0.0] Got: [-2.4494897428 0.0 0.0] [-3.6742346142 0.7071067812 0.0] [-4.8989794856 1.4142135624 -0.0] ********************************************************************** 1 items had failures:
That one is not that worrying, I just wish we could easily deal with 0.0 sign flipping.
sage -t -long -force_lib devel/sage/sage/numerical/optimize.py ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/numerical/optimize.py", line 469: sage: sol['x'] Expected: (0.999..., 1.000...) Got nothing ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/numerical/optimize.py", line 479: sage: sol['x'] Expected: (45.000000..., 6.2499999...3, 1.00000000...) Got nothing GLPK Simplex Optimizer, v4.44 6 rows, 3 columns, 8 non-zeros Preprocessing... 2 rows, 2 columns, 4 non-zeros Scaling... A: min|aij| = 2.400e+01 max|aij| = 5.000e+01 ratio = 2.083e+00 GM: min|aij| = 8.128e-01 max|aij| = 1.230e+00 ratio = 1.514e+00 EQ: min|aij| = 6.606e-01 max|aij| = 1.000e+00 ratio = 1.514e+00 Constructing initial basis... Size of triangular part = 2 * 0: obj = -5.100000000e+01 infeas = 0.000e+00 (0) * 1: obj = -5.225000000e+01 infeas = 0.000e+00 (0) OPTIMAL SOLUTION FOUND ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/numerical/optimize.py", line 564: sage: find_fit(data, model) Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_7[5]>", line 1, in <module> find_fit(data, model)###line 564: sage: find_fit(data, model) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/numerical/optimize.py", line 655, in find_fit estimated_params, d = leastsq(error_function, initial_guess, args = (x_data, y_data)) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/scipy/optimize/minpack.py", line 324, in leastsq raise errors[info][1](errors[info][0]) TypeError: Improper input parameters. ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/numerical/optimize.py", line 570: sage: fit = find_fit(data, f, parameters = [a, b, c], variables = [x], solution_dict = True) Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_7[7]>", line 1, in <module> fit = find_fit(data, f, parameters = [a, b, c], variables = [x], solution_dict = True)###line 570: sage: fit = find_fit(data, f, parameters = [a, b, c], variables = [x], solution_dict = True) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/numerical/optimize.py", line 655, in find_fit estimated_params, d = leastsq(error_function, initial_guess, args = (x_data, y_data)) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/scipy/optimize/minpack.py", line 324, in leastsq raise errors[info][1](errors[info][0]) TypeError: Improper input parameters. ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/numerical/optimize.py", line 571: sage: fit[a], fit[b], fit[c] Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_7[8]>", line 1, in <module> fit[a], fit[b], fit[c]###line 571: sage: fit[a], fit[b], fit[c] NameError: name 'fit' is not defined ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/numerical/optimize.py", line 577: sage: find_fit(dataprime, a * x * log(b * x), parameters = [a, b], variables = [x]) Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_7[10]>", line 1, in <module> find_fit(dataprime, a * x * log(b * x), parameters = [a, b], variables = [x])###line 577: sage: find_fit(dataprime, a * x * log(b * x), parameters = [a, b], variables = [x]) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/numerical/optimize.py", line 655, in find_fit estimated_params, d = leastsq(error_function, initial_guess, args = (x_data, y_data)) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/scipy/optimize/minpack.py", line 324, in leastsq raise errors[info][1](errors[info][0]) TypeError: Improper input parameters. ********************************************************************** 2 items had failures:
That looks bad we obviously have stuff wrong in scipy.
sage -t -long -force_lib devel/sage/sage/ext/fast_callable.pyx get_str.c:149: MPFR assertion failed: size_s1 >= m ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/ext/fast_callable.pyx", line 1445: sage: square(RIF(-1, 1)).str(style='brackets') Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_50[7]>", line 1, in <module> square(RIF(-Integer(1), Integer(1))).str(style='brackets')###line 1445: sage: square(RIF(-1, 1)).str(style='brackets') File "real_mpfi.pyx", line 1425, in sage.rings.real_mpfi.RealIntervalFieldElement.str (sage/rings/real_mpfi.c:8979) File "real_mpfr.pyx", line 1618, in sage.rings.real_mpfr.RealNumber.str (sage/rings/real_mpfr.c:11037) RuntimeError: Aborted ********************************************************************** 1 items had failures:
Something miscompiled in mpfr?
sage -t -long -force_lib devel/sage/sage/categories/pushout.py Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.RuntimeError'> ignored ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/categories/pushout.py", line 2421: sage: F2(QQ).coerce_embedding() Expected: Generic morphism: From: Number Field in a with defining polynomial x^3 - x^2 + 1 To: Real Lazy Field Defn: a -> -0.7548776662466928? Got: Generic morphism: From: Number Field in a with defining polynomial x^3 - x^2 + 1 To: Real Lazy Field Defn: a -> 0 **********************************************************************
And we have a repeat of errors from qqbar.py in that test too.
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/period_lattice.py
more qqbar.py failuresalong with mpfr/mpfi like in elliptic_curves.rst and some wrong results:
File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/schemes/elliptic_curves/period_lattice.py", line 854: sage: L.basis_matrix() Expected: [ 2.49021256085505 0.000000000000000] [0.000000000000000 1.97173770155165] Got: [ 1.26920930427955 0.000000000000000] [0.634604652139777 1.45881661693850] ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/schemes/elliptic_curves/period_lattice.py", line 857: sage: L.basis_matrix(normalised=True) Expected: [ 2.49021256085505 0.000000000000000] [0.000000000000000 -1.97173770155165] Got: [0.634604652139777 -1.45881661693850] [-1.26920930427955 0.000000000000000] **********************************************************************
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/descent_two_isogeny.pyx ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/schemes/elliptic_curves/descent_two_isogeny.pyx", line 1147: sage: E.sha().an() Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_18[28]>", line 1, in <module> E.sha().an()###line 1147: sage: E.sha().an() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/sha_tate.py", line 392, in an L1_over_omega = E.lseries().L_ratio() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/lseries_ell.py", line 686, in L_ratio omega = self.__E.period_lattice().basis()[0] File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 2861, in period_lattice self._period_lattice = PeriodLattice_ell(self) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/period_lattice.py", line 231, in __init__ self._ei = self.f2.roots(AA,multiplicities=False) File "polynomial_element.pyx", line 4850, in sage.rings.polynomial.polynomial_element.Polynomial.roots (sage/rings/polynomial/polynomial_element.c:31255) File "real_roots.pyx", line 4115, in sage.rings.polynomial.real_roots.real_roots (sage/rings/polynomial/real_roots.c:36162) File "real_mpfi.pyx", line 277, in sage.rings.real_mpfi.RealIntervalField (sage/rings/real_mpfi.c:2982) File "real_mpfi.pyx", line 441, in sage.rings.real_mpfi.RealIntervalField_class.__init__ (sage/rings/real_mpfi.c:3124) OverflowError: value too large to convert to int ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/schemes/elliptic_curves/descent_two_isogeny.pyx", line 1147: sage: E.sha().an() Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_18[28]>", line 1, in <module> E.sha().an()###line 1147: sage: E.sha().an() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/sha_tate.py", line 392, in an L1_over_omega = E.lseries().L_ratio() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/lseries_ell.py", line 686, in L_ratio omega = self.__E.period_lattice().basis()[0] File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 2861, in period_lattice self._period_lattice = PeriodLattice_ell(self) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/period_lattice.py", line 231, in __init__ self._ei = self.f2.roots(AA,multiplicities=False) File "polynomial_element.pyx", line 4850, in sage.rings.polynomial.polynomial_element.Polynomial.roots (sage/rings/polynomial/polynomial_element.c:31255) File "real_roots.pyx", line 4115, in sage.rings.polynomial.real_roots.real_roots (sage/rings/polynomial/real_roots.c:36162) File "real_mpfi.pyx", line 277, in sage.rings.real_mpfi.RealIntervalField (sage/rings/real_mpfi.c:2982) File "real_mpfi.pyx", line 441, in sage.rings.real_mpfi.RealIntervalField_class.__init__ (sage/rings/real_mpfi.c:3124) OverflowError: value too large to convert to int **********************************************************************
again and again in that one
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/padics.py
There are other errors in that last one but I think they are consequences of previous failures.
Same error in
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/ell_modular_symbols.py
again some other errors that are probably consequences of this particular failure. We get some qqbar.py errors too in that one.
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/lseries_ell.py *** Warning: new stack size = 1001728 (0.955 Mbytes). *** Warning: new stack size = 1002624 (0.956 Mbytes). *** Warning: new stack size = 1010736 (0.964 Mbytes). *** Warning: new stack size = 1114144 (1.063 Mbytes). ********************************************************************** sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/ell_point.py sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/modular_parametrization.py sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/BSD.py sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/padic_lseries.py sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/heegner.py sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/sha_tate.py sage -t -long -force_lib devel/sage/sage/rings/real_lazy.pyx sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py sage -t -long -force_lib devel/sage/sage/rings/qqbar.py <- what a surprise (got MPFR assertion errors too) sage -t -long -force_lib devel/sage/sage/rings/number_field/totallyreal_rel.py sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_morphisms.pyx sage -t -long -force_lib devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py sage -t -long -force_lib devel/sage/sage/rings/polynomial/real_roots.pyx get_str.c:149: MPFR assertion failed: size_s1 >= m get_str.c:149: MPFR assertion failed: size_s1 >= m
some more of the same with qqbar.py and mpfi/mpfr.
sage -t -long -force_lib devel/sage/sage/rings/real_interval_absolute.pyx get_str.c:149: MPFR assertion failed: size_s1 >= m get_str.c:149: MPFR assertion failed: size_s1 >= m ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/rings/real_interval_absolute.pyx", line 237: sage: R(1) Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_12[4]>", line 1, in <module> R(Integer(1))###line 237: sage: R(1) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/misc/displayhook.py", line 174, in displayhook print_obj(sys.stdout, obj) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/misc/displayhook.py", line 142, in print_obj print >>out_stream, `obj` File "sage_object.pyx", line 154, in sage.structure.sage_object.SageObject.__repr__ (sage/structure/sage_object.c:1463) File "real_interval_absolute.pyx", line 434, in sage.rings.real_interval_absolute.RealIntervalAbsoluteElement._repr_ (sage/rings/real_interval_absolute.c:4989) return repr(self._real_mpfi_(RealIntervalField(prec))) File "real_mpfi.pyx", line 1109, in sage.rings.real_mpfi.RealIntervalFieldElement.__repr__ (sage/rings/real_mpfi.c:7925) return self.str(10) File "real_mpfi.pyx", line 1434, in sage.rings.real_mpfi.RealIntervalFieldElement.str (sage/rings/real_mpfi.c:9075) return self._str_question_style(base, error_digits, e, prefer_sci) File "real_mpfi.pyx", line 1650, in sage.rings.real_mpfi.RealIntervalFieldElement._str_question_style (sage/rings/real_mpfi.c:9520) sig_on() RuntimeError: Aborted get_str.c:149: MPFR assertion failed: size_s1 >= m
mpfr troubles with one backtrace
File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/rings/real_interval_absolute.pyx", line 915: sage: R(10)^-10 Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_39[7]>", line 1, in <module> R(Integer(10))**-Integer(10)###line 915: sage: R(10)^-10 File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/misc/displayhook.py", line 174, in displayhook print_obj(sys.stdout, obj) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/misc/displayhook.py", line 142, in print_obj print >>out_stream, `obj` File "sage_object.pyx", line 154, in sage.structure.sage_object.SageObject.__repr__ (sage/structure/sage_object.c:1463) File "real_interval_absolute.pyx", line 434, in sage.rings.real_interval_absolute.RealIntervalAbsoluteElement._repr_ (sage/rings/real_interval_absolute.c:4989) return repr(self._real_mpfi_(RealIntervalField(prec))) File "real_mpfi.pyx", line 1109, in sage.rings.real_mpfi.RealIntervalFieldElement.__repr__ (sage/rings/real_mpfi.c:7925) return self.str(10) File "real_mpfi.pyx", line 1434, in sage.rings.real_mpfi.RealIntervalFieldElement.str (sage/rings/real_mpfi.c:9075) return self._str_question_style(base, error_digits, e, prefer_sci) File "real_mpfi.pyx", line 1650, in sage.rings.real_mpfi.RealIntervalFieldElement._str_question_style (sage/rings/real_mpfi.c:9520) sig_on() RuntimeError: Aborted /tmp/bjones/sage-4.7.2.alpha2/local/lib/libcsage.so(print_backtrace-0x1cf7c)[0x40000a4e49c] /tmp/bjones/sage-4.7.2.alpha2/local/lib/libcsage.so(sigdie-0x1cf24)[0x40000a4e50c] /tmp/bjones/sage-4.7.2.alpha2/local/lib/libcsage.so(sage_signal_handler-0x1d600)[0x40000a4dd88] [0x40000040418] [0xfffcd8e00f0] /tmp/bjones/sage-4.7.2.alpha2/local/lib/libpython2.6.so.1.0(PyString_FromString-0x1346dc)[0x40000132594] /tmp/bjones/sage-4.7.2.alpha2/local/lib/libpython2.6.so.1.0(PyErr_SetString-0xbeac8)[0x400001aced0] /tmp/bjones/sage-4.7.2.alpha2/local/lib/libcsage.so(sage_signal_handler-0x1d6c0)[0x40000a4dcc8] [0x40000040418] /tmp/bjones/sage-4.7.2.alpha2/local/lib/libgmp.so.3(__gmpz_get_str-0x62970)[0x400013b3cf0] /tmp/bjones/sage-4.7.2.alpha2/local/lib/libgmp.so.3(__gmpq_get_str-0x55e8c)[0x400013c111c] /tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/rings/rational.so(+0x2156c)[0x40003b8156c] /tmp/bjones/sage-4.7.2.alpha2/local/lib/libpython2.6.so.1.0(PyCFunction_Call-0x1459b8)[0x4000011fc80] /tmp/bjones/sage-4.7.2.alpha2/local/lib/libpython2.6.so.1.0(PyObject_Call-0x18cd08)[0x400000d3590] /tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/rings/rational.so(+0x133cc)[0x40003b733cc]
Also
sage -t -long -force_lib devel/sage/sage/rings/complex_interval.pyx get_str.c:149: MPFR assertion failed: size_s1 >= m get_str.c:149: MPFR assertion failed: size_s1 >= m sage -t -long -force_lib devel/sage/sage/rings/real_mpfi.pyx get_str.c:149: MPFR assertion failed: size_s1 >= m get_str.c:149: MPFR assertion failed: size_s1 >= m (and a bunch of other errors) sage -t -long -force_lib devel/sage/sage/misc/functional.py #0: simplify_sum(expr='sum(q^k,k,0,inf)) #1: simplify_sum(expr=a*'sum(q^k,k,0,inf)) get_str.c:149: MPFR assertion failed: size_s1 >= m sage -t -long -force_lib devel/sage/sage/rings/polynomial/real_roots.pyx get_str.c:149: MPFR assertion failed: size_s1 >= m get_str.c:149: MPFR assertion failed: size_s1 >= m
sage -t -long -force_lib devel/sage/sage/lfunctions/sympow.py ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/lfunctions/sympow.py", line 213: sage: sympow.modular_degree(EllipticCurve('11a')) Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_6[2]>", line 1, in <module> sympow.modular_degree(EllipticCurve('11a'))###line 213: sage: sympow.modular_degree(EllipticCurve('11a')) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/lfunctions/sympow.py", line 229, in modular_degree raise RuntimeError, "failed to compute modular degree" RuntimeError: failed to compute modular degree
sympow...
sage -t -long -force_lib devel/sage/sage/interfaces/qepcad.py ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/interfaces/qepcad.py", line 2045: sage: x = _eval_qepcad_algebraic('the unique root of 8 x^2 - 8 x - 29 between -47/32 and -1503/1024'); x Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_52[3]>", line 1, in <module> x = _eval_qepcad_algebraic('the unique root of 8 x^2 - 8 x - 29 between -47/32 and -1503/1024'); x###line 2045: sage: x = _eval_qepcad_algebraic('the unique root of 8 x^2 - 8 x - 29 between -47/32 and -1503/1024'); x File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/interfaces/qepcad.py", line 2069, in _eval_qepcad_algebraic raise ValueError, "%s or %s not an exact floating-point number"%(lbound, ubound) ValueError: -47/32 or -1503/1024 not an exact floating-point number ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/interfaces/qepcad.py", line 2047: sage: 8*x^2 - 8*x - 29 == 0 Expected: True Got: 8*x^2 - 8*x - 29 == 0 **********************************************************************
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_rel.py ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/rings/number_field/number_field_rel.py", line 1876: sage: L.places() Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_54[3]>", line 1, in <module> L.places()###line 1876: sage: L.places() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/rings/number_field/number_field_rel.py", line 1899, in places pl = L.places(all_complex, prec) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/rings/number_field/number_field.py", line 6226, in places real_intervals = [ x[0] for x in self.defining_polynomial().roots(R) ] File "polynomial_element.pyx", line 4853, in sage.rings.polynomial.polynomial_element.Polynomial.roots (sage/rings/polynomial/polynomial_element.c:31307) File "real_roots.pyx", line 4115, in sage.rings.polynomial.real_roots.real_roots (sage/rings/polynomial/real_roots.c:36162) File "real_mpfi.pyx", line 277, in sage.rings.real_mpfi.RealIntervalField (sage/rings/real_mpfi.c:2982) File "real_mpfi.pyx", line 441, in sage.rings.real_mpfi.RealIntervalField_class.__init__ (sage/rings/real_mpfi.c:3124) OverflowError: value too large to convert to int ********************************************************************** 1 items had failures:
sage -t -long -force_lib devel/sage/sage/plot/plot3d/list_plot3d.py ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/plot/plot3d/list_plot3d.py", line 102: sage: list_plot3d(m, texture='yellow', interpolation_type='spline',frame_aspect_ratio=[1,1,1/3]) Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_1[9]>", line 1, in <module> list_plot3d(m, texture='yellow', interpolation_type='spline',frame_aspect_ratio=[Integer(1),Integer(1),Integer(1)/Integer(3)])###line 102: sage: list_plot3d(m, texture='yellow', interpolation_type='spline',frame_aspect_ratio=[1,1,1/3]) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/plot/plot3d/list_plot3d.py", line 172, in list_plot3d return list_plot3d_tuples(l,interpolation_type,texture,**kwds) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/plot/plot3d/list_plot3d.py", line 316, in list_plot3d_tuples s=interpolate.bisplrep(x,y,z,[int(1)]*len(x),xmin,xmax,ymin,ymax,kx=kx,ky=ky,s=s) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/scipy/interpolate/fitpack.py", line 873, in bisplrep tx,ty,nxest,nyest,wrk,lwrk1,lwrk2) ValueError: negative dimensions are not allowed ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/plot/plot3d/list_plot3d.py", line 109: sage: list_plot3d(m, texture='yellow', interpolation_type='spline', degree=5, frame_aspect_ratio=[1,1,1/3]) Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_1[10]>", line 1, in <module> list_plot3d(m, texture='yellow', interpolation_type='spline', degree=Integer(5), frame_aspect_ratio=[Integer(1),Integer(1),Integer(1)/Integer(3)])###line 109: sage: list_plot3d(m, texture='yellow', interpolation_type='spline', degree=5, frame_aspect_ratio=[1,1,1/3]) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/plot/plot3d/list_plot3d.py", line 172, in list_plot3d return list_plot3d_tuples(l,interpolation_type,texture,**kwds) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/plot/plot3d/list_plot3d.py", line 316, in list_plot3d_tuples s=interpolate.bisplrep(x,y,z,[int(1)]*len(x),xmin,xmax,ymin,ymax,kx=kx,ky=ky,s=s) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/scipy/interpolate/fitpack.py", line 873, in bisplrep tx,ty,nxest,nyest,wrk,lwrk1,lwrk2) ValueError: negative dimensions are not allowed ********************************************************************** 1 items had failures: 2 of 26 in __main__.example_1
sage -t -long -force_lib devel/sage/sage/modular/abvar/abvar.py ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/modular/abvar/abvar.py", line 3305: sage: E.modular_degree() Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_84[8]>", line 1, in <module> E.modular_degree()###line 3305: sage: E.modular_degree() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 3201, in modular_degree m = sympow.modular_degree(self) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/lfunctions/sympow.py", line 229, in modular_degree raise RuntimeError, "failed to compute modular degree" RuntimeError: failed to compute modular degree ********************************************************************** 1 items had failures: sage -t -long -force_lib devel/sage/sage/modular/hecke/submodule.py ********************************************************************** File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/modular/hecke/submodule.py", line 511: sage: EllipticCurve('128a').congruence_number() Exception raised: Traceback (most recent call last): File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_17[19]>", line 1, in <module> EllipticCurve('128a').congruence_number()###line 511: sage: EllipticCurve('128a').congruence_number() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 3294, in congruence_number m = self.modular_degree() File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 3201, in modular_degree m = sympow.modular_degree(self) File "/tmp/bjones/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/lfunctions/sympow.py", line 229, in modular_degree raise RuntimeError, "failed to compute modular degree" RuntimeError: failed to compute modular degree ********************************************************************** 1 items had failures: 1 of 21 in __main__.example_17
come from sympow
So big trouble coming from mpfr or possibly mpir underneath. Once we isolate that most of these will disapear.
comment:15 follow-up: 17 Changed 11 years ago by
comment:16 Changed 11 years ago by
I was hoping the mpir upgrade would deal with some of these. I'd like to try a vanilla compiler from SLES (gfortran is on a separate SDK DVD I discovered).
comment:17 Changed 11 years ago by
Replying to jhpalmieri:
With the new mpir spkg from #11964, Sage builds for me on silius, using gcc 4.6.2. I get a lot of test failures, though: I think that many of these are as reported before. See the log for full details.
The following tests failed: sage -t -long -force_lib devel/sagenb-main/sagenb/interfaces/status.py # File not found sage -t -long -force_lib devel/sage/doc/en/numerical_sage/cvxopt.rst # 1 doctests failed sage -t -long -force_lib devel/sage/doc/en/bordeaux_2008/elliptic_curves.rst # 10 doctests failed sage -t -long -force_lib devel/sage/sage/modular/hecke/submodule.py # 1 doctests failed sage -t -long -force_lib devel/sage/sage/modular/abvar/abvar.py # 1 doctests failed sage -t -long -force_lib devel/sage/sage/numerical/optimize.py # 6 doctests failed sage -t -long -force_lib devel/sage/sage/misc/functional.py # 1 doctests failed sage -t -long -force_lib devel/sage/sage/libs/libecm.pyx # Killed/crashed sage -t -long -force_lib devel/sage/sage/categories/pushout.py # 8 doctests failed sage -t -long -force_lib devel/sage/sage/rings/qqbar.py # 119 doctests failed sage -t -long -force_lib devel/sage/sage/rings/real_interval_absolute.pyx # 53 doctests failed sage -t -long -force_lib devel/sage/sage/rings/complex_interval.pyx # 22 doctests failed sage -t -long -force_lib devel/sage/sage/rings/real_lazy.pyx # 3 doctests failed sage -t -long -force_lib devel/sage/sage/rings/number_field/totallyreal_rel.py # 8 doctests failed sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_morphisms.pyx # 2 doctests failed sage -t -long -force_lib devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_rel.py # 1 doctests failed sage -t -long -force_lib devel/sage/sage/misc/randstate.pyx # Time out sage -t -long -force_lib devel/sage/sage/rings/polynomial/real_roots.pyx # 23 doctests failed sage -t -long -force_lib devel/sage/sage/structure/parent.pyx # 1 doctests failed sage -t -long -force_lib devel/sage/sage/rings/real_mpfi.pyx # Time out sage -t -long -force_lib devel/sage/sage/structure/sage_object.pyx # 1 doctests failed sage -t -long -force_lib devel/sage/sage/lfunctions/sympow.py # 13 doctests failed sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_element.pyx # Time out sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field.py # Time out sage -t -long -force_lib devel/sage/sage/rings/polynomial/polynomial_element.pyx # Time out sage -t -long -force_lib devel/sage/sage/plot/plot3d/list_plot3d.py # 2 doctests failed sage -t -long -force_lib devel/sage/sage/interfaces/qepcad.py # 2 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/padics.py # 10 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/padic_lseries.py # 44 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/lseries_ell.py # 3 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/ell_point.py # 9 doctests failed sage -t -long -force_lib devel/sage/sage/tests/startup.py # Time out sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/ell_modular_symbols.py # 16 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/modular_parametrization.py # 4 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/BSD.py # 6 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/descent_two_isogeny.pyx # 2 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/heegner.py # 72 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/period_lattice.py # 70 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py # 48 doctests failed sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/sha_tate.py # 40 doctests failed sage -t -long -force_lib devel/sage/sage/ext/fast_callable.pyx # 1 doctests failed sage -t -long -force_lib devel/sage/sage/interfaces/psage.py # Time out sage -t -long -force_lib devel/sage/sage/interfaces/expect.py # Time out sage -t -long -force_lib devel/sage/sage/interfaces/sage0.py # Time out ----------------------------------------------------------------------
FWIW, I previously managed to reduce the doctest errors to 7 files IIRC; from sage-release (Sage 4.7.2.alpha3 thread):
leif wrote: > > I've also tested on Linux PPC64 (POWER7), but there a lot goes wrong > > (mainly due to a partially broken ECL and Maxima I think), including > > some noise I didn't see on any of the other platforms, e.g. ones that > > don't match "1.00..." because they are slightly *less* than one. P.S.: The following tests even timeout when run individually (with the default timeout of half an hour on a quite fast box) in my current build: sage -t -long -force_lib sage/rings/real_mpfi.pyx # Time out sage -t -long -force_lib sage/rings/polynomial/polynomial_element.pyx # Time out sage -t -long -force_lib sage/rings/number_field/number_field_element.pyx # Time out sage -t -long -force_lib sage/sage/rings/number_field/number_field.py # Time out Interestingly also sandpile takes a long time, although this is SUSE Linux Enterprise Server 11 SP1 (ppc64), Kernel version 2.6.32.43-0.4-ppc64 and not Ubuntu. The other failing doctests are in: sage/misc/functional.py # 1 doctests failed (failing MPFR assertion) sage/interfaces/qepcad.py # 2 doctests failed (two funny errors) sage/plot/plot3d/list_plot3d.py # 2 doctests failed (two times "ValueError: negative dimensions are not allowed" in list_plot3d()) Note that there are further doctest errors in the files which timeout, i.e., before tests start to hang. -leif
I unfortunately cannot tell (at least at the moment) how I exactly built that version since I had trouble with various things like GCC 4.4.6 not recognizing -mvsx
(which ATLAS uses without first trying whether the command line option is supported) and the PolyBoRi spkg which didn't propagate LIBRARY_PATH
etc.
comment:18 Changed 11 years ago by
Description: | modified (diff) |
---|
comment:19 Changed 11 years ago by
I have built 5.0.prealpha on one of the power7 box I have access too (not silius). I get the following after running the tests (not in parallel)
The following tests failed: sage -t -long -force_lib "devel/sage/sage/numerical/optimize.py" sage -t -long -force_lib "devel/sage/sage/misc/functional.py" sage -t -long -force_lib "devel/sage/sage/libs/libecm.pyx" # Killed/crashed sage -t -long -force_lib "devel/sage/sage/categories/pushout.py" sage -t -long -force_lib "devel/sage/sage/rings/real_mpfi.pyx" # Time out sage -t -long -force_lib "devel/sage/sage/rings/number_field/totallyreal_rel.py" sage -t -long -force_lib "devel/sage/sage/rings/number_field/number_field_element.pyx" # Time out sage -t -long -force_lib "devel/sage/sage/rings/number_field/number_field_morphisms.pyx" sage -t -long -force_lib "devel/sage/sage/rings/number_field/number_field.py" # Killed/crashed sage -t -long -force_lib "devel/sage/sage/rings/number_field/number_field_rel.py" sage -t -long -force_lib "devel/sage/sage/rings/qqbar.py" sage -t -long -force_lib "devel/sage/sage/rings/real_interval_absolute.pyx" sage -t -long -force_lib "devel/sage/sage/rings/complex_interval.pyx" sage -t -long -force_lib "devel/sage/sage/rings/real_lazy.pyx" sage -t -long -force_lib "devel/sage/sage/rings/polynomial/polynomial_element.pyx" # Time out sage -t -long -force_lib "devel/sage/sage/rings/polynomial/real_roots.pyx" sage -t -long -force_lib "devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py" sage -t -long -force_lib "devel/sage/sage/structure/parent.pyx" sage -t -long -force_lib "devel/sage/sage/structure/sage_object.pyx" sage -t -long -force_lib "devel/sage/sage/plot/plot3d/list_plot3d.py" sage -t -long -force_lib "devel/sage/sage/interfaces/qepcad.py" sage -t -long -force_lib "devel/sage/sage/graphs/graph_decompositions/vertex_separation.pyx" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/padics.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/padic_lseries.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/ell_point.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/lseries_ell.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/ell_modular_symbols.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/modular_parametrization.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/BSD.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/sha_tate.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/heegner.py" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/descent_two_isogeny.pyx" sage -t -long -force_lib "devel/sage/sage/schemes/elliptic_curves/period_lattice.py" sage -t -long -force_lib "devel/sage/sage/schemes/plane_conics/con_number_field.py" sage -t -long -force_lib "devel/sage/sage/ext/fast_callable.pyx" Total time for all tests: 21029.5 seconds
I cannot really post many details right now but the errors are similar to before. Problems with mpfr and scipy are the main culprits. Some details on the box used:
frb15@p2n14-c /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0 :uname -a Linux p2n14-c 2.6.32.12-0.7-ppc64 #1 SMP 2010-05-20 11:14:20 +0200 ppc64 ppc64 ppc64 GNU/Linux
and the end of /proc/cpuinfo:
processor : 61 cpu : POWER7 (architected), altivec supported clock : 3300.000000MHz revision : 2.1 (pvr 003f 0201) timebase : 512000000 platform : pSeries model : IBM,8233-E8B machine : CHRP IBM,8233-E8B
comment:20 Changed 11 years ago by
I can supply gdb output for the test that got killed, "devel/sage/sage/rings/number_field/number_field.py":
init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_prec_t)(~(mpfr_prec_t)0)>>1)) Program received signal SIGABRT, Aborted. 0x00000400004c80e0 in .raise () from /lib64/power7/libc.so.6 (gdb) bt #0 0x00000400004c80e0 in .raise () from /lib64/power7/libc.so.6 #1 0x00000400004c9da0 in .abort () from /lib64/power7/libc.so.6 #2 0x0000040004202580 in .mpfr_assert_fail () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.1 #3 0x00000400041f9278 in .mpfr_init2 () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.1 #4 0x00000400041e92c0 in .set_z () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.1 #5 0x00000400041e9424 in .mpfr_set_q () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.1 #6 0x00000400044ba900 in mpfi_interv_q (a=0x1703db98, b=0x17034250, c=0x170342b0) at mpfi.c:3648 #7 0x000004000445b3a0 in __pyx_pf_4sage_5rings_9real_mpfi_24RealIntervalFieldElement___init__ (__pyx_v_self=0x1703db78, __pyx_args=<value optimized out>, __pyx_kwds=<value optimized out>) at sage/rings/real_mpfi.c:7366 #8 0x000004000017736c in type_call (type=<value optimized out>, args=0x17025500, kwds=0x0) at Objects/typeobject.c:735 #9 0x00000400000ecb3c in PyObject_Call (func=0x4000449c208, arg=0x17025500, kw=0x0) at Objects/abstract.c:2529 #10 0x000004000445e514 in __pyx_pf_4sage_5rings_9real_mpfi_23RealIntervalField_class_9__call__ (__pyx_v_self=0x10ee1c50, __pyx_args=<value optimized out>, __pyx_kwds=<value optimized out>) at sage/rings/real_mpfi.c:4421
I may try to upgrade mpfi/mpfr to see if it improve things.
comment:21 Changed 11 years ago by
I have updated mpfi and mpfr using #12171 and #11666 and now I am getting a backtrace going back to mpir:
Program received signal SIGSEGV, Segmentation fault. 0x000004000155c604 in .__gmpn_lshift () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libgmp.so.8 (gdb) bt #0 0x000004000155c604 in .__gmpn_lshift () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libgmp.so.8 #1 0x00000400041efbd0 in .set_z () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.4 #2 0x00000400041efd3c in .mpfr_set_q () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.4 #3 0x00000400044d0580 in mpfi_interv_q (a=0x17033b98, b=0x170342b0, c=0x17034310) at interv_q.c:34 #4 0x000004000446b3a0 in __pyx_pf_4sage_5rings_9real_mpfi_24RealIntervalFieldElement___init__ (__pyx_v_self=0x17033b78, __pyx_args=<value optimized out>, __pyx_kwds=<value optimized out>) at sage/rings/real_mpfi.c:7366 #5 0x000004000017736c in type_call (type=<value optimized out>, args=0x17025500, kwds=0x0) at Objects/typeobject.c:735 #6 0x00000400000ecb3c in PyObject_Call (func=0x400044ac208, arg=0x17025500, kw=0x0) at Objects/abstract.c:2529 #7 0x000004000446e514 in __pyx_pf_4sage_5rings_9real_mpfi_23RealIntervalField_class_9__call__ (__pyx_v_self=0x10ee1c50, __pyx_args=<value optimized out>, __pyx_kwds=<value optimized out>) at sage/rings/real_mpfi.c:4421
comment:22 Changed 11 years ago by
Just one more detail on the crash running the test with -verbose to get the failing bit:
Trying: L = NumberField(x**Integer(3) - Integer(4)*x + Integer(1), embedding = RealNumber('1.86'), names=('b',)); (b,) = L._first_ngens(1)###line 5176:_sage_ >>> L.<b> = NumberField(x^3 - 4*x + 1, embedding = 1.86) Expecting nothing ok Trying: L(a)###line 5177:_sage_ >>> L(a) Expecting: Traceback (most recent call last): ... ValueError: Cannot convert a to Number Field in b with defining polynomial x^3 - 4*x + 1 (using the specified embeddings) /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libcsage.so(print_backtrace-0x1cf74)[0x40000a5e1ec] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libcsage.so(sigdie-0x1cf1c)[0x40000a5e25c] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libcsage.so(sage_signal_handler-0x1d370)[0x40000a5dd60] [0x40000040418] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.4(+0x2fbb0)[0x400040ffbb0] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.4(mpfr_set_q-0x4f1b4)[0x400040ffd3c] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfi.so.0(mpfi_interv_q-0x1b260)[0x400043e0580] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/python/site-packages/sage/rings/real_mpfi.so(+0x2b3a0)[0x4000437b3a0] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libpython2.7.so.1.0(+0x11736c)[0x4000017736c] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libpython2.7.so.1.0(PyObject_Call-0x1bff54)[0x400000ecb3c] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/python/site-packages/sage/rings/real_mpfi.so(+0x2e514)[0x4000437e514] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libpython2.7.so.1.0(PyObject_Call-0x1bff54)[0x400000ecb3c] The doctested process was killed by signal 11 [5.9 s]
So we are expecting to catch some failure here in the first place and it doesn't go according to plan.
Also I forgot to mention I used the compiler fron SLES rather than compiling a newer version:
gcc -v Using built-in specs. Target: powerpc64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=power4 --enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux Thread model: posix gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) gfortran -v Using built-in specs. Target: powerpc64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=power4 --enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux Thread model: posix gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)
comment:23 Changed 11 years ago by
I am doing a complete test run with the new mpfi/mpfr combo but so far the results don't look any different. I looked a little bit more into the test that timed out (devel/sage/sage/rings/real_mpfi.pyx) with verbose and it stops dead there:
Trying: RIF(Integer(5)).gamma()###line 4133:_sage_ >>> RIF(5).gamma() Expecting: 24 ok Trying: a = RIF(Integer(3),Integer(4)).gamma(); a###line 4135:_sage_ >>> a = RIF(3,4).gamma(); a Expecting: 1.?e1
I'll look at the other killed test (libecm.pyx) a bit later.
comment:24 Changed 11 years ago by
libecm.pyx doesn't seem to work at all
frb15@p2n14-c /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0 :./sage -t -long -force_lib "devel/sage/sage/libs/libecm.pyx" -verbose sage -t -long -force_lib -verbose "devel/sage/sage/libs/libecm.pyx" Trying: set_random_seed(0L) Expecting nothing ok Trying: change_warning_output(sys.stdout) Expecting nothing ok Trying: import sage.libs.libecm###line 14:_sage_ >>> import sage.libs.libecm Expecting nothing ok Trying: from sage.libs.libecm import ecmfactor###line 15:_sage_ >>> from sage.libs.libecm import ecmfactor Expecting nothing ok Trying: result = ecmfactor(Integer(999), RealNumber('0.00'))###line 16:_sage_ >>> result = ecmfactor(999, 0.00) Expecting nothing /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libcsage.so(print_backtrace-0x1cf74)[0x40000a5e1ec] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libcsage.so(sigdie-0x1cf1c)[0x40000a5e25c] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libcsage.so(sage_signal_handler-0x1d370)[0x40000a5dd60] [0x40000040418] [0xfffc9771790] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/python/site-packages/sage/libs/libecm.so(+0x27c84)[0x4000a207c84] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/python/site-packages/sage/libs/libecm.so(ecm-0x657dc)[0x4000a1f60e4] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/python/site-packages/sage/libs/libecm.so(ecm_factor-0x6746c)[0x4000a1f43ac] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/python/site-packages/sage/libs/libecm.so(+0x133d4)[0x4000a1f33d4] /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libpython2.7.so.1.0(PyCFunction_Call-0x15fed4)[0x40000152c1c]
and from gdb
Program received signal SIGSEGV, Segmentation fault. 0x7d0429d27d242810 in ?? () (gdb) bt #0 0x7d0429d27d242810 in ?? () #1 0x000004000a5d3f70 in mulredc (z=0x13afdb50, x=<value optimized out>, y=<value optimized out>, m=0x13b05df0, nn=1, invm=4727093576446091305) at mpmod.c:386 #2 0x000004000a5d7c84 in ecm_mulredc_basecase (R=0xfffffffb080, S1=0xfffffffb1a8, S2=0xfffffffb178, modulus=0xfffffffb130) at mpmod.c:611 #3 0x000004000a5c60e4 in ecm (f=0xfffffffb578, x=0xfffffffb3d8, sigma=0xfffffffb3e8, n=0xfffffffb568, go=0xfffffffb400, B1done=0xfffffffb410, B1=0, B2min_parm=0xfffffffb418, B2_parm=0xfffffffb428, B2scale=1, k=0, S=0, verbose=0, repr=<value optimized out>, nobase2step2=0, use_ntt=1, sigma_is_A=0, os=0x4000061d698, es=0x4000061d778, chkfilename=0x0, TreeFilename=0x0, maxmem=0, stage1time=0, rng=0xfffffffb480, stop_asap=0) at ecm.c:940 #4 0x000004000a5c43ac in ecm_factor (f=0xfffffffb578, n=0xfffffffb568, B1=0, p=0xfffffffb3d0) at factor.c:93 #5 0x000004000a5c33d4 in __pyx_pf_4sage_4libs_6libecm_ecmfactor (__pyx_self=<value optimized out>, __pyx_args=<value optimized out>, __pyx_kwds=<value optimized out>) at sage/libs/libecm.c:1894 #6 0x0000040000152c1c in PyCFunction_Call (func=0x13aae368, arg=0x13ac1878, kw=<value optimized out>) at Objects/methodobject.c:85
comment:26 Changed 11 years ago by
Strangely enough I now get the following backtrace for real_mpfi.pyx, I have installed texlive in the mean time which may have made a difference.
get_str.c:153: MPFR assertion failed: size_s1 >= m Program received signal SIGABRT, Aborted. 0x00000400004c80e0 in .raise () from /lib64/power7/libc.so.6 (gdb) bt #0 0x00000400004c80e0 in .raise () from /lib64/power7/libc.so.6 #1 0x00000400004c9da0 in .abort () from /lib64/power7/libc.so.6 #2 0x00000400042ec060 in .mpfr_assert_fail () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.4 #3 0x00000400042c12fc in .mpfr_get_str_aux () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.4 #4 0x00000400042c1d48 in .mpfr_get_str () from /hpc/scratch/frb15/sandbox/sage-5.0.prealpha0/local/lib/libmpfr.so.4 #5 0x0000040004547ff4 in __pyx_f_4sage_5rings_9real_mpfi_24RealIntervalFieldElement__str_question_style (__pyx_v_self=0x13f47408, __pyx_v_base=0, __pyx_v_error_digits=0, __pyx_v_e=0x40000646cb0, __pyx_v_prefer_sci=0, __pyx_skip_dispatch=<value optimized out>) at sage/rings/real_mpfi.c:9727 #6 0x00000400045524f8 in __pyx_pf_4sage_5rings_9real_mpfi_24RealIntervalFieldElement_12str (__pyx_v_self=0x13f47408, __pyx_args=<value optimized out>, __pyx_kwds=<value optimized out>) at sage/rings/real_mpfi.c:9275
I will move to 5.0.prealpha1 soon.
comment:27 Changed 11 years ago by
Cc: | Paul Zimmermann added |
---|---|
Keywords: | sd35.5 added |
did someone try to compile MPFR 3.1.0 outside from Sage, and run its test suite (make check)? Same for MPFI 1.5.0?
Paul Zimmermann
comment:28 Changed 11 years ago by
note: I just tried MPFR 3.1.0 on top of MPIR 2.1.3 on gcc110.fsffrance.org and "make check" worked.
Paul
comment:29 Changed 11 years ago by
Replying to zimmerma:
did someone try to compile MPFR 3.1.0 outside from Sage, and run its test suite (make check)?
I did build both release candidates on Silius (Skynet); all [run] tests passed (although I don't recall with which GCC version; I guess I used my own build of 4.4.6).
I now see at least rc2 passed all tests with 4.3.4 and 4.6.1, too.
Same for MPFI 1.5.0?
Nope.
comment:30 follow-up: 32 Changed 11 years ago by
Leif,
I did build both release candidates on Silius (Skynet); all [run] tests passed
please could you check again with the 3.1.0 release? Alternatively if I have access to this machine (Silius?) I can try to investigate. William, is it possible?
Paul
comment:31 Changed 11 years ago by
Description: | modified (diff) |
---|
comment:32 Changed 11 years ago by
Replying to zimmerma:
I did build both release candidates on Silius (Skynet); all [run] tests passed
please could you check again with the 3.1.0 release?
IIRC there was no difference to the rc2 (except for version strings and the like), but I can probably retry a build tomorrow.
Alternatively if I have access to this machine (Silius?) I can try to investigate.
If you have a skynet account, you can log into silius from eno; otherwise you can ask Mariah Lenox for an account.
comment:33 Changed 11 years ago by
Cc: | Mariah Lennox added |
---|
Leif,
I only have an account on sage.math, thus I don't think I have one on eno. Mariah, if you are out there, please can you create an account for me on skynet? My email is Paul dot Zimmermann at inria dot fr.
Paul
comment:34 Changed 11 years ago by
Just for the record:
leif@silius:~> gcc -v Using built-in specs. Target: powerpc64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=power4 --enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux Thread model: posix gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) leif@silius:~> (. /usr/local/skynet_bash_profile ; gcc -v) Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.2/ppc64-Linux-power7-suse/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.2/lto-wrapper Target: powerpc64-unknown-linux-gnu Configured with: /usr/local/gcc-4.6.2/src/gcc-4.6.2/configure --enable-languages=c,c++,fortran --with-gnu-as --with-gnu-as=/usr/local/binutils-2.21.1/ppc64-Linux-power7-suse-gcc-4.6.1/bin/as --with-gnu-ld --with-ld=/usr/local/binutils-2.21.1/ppc64-Linux-power7-suse-gcc-4.6.1/bin/ld --with-gmp=/usr/local/mpir-2.4.0/ppc64-Linux-power7-suse-gcc-4.3.4-suse --with-mpfr=/usr/local/mpfr-3.1.0/ppc64-Linux-power7-suse-mpir-2.4.0-gcc-4.6.0 --with-mpc=/usr/local/mpc-0.9/ppc64-Linux-power7-suse-mpir-2.4.0-mpfr-3.1.0-gcc-4.6.1 --prefix=/usr/local/gcc-4.6.2/ppc64-Linux-power7-suse Thread model: posix gcc version 4.6.2 (GCC)
I.e., Mariah did build GCC 4.6.2 with MPFR 3.1.0 as well.
(And I'm pretty sure it defaults to power7
; as you can see the "native" [SuSE] GCC 4.3.4 defaults to power4
.)
comment:35 Changed 11 years ago by
Oh, btw., all my stand-alone builds of MPFR (3.1.0[.rc{1,2}]) were with GMP 5.0.2, not MPIR.
==================== All 160 tests passed (1 test was not run) ==================== ... leif@silius:~/src/mpfr-3.1.0-build.silius-gmp-5.0.2-gcc-4.3.4> gcc -v ; egrep "__GMP_(CC|CFLAGS)" /home/leif/local/silius-gmp-5.0.2/include/gmp.h Using built-in specs. Target: powerpc64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=power4 --enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux Thread model: posix gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) #define __GMP_CC "gcc -std=gnu99" #define __GMP_CFLAGS "-O3 -g -fno-strict-aliasing -mcpu=power7 -mtune=power7" leif@silius:~/src/mpfr-3.1.0-build.silius-gmp-5.0.2-gcc-4.3.4>
(Just built again. I didn't set CC
or CFLAGS
etc., so MPFR took GMP's settings -- those above.)
comment:36 Changed 11 years ago by
Same with GCC 4.6.2:
==================== All 160 tests passed (1 test was not run) ==================== ... leif@silius:~/src/mpfr-3.1.0-build.silius-gmp-5.0.2-gcc-4.6.2> gcc -v ; egrep "__GMP_(CC|CFLAGS)" /home/leif/local/silius-gmp-5.0.2/include/gmp.h Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.2/ppc64-Linux-power7-suse/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.2/lto-wrapper Target: powerpc64-unknown-linux-gnu Configured with: /usr/local/gcc-4.6.2/src/gcc-4.6.2/configure --enable-languages=c,c++,fortran --with-gnu-as --with-gnu-as=/usr/local/binutils-2.21.1/ppc64-Linux-power7-suse-gcc-4.6.1/bin/as --with-gnu-ld --with-ld=/usr/local/binutils-2.21.1/ppc64-Linux-power7-suse-gcc-4.6.1/bin/ld --with-gmp=/usr/local/mpir-2.4.0/ppc64-Linux-power7-suse-gcc-4.3.4-suse --with-mpfr=/usr/local/mpfr-3.1.0/ppc64-Linux-power7-suse-mpir-2.4.0-gcc-4.6.0 --with-mpc=/usr/local/mpc-0.9/ppc64-Linux-power7-suse-mpir-2.4.0-mpfr-3.1.0-gcc-4.6.1 --prefix=/usr/local/gcc-4.6.2/ppc64-Linux-power7-suse Thread model: posix gcc version 4.6.2 (GCC) #define __GMP_CC "gcc -std=gnu99" #define __GMP_CFLAGS "-O3 -g -fno-strict-aliasing -mcpu=power7 -mtune=power7"
comment:37 Changed 11 years ago by
Same with MPIR (although 2.5.0, and slightly different CFLAGS
):
==================== All 160 tests passed (1 test was not run) ==================== ... leif@silius:~/src/mpfr-3.1.0-build.silius-mpir-2.5.0-gcc-4.6.2> gcc -v ; egrep "__(GMP|MPIR)_(CC|CFLAGS)" /home/leif/local/silius-mpir-2.5.0/include/gmp.h Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.2/ppc64-Linux-power7-suse/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.2/lto-wrapper Target: powerpc64-unknown-linux-gnu Configured with: /usr/local/gcc-4.6.2/src/gcc-4.6.2/configure --enable-languages=c,c++,fortran --with-gnu-as --with-gnu-as=/usr/local/binutils-2.21.1/ppc64-Linux-power7-suse-gcc-4.6.1/bin/as --with-gnu-ld --with-ld=/usr/local/binutils-2.21.1/ppc64-Linux-power7-suse-gcc-4.6.1/bin/ld --with-gmp=/usr/local/mpir-2.4.0/ppc64-Linux-power7-suse-gcc-4.3.4-suse --with-mpfr=/usr/local/mpfr-3.1.0/ppc64-Linux-power7-suse-mpir-2.4.0-gcc-4.6.0 --with-mpc=/usr/local/mpc-0.9/ppc64-Linux-power7-suse-mpir-2.4.0-mpfr-3.1.0-gcc-4.6.1 --prefix=/usr/local/gcc-4.6.2/ppc64-Linux-power7-suse Thread model: posix gcc version 4.6.2 (GCC) #define __GMP_CC __MPIR_CC #define __GMP_CFLAGS __MPIR_CFLAGS #define __MPIR_CC "gcc -std=gnu99" #define __MPIR_CFLAGS "-m64 -O3"
comment:38 follow-up: 39 Changed 11 years ago by
Same with MPIR (although 2.5.0, and slightly different CFLAGS):
but gcc -v
says --with-gmp=/usr/local/mpir-2.4.0 instead.
Please could you try with MPIR 2.1.3, which is as far as I know the version currently used by
Sage?
Paul
comment:39 follow-up: 40 Changed 11 years ago by
Replying to zimmerma:
Same with MPIR (although 2.5.0, and slightly different CFLAGS):
but
gcc -v
says --with-gmp=/usr/local/mpir-2.4.0 instead. Please could you try with MPIR 2.1.3, which is as far as I know the version currently used by Sage?
Well, that's the version GCC was built with, which doesn't matter here.
But I could rebuild and test MPFR 3.1.0 with (e.g.) MPIR 2.1.4 later.
comment:40 Changed 11 years ago by
Replying to leif:
Replying to zimmerma:
Same with MPIR (although 2.5.0, and slightly different CFLAGS):
but
gcc -v
says --with-gmp=/usr/local/mpir-2.4.0 instead. Please could you try with MPIR 2.1.3, which is as far as I know the version currently used by Sage?Well, that's the version GCC was built with, which doesn't matter here.
But I could rebuild and test MPFR 3.1.0 with (e.g.) MPIR 2.1.4 later.
Ok, I now also built MPIR 2.1.4 (changes w.r.t. 2.1.3 don't matter) and MPFR 3.1.0 with that version on silius; once without specifying any CFLAGS
(such that MPIR used -m64 -O3
, without any -march=
/-mcpu=
/-mtune=
), once with CFLAGS="-mcpu=power7 -mtune=power7 -m64 -g -O3
(but in both cases only with GCC 4.6.2).
All test suites passed, as expected.
comment:41 Changed 11 years ago by
Not sure how I ended with a crash in real_mpfi.pyx, there is a time out. But I don't see a crash anymore after a rebuild from scratch including mpfi-1.5.0. The time out may be caused by some other components.
comment:42 Changed 11 years ago by
I have now an account on silius, thus I will be able to try. Francois, which version of Sage did you try?
Paul
comment:43 Changed 11 years ago by
I am now trying to compile http://boxen.math.washington.edu/home/release/sage-4.8/sage-4.8.tar
Paul
comment:44 Changed 11 years ago by
compilation of sage-4.8 succeeded. Running sage -tp 48 *
failed with:
sage -t devel/sage-main/sage/categories/pushout.py # 8 doctests failed sage -t devel/sage-main/sage/ext/fast_callable.pyx # 1 doctests failed sage -t devel/sage-main/sage/graphs/graph_decompositions/vertex_separation.pyx # 3 doctests failed sage -t devel/sage-main/sage/interfaces/qepcad.py # 2 doctests failed sage -t devel/sage-main/sage/libs/libecm.pyx # Killed/crashed sage -t devel/sage-main/sage/lfunctions/sympow.py # 10 doctests failed sage -t devel/sage-main/sage/misc/functional.py # 1 doctests failed sage -t devel/sage-main/sage/numerical/optimize.py # 6 doctests failed sage -t devel/sage-main/sage/modular/hecke/submodule.py # 1 doctests failed sage -t devel/sage-main/sage/plot/plot3d/list_plot3d.py # 2 doctests failed sage -t devel/sage-main/sage/modular/abvar/abvar.py # 1 doctests failed sage -t devel/sage-main/sage/rings/real_interval_absolute.pyx # 53 doctests failed sage -t devel/sage-main/sage/rings/real_lazy.pyx # 3 doctests failed sage -t devel/sage-main/sage/rings/complex_interval.pyx # 22 doctests failed sage -t devel/sage-main/sage/rings/qqbar.py # 119 doctests failed sage -t devel/sage-main/sage/rings/number_field/totallyreal_rel.py # 8 doctests failed sage -t devel/sage-main/sage/rings/number_field/number_field_morphisms.pyx # 2 doctests failed sage -t devel/sage-main/sage/rings/number_field/number_field.py # Killed/crashed sage -t devel/sage-main/sage/schemes/elliptic_curves/modular_parametrization.py # 4 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/lseries_ell.py # 3 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/descent_two_isogeny.pyx # 2 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/padics.py # 10 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/period_lattice.py # 70 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/BSD.py # 4 doctests failed sage -t devel/sage-main/sage/structure/parent.pyx # 1 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/ell_modular_symbols.py # 13 doctests failed sage -t devel/sage-main/sage/structure/sage_object.pyx # 1 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/padic_lseries.py # 43 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/ell_point.py # 9 doctests failed sage -t devel/sage-main/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/sha_tate.py # 34 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/heegner.py # 66 doctests failed sage -t devel/sage-main/sage/schemes/elliptic_curves/ell_rational_field.py # 44 doctests failed sage -t devel/sage-main/sage/rings/real_mpfi.pyx # Time out sage -t devel/sage-main/sage/rings/number_field/number_field_element.pyx # Time out sage -t devel/sage-main/sage/rings/number_field/number_field_rel.py # Time out sage -t devel/sage-main/sage/rings/polynomial/polynomial_element.pyx # Time out sage -t devel/sage-main/sage/rings/polynomial/real_roots.pyx # Time out sage -t devel/sage-main/sage/sandpiles/sandpile.py # Time out sage -t devel/sage-main/sage/schemes/plane_conics/con_number_field.py # Time out
I will investigate further.
Paul
comment:45 Changed 11 years ago by
I can isolate one issue with MPFI:
sage: RIF(1,1).lower() 5.96124715852883e27 sage: RIF(1,1).upper() 4.05648192073034e31 sage: RIF(0,1).lower() ... RuntimeError: Aborted
Paul
comment:46 Changed 11 years ago by
if I modify the function mpfi_interv_z
of MPFI as follows:
int mpfi_interv_z(mpfi_ptr a,mpz_srcptr b,mpz_srcptr c) { int inexact_left, inexact_right, inexact=0; mpz_dump (b); mpz_dump (c); if ( mpz_cmp(b,c) <= 0 ) { inexact_left = mpfr_set_z(&(a->left), b, MPFI_RNDD); mpfr_dump (&(a->left)); inexact_right = mpfr_set_z(&(a->right), c, MPFI_RNDU); mpfr_dump (&(a->right)); } ...
then I get:
sage: RIF(1,2) 000000000000000001 000000000000000002 0.00000000000000000000000000000000000000000000000000000E65 0.00000000000000000000000000000000000000000000000000001E65 get_str.c:149: MPFR assertion failed: size_s1 >= m ...
thus clearly something is corrupted with GMP and MPFR, since we should get:
1 2 0.10000000000000000000000000000000000000000000000000000E1 0.10000000000000000000000000000000000000000000000000000E2
Note: I cannot reproduce the problem outside from Sage, thus it is probably due to the way GMP (i.e., MPIR) and/or MPFR are compiled within Sage.
Paul
comment:47 Changed 11 years ago by
sage-5.0-beta5 + #11666 + #12171
sage: RIF(1,1).lower() get_str.c:153: MPFR assertion failed: size_s1 >= m --------------------------------------------------------------------------- RuntimeError Traceback (most recent call last) /hpc/scratch/frb15/sandbox/sage-5.0.beta5/<ipython console> in <module>() /hpc/scratch/frb15/sandbox/sage-5.0.beta5/local/lib/python2.7/site-packages/IPython/Prompts.pyc in __call__(self, arg) 550 551 # and now call a possibly user-defined print mechanism --> 552 manipulated_val = self.display(arg) 553 554 # user display hooks can change the variable to be stored in /hpc/scratch/frb15/sandbox/sage-5.0.beta5/local/lib/python2.7/site-packages/IPython/Prompts.pyc in _display(self, arg) 576 return IPython.generics.result_display(arg) 577 except TryNext: --> 578 return self.shell.hooks.result_display(arg) 579 580 # Assign the default display method: /hpc/scratch/frb15/sandbox/sage-5.0.beta5/local/lib/python2.7/site-packages/IPython/hooks.pyc in __call__(self, *args, **kw) 139 #print "prio",prio,"cmd",cmd #dbg 140 try: --> 141 ret = cmd(*args, **kw) 142 return ret 143 except ipapi.TryNext, exc: /hpc/scratch/frb15/sandbox/sage-5.0.beta5/local/lib/python2.7/site-packages/sage/misc/displayhook.pyc in result_display(ip_self, obj) 148 # IPython's default result_display() uses the IPython.genutils.Term.cout stream. 149 # See also local/lib/python2.6/site-packages/IPython/hooks.py. --> 150 print_obj(IPython.genutils.Term.cout, obj) 151 152 def displayhook(obj): /hpc/scratch/frb15/sandbox/sage-5.0.beta5/local/lib/python2.7/site-packages/sage/misc/displayhook.pyc in print_obj(out_stream, obj) 140 if _check_tall_list_and_print(out_stream, obj): 141 return --> 142 print >>out_stream, `obj` 143 144 def result_display(ip_self, obj): /hpc/scratch/frb15/sandbox/sage-5.0.beta5/local/lib/python2.7/site-packages/sage/rings/real_mpfr.so in sage.rings.real_mpfr.RealNumber.__repr__ (sage/rings/real_mpfr.c:9438)() /hpc/scratch/frb15/sandbox/sage-5.0.beta5/local/lib/python2.7/site-packages/sage/rings/real_mpfr.so in sage.rings.real_mpfr.RealNumber.str (sage/rings/real_mpfr.c:11257)() RuntimeError: Aborted
Same thing with upper. But your remark about it working outside of sage makes me want to hack sage "provided atlas" style and see what happens.
comment:48 Changed 11 years ago by
Ok I did a build of 5.0.beta8-gcc along with the new mpir from #11616. I asked the gcc spkg to be built. I may do another build without it later. I didn't run all the test I just looked at one key test at the moment:sage -t -long -force_lib "devel/sage/sage/rings/number_field/number_field.py" because it is killed. I am still getting a backtrace similar to comment 21.
Program received signal SIGSEGV, Segmentation fault. .__gmpn_lshift () at tmp-lshift.s:105 105 tmp-lshift.s: No such file or directory. in tmp-lshift.s Current language: auto The current source language is "auto; currently asm". (gdb) bt #0 .__gmpn_lshift () at tmp-lshift.s:105 #1 0x000004000874c908 in set_z (f=0xfffffff74d0, z=0x16eef0d0, zs=<value optimized out>) at set_q.c:53 #2 0x000004000874ca4c in mpfr_set_q (f=0x1724ca00, q=0x16eef0d0, rnd=<value optimized out>) at set_q.c:101 #3 0x0000040008a00198 in mpfi_interv_q (a=0x1724ca00, b=0x16eef0d0, c=0x16eef130) at interv_q.c:34 #4 0x00000400089b7a14 in __pyx_pf_4sage_5rings_9real_mpfi_24RealIntervalFieldElement___init__ (__pyx_v_self=0x1724c9e0, __pyx_args=<value optimized out>, __pyx_kwds=<value optimized out>) at sage/rings/real_mpfi.c:7366 #5 0x000004000016aed0 in type_call (type=0x400089e8360, args=0x17232730, kwds=0x0) at Objects/typeobject.c:737 #6 0x00000400000f33f0 in PyObject_Call (func=0x400089e8360, arg=<value optimized out>, kw=<value optimized out>) at Objects/abstract.c:2529 #7 0x00000400089b2044 in __pyx_pf_4sage_5rings_9real_mpfi_23RealIntervalField_class_9__call__ (__pyx_v_self=0x10fb44e0, __pyx_args=<value optimized out>, __pyx_kwds=<value optimized out>) at sage/rings/real_mpfi.c:4421
and I am still getting the following:
sage: RIF(1,1).lower() get_str.c:153: MPFR assertion failed: size_s1 >= m --------------------------------------------------------------------------- RuntimeError Traceback (most recent call last) /hpc/scratch/frb15/sandbox/sage-5.0.beta8-gcc/<ipython console> in <module>() /hpc/scratch/frb15/sandbox/sage-5.0.beta8-gcc/local/lib/python2.7/site-packages/IPython/Prompts.pyc in __call__(self, arg) 550 551 # and now call a possibly user-defined print mechanism --> 552 manipulated_val = self.display(arg) 553 554 # user display hooks can change the variable to be stored in /hpc/scratch/frb15/sandbox/sage-5.0.beta8-gcc/local/lib/python2.7/site-packages/IPython/Prompts.pyc in _display(self, arg) 576 return IPython.generics.result_display(arg) 577 except TryNext: --> 578 return self.shell.hooks.result_display(arg) 579 580 # Assign the default display method: /hpc/scratch/frb15/sandbox/sage-5.0.beta8-gcc/local/lib/python2.7/site-packages/IPython/hooks.pyc in __call__(self, *args, **kw) 139 #print "prio",prio,"cmd",cmd #dbg 140 try: --> 141 ret = cmd(*args, **kw) 142 return ret 143 except ipapi.TryNext, exc: /hpc/scratch/frb15/sandbox/sage-5.0.beta8-gcc/local/lib/python2.7/site-packages/sage/misc/displayhook.pyc in result_display(ip_self, obj) 148 # IPython's default result_display() uses the IPython.genutils.Term.cout stream. 149 # See also local/lib/python2.6/site-packages/IPython/hooks.py. --> 150 print_obj(IPython.genutils.Term.cout, obj) 151 152 def displayhook(obj): /hpc/scratch/frb15/sandbox/sage-5.0.beta8-gcc/local/lib/python2.7/site-packages/sage/misc/displayhook.pyc in print_obj(out_stream, obj) 140 if _check_tall_list_and_print(out_stream, obj): 141 return --> 142 print >>out_stream, `obj` 143 144 def result_display(ip_self, obj): /hpc/scratch/frb15/sandbox/sage-5.0.beta8-gcc/local/lib/python2.7/site-packages/sage/rings/real_mpfr.so in sage.rings.real_mpfr.RealNumber.__repr__ (sage/rings/real_mpfr.c:9438)() /hpc/scratch/frb15/sandbox/sage-5.0.beta8-gcc/local/lib/python2.7/site-packages/sage/rings/real_mpfr.so in sage.rings.real_mpfr.RealNumber.str (sage/rings/real_mpfr.c:11257)() RuntimeError: Aborted
comment:49 Changed 11 years ago by
Francois, just to be sure, did you check MPFR is built with --disable-thread-safe
?
Can you try to build GMP/MPIR and MPFR with --enable-assert
?
If you tell me where your build is I can try again to isolate the problem.
Paul
comment:50 Changed 11 years ago by
FWIW, I've also built Sage 5.0.beta8 on silius (skynet), where GCC 4.6.3 meanwhile is the default compiler (although one still has to source /local/bin/skynet_bash_profile
, since otherwise a few packages, two IIRC, fail to build because of wrong libraries / not sufficiently set LD_LIBRARY_PATH
).
I've built once with MPIR 2.1.3 and once with MPIR 2.4.0[.p1], which doesn't seem to make a difference regarding the results of ptestlong
.
According to Bill, MPIR doesn't make (much) use of assertions; they mainly rely on their test suites (same for FLINT).
comment:51 Changed 11 years ago by
P.S.: I've of course built MPIR 2.4.0 (successfully) with SAGE_CHECK=yes
; the GCC on silius is itself built with MPIR 2.5.0 and MPFR 3.1.0.
I use -mcpu=power7 -mtune=power7 -O3 -g [-fno-strict-aliasing]
; with earlier Sage versions, I did build ECL with -mcpu=power4 ...
, which (besides other variations) led to less errors (doctest errors in only 8 files IIRC), but I currently can't give a comparison or more details.
comment:52 Changed 11 years ago by
Replying to zimmerma:
Francois, just to be sure, did you check MPFR is built with
--disable-thread-safe
?
The MPFR 3.1.0.p0 spkg included in Sage 5.0.beta8 uses --disable-thread-safe
.
comment:53 Changed 11 years ago by
I have build sage again with SAGE_DEBUG set to yes but I don't get more information this is annoying.
comment:54 Changed 11 years ago by
All mpir/mpfr/mpfi tests pass (expect tget_set_d64 in mpfr which is skipped). One strange thing in mpfr
[tversion] MPIR: header 2.4.0, library 2.4.0 [tversion] MPFR tuning parameters from src/powerpc32/mparam.h
this is a powerpc64 machine (and I am sure mpir is configured 64bits), does it matter?
comment:55 Changed 11 years ago by
It doesn't seem to matter but I am not sure the configuration works as it should in mpfr, if both ARCH_PPC and PPC64 are present PPC64 is just ignored.
comment:56 Changed 11 years ago by
Francois,
I don't think it matters, since the mparam.h
file only contains tuning parameters,
however I will fix that in the development version. Thank you for pointing out this.
Paul
comment:57 Changed 11 years ago by
in fact this issue was already fixed in the development version of MPFR. Here is a patch:
zimmerma@silius:~/mpfr-3.1.0> diff -u src/mparam_h.in.orig src/mparam_h.in --- src/mparam_h.in.orig 2012-03-23 07:46:30.412866000 +0000 +++ src/mparam_h.in 2012-03-23 07:46:41.821355000 +0000 @@ -61,14 +61,14 @@ #define MPFR_TUNE_CASE "src/arm/mparam.h" #include "arm/mparam.h" -#elif defined (_ARCH_PPC) /* Threshold for 32-bit PowerPC */ -#define MPFR_TUNE_CASE "src/powerpc32/mparam.h" -#include "powerpc32/mparam.h" - #elif defined (__PPC64__) /* Threshold for 64-bit PowerPC */ #define MPFR_TUNE_CASE "src/powerpc64/mparam.h" #include "powerpc64/mparam.h" +#elif defined (_ARCH_PPC) /* Threshold for 32-bit PowerPC */ +#define MPFR_TUNE_CASE "src/powerpc32/mparam.h" +#include "powerpc32/mparam.h" + #elif defined (__sparc_v9__) /* Threshold for 64-bits Sparc */ #define MPFR_TUNE_CASE "src/sparc64/mparam.h" #include "sparc64/mparam.h"
Paul
comment:58 follow-up: 59 Changed 11 years ago by
would it be possible to send me the config.log
file from MPFR when configured within Sage?
Paul
comment:59 Changed 11 years ago by
Replying to zimmerma:
would it be possible to send me the
config.log
file from MPFR when configured within Sage?
I've uploaded two config.log
s of MPFR from silius:
- MPFR 3.1.0.p0 configured with MPIR 2.1.3 (p9, Sage 5.0.beta9)
- MPFR 3.1.0.p0 configured with MPIR 2.4.0 (p1 from #11616, otherwise Sage 5.0.beta9)
They don't differ except for the name of a temporary file.
(GCC 4.6.3, which meanwhile is the default compiler on that machine; CFLAGS
/CXXFLAGS
: -mcpu=power7 -mtune=power7 -O3 -g -fno-strict-aliasing
)
-leif
comment:60 Changed 11 years ago by
Leif,
thank you. I did compare your config.log of MPFR 3.1.0.p0 configured with MPIR 2.4.0 with the one for a vanilla MPFR-3.1.0 configured with GMP 5.0.4:
(1) it seems your config.log does not extract CC and CFLAGS from gmp.h
(2) mine uses gcc -std=gnu99 instead of gcc alone
(3) your config.log uses -mcpu=power7 -mtune=power7 instead of -m64
(4) the linker used is ld in your case and /usr/local/binutils-2.21.1/ppc64-Linux-power7-suse-gcc-4.6.1/bin/ld
for a vanilla MPFR
I'd like to reproduce exactly your build with a vanilla MPFR but I cannot access some of your files:
zimmerma@silius:~/mpfr-3.1.0> ls /home/leif/Sage/release/build/silius/sage-5.0.beta9-gcc-4.6.3/local/include ls: cannot access /home/leif/Sage/release/build/silius/sage-5.0.beta9-gcc-4.6.3/local/include: Permission denied
Paul
comment:61 Changed 11 years ago by
Replying to zimmerma:
I did compare your config.log of MPFR 3.1.0.p0 configured with MPIR 2.4.0 with the one for a vanilla MPFR-3.1.0 configured with GMP 5.0.4:
(1) it seems your config.log does not extract CC and CFLAGS from gmp.h
It does, but MPIR takes (also) the flags I specified and hence writes these to gmp.h
:
leif@silius:~/.../sage-5.0.beta9-gcc-4.6.3> egrep "__(GMP|MPIR)_(CC|CFLAGS)" local/include/gmp.h #define __GMP_CC __MPIR_CC #define __GMP_CFLAGS __MPIR_CFLAGS #define __MPIR_CC "gcc -std=gnu99" #define __MPIR_CFLAGS " -g -O3 -mcpu=power7 -mtune=power7 -O3 -g -fno-strict-aliasing "
(This is the gmp.h
created by MPIR 2.4.0.p1. I know the one from MPIR 2.1.3 does look different: First of all, __GMP_CC
and __GMP_CFLAGS
are defined to strings as well, instead of referring to their respective MPIR macros, and -- which is a known bug -- __GMP_CC
doesn't contain -std=gnu99
, although __MPIR_CC
does.)
(2) mine uses gcc -std=gnu99 instead of gcc alone
This shouldn't matter; I could retry building MPIR and MPFR with CC="gcc -std=gnu99"
though.
(3) your config.log uses -mcpu=power7 -mtune=power7 instead of -m64
See above.
(4) the linker used is ld in your case and
/usr/local/binutils-2.21.1/ppc64-Linux-power7-suse-gcc-4.6.1/bin/ld
for a vanilla MPFR
leif@silius:~> command -v ld /usr/bin/ld leif@silius:~> (. /usr/local/skynet_bash_profile ; command -v ld) /usr/bin/ld leif@silius:~> command ld --version GNU ld (GNU Binutils; SUSE Linux Enterprise 11) 2.20.0.20100122-0.7.9 Copyright 2009 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. leif@silius:~> (. /usr/local/skynet_bash_profile ; command ld --version) GNU ld (GNU Binutils; SUSE Linux Enterprise 11) 2.20.0.20100122-0.7.9 Copyright 2009 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. leif@silius:~> echo $PATH /usr/local/bin/ppc64-Linux-power7-suse:/home/leif/.local/bin:/home/leif/bin/silius:/home/leif/bin:/opt/csm/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
I'd like to reproduce exactly your build with a vanilla MPFR but I cannot access some of your files.
I've copied the headers and libs into /tmp/leif/sage-5.0beta9/MPIR-{2.1.3,2.4.0}/local/{include,lib}/
, so you should be able to configure MPFR with --with-gmp=/tmp/leif/sage-5.0beta9/MPIR-2.1.3/local/
etc.
[Sorry for the delay, had some network trouble.]
comment:62 Changed 11 years ago by
with MPFR configured with --enable-assert
within sage-5.0.beta9, I can simplify the
problem to:
sage: RIF(1,1) get_exp.c:29: MPFR assertion failed: ((x)->_mpfr_d)[(((((x))->_mpfr_prec)-1)/(64 - 0)+1)-1] & ((~(mp_limb_t)0) ^ ((~(mp_limb_t)0) >> 1))
This means that we compute the exponent of a number which is either NaN, infinite or zero. I will continue to investigate.
Paul
comment:63 follow-up: 64 Changed 11 years ago by
I have spent several hours on this and my conclusion is that the culprit is Sage (i.e. Cython).
In real_mpfi.pyx
one can read:
elif PY_TYPE_CHECK(a, Rational) and PY_TYPE_CHECK(b, Rational): rat = a rat1 = b # todo: The <object> coerce is evidently to get around a weird bug in SageX (?) mpfi_interv_q(self.value, <object>rat.value, <object>rat1.value)
and the same coerce is done in the integer case.
I am 99% sure that we hit that weird bug. Indeed with RIF(1,1)
the integers (mpz_t) which are
passed to mpfi_interv_z
are malformed, with SIZ=2
instead of SIZ=1
.
However I have no idea how to solve that weird bug, or how to find another workaround. Can we know who did write this comment?
It might be that the issue is related to the fact that the Power7 is big endian. Was Sage tested on other 64-bit big endian platforms?
Paul
comment:64 Changed 11 years ago by
Replying to zimmerma:
I am 99% sure that we hit that weird bug. However I have no idea how to solve that weird bug, or how to find another workaround.
? The coercion is supposed to work around just that "weird bug", as I understand this.
But this comment is likely to be obsolete ("SageX") anyway; did you try removing the <object>
?
Can we know who did write this comment?
hg annotate ...
(an alias for blame
;-) ) gives the changeset number, then hg log [-v] ...
to see who made that change.
It might be that the issue is related to the fact that the Power7 is big endian. Was Sage tested on other 64-bit big endian platforms?
Well, [SunOS/Solaris] SPARC (V9), but the 64-bit port (including x86_64) is still incomplete AFAIK. (There's some wiki page on it, and a couple of meta-tickets; or ask Dave Kirkby, who did most if not all of it on his own.)
comment:65 Changed 11 years ago by
Leif,
yes I tried removing the coercion. It gives:
Error compiling Cython file: ------------------------------------------------------------ ... mpfi_interv_q(self.value, <object>rat.value, <object>rat1.value) elif PY_TYPE_CHECK(a, Integer) and PY_TYPE_CHECK(b, Integer): integ = a integ1 = b mpfi_interv_z(self.value, integ.value, integ1.value) ^ ------------------------------------------------------------ sage/rings/real_mpfi.pyx:1045:47: Cannot convert 'mpz_t' to Python object
This is strange because mpfi_interv_z
expects a mpz_t
as 2nd and 3rd arguments, and
integ.value
is a mpz_t
, thus I don't see any reason to convert to a Python object.
Paul
comment:66 Changed 11 years ago by
on sage.math with Sage 4.8 hg annotate
gives:
2617: # todo: The <object> coerce is evidently to get around a weird bug in SageX (?) 2617: mpfi_interv_q(self.value, <object>rat.value, <object>rat1 .value)
then:
zimmerma@sage:~/sage-4.8/devel/sage/sage/rings$ hg log -r 2617 changeset: 2617:616e5624646c user: William Stein <wstein@gmail.com> date: Wed Jan 24 11:42:46 2007 -0800 summary: Switch to Carl Witty's new MPFI wrapper; also some fixes for the reference manual.
I'll thus ask William to help.
Paul
comment:67 Changed 11 years ago by
I've sent a private mail to William. The bug seems clearly in Cython. In real_mpfi.c
I see:
__pyx_t_3 = ((PyObject *)__pyx_v_integ->value); __Pyx_INCREF(__pyx_t_3); __pyx_t_8 = ((PyObject *)__pyx_v_integ1->value); __Pyx_INCREF(__pyx_t_8); mpfi_interv_z(((struct __pyx_obj_4sage_5rings_9real_mpfi_RealIntervalFiel\ dElement *)__pyx_v_self)->value, __pyx_t_3, __pyx_t_8);
thus __pyx_t_3
is of the wrong type: it should be of type Integer and not of type Python object
(compare to the call to mpfi_set_z
in the same file).
Paul
comment:68 Changed 11 years ago by
I believe I understand what happens. The fact that __pyx_t_3
has the wrong type is not a problem,
since it is a pointer, like what mpz_t
expects as 2nd (and 3rd) argument of mpfi_interv_z
.
However my guess is that the __Pyx_INCREF(__pyx_t_3)
call is intended to increase a reference counter stored somewhere in the PyObject
struct. Since __pyx_v_integ->value
is not a Python object but a mpz_t
, this call makes a side effect on the mpz_t
structure, which has the
effect to increase its "size" from 1 to 2, which explains why the mpz_t
object seen by
mpfi_interv_z
is corrupted.
What is annoying is that this corruption also happens on other configurations (in particular
little endian). For some reason it gets unnoticed, maybe because the corrupted field is not the size
(maybe the allocated size). However one might be able to reproduce the problem also by changing the
order of the fields in the mpz_t
structure in gmp.h
. Putting _mp_size
first seems to
break Sage on 64-bit Intel processors.
Paul
comment:69 follow-up: 70 Changed 11 years ago by
I still got no answer from William. Does anybody know if it is possible to recompile Sage
after modifying manually the real_mpfi.c
file, without it being automatically generated?
My idea is to remove the __Pyx_INCREF
instructions to confirm my guess.
Paul
comment:70 Changed 11 years ago by
Replying to zimmerma:
I still got no answer from William. Does anybody know if it is possible to recompile Sage after modifying manually the
real_mpfi.c
file, without it being automatically generated?
./sage -b
should just do that, since Cython won't (re)generate files that are newer than their sources.
Of course first make a copy of it, but I've patched C and C++ files generated by Cython a couple of times without problems.
comment:71 Changed 11 years ago by
thank you Leif. This confirms my guess: if I comment the two __Pyx_INCREF
before
the call to mpfi_interv_z
, and the two __Pyx_DECREF
after, then RIF(1,1)
runs ok.
The problem is thus isolated, we now need somebody fluent in Cython to solve it or find another (platform independent) workaround.
Where do we report Cython bugs?
Paul
comment:73 follow-up: 74 Changed 11 years ago by
it seems indeed to solve the MPFI problem. I will try this patch on top of sage-5.0.beta10. Good catch Jeroen! Btw, why did you remove the cdef for free()?
Paul
comment:74 Changed 11 years ago by
Replying to zimmerma:
Btw, why did you remove the cdef for free()?
- Because it is not needed.
- Because in Sage, you should use
sage_free()
(which blocks interrupts and could potentially do other stuff too).
comment:75 Changed 11 years ago by
with the patch on top of sage-5.0.beta10, we are making good progress, but the following doctests still fail:
sage -t devel/sage-11705/sage/functions/special.py # 2 doctests failed sage -t devel/sage-11705/sage/graphs/graph_decompositions/vertex_separation.pyx # 3 doctests failed sage -t devel/sage-11705/sage/libs/libecm.pyx # Killed/crashed sage -t devel/sage-11705/sage/numerical/optimize.py # 6 doctests failed sage -t devel/sage-11705/sage/plot/plot3d/list_plot3d.py # 4 doctests failed sage -t devel/sage-11705/sage/sandpiles/sandpile.py # Time out
I will investigate the libecm problem.
Paul
comment:76 Changed 11 years ago by
the sandpile.py
doctest passes with -long
, thus only 5 doctests fail.
Paul
comment:77 Changed 11 years ago by
the libecm problem disappears when configuring GMP-ECM with --disable-asm-redc
. The error is when
the assembly function mulredc1
is called. Nothing seems wrong in the arguments, and I cannot reproduce the problem when configuring GMP-ECM alone. Also after adding make check
in spkg-install
everything is ok (btw why is make check
not done?).
Maybe the problem is similar to the one Jeroen solved with MPFI?
Paul
comment:78 Changed 11 years ago by
Building cvxopt with SAGE_CHECK=yes
fails on silius with GCC-4.6.3:
Testing l1.py ... pcost dcost gap pres dres k/t 0: 8.3671e+02 2.4168e+02 6e+02 8e-17 6e-15 1e+00 Traceback (most recent call last): File "l1.py", line 126, in <module> x, y = l1(P,q) File "l1.py", line 120, in l1 primalstart={'x': x0, 's': s0}, dualstart={'z': z0}) File "/home/jdemeyer/silius/sage-5.0.beta12-gcc/local/lib/python2.7/site-packages/cvxopt/coneprog.py", line 1084, in conelp raise ValueError("Rank(A) < p or Rank([G; A]) < n") ValueError: Rank(A) < p or Rank([G; A]) < n Error: test /home/jdemeyer/silius/sage-5.0.beta12-gcc/spkg/build/cvxopt-1.1.3.p1/src/examples/doc/chap8/l1.py failed
comment:79 Changed 11 years ago by
Here is the backtrace for the ECM Segmentation Fault:
#0 0x7d0429d27d242810 in ?? () #1 0x00000fffae273c18 in mulredc (z=0x10678760, x=<optimized out>, y=<optimized out>, m=0x1410d4b0, nn=1, invm=4727093576446091305) at mpmod.c:386 #2 0x00000fffae277300 in ecm_mulredc_basecase (R=0xfffffffc3b0, S1=0xfffffffc4d8, S2=0xfffffffc4a8, modulus=0xfffffffc460) at mpmod.c:611 #3 0x00000fffae26576c in ecm (f=0xfffffffc878, x=0xfffffffc6e8, sigma=0xfffffffc6f8, n=0xfffffffc888, go=0xfffffffc710, B1done=0xfffffffc720, B1=0, B2min_parm=0xfffffffc728, B2_parm=0xfffffffc738, B2scale=1, k=0, S=0, verbose=0, repr=0, nobase2step2=0, use_ntt=1, sigma_is_A=0, os=0xfffb7b7d698, es=0xfffb7b7d778, chkfilename=0x0, TreeFilename=0x0, maxmem=0, stage1time=0, rng=0xfffffffc790, stop_asap=0) at ecm.c:940 #4 0x00000fffae264e34 in ecm_factor (f=0xfffffffc878, n=0xfffffffc888, B1=0, p=0xfffffffc6e0) at factor.c:93 #5 0x00000fffae262640 in __pyx_pf_4sage_4libs_6libecm_ecmfactor (__pyx_self=<optimized out>, __pyx_args=<optimized out>, __pyx_kwds=<optimized out>) at sage/libs/libecm.c:1958 #6 0x00000fffb7e13ed4 in PyCFunction_Call (func=0x140c36c8, arg=<optimized out>, kw=<optimized out>) at Objects/methodobject.c:85 #7 0x00000fffb7e8fc18 in call_function (oparg=<optimized out>, pp_stack=0xfffffffca48) at Python/ceval.c:4013 #8 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666 #9 0x00000fffb7e91908 in PyEval_EvalCodeEx (co=0x140c2830, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=<optimized out>, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253 #10 0x00000fffb7e9199c in PyEval_EvalCode (co=<optimized out>, globals=<optimized out>, locals=<optimized out>) at Python/ceval.c:667
comment:80 Changed 11 years ago by
Jeroen, I get the same backtrace, then the mulredc() function should call the assembly code
mulredc1.asm
in the powerpc64 subdirectory. I don't know if this assembly function is
called or not. Could it be a problem in the way parameters are passed to that assembly function?
Paul
comment:82 Changed 11 years ago by
Replying to jdemeyer:
Recompiling ecm with -O0 doesn't help.
yes. I'll try with GMP-ECM 6.4.2 to see if the problem persists.
Paul
comment:84 Changed 11 years ago by
I tried linking the GMP-ECM binary with the libecm.a and libgmp.a files produced by Sage, and then the same example works fine... No more idea for now.
Paul
comment:85 Changed 11 years ago by
interesting, the segv only occurs for some inputs. For example the following works:
sage: ecmfactor(2^20-1,0.0) (True, 33)
Paul
comment:86 follow-up: 99 Changed 11 years ago by
I tried configuring GMP-ECM with -enable-assert
, nothing wrong happens.
I have no further idea to investigate. Any suggestion out there?
Of course a possible workaround would be to configure with --disable-asm-redc
on
powerpc64, but it would be nice to find the reason of this problem. Is there any other
powerpc on which we could test?
What is strange is that the bug occurs inside libecm.a when called from within Sage, and does not occur when called from the binary GMP-ECM (with the same libecm.a). Maybe a memory corruption related to the ecm_params structure which is not really defined in libecm.pyx? Is it possible to link libecm dynamically to Sage?
Paul
comment:87 Changed 11 years ago by
Ok so I applied the patch to beta10 and run the long test (in serial) and we have made a lot of progress:
sage -t -long "devel/sage/doc/en/numerical_sage/cvxopt.rst" sage -t -long "devel/sage/sage/functions/special.py" sage -t -long "devel/sage/sage/graphs/graph_decompositions/vertex_separation.pyx" sage -t -long "devel/sage/sage/libs/libecm.pyx" # Killed/crashed sage -t -long "devel/sage/sage/numerical/optimize.py" sage -t -long "devel/sage/sage/plot/plot3d/list_plot3d.py"
I am applying #12777 next to see if that helps with libecm.
comment:89 Changed 11 years ago by
And it indeed doesn't. I was just curious if it would help get a better report on the problem. It doesn't.
comment:90 Changed 11 years ago by
Authors: | → Paul Zimmermann, Jeroen Demeyer |
---|
comment:91 Changed 10 years ago by
I moved the mpfi patch to #12829. We should merge this patch, even though it doesn't solve all ppc64 problems. Paul, are you able to review it?
I had a quick look at the other ppc64 issues, but I couldn't immediately find out what the problem was.
comment:92 Changed 10 years ago by
Description: | modified (diff) |
---|
comment:93 Changed 10 years ago by
Description: | modified (diff) |
---|
comment:94 Changed 10 years ago by
I think we should split the libecm.pyx issue as well. I think at least two other failures are linked to a single problem in scipy (optimize.py and list_plot3d.py) but I haven't been able to track that down yet, upgrading scipy to 0.10.1 doesn't solve the problem.
comment:96 Changed 10 years ago by
special.py look like a serious maxima/ecl problem.
sage -t -long "devel/sage/sage/functions/special.py" ;;; ;;; Stack overflow. ;;; Jumping to the outermost toplevel prompt ;;; ;;; ;;; Stack overflow. ;;; Jumping to the outermost toplevel prompt ;;; ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.0.beta10/devel/sage/sage/functions/special.py", line 1602: sage: elliptic_f(RR(pi/2), 0.5) Expected: 1.8540746773 Got: sage165 ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.0.beta10/devel/sage/sage/functions/special.py", line 1611: sage: elliptic_f(RR(pi/2), 0.5) Expected: 1.8540746773 Got: sage167 **********************************************************************
comment:97 Changed 10 years ago by
sorry I was in vacation. Thank you Francois for reviewing #12829. Shouldn't it be in the dependencies of that ticket?
Paul
comment:98 Changed 10 years ago by
Dependencies: | 12832 → #12829, #12832 |
---|
comment:99 Changed 10 years ago by
Replying to zimmerma:
I tried configuring GMP-ECM with
-enable-assert
, nothing wrong happens. I have no further idea to investigate. Any suggestion out there?Of course a possible workaround would be to configure with
--disable-asm-redc
on powerpc64, but it would be nice to find the reason of this problem. Is there any other powerpc on which we could test?What is strange is that the bug occurs inside libecm.a when called from within Sage, and does not occur when called from the binary GMP-ECM (with the same libecm.a). Maybe a memory corruption related to the ecm_params structure which is not really defined in libecm.pyx?
The pyx just contains a type definition, and passes a null pointer to ecm_factor()
instead of some structure. Segfaults also happen outside of Sage; see below.
Is it possible to link libecm dynamically to Sage?
Of course, you just have to build a shared library (ECM_EXTRA_OPTS="--enable-shared"
); see below.
This is IMHO an upstream (or probably compiler/assembler etc.) bug.
Note that GMP-ECM's test suite segfaults in its first test when configured with --enable-shared
(and asm-redc enabled, which is the default). Same for a trivial stand-alone program just resembling Sage's doctest.
The segfaults vanish in both cases if I in addition pass --disable-asm-redc
. So Sage just exposes the problem, it doesn't cause it.
[FWIW, Sage's ecmfactor()
apparently works for even numbers, as well as interestingly 1025, while all other odd numbers between 950 and 1050 cause a segfault.]
comment:100 Changed 10 years ago by
P.S.: Shooting into the dark, I'd say that the ppc64 redc assembler code simply isn't position-independent.
comment:101 follow-up: 102 Changed 10 years ago by
I've contacted Phil McLaughlin? who is the author of the PowerPC64 code. It might be that he will need access to silius to investigate and possible fix the problem.
Paul
comment:102 follow-up: 103 Changed 10 years ago by
Replying to zimmerma:
I've contacted Phil McLaughlin who is the author of the PowerPC64 code. It might be that he will need access to silius to investigate and possible fix the problem.
I'll also take a closer look at the asm code; it's probably just incompatible to the ppc64 ABI when linked dynamically. Even mulredc1()
, which only uses registers (besides storing the result into the mp_limb_t
whose address is passed), segfaults. (Or probably the calling function segfaults immediately after return).
comment:103 Changed 10 years ago by
Replying to leif:
I'll also take a closer look at the asm code; it's probably just incompatible to the ppc64 ABI when linked dynamically.
The assembly code cannot work with dynamic linking, as all of its functions lack function descriptors.
I'll try to fix that tomorrow, although presumably not [yet] by an upstream-ready patch, as the .asm
(m4
) files are itself generated by m4
, but normally not at build time. Unfortunately also the real assembler (.s
) files, which are generated from the .asm
files, aren't kept, so it's impossible to (temporarily) patch these.
comment:104 follow-up: 105 Changed 10 years ago by
Leif, if you make a patch for mulredc1.asm, maybe I could figure out what is needed in the m4 generating file.
Paul
Changed 10 years ago by
Attachment: | GMP-ECM_PPC64_ELF_function_descriptors.patch added |
---|
Patch to GMP-ECM's PowerPC64 assembly[-generating] files to support dynamic linking (on ELF systems only). For reference only.
comment:105 follow-up: 107 Changed 10 years ago by
Replying to zimmerma:
Leif, if you make a patch for mulredc1.asm, maybe I could figure out what is needed in the m4 generating file.
I've attached a patch to the three .asm
/ .m4
files all PPC64 assembly files are generated from. (FWIW, also applies clean to GMP-ECM 6.4.2.)
While the original files seem partially over-autoconf'd to me (e.g. TEXT
, defined in config.m4
after configure
), I've currently "hardcoded" the ELF function descriptors, i.e., haven't used new macros for them at all. Even if GMP-ECM currently only supports systems using ELF on PPC64 (I think; Darwin PPC is 32-bit, and asm-redc
is disabled on it, although it IMHO wouldn't have to be), one could at least write some m4
macros for [PowerPC] ELF![64] for convenience and put them into (e.g.) powerpc64/elf.m4
, then probably only "enable" them if configure
determines it's an ELF system. (I didn't want to mess with the autoconf
files anyway.)
One could also add some debugging info to the functions, i.e. traceback tables.
I haven't changed the broken indentation of redc.asm
, to keep the patch small and readable.
A preliminary GMP-ECM 6.3.p8 spkg (applying my patches) is here. Note that it is based on the p7 from #12830, which still needs review.
Patches
- ...
- mulredc.m4.patch, mulredc_1_2.m4.patch:
Add function descriptors to PPC64 assembler code to support dynamic linking.
(Even with a static
libecm.a
, Sage segfaulted with--enable-asm-redc
on Linux PPC64, because the [static] GMP-ECM library gets linked into a shared library, namely the Python extension module "libecm".) We patch the twom4
files the twenty.asm
files (insrc/powerpc64/
) are generated from; the latter are again macroprocessor files from which the (only temporary) real assembly files (.s
) are created during build. - redc.asm.patch:
Also add a function descriptor here, although apparently this code isn't
used by Sage, nor GMP-ECM's test suite, at least not currently (as of
GMP-ECM 6.3 / ecm-6.3.p8). (The function it provides is
ecm_redc3()
.)
ecm-6.3.p8 (Leif Leonhardy, April 24th 2012)
- #12830: Add patches to
src/powerpc64/{mulredc,mulredc_1_2}.m4
to support dynamic linking, otherwise the Python extension module "libecm" segfaults with--enable-asm-redc
on [Linux] PPC64, regardless of whether we build a shared and/or static GMP-ECM library. For consistency, also patchsrc/powerpc64/redc.asm
in the same way, al- though it doesn't seem that this code was currently used. (See also the Linux PPC64 meta-ticket #11705.)
I've only tested it on Silius, with --enable-shared
and --disable-shared
(--enable-asm-redc
is the default), with Sage 5.0.beta9 (plus some replacement spkgs and #12829) and GCC 4.6.3, FWIW.
Perhaps François could test the attached patch with vanilla GMP-ECM on AIX.
comment:106 Changed 10 years ago by
Leif, thank you very much for your patch. I have incorporated it to the development version, where it applies cleanly. I have checked that both --enable-shared and --disable-shared work on silius.
Paul
comment:107 Changed 10 years ago by
Replying to leif:
While the original files seem partially over-autoconf'd to me (e.g.
TEXT
, defined inconfig.m4
afterconfigure
), I've currently "hardcoded" the ELF function descriptors, i.e., haven't used new macros for them at all. Even if GMP-ECM currently only supports systems using ELF on PPC64 (I think; Darwin PPC is 32-bit, andasm-redc
is disabled on it, although it IMHO wouldn't have to be), one could at least write somem4
macros for [PowerPC] ELF![64] for convenience and put them into (e.g.)powerpc64/elf.m4
, then probably only "enable" them ifconfigure
determines it's an ELF system. (I didn't want to mess with theautoconf
files anyway.)
Patching configure
[.in
] to also include powerpc64/elf.m4
if appropriate is trivial, so I'll probably add that, too. (And write [slightly corrected] PROLOG()
/ EPILOG()
macros.)
One could also add some debugging info to the functions, i.e. traceback tables.
[Planned.]
Perhaps François could test the attached patch with vanilla GMP-ECM on AIX.
Reading configure.in
(of GMP-ECM 6.4.2), I see that asm-redc
for PPC64 is currently only supported on Linux anyway, so testing it on AIX doesn't make sense. (On AIX, it isn't enabled by default, and explicitly enabling it will just raise a configure
error, so that's fine [for now].)
comment:108 Changed 10 years ago by
I'll be completely cut off the internet until the end of the month so I won't be able to test anything until then. I won't even be able to read emails for a while.
comment:109 Changed 10 years ago by
did someone test sage-5.0.rc1 on silius, to see which doctests still fail?
Paul
comment:111 Changed 10 years ago by
Description: | modified (diff) |
---|
comment:112 follow-up: 113 Changed 10 years ago by
I did a test build and run of 5.1beta5 yesterday, with gcc-4.6.3 shipped with sage. There doctests failures in 4 files at this stage:
The following tests failed: sage -t -long -force_lib devel/sage/sage/functions/special.py # 2 doctests failed sage -t -long -force_lib devel/sage/sage/numerical/optimize.py # 6 doctests failed sage -t -long -force_lib devel/sage/sage/libs/libecm.pyx # 7 doctests failed sage -t -long -force_lib devel/sage/sage/plot/plot3d/list_plot3d.py # 4 doctests failed
Which I guess is fairly good and down from before the 5.0 release. I guess I should test an updated GMP-ECM next.
comment:113 follow-up: 114 Changed 10 years ago by
Replying to fbissey:
Which I [...] down from before the 5.0 release.
Are you sure, because I still get the 5 failures mentioned in the ticket description on Skynet silius.
comment:114 Changed 10 years ago by
Replying to jdemeyer:
Replying to fbissey:
Which I [...] down from before the 5.0 release.
Are you sure, because I still get the 5 failures mentioned in the ticket description on Skynet silius.
That's very curious. I didn't have it in my doctest run. I must have done it wrong. The cvxopt does indeed still fail.
comment:115 Changed 10 years ago by
Sage's cvxopt spkg sucks. It's way overlinked everywhere. It probably won't help much with the tests but I will do experiments to bring it 1.1.5 and clean that mess.
comment:116 Changed 10 years ago by
Looking at special.py tests
sage: elliptic_kc(0.5) 1.8540746773 sage: elliptic_f(RR(pi/2), 0.5) elliptic_f(1.57079632679490, 0.500000000000000) sage: elliptic_f(1.57079632679490, 0.500000000000000) 1.8540746773
So in effect elliptic_f is not evaluated straight away on power7.
comment:117 Changed 10 years ago by
Just a note, it may not be power7 specific. I am building a debug version of sage with SAGE_DEBUG=yes and polybori-0.8.1.p0 compilation broke. So far that's the only thing that failed to build with SAGE_DEBUG.
comment:118 Changed 10 years ago by
Well, that was a long time to do anything. I have just build 5.7.beta3 + numpy-1.7. Apart from the expected stuff from numpy we have the same doctest files failing. But the number has gone down for two of them:
sage -t -long devel/sage-main/sage/libs/libecm.pyx # 7 doctests failed [was 10] sage -t -long devel/sage-main/sage/numerical/optimize.py # 2 doctests failed [was 6]
Now that we have a killer debugging system in place things may get interesting.
comment:119 Changed 10 years ago by
I unfortunately no longer have access to a ppc64 system. Is anybody willing to donate access to such a machine for the Sage buildbot?
comment:120 follow-up: 121 Changed 10 years ago by
I cannot donate unfortunately - not without losing my job. What happened to silius?
comment:121 follow-up: 123 Changed 10 years ago by
comment:122 follow-up: 124 Changed 10 years ago by
Francois, for libecm, did you apply the patch to allow dynamic linking with assembly files?
I could try to help with libecm.pyx if you provide a detailed output of the libecm failures.
Paul
comment:123 Changed 10 years ago by
Replying to jdemeyer:
Replying to fbissey:
What happened to silius?
It has been down for a while, that's all I know.
I could possibly donate expertise to bring it back up depending on whether it can be dealt with remotely or not. But I would need more details on the way it is administered, I doubt there is an HMC or an xcat server for just one node.
comment:124 Changed 10 years ago by
Replying to zimmerma:
Francois, for libecm, did you apply the patch to allow dynamic linking with assembly files?
I could try to help with libecm.pyx if you provide a detailed output of the libecm failures.
Hi Paul,
Haven't tried yet and I certainly can provide detailed output and backtraces. I have just started a 5.7beta4 with SAGE_DEBUG. On beta3 we have this kind of failures currently:
sage -t -long "devel/sage-main/sage/libs/libecm.pyx" ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/devel/sage-main/sage/libs/libecm.pyx", line 18: sage: result = ecmfactor(999, 0.00) Exception raised: Traceback (most recent call last): File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_0[3]>", line 1, in <module> result = ecmfactor(Integer(999), RealNumber('0.00'))###line 18: sage: result = ecmfactor(999, 0.00) File "libecm.pyx", line 152, in sage.libs.libecm.ecmfactor (sage/libs/libecm.c:2015) RuntimeError: Segmentation fault ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/devel/sage-main/sage/libs/libecm.pyx", line 19: sage: result in [(True, 27), (True, 37), (True, 999)] Exception raised: Traceback (most recent call last): File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_0[4]>", line 1, in <module> result in [(True, Integer(27)), (True, Integer(37)), (True, Integer(999))]###line 19: sage: result in [(True, 27), (True, 37), (True, 999)] NameError: name 'result' is not defined ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/devel/sage-main/sage/libs/libecm.pyx", line 21: sage: result = ecmfactor(999, 0.00, verbose=True) Exception raised: Traceback (most recent call last): File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_0[5]>", line 1, in <module> result = ecmfactor(Integer(999), RealNumber('0.00'), verbose=True)###line 21: sage: result = ecmfactor(999, 0.00, verbose=True) File "libecm.pyx", line 152, in sage.libs.libecm.ecmfactor (sage/libs/libecm.c:2015) RuntimeError: Segmentation fault ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/devel/sage-main/sage/libs/libecm.pyx", line 24: sage: result in [(True, 27), (True, 37), (True, 999)] Exception raised: Traceback (most recent call last): File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_0[6]>", line 1, in <module> result in [(True, Integer(27)), (True, Integer(37)), (True, Integer(999))]###line 24: sage: result in [(True, 27), (True, 37), (True, 999)] NameError: name 'result' is not defined ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/devel/sage-main/sage/libs/libecm.pyx", line 108: sage: ecmfactor(N, 100, verbose=True) Exception raised: Traceback (most recent call last): File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_1[15]>", line 1, in <module> ecmfactor(N, Integer(100), verbose=True)###line 108: sage: ecmfactor(N, 100, verbose=True) File "libecm.pyx", line 152, in sage.libs.libecm.ecmfactor (sage/libs/libecm.c:2015) RuntimeError: Segmentation fault ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/devel/sage-main/sage/libs/libecm.pyx", line 112: sage: ecmfactor(N/11, 100, verbose=True) Exception raised: Traceback (most recent call last): File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_1[16]>", line 1, in <module> ecmfactor(N/Integer(11), Integer(100), verbose=True)###line 112: sage: ecmfactor(N/11, 100, verbose=True) File "libecm.pyx", line 152, in sage.libs.libecm.ecmfactor (sage/libs/libecm.c:2015) RuntimeError: Segmentation fault ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/devel/sage-main/sage/libs/libecm.pyx", line 132: sage: ecmfactor(1, 100) Exception raised: Traceback (most recent call last): File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/hpc/scratch/frb15/sandbox/sage-5.7.beta3-NDEBUG/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_1[19]>", line 1, in <module> ecmfactor(Integer(1), Integer(100))###line 132: sage: ecmfactor(1, 100) File "libecm.pyx", line 152, in sage.libs.libecm.ecmfactor (sage/libs/libecm.c:2015) RuntimeError: Segmentation fault **********************************************************************
comment:126 follow-up: 129 Changed 10 years ago by
with the attached patch, the libecm issues should disappear.
Paul
comment:127 Changed 10 years ago by
I have an unexpected development at #14098 SAGE_DEBUG=yes seems to imply that tests are run on most spkg and zn_poly died an horrible death.
comment:128 Changed 10 years ago by
AH reading spkg-install it doesn't imply testing of all spkg this one has a quick test suite that always run. And it didn't fail in beta3 without debug and now fails in beta4 with debug.
comment:129 Changed 10 years ago by
Replying to zimmerma:
with the attached patch, the libecm issues should disappear.
frb15@p2n14-c /hpc/scratch/frb15/sandbox/sage-5.7.beta4 :./sage -t -long "devel/sage-main/sage/libs/libecm.pyx" sage -t -long "devel/sage-main/sage/libs/libecm.pyx" [10.8 s] ---------------------------------------------------------------------- All tests passed!
Now that's a good patch!
comment:130 Changed 10 years ago by
Francois, please could you update the ticket description with the current status?
Paul
comment:131 Changed 10 years ago by
Description: | modified (diff) |
---|
OK done. I am trying to figure out cvxopt problems again. I will split up the ecm issue since we have a fix. Is the fix included in newer ecm? sage is a bit behind it could be an opportunity to upgrade. I know that 6.4.2 compiles fine under linux and works with sage without changes - doesn't compile in my gentoo prefix on my imac core2 duo but I suspect the problem is the compiler.
comment:132 Changed 10 years ago by
Dependencies: | #12829, #12832 → #12829, #12832, #14098 |
---|
comment:133 follow-up: 150 Changed 10 years ago by
Francois, the ecm patch is not yet included in the last release 6.4.3. I'll see if we can make a new release of GMP-ECM.
Paul
comment:134 Changed 10 years ago by
Description: | modified (diff) |
---|
OK that's cool. In the mean time I'll do a new run o doctesting - I haven't done a full one on that build yet I had limited myself to key tests. And I have just found:
frb15@p2n14-c /hpc/scratch/frb15/sandbox/sage-5.7.beta4 :./sage -t --long -force_lib devel/sage/sage/plot/plot3d/list_plot3d.py sage -t --long -force_lib "devel/sage/sage/plot/plot3d/list_plot3d.py" [16.4 s] ---------------------------------------------------------------------- All tests passed! Total time for all tests: 16.6 seconds
So somehow this one got fixed. I had misread the test results from beta3+numpy-1.7. So updating description again.
comment:135 Changed 10 years ago by
Francois, if you give a detailed output of the failures maybe we can give some hint.
Paul
comment:136 Changed 10 years ago by
That's repeating from earlier comments but this is now a long thread:
./sage -t --long -force_lib devel/sage/sage/functions/special.py sage -t --long -force_lib "devel/sage/sage/functions/special.py" ;;; ;;; Stack overflow. ;;; Jumping to the outermost toplevel prompt ;;; ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta4/devel/sage/sage/functions/special.py", line 1614: sage: elliptic_f(RR(pi/2), 0.5) Expected: 1.8540746773 Got: sage165 ;;; ;;; Stack overflow. ;;; Jumping to the outermost toplevel prompt ;;; ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta4/devel/sage/sage/functions/special.py", line 1623: sage: elliptic_f(RR(pi/2), 0.5) Expected: 1.8540746773 Got: sage167 ********************************************************************** 2 items had failures: 1 of 5 in __main__.example_44 1 of 5 in __main__.example_45 ***Test Failed*** 2 failures. For whitespace errors, see the file /hpc/home/frb15/.sage//tmp/special_36988.py [31.9 s] ----------------------------------------------------------------------
A maxima/ecl problem, I'll try to get more details so we can forward this to the ecl people (or maxima but I suspect the fault is in ecl).
sage -t --long -force_lib "devel/sage/doc/en/numerical_sage/cvxopt.rst" ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta4/devel/sage/doc/en/numerical_sage/cvxopt.rst", line 129: sage: print sol['x'] # ... below since can get -00 or +00 depending on architecture Expected: [ 1.00e...00] [ 1.00e+00] Got: [ 9.87e-01] [ 9.92e-01] <BLANKLINE> **********************************************************************
could be considered noise, but it is of a worrying kind especially when combined with the next one:
sage -t -long "devel/sage-main/sage/numerical/optimize.py" ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta4/devel/sage-main/sage/numerical/optimize.py", line 515: sage: sol['x'] Expected: (0.999..., 1.000...) Got nothing ********************************************************************** File "/hpc/scratch/frb15/sandbox/sage-5.7.beta4/devel/sage-main/sage/numerical/optimize.py", line 525: sage: sol['x'] Expected: (45.000000..., 6.2499999...3, 1.00000000...) Got nothing GLPK Simplex Optimizer, v4.44 6 rows, 3 columns, 8 non-zeros Preprocessing... 2 rows, 2 columns, 4 non-zeros Scaling... A: min|aij| = 2.400e+01 max|aij| = 5.000e+01 ratio = 2.083e+00 GM: min|aij| = 8.128e-01 max|aij| = 1.230e+00 ratio = 1.514e+00 EQ: min|aij| = 6.606e-01 max|aij| = 1.000e+00 ratio = 1.514e+00 Constructing initial basis... Size of triangular part = 2 * 0: obj = -5.100000000e+01 infeas = 0.000e+00 (0) * 1: obj = -5.225000000e+01 infeas = 0.000e+00 (0) OPTIMAL SOLUTION FOUND **********************************************************************
I have digged deeper at what is happening under the hood in the first case comparing with 5.6 on my imac. The imac run
sage: c=vector(RDF,[-4,-5]) sage: G=matrix(RDF,[[2,1],[1,2],[-1,0],[0,-1]]) sage: h=vector(RDF,[3,3,0,0]) sage: sol=linear_program(c,G,h) sage: sol['x'] (0.999999939767, 1.00000001047) sage: from cvxopt.base import matrix as m sage: from cvxopt import solvers sage: solvers.options['show_progress']=True sage: c_=m(c.base_extend(RDF).numpy()) sage: G_=m(G.base_extend(RDF).numpy()) sage: h_=m(h.base_extend(RDF).numpy()) sage: solvers.lp(c_,G_,h_,solver=None) pcost dcost gap pres dres k/t 0: -8.1000e+00 -1.8300e+01 4e+00 0e+00 8e-01 1e+00 1: -8.8055e+00 -9.4357e+00 2e-01 1e-16 4e-02 3e-02 2: -8.9981e+00 -9.0049e+00 2e-03 1e-16 5e-04 4e-04 3: -9.0000e+00 -9.0000e+00 2e-05 1e-16 5e-06 4e-06 4: -9.0000e+00 -9.0000e+00 2e-07 1e-16 5e-08 4e-08 Optimal solution found. {'status': 'optimal', 'dual slack': 2.7986120477842287e-08, 'iterations': 4, 'residual as primal infeasibility certificate': None, 'relative gap': 2.7257517543273638e-08, 'dual objective': -9.00000049248484, 'residual as dual infeasibility certificate': None, 'gap': 2.453176527488781e-07, 's': <4x1 matrix, tc='d'>, 'primal infeasibility': 1.0136264998440638e-16, 'dual infeasibility': 4.812169483742963e-08, 'primal objective': -8.99999981140672, 'primal slack': 3.929722790979621e-08, 'y': <0x1 matrix, tc='d'>, 'x': <2x1 matrix, tc='d'>, 'z': <4x1 matrix, tc='d'>}
The power7 one
sage: c=vector(RDF,[-4,-5]) sage: G=matrix(RDF,[[2,1],[1,2],[-1,0],[0,-1]]) sage: h=vector(RDF,[3,3,0,0]) sage: sol=linear_program(c,G,h) sage: sol['x'] sage: from cvxopt.base import matrix as m sage: from cvxopt import solvers sage: solvers.options['show_progress']=True sage: c_=m(c.base_extend(RDF).numpy()) sage: G_=m(G.base_extend(RDF).numpy()) sage: h_=m(h.base_extend(RDF).numpy()) sage: solvers.lp(c_,G_,h_,solver=None) pcost dcost gap pres dres k/t 0: -8.1000e+00 -1.8300e+01 4e+00 0e+00 8e-01 1e+00 1: -8.2446e+00 -9.9047e+00 3e-01 8e-02 1e-01 6e-02 2: -7.6587e+00 -8.5347e+00 9e-02 1e+00 5e-02 2e-02 3: -7.0226e+00 -7.7110e+00 6e-02 1e+01 1e-01 1e-02 4: -6.4985e+00 -7.0882e+00 5e-02 2e+01 2e-01 9e-03 5: -5.5876e+00 -6.0350e+00 4e-02 2e+02 3e-01 5e-03 6: -4.8663e+00 -5.2180e+00 3e-02 3e+02 4e-01 3e-03 7: -4.1532e+00 -4.4125e+00 2e-02 2e+03 5e-01 2e-03 8: -3.6054e+00 -3.8041e+00 2e-02 4e+03 6e-01 1e-03 9: -3.1924e+00 -3.3415e+00 1e-02 2e+04 6e-01 8e-04 10: -2.8113e+00 -2.9258e+00 1e-02 4e+04 7e-01 5e-04 11: -2.5706e+00 -2.6588e+00 8e-03 2e+05 7e-01 4e-04 12: -2.2854e+00 -2.3535e+00 6e-03 4e+05 7e-01 3e-04 13: -2.1174e+00 -2.1709e+00 5e-03 2e+06 8e-01 3e-04 14: -1.9020e+00 -1.9438e+00 4e-03 4e+06 8e-01 2e-04 15: -1.7759e+00 -1.8093e+00 3e-03 2e+07 8e-01 2e-04 16: -1.6170e+00 -1.6435e+00 2e-03 4e+07 8e-01 1e-04 17: -1.5242e+00 -1.5457e+00 2e-03 2e+08 8e-01 1e-04 18: -1.4088e+00 -1.4261e+00 2e-03 4e+08 8e-01 1e-04 19: -1.3438e+00 -1.3581e+00 1e-03 2e+09 8e-01 1e-04 20: -1.2614e+00 -1.2731e+00 1e-03 5e+09 9e-01 8e-05 21: -1.2205e+00 -1.2303e+00 1e-03 2e+10 9e-01 8e-05 22: -1.1641e+00 -1.1723e+00 8e-04 5e+10 9e-01 7e-05 23: -1.1457e+00 -1.1526e+00 7e-04 3e+11 9e-01 6e-05 24: -1.1120e+00 -1.1178e+00 6e-04 6e+11 9e-01 5e-05 25: -1.1175e+00 -1.1225e+00 5e-04 3e+12 9e-01 5e-05 26: -1.1071e+00 -1.1114e+00 4e-04 7e+12 9e-01 5e-05 27: -1.1440e+00 -1.1477e+00 4e-04 3e+13 9e-01 5e-05 28: -1.1644e+00 -1.1676e+00 4e-04 8e+13 9e-01 4e-05 29: -1.2555e+00 -1.2584e+00 3e-04 3e+14 9e-01 4e-05 30: -1.3345e+00 -1.3370e+00 3e-04 1e+15 9e-01 4e-05 31: -1.5684e+00 -1.5705e+00 3e-04 4e+15 8e-01 5e-05 32: -1.8504e+00 -1.8522e+00 3e-04 1e+16 8e-01 5e-05 33: -3.2927e+00 -3.2940e+00 4e-04 5e+16 6e-01 6e-05 34: -7.2895e+00 -7.2897e+00 4e-04 1e+17 2e-01 6e-05 35: -8.2349e+00 -8.2350e+00 2e-04 2e+17 8e-02 3e-05 36: -8.1449e+00 -8.1450e+00 3e-04 3e+18 9e-02 2e-05 37: -8.1562e+00 -8.1563e+00 2e-04 5e+18 9e-02 3e-05 38: -8.5850e+00 -8.5850e+00 2e-04 4e+19 5e-02 1e-05 39: -8.7398e+00 -8.7398e+00 1e-04 7e+19 3e-02 7e-06 40: -8.5796e+00 -8.5796e+00 1e-04 2e+21 5e-02 9e-06 41: -8.5844e+00 -8.5844e+00 9e-05 2e+21 5e-02 1e-05 42: -8.7635e+00 -8.7635e+00 5e-05 1e+22 3e-02 4e-06 43: -8.6210e+00 -8.6210e+00 6e-05 3e+23 4e-02 5e-06 44: -8.6127e+00 -8.6127e+00 4e-05 5e+23 4e-02 6e-06 45: -8.7308e+00 -8.7308e+00 4e-05 4e+24 3e-02 3e-06 46: -8.8323e+00 -8.8323e+00 2e-05 7e+24 2e-02 2e-06 47: -8.7174e+00 -8.7174e+00 3e-05 2e+26 3e-02 2e-06 48: -8.6973e+00 -8.6973e+00 3e-05 2e+26 3e-02 3e-06 49: -8.8058e+00 -8.8058e+00 2e-05 2e+27 2e-02 1e-06 50: -8.8546e+00 -8.8546e+00 1e-05 4e+27 2e-02 9e-07 51: -8.7514e+00 -8.7514e+00 2e-05 1e+29 3e-02 1e-06 52: -8.7405e+00 -8.7405e+00 1e-05 1e+29 3e-02 1e-06 53: -8.8161e+00 -8.8161e+00 1e-05 1e+30 2e-02 7e-07 54: -8.8781e+00 -8.8781e+00 7e-06 2e+30 1e-02 5e-07 55: -8.7917e+00 -8.7917e+00 1e-05 5e+31 2e-02 6e-07 56: -8.7732e+00 -8.7732e+00 7e-06 7e+31 3e-02 8e-07 57: -8.8288e+00 -8.8288e+00 7e-06 7e+32 2e-02 5e-07 58: -8.9006e+00 -8.9006e+00 4e-06 1e+33 1e-02 3e-07 59: -8.8275e+00 -8.8275e+00 6e-06 2e+34 2e-02 3e-07 60: -8.8035e+00 -8.8035e+00 4e-06 3e+34 2e-02 4e-07 61: -8.8360e+00 -8.8360e+00 5e-06 3e+35 2e-02 3e-07 62: -8.9251e+00 -8.9251e+00 1e-06 4e+35 8e-03 1e-07 63: -8.8661e+00 -8.8661e+00 3e-06 8e+36 1e-02 2e-07 64: -8.8364e+00 -8.8364e+00 3e-06 1e+37 2e-02 2e-07 65: -8.8262e+00 -8.8262e+00 4e-06 2e+38 2e-02 2e-07 66: -8.9471e+00 -8.9471e+00 6e-07 2e+38 6e-03 8e-08 67: -8.9304e+00 -8.9304e+00 7e-07 3e+38 8e-03 8e-08 68: -8.8850e+00 -8.8850e+00 1e-06 5e+39 1e-02 9e-08 69: -8.8583e+00 -8.8583e+00 1e-06 1e+40 2e-02 1e-07 70: -8.8071e+00 -8.8071e+00 3e-06 2e+41 2e-02 1e-07 71: -8.9335e+00 -8.9335e+00 6e-07 2e+41 7e-03 1e-07 72: -8.9106e+00 -8.9106e+00 6e-07 3e+41 1e-02 1e-07 73: -8.8518e+00 -8.8518e+00 1e-06 5e+42 2e-02 9e-08 74: -8.8289e+00 -8.8289e+00 9e-07 8e+42 2e-02 1e-07 75: -8.8343e+00 -8.8343e+00 1e-06 1e+44 2e-02 8e-08 76: -8.9463e+00 -8.9463e+00 2e-07 1e+44 6e-03 3e-08 77: -8.9336e+00 -8.9336e+00 2e-07 3e+44 7e-03 3e-08 78: -8.9035e+00 -8.9035e+00 4e-07 4e+45 1e-02 3e-08 79: -8.8828e+00 -8.8828e+00 4e-07 8e+45 1e-02 4e-08 80: -8.8369e+00 -8.8369e+00 8e-07 2e+47 2e-02 4e-08 81: -8.8225e+00 -8.8225e+00 7e-07 2e+47 2e-02 7e-08 82: -8.8762e+00 -8.8762e+00 8e-07 3e+48 1e-02 5e-08 83: -8.9445e+00 -8.9445e+00 2e-07 3e+48 6e-03 2e-08 84: -8.9062e+00 -8.9062e+00 4e-07 5e+49 1e-02 2e-08 85: -8.8852e+00 -8.8852e+00 4e-07 9e+49 1e-02 3e-08 86: -8.8567e+00 -8.8567e+00 9e-07 2e+51 2e-02 4e-08 87: -8.9491e+00 -8.9491e+00 2e-07 1e+51 6e-03 2e-08 88: -8.9309e+00 -8.9309e+00 2e-07 2e+51 8e-03 2e-08 89: -8.8818e+00 -8.8818e+00 5e-07 4e+52 1e-02 3e-08 90: -8.8660e+00 -8.8660e+00 4e-07 7e+52 1e-02 4e-08 91: -8.8989e+00 -8.8989e+00 4e-07 7e+53 1e-02 3e-08 92: -8.9524e+00 -8.9524e+00 1e-07 9e+53 5e-03 1e-08 93: -8.9187e+00 -8.9187e+00 2e-07 1e+55 9e-03 1e-08 94: -8.9004e+00 -8.9004e+00 2e-07 3e+55 1e-02 2e-08 95: -8.8722e+00 -8.8722e+00 5e-07 5e+56 1e-02 2e-08 96: -8.9530e+00 -8.9530e+00 1e-07 4e+56 5e-03 1e-08 97: -8.9359e+00 -8.9359e+00 1e-07 6e+56 7e-03 2e-08 98: -8.8923e+00 -8.8923e+00 3e-07 1e+58 1e-02 2e-08 99: -8.8786e+00 -8.8786e+00 2e-07 2e+58 1e-02 2e-08 100: -8.9075e+00 -8.9075e+00 3e-07 2e+59 1e-02 2e-08 Terminated (maximum number of iterations reached). {'dual infeasibility': 0.010220406013259782, 'dual objective': -8.907506570132597, 'dual slack': 9.311702859901095e-68, 'gap': 2.543051531583804e-07, 'iterations': 100, 'primal infeasibility': 1.9410386424538202e+59, 'primal objective': -8.907506586345107, 'primal slack': 8.257930718191955e-09, 'relative gap': 2.85495329914458e-08, 'residual as dual infeasibility certificate': 2.1791043583727054e+58, 'residual as primal infeasibility certificate': None, 's': <4x1 matrix, tc='d'>, 'status': 'unknown', 'x': <2x1 matrix, tc='d'>, 'y': <0x1 matrix, tc='d'>, 'z': <4x1 matrix, tc='d'>}
We have a method that completely fail to converge. I had done some exploration in #12832 when I thought it was a problem in scipy and I will probably continue to track that one over there after a good editing of the issue description.
comment:137 Changed 10 years ago by
Francois, please could you try the new release candidate of GMP-ECM at http://www.loria.fr/~kruppaal/ecm-6.4.4-rc2.tar.gz? It includes the patch of this ticket.
Paul
comment:138 Changed 10 years ago by
Cc: | Jean-Pierre Flori added |
---|
comment:139 Changed 10 years ago by
I've tried to build Sage on another Power 7 running debian. This is a vanilla Sage 5.7 + ATLAS from #10508, I did not try to include any patch from here yet. No problem to build it. The log of "make ptestlong" is at http://boxen.math.washington.edu/home/jpflori/ptestlong-gcc110-power7-debian.log Ive not had a deep look but the failures look similar to what has been reported here.
comment:140 follow-up: 141 Changed 10 years ago by
You have more failures. In the tutorial translations curiously your gap install totally crashed. And the rings/arith.py failure is totally weird. I'll try to move to 5.8.beta to see if I can reproduce some of these. You don't have the failure in functions/special.py. I suspect gcc is involved. What gcc do you use?
comment:141 Changed 10 years ago by
Replying to fbissey:
I'll try to move to 5.8.beta to see if I can reproduce some of these.
Please note I used 5.7 (plus new ATLAS).
You don't have the failure in functions/special.py. I suspect gcc is involved. What gcc do you use?
Its
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
And as you can see its not Debian but Fedora...
comment:142 follow-up: 143 Changed 10 years ago by
OK, I think getting a new gcc on board may help. Of course you are using a gcc provided by red hat for ppc so there may be specific fixes in there. We know that some version of gcc were leading to breakage in ecl earlier on.
The next thing is that in some circumstances your GAP is breaking. If it was just plain broken there would be more test failures.
comment:143 Changed 10 years ago by
Replying to fbissey:
OK, I think getting a new gcc on board may help. Of course you are using a gcc provided by red hat for ppc so there may be specific fixes in there. We know that some version of gcc were leading to breakage in ecl earlier on.
You mean more recent that 4.7.2? That will be quite bleeding edge won't it?
The next thing is that in some circumstances your GAP is breaking. If it was just plain broken there would be more test failures.
Indeed, I can launch the built gap and compute 1+1
comment:145 Changed 10 years ago by
Same for all rst files except cvxopt.rst which still fails (prec problem which was already reported here on the Suse install).
optimize.py and libecm.py are still failing as expected.
special.py still does not fail.
comment:146 Changed 10 years ago by
I was going to ask you to re-test. Not reproducible, it may be a small problem with parrallel testing, possibly concurrent GAP sessions. Not sure for arith.py.
As for compiler I meant that I used 4.7.1 for my own build. You are using a recent so you could also have small bug fix in kernel or glibc that helps (on a not mainstream platform).
comment:147 Changed 10 years ago by
I tried 5.8.beta2 with gcc 4.7.2 and it is worse (no patch applied):
The following tests failed: sage -t -long -force_lib devel/sage-main/sage/groups/matrix_gps/matrix_group.py # Time out sage -t -long -force_lib devel/sage-main/sage/combinat/sf/k_dual.py # Time out sage -t -long -force_lib devel/sage-main/doc/en/numerical_sage/cvxopt.rst # 1 doctests failed sage -t -long -force_lib devel/sage-main/sage/libs/libecm.pyx # 7 doctests failed sage -t -long -force_lib devel/sage-main/sage/functions/special.py # 2 doctests failed sage -t -long -force_lib devel/sage-main/sage/numerical/optimize.py # 2 doctests failed
So I still get the special.py failure which means something esle fixed it for you (I suspect glibc/kernel). I also have two time out. I am doing a gcc 4.7.1 to see if they are compiler dependent.
comment:148 follow-up: 149 Changed 10 years ago by
I redid the build with gcc-4.7.1 and I am back with the same failures as before. It could also be that red hat has put some ppc64 specific fix in their gcc. Which exact version of fedora do you have?
comment:149 follow-up: 151 Changed 10 years ago by
Replying to fbissey:
I redid the build with gcc-4.7.1 and I am back with the same failures as before. It could also be that red hat has put some ppc64 specific fix in their gcc. Which exact version of fedora do you have?
That's gcc110 from http://gcc.gnu.org/wiki/CompileFarm It's stated its
name port disk CPU Notes gcc110 2TB 4x16x3.55 GHz IBM POWER7 / 64 GB RAM / IBM Power 730 Express server / Fedora 18 ppc64
From there I gathered
[jpflori@gcc1-power7 sage-5.7]$ uname -a Linux gcc1-power7.osuosl.org 3.7.2-204.fc18.ppc64 #1 SMP Fri Jan 18 10:44:51 MST 2013 ppc64 ppc64 ppc64 GNU/Linux [jpflori@gcc1-power7 sage-5.7]$ cat /etc/redhat-release Fedora release 18 (Spherical Cow) [jpflori@gcc1-power7 sage-5.7]$ gcc -v Utilisation des specs internes. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.7.2/lto-wrapper Target: ppc64-redhat-linux Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux Modèle de thread: posix gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) [jpflori@gcc1-power7 sage-5.7]$ yum list gcc Modules complémentaires chargés : auto-update-debuginfo, langpacks, presto, : refresh-packagekit Paquets installés gcc.ppc64 4.7.2-8.fc18 installed
comment:150 Changed 10 years ago by
comment:151 Changed 10 years ago by
Replying to jpflori:
Replying to fbissey:
I redid the build with gcc-4.7.1 and I am back with the same failures as before. It could also be that red hat has put some ppc64 specific fix in their gcc. Which exact version of fedora do you have?
That's gcc110 from http://gcc.gnu.org/wiki/CompileFarm It's stated its
name port disk CPU Notes gcc110 2TB 4x16x3.55 GHz IBM POWER7 / 64 GB RAM / IBM Power 730 Express server / Fedora 18 ppc64From there I gathered
[jpflori@gcc1-power7 sage-5.7]$ uname -a Linux gcc1-power7.osuosl.org 3.7.2-204.fc18.ppc64 #1 SMP Fri Jan 18 10:44:51 MST 2013 ppc64 ppc64 ppc64 GNU/Linux [jpflori@gcc1-power7 sage-5.7]$ cat /etc/redhat-release Fedora release 18 (Spherical Cow) [jpflori@gcc1-power7 sage-5.7]$ gcc -v Utilisation des specs internes. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.7.2/lto-wrapper Target: ppc64-redhat-linux Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux Modèle de thread: posix gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) [jpflori@gcc1-power7 sage-5.7]$ yum list gcc Modules complémentaires chargés : auto-update-debuginfo, langpacks, presto, : refresh-packagekit Paquets installés gcc.ppc64 4.7.2-8.fc18 installed
I really have to dig the patches from redhat. I have just done a build with gcc-4.8.0 vanilla and there is no changes.
comment:152 Changed 9 years ago by
Dependencies: | #12829, #12832, #14098 → #12829, #12832, #14098, #14151 |
---|
comment:153 Changed 9 years ago by
Description: | modified (diff) |
---|
comment:154 follow-up: 163 Changed 9 years ago by
I am planing to test the new e cm spkg ASAP but I am a bit buried into reporting at work. Upstream cvxopt provided me with a cvxopt 1.1.6beta to try to solve the issue. It is on my todo list as well. Finally from Jean-Pierre's test it look like the ecl/maxima problem is one last gcc issue on ppc. I heve to try patch from fedora to gcc to confirm this.
comment:156 Changed 9 years ago by
yes, the beta sent to m e by upstream seems to solve all the problems.
comment:157 Changed 9 years ago by
Description: | modified (diff) |
---|
The cvxopt spkg at #12832 needs review.
comment:158 Changed 9 years ago by
Description: | modified (diff) |
---|
comment:159 Changed 9 years ago by
Jeroen, which machine do you use to work on this ticket? Do I have access to it?
Paul
comment:161 follow-up: 164 Changed 9 years ago by
Is silius still running SLES11? If so which SP? It seems that Jean-Pierre had more luck with that last bug using fedora 18. So I am suspecting something in the toolchain - but it could be ld, glibc or even kernel stuff rather than just gcc.
comment:162 Changed 9 years ago by
According to /etc/issue
, it is SUSE Linux Enterprise Server 11 SP1
.
comment:163 Changed 9 years ago by
Replying to fbissey:
Finally from Jean-Pierre's test it look like the ecl/maxima problem is one last gcc issue on ppc. I heve to try patch from fedora to gcc to confirm this.
I suppose you are refering to the special.py
failure? Why do you think it is a GCC issue?
comment:164 follow-up: 166 Changed 9 years ago by
Replying to fbissey:
Is silius still running SLES11? If so which SP? It seems that Jean-Pierre had more luck with that last bug using fedora 18. So I am suspecting something in the toolchain - but it could be ld, glibc or even kernel stuff rather than just gcc.
If there is another machine on which special.py
works, then we can really investigate. jpflori: can you retest with the latest Sage beta? If everything works there, is there any chance I could get access to that machine?
comment:165 Changed 9 years ago by
Yes, this is the last failure we observe. It is related to maxima/ecl. I have no proof of it being caused by GCC. Just a hunch based on the fact that the first hurdle we had in the port was that maxima wouldn't build because the version of GCC used miscompiled ecl. Furthermore Jean-Pierre Flori reports that he doesn't observe the failure on fedora 18 whose toolchain is based on gcc-4.8.0.
My gut feeling is that an element of the toolchain is responsible.
comment:166 follow-up: 167 Changed 9 years ago by
Replying to jdemeyer:
Replying to fbissey:
Is silius still running SLES11? If so which SP? It seems that Jean-Pierre had more luck with that last bug using fedora 18. So I am suspecting something in the toolchain - but it could be ld, glibc or even kernel stuff rather than just gcc.
If there is another machine on which
special.py
works, then we can really investigate. jpflori: can you retest with the latest Sage beta? If everything works there, is there any chance I could get access to that machine?
I've just launched a build of 5.10.beta5 (not official, but at least there is the latest ATLAS there). And yes I guess you can access it, it's gcc110 on GCC Compile Farm.
comment:167 follow-up: 170 Changed 9 years ago by
comment:168 Changed 9 years ago by
Replying to fbissey:
Yes, this is the last failure we observe. It is related to maxima/ecl. I have no proof of it being caused by GCC. Just a hunch based on the fact that the first hurdle we had in the port was that maxima wouldn't build because the version of GCC used miscompiled ecl. Furthermore Jean-Pierre Flori reports that he doesn't observe the failure on fedora 18 whose toolchain is based on gcc-4.8.0.
My gut feeling is that an element of the toolchain is responsible.
Did you try to build ECL with -mcpu=power4
(as opposed to power7
, say)? (Maxima will pick up ECL's flags, too.)
Although both Maxima and ECL have meanwhile been upgraded at least once, I previously did have more luck with that. (I'm not entirely sure, but IIRC GCC 4.4.6 did successfully build ECL and Maxima even without that, and with much fewer doctest failures, and especially ;-) not in special.py
. Same with later GCC versions and -mcpu=power4
.)
Note that distros' GCCs generally use more generic target CPU types than a GCC you build natively.
comment:169 Changed 9 years ago by
Description: | modified (diff) |
---|
comment:170 Changed 9 years ago by
Replying to jdemeyer:
Replying to jpflori:
it's gcc110 on GCC Compile Farm.
And how should I access it?
Ask for an account foolowing the instructions there: http://gcc.gnu.org/wiki/CompileFarm saying you're working on (the GPL licensed) Sage. The guy in charge is quite reactive.
comment:171 follow-up: 172 Changed 9 years ago by
And with 5.10.beta5 "make ptestlong" finishes without any error on gcc110!
comment:172 Changed 9 years ago by
Replying to jpflori:
And with 5.10.beta5 "make ptestlong" finishes without any error on gcc110!
Haha, beta5...
What does
$ gcc -v -x c /dev/null -S -o /dev/null
give?
comment:173 Changed 9 years ago by
[jpflori@gcc1-power7 ~]$ sh -c "gcc -v -x c /dev/null -S -o /dev/null" Utilisation des specs internes. COLLECT_GCC=/usr/bin/gcc Target: ppc64-redhat-linux Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux Modèle de thread: posix gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) COLLECT_GCC_OPTIONS='-v' '-S' '-o' '/dev/null' /usr/libexec/gcc/ppc64-redhat-linux/4.7.2/cc1 -quiet -v -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix /dev/null -msecure-plt -quiet -dumpbase null -auxbase-strip /dev/null -version -o /dev/null GNU C (GCC) version 4.7.2 20121109 (Red Hat 4.7.2-8) (ppc64-redhat-linux) compiled by GNU C version 4.7.2 20121109 (Red Hat 4.7.2-8), GMP version 5.0.5, MPFR version 3.1.1, MPC version 0.9 heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 le répertoire « /usr/lib/gcc/ppc64-redhat-linux/4.7.2/include-fixed » est ignoré car inexistant le répertoire « /usr/lib/gcc/ppc64-redhat-linux/4.7.2/../../../../ppc64-redhat-linux/include » est ignoré car inexistant la recherche pour #include "..." débute ici : la recherche pour #include <...> débute ici: /usr/lib/gcc/ppc64-redhat-linux/4.7.2/include /usr/local/include /usr/include Fin de la liste de recherche. GNU C (GCC) version 4.7.2 20121109 (Red Hat 4.7.2-8) (ppc64-redhat-linux) compiled by GNU C version 4.7.2 20121109 (Red Hat 4.7.2-8), GMP version 5.0.5, MPFR version 3.1.1, MPC version 0.9 heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: cad711fd18d29c74d62d6fd41cd26eeb COMPILER_PATH=/usr/libexec/gcc/ppc64-redhat-linux/4.7.2/:/usr/libexec/gcc/ppc64-redhat-linux/4.7.2/:/usr/libexec/gcc/ppc64-redhat-linux/:/usr/lib/gcc/ppc64-redhat-linux/4.7.2/:/usr/lib/gcc/ppc64-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/ppc64-redhat-linux/4.7.2/:/usr/lib/gcc/ppc64-redhat-linux/4.7.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/ppc64-redhat-linux/4.7.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-S' '-o' '/dev/null'
comment:174 Changed 9 years ago by
Milestone: | sage-5.11 → sage-5.12 |
---|
comment:175 Changed 9 years ago by
Description: | modified (diff) |
---|
5.12.beta1 on SLES11SP1 with gcc 4.8.1 and binutils 2.22. Still problems in functions/special.py - there is one more failure there. I also got two timeout but I haven't checked yet increasing the time limit.
comment:176 Changed 9 years ago by
On gcc110, no problems at all with current git develop (6.1.beta2) :)
comment:177 Changed 9 years ago by
I spoke too fast, it seems it was with 6.0. I have problems with the ncurses ada bindings with 6.1 betas.
comment:178 Changed 9 years ago by
I'm getting noisy, in fact it was the converse, the problem was with 6.0, not 6.1 betas.
comment:179 Changed 9 years ago by
I still got the failures in special.py on sles11sp1. I have another amusing one that I can produce at will:
sage -t --long src/sage/tests/cmdline.py ********************************************************************** File "src/sage/tests/cmdline.py", line 467, in sage.tests.cmdline.test_executable Failed example: ret, err Expected: (0, '') Got: (1, 'Traceback (most recent call last):\n File "/hpc/scratch/frb15/sandbox/sage-6.1.beta3/src/bin/sage-dev", line 334, in <module>\n parser = parser_from_object(DEV)\n File "/hpc/scratch/frb15/sandbox/sage-6.1.beta3/src/bin/sage-dev", line 258, in parser_from_object\n parser = argparse.ArgumentParser(*args, **kwds)\n File "/hpc/scratch/frb15/sandbox/sage-6.1.beta3/local/lib/python/argparse.py", line 1600, in __init__\n help=_(\'show this help message and exit\'))\n File "/hpc/scratch/frb15/sandbox/sage-6.1.beta3/local/lib/python/argparse.py", line 1291, in add_argument\n self._get_formatter()._format_args(action, None)\n File "/hpc/scratch/frb15/sandbox/sage-6.1.beta3/local/lib/python/argparse.py", line 2314, in _get_formatter\n return self.formatter_class(prog=self.prog)\n File "/hpc/scratch/frb15/sandbox/sage-6.1.beta3/src/bin/sage-dev", line 37, in __init__\n width=DEV._sagedev._UI._get_dimensions()[1]-2, *args, **kwds)\n File "/hpc/scratch/frb15/sandbox/sage-6.1.beta3/local/lib/python2.7/site-packages/sage/dev/cmd_line_interface.py", line 264, in _get_dimensions\n fd = os.open(os.ctermid(), os.O_RDONLY)\nOSError: [Errno 6] No such device or address: \'/dev/tty\'\n') ********************************************************************** File "src/sage/tests/cmdline.py", line 474, in sage.tests.cmdline.test_executable Failed example: ('usage: sage-dev' in out) or ('Developer interface disabled' in out) Expected: True Got: False ********************************************************************** 1 item had failures: 2 of 210 in sage.tests.cmdline.test_executable [209 tests, 2 failures, 136.44 s]
For a little bit of background, I used a compute node to build/run the test suite. Which means that the testing was submitted as a batch job using loadleveler (a batch queue manager from IBM). loadleveler starts jobs without a tty which cause these errors. testing from the command line proper the failures just disappear.
comment:180 Changed 9 years ago by
Did someone try to build pillow (included in latest betas)? It seems to fail on gcc110 with ld yielding "escamotage incompatible" which is very nice french but not that easy to decipher without context. Anyway it seems there is some 32/64 bit issue here, and the corresponding english error message would be "skipping incompatible library" which is more talkative.
comment:181 Changed 9 years ago by
Usually because you try to link a 64 bit object with a 32bit library. Yes it probably find the wrong version of one of the libraries (ziplib, png, jpeg) the setup script is not very smart but I thought we had ourselves covered. Would you by any chance have some of the aforementioned libraries installed in 32bit but not 64?
comment:182 Changed 9 years ago by
I'll have a look. Sorry for the rough report, I basically just wanted to know if that also happened to someone else, so I did not investigate it yet.
comment:183 Changed 9 years ago by
I have 6.1 beta3 built here with pillow and without a hitch. I honestly don't think it is a power7 issue per see. setup.py is not very smart at detecting stuff so you have to consider all corners. I have been in the latest gentoo bug concerning building pillow as well as the pillow ticket here. This stuff is fragile.
comment:184 Changed 9 years ago by
Ok, the problem is simply with liblcms install on gcc110. For some reason there is no liblcms.so in /usr/lib64 (although different versions of 64-bit liblcms.so.* are available there), but one in /usr/lib pointing to a 32 bit version.
comment:185 Changed 9 years ago by
That probably mean that there is a 64bit dev rpm not installed. But that's what I suspected.
comment:186 Changed 9 years ago by
Milestone: | sage-6.1 → sage-6.2 |
---|
comment:187 Changed 8 years ago by
Status: | new → needs_review |
---|
So I finally pointed the finger to glibc/kernel headers. To build sage on SLES11SP1 and probably some other "enterprise distro" that are far behind in their toolchain stack on power7 I recommend IBM advance toolchain 7.0.3 and later. http://ibm.co/AdvanceToolchain It include its own glibc and that's the killer feature to get through the final issue I think. It is possible that gcc also includes a few IBM patches.
comment:189 Changed 8 years ago by
Milestone: | sage-6.2 → sage-6.3 |
---|
comment:190 Changed 8 years ago by
Milestone: | sage-6.3 → sage-6.4 |
---|
comment:191 Changed 8 years ago by
I still have no issue at all on a RedHad? POWER7. What about Suse? Should this be closed?
comment:192 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Reviewers: | → Jean-Pierre Flori, François Bissey |
Status: | needs_review → closed |
Yes.
I am actually in the process of commissioning such hardware and suse will be on some nodes (Aix 6.1 on the other nodes).