Opened 8 years ago

Last modified 8 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.

**Note:**See TracTickets for help on using tickets.