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

[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?

Dear Nils,

On 2012-11-17, Nils Bruin <nbr...@sfu.ca> wrote:

Not before Monday (have a grant application to finish...)

I think it should be on a Sage trac ticket even if it should be the case
that ultimately it is an upstream bug. The question is whether it should
be on a *new* ticket (cc me, please!) or on #13477. Do you say that
the memory corruption occurs in a garbage collection? Then I guess it
better belong to #13477.

Cheers,
Simon

On Nov 16, 10:57 pm, Simon King <simon.k...@uni-jena.de> wrote:

I don't think it's upstream. I think it's a bad interaction between
how we (fail to) properly refcount singular objects and how it is
expected by the library. My main issue is that the behaviour I noticed
is under rather strained and unusual circumstances. It's just that I
think it's a reproducible symptom of a real problem.

The error traceback does not have a gc_collect in it. However, it's
likely that the damage is done due to a premature free in a garbage
collection. That or an argument gets passed to a Singular routine that
find a refcount that it deems low enough that the thing should be
collected.

Good luck with the grant proposal!

On Nov 16, 7:05 pm, Nils Bruin <nbr...@sfu.ca> wrote:

Interestingly, when running this with ElectricFence using

$ export LD_PRELOAD=libefence.so
$ export EF_ALLOW_MALLOC_0=1     #apparently sage/python does a
malloc(0) somewhere
$ echo 512000 | sudo tee /proc/sys/vm/max_map_count #efence uses
mprotect A LOT

I get a segfault, but it happens elsewhere:

#0  0x00007fffce9fb3f2 in List<CanonicalForm>::isEmpty
(this=0x7fffa515b000) at ./templates/ftmpl_list.cc:256
#1  0x00007fffce96a350 in multiFactorize (F=..., v=...) at
facFactorize.cc:710
#2  0x00007fffce905e9d in ratSqrfFactorize (v=..., G=...) at
facFactorize.h:45
#3  ratFactorize (G=..., v=..., substCheck=<optimized out>) at
facFactorize.h:125
#4  0x00007fffce90303c in factorize (f=..., issqrfree=false) at
cf_factor.cc:651
#5  0x00007fffce7a5b44 in singclap_factorize (f=0x7fff9e16dfd0,
v=0x7fffffffb548, with_exps=0) at clapsing.cc:835
#6  0x00007fffce720d50 in jjFAC_P (res=0x7fff9e16ffc0,
u=0x7fff9ea7afc0) at iparith.cc:3995
#7  0x00007fffce729c42 in iiExprArith1 (res=0x7fff9e16ffc0,
a=0x7fff9ea7afc0, op=424) at iparith.cc:7869
#8  0x00007fffce12df55 in
__pyx_f_4sage_4libs_8singular_8function_17KernelCallHandler_handle_call
(__pyx_v_self=0x7fff9e967b48,
    __pyx_v_argument_list=0x7fff9e975b40,
__pyx_optional_args=<optimized out>) at sage/libs/singular/
function.cpp:11286

This is with libsingular-malloc (of course). Reading the
documentation, Electric Fence seems to do about the same thing as
gmalloc. So it should catch the first access-after-free, for instance.
Things run *very* slowly with it (slower than valgrind I think).

For debugging, the behaviour already occurs with:

    sage: A.<x,y> = FreeAlgebra(QQ, 2)
    sage: P.<x,y> = A.g_algebra({y*x:-x*y})
    sage: x*y

if you set `MALLOC_CHECK_ 3` and use singular-malloc. So I'd be
surprised if python's gc comes into play here. I think it might be a
pure mismatch in refcount interpretation in (our use of) libsingular.

ElectricFence doesn't trip on this one. That's a different issue.

These issues are now trac-ed at
http://trac.sagemath.org/sage_trac/ticket/13731
Feel free to reformat/redistribute that data.

It would be very welcome if someone would clean up the libsingular-
malloc package so that it can be used more cleanly. I don't have the
packaging skill to do that, but I did do the work already to put in
the required extra declarations to make omalloc's "emulate" mode work
with modern singular again.