This is probably a good one for Simon King to look into:
sage-5.5beta1, with gc.collect() inserted in local/bin/
sagedoctest.py:run_one_example
Furthermore, modified singular to use system malloc:
http://sage.math.washington.edu/home/nbruin/singular-3-1-5.malloc-linux.spkg
[Note: this is a very untidy spkg. As far as I can tell it produces an
invalid Singular executable, so save your original one before
installing this package. Furthermore, it needs local/include/omalloc/
omMalloc.h for extensions to rebuild properly. You can copy this over
from the spkg once it's configured.]
and done an
export MALLOC_CHECK_ 3
Then with
./sage -t --gdb devel/sage/sage/libs/singular/function.pyx
I get
*** glibc detected *** /usr/local/sage/5.5b1/local/bin/python: free():
invalid pointer: 0x00000000028cf7c0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x31cfe7da76]
/usr/local/sage/5.5b1/local/lib/
libsingular.so(_Z14gnc_mm_Mult_nnPiS_P9sip_sring+0x294)
[0x7fffd82d5c34]
/usr/local/sage/5.5b1/local/lib/
libsingular.so(_Z20gnc_p_Mult_mm_CommonP8spolyrecS0_iP9sip_sring+0x1fc)
[0x7fffd82d6abc]
/usr/local/sage/5.5b1/local/lib/python/site-packages/sage/libs/
singular/polynomial.so(+0x4860)[0x7fffd76c7860]
/usr/local/sage/5.5b1/local/lib/python/site-packages/sage/rings/
polynomial/plural.so(+0x1f6f8)[0x7fffd7b096f8]
/usr/local/sage/5.5b1/local/lib/python/site-packages/sage/structure/
element.so(+0x29ea9)[0x7fffe971fea9]
/usr/local/sage/5.5b1/local/lib/libpython2.7.so.1.0(+0x4635f)
[0x7ffff7c6a35f]
/usr/local/sage/5.5b1/local/lib/libpython2.7.so.1.0(PyNumber_Multiply
+0x28)[0x7ffff7c6d2a8]
The gdb bt gives:
#0 0x00000031cfe36285 in raise () from /lib64/libc.so.6
#1 0x00000031cfe37b9b in abort () from /lib64/libc.so.6
#2 0x00000031cfe7774e in __libc_message () from /lib64/libc.so.6
#3 0x00000031cfe7da76 in malloc_printerr () from /lib64/libc.so.6
#4 0x00007fffd82d5c34 in gnc_mm_Mult_nn (F0=<optimized out>,
G0=<optimized out>, r=0x2faa720) at gring.cc:507
#5 0x00007fffd82d6abc in gnc_p_Mult_mm_Common (p=0x326e8c0,
m=<optimized out>, side=0, r=0x2faa720) at gring.cc:424
#6 0x00007fffd76c7860 in nc_mm_Mult_pp (p=0x342aaf0, r=0x2faa720,
m=0x2fb6530) at /usr/local/sage/5.5b1/local/include/singular/gring.h:
171
#7 pp_Mult_qq (r=0x2faa720, q=0x342aaf0, p=0x2fb6530) at /usr/local/
sage/5.5b1/local/include/singular/pInline2.h:667
#8 __pyx_f_4sage_4libs_8singular_10polynomial_singular_polynomial_mul
(__pyx_v_ret=0x7fffffffb3c8, __pyx_v_p=0x2fb6530, __pyx_v_q=0x342aaf0,
__pyx_v_r=0x2faa720)
at sage/libs/singular/polynomial.cpp:3895
#9 0x00007fffd7b096f8 in
__pyx_f_4sage_5rings_10polynomial_6plural_19NCPolynomial_plural__mul_
(__pyx_v_left=0x7fffbe6bd758, __pyx_v_right=0x7fffbe6bd878,
__pyx_skip_dispatch=<optimized out>)
at sage/rings/polynomial/plural.cpp:12060
Running the same thing in valgrind also points to mm_Mult_nn doing bad
things:
==20553== Invalid read of size 8
==20553== at 0x2694CB7C: gnc_mm_Mult_nn(int*, int*, sip_sring*)
(gring.cc:503)
==20553== by 0x2694DABB: gnc_p_Mult_mm_Common(spolyrec*, spolyrec*,
int, sip_sring*) (gring.cc:424)
==20553== by 0x269C7726: p_Power(spolyrec*, int, sip_sring*)
(gring.h:181)
...
==20553== Address 0x40c39c48 is 8 bytes inside a block of size 12
alloc'd
==20553== at 0x4A0762F: malloc (vg_replace_malloc.c:270)
==20553== by 0x26BADA45: omEmulateAlloc0 (omAllocEmulate.c:15)
==20553== by 0x2694C9EE: gnc_mm_Mult_nn(int*, int*, sip_sring*)
(gring.cc:472)
==20553== by 0x2694DABB: gnc_p_Mult_mm_Common(spolyrec*, spolyrec*,
int, sip_sring*) (gring.cc:424)
==20553== by 0x269C7726: p_Power(spolyrec*, int, sip_sring*)
(gring.h:181)
After all these modification one is of course tempted to blame the
maimed libsingular. However, a *lot* of tests run successfully with
the modifications, so I think this may be indicative of an actual
problem, see also
http://trac.sagemath.org/sage_trac/ticket/13447
Should this be on a trac ticket?