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