2011/11/9 Francois Bissey <francois.bis...@canterbury.ac.nz>: >> Em 9 de novembro de 2011 00:29, Paulo César Pereira de Andrade >> >> <paulo.cesar.pereira.de.andr...@gmail.com> escreveu: >> > 2011/11/8 Francois Bissey <francois.bis...@canterbury.ac.nz>: >> >>> 2011/11/8 Francois Bissey <francois.bis...@canterbury.ac.nz>: >> >>> >> >>> [...] >> >>> >> >>> > I don't get any of that. I suspect there may be an issue with >> >>> > gmp/mpir. But I have really no clue about the glibc problem, you are >> >>> > using mpmath-0.17 I expect. >> >>> >> >>> Yes, mpmath-0.17. >> >>> >> >>> This should be an issue with gmp / pylong / ntl conversions, in >> >>> >> >>> the sage/c_lib/src/*c or sage/c_lib/include/*.h >> >>> >> >>> Should be an off by one wordsize miscalculation of some buffer. >> >>> >> >>> I will try to debug some of it soon, but in the meantime, these may >> >>>ring >> >>> >> >>> some bell to somebody... >> >>> >> >>> Invalid write of size 8 >> >>> ==6304== at 0x1FCB67F8: ??? (in /usr/lib64/libgmp.so.10.0.2) >> >>> ==6304== by 0x1FCB7253: __gmpz_fac_ui (in >> >>> /usr/lib64/libgmp.so.10.0.2) ==6304== by 0x2728775F: ??? (in >> >>> /usr/lib64/python2.7/site-packages/sage/rings/integer.so) >> >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 >> >>> alloc'd >> >>> >> >>> ==6304== Invalid read of size 8 >> >>> ==6304== at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) >> >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 >> >>> alloc'd >> >>> >> >>> ==6304== Invalid read of size 8 >> >>> ==6304== at 0x1FA95871: mpn_get_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95D61: mpz_get_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in >> >>> /usr/lib64/libcsage.so) ==6304== Address 0x29c39df8 is 0 bytes after >> >>> a block of size 8 alloc'd >> >>> >> >>> ==6304== Invalid write of size 8 >> >>> ==6304== at 0x1FA95A74: mpn_set_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95E7B: mpz_set_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 >> >>> alloc'd >> >>> >> >>> ==6304== Invalid read of size 8 >> >>> ==6304== at 0x1FCC06AA: __gmpz_sizeinbase (in >> >>> /usr/lib64/libgmp.so.10.0.2) ==6304== Address 0x29c39df8 is 0 bytes >> >>> after a block of size 8 alloc'd >> >>> >> >>> .. >> >>> >> >>> Also miscalculation and warning because of reading non initialized >> >>>data >> >>> >> >>> ==6304== Conditional jump or move depends on uninitialised value(s) >> >>> ==6304== at 0x1FCB7EE3: __gmpz_fits_slong_p (in >> >>> /usr/lib64/libgmp.so.10.0.2) ==6304== by 0x1FA95DA5: >> >>> mpz_get_pyintlong (in /usr/lib64/libcsage.so) >> >>> >> >>> ==6304== Conditional jump or move depends on uninitialised value(s) >> >>> ==6304== at 0x1FA95689: ??? (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in >> >>> /usr/lib64/libcsage.so) >> >>> >> >>> ==6304== Use of uninitialised value of size 8 >> >>> ==6304== at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in >> >>> /usr/lib64/libcsage.so) >> >>> >> >>> And a lot of other warnings following this pattern. >> >>> >> >> Hi Paulo, >> >> >> >> with gmp5 I had to do the following for sage to even compile in >> >> sage/rings/integer.so precisely: >> >> sed -i "s:__GMP_BITS_PER_MP_LIMB:GMP_LIMB_BITS:g" >> >> sage/rings/integer.pyx >> >> >> >> Since that's a deprecation problem that will reach mpir eventually, we >> >> should >> >> open a ticket on trac even it is not your present problem. >> >> >> >> While I don't have a crash or any warnings I am wondering if it is >> >> related to http://trac.sagemath.org/sage_trac/ticket/11986 >> >> Since it seems that some stuff in pylong is not working as expected. >> >> Is it working on x86 but not on x86_64? >> > >> > For the record, do you not notice the warnings if running sage as >> > $ MALLOC_CHECK_=1 sage >> > >> > ? If I do not set MALLOC_CHECK_=1 I do not see any warnings, >> > and if setting to 2, useful in sage -gdb, I get it to call abort, what >> > is useful with "sage -gdb". >> >> I found a way to run it with exporting MALLOC_CHECK_=1 and >> not having any warnings printed. It appears to be an issue when >> python-gmpy is installed. >> >> If running something like: >> $ sudo rpm -e python-gmpy >> >> And then: >> >> $ sage -t -force_lib "devel/sage/sage/rings/integer.pyx" >> >> I see just: >> >> sage -t -force_lib "devel/sage/sage/rings/integer.pyx" >> ********************************************************************** >> File "/usr/share/sage/devel/sage/sage/rings/integer.pyx", line 4653: >> sage: numpy.array(2**40).dtype >> Expected: >> dtype('int64') >> Got: >> dtype('object') >> ********************************************************************** >> File "/usr/share/sage/devel/sage/sage/rings/integer.pyx", line 3046: >> sage: n = -920390823904823094890238490238484; n.__hash__() >> Expected: >> 6874330978542788722 >> Got: >> -2623069716 >> ********************************************************************** >> File "/usr/share/sage/devel/sage/sage/rings/integer.pyx", line 3061: >> sage: hash(n) >> Expected: >> -9223372036854767616 >> Got: >> 8192 >> ********************************************************************** >> File "/usr/share/sage/devel/sage/sage/rings/integer.pyx", line 3064: >> sage: hash(n) == hash(int(n)) >> Expected: >> True >> Got: >> False >> ********************************************************************** >> 2 items had failures: >> 1 of 9 in __main__.example_113 >> 3 of 13 in __main__.example_63 >> ***Test Failed*** 4 failures. >> For whitespace errors, see the file /home/pcpa/.sage//tmp/integer_17043.py >> [6.5 s] >> >> ---------------------------------------------------------------------- >> The following tests failed: >> >> >> sage -t -force_lib "devel/sage/sage/rings/integer.pyx" >> Total time for all tests: 6.5 seconds >> >> instead of 170k+ lines of glibc warning messages (but same doc test >> output). The warnings happens because I export MALLOC_CHECK_=1 >> in the /usr/bin/sage script. What was left from other debug sessions, but >> I thought would be better to run sage with some internal malloc checks, >> and left so... >> > Hi Paulo, > > So I guess gmpy and sage were in competition! You could try to set > MPMATH_NOGMPY before running sage. That may work and you could > add it to sage-env for Mandriva.
Already tried before sending previous email, but before looking a bit more in gpmy sources. I believe it is a side effect of gmpy also calling mp_set_memory_functions and sage doing some "short circuit" calls to update mpz fields, or something related to gmpy vs sage caches of mpz_t objects. Maybe setting MPMATH_NOGMPY is not enough to prevent it to call to gmpy "init" function that calls mp_set_memory_functions. I will try to debug a bit further, in the worst case, I can resubmit a sagemath package with "Conflicts: python-gmpy". I had it for a long time with "Conflicts: python-numpy" when using the patch to use sympy version of mpmath... With the conflicts rpm information, it asks the user for removal of the package unless using some "--force" like option (actually, usually --nodeps). > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
