#13731: Fix libsingular memory management
-----------------------+----------------------------------------------------
Reporter: nbruin | Owner: rlm
Type: defect | Status: new
Priority: major | Milestone: sage-5.6
Component: memleak | Keywords:
Work issues: | Report Upstream: N/A
Reviewers: | Authors:
Merged in: | Dependencies:
Stopgaps: |
-----------------------+----------------------------------------------------
We have several indications that interaction with libsingular's memory
management is tricky. Debugging is hard, because libsingular uses omalloc
for its memory management and that hides all allocation/deallocation from
conventional memory checking tools. Singular's allocation library is
relatively pluggable, though, and (at a speed penalty) one can mostly
switch it to using the system malloc for everything. Example spkgs for
that are
[http://sage.math.washington.edu/home/nbruin/singular-3-1-5.malloc-
linux.spkg] (for linux)
[http://sage.math.washington.edu/home/nbruin/singular-3-1-5.malloc.spkg]
(for OSX)
'''WARNING:''' I don't think these packages produce a viable singular
executable, so save your original one. The singular library seems to be
fine, though. Only install these on a dedicated debugging install!
Anyway, with this singular on linux:
{{{
$ export MALLOC_CHECK_ 3
$ sage
...
sage: A.<x,y> = FreeAlgebra(QQ, 2)
sage: P.<x,y> = A.g_algebra({y*x:-x*y})
sage: x*y
*** glibc detected *** /usr/local/sage/5.5b1/local/bin/python: free():
}}}
gdb backtrace:
{{{
#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 it in valgrind gets you complaints about the same locations.
There's a slim chance this error is an artifact of the way libsingular-
malloc is constructed, but I think that's unlikely. I think it's more
likely this is a reliable way of detecting the same issues that are
haunting us intermittently on various architectures.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13731>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
