Opened 7 years ago

Last modified 7 years ago

#13731 closed defect

Fix libsingular memory management — at Initial Version

Reported by: nbruin Owned by: rlm
Priority: major Milestone: sage-5.6
Component: memleak Keywords:
Cc: SimonKing, fbissey, malb Merged in:
Authors: Reviewers:
Report Upstream: Fixed upstream, in a later stable release. Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

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.

Change History (0)

Note: See TracTickets for help on using tickets.