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". 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
