#9129: sqrt memory leaks
--------------------------------+-------------------------------------------
Reporter: zimmerma | Owner: AlexGhitza
Type: defect | Status: new
Priority: critical | Milestone: sage-4.5.2
Component: basic arithmetic | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
--------------------------------+-------------------------------------------
Changes (by rlm):
* cc: malb, craigcitro (added)
Comment:
Replying to [comment:9 zimmerma]:
> those lines seem to indicate the problem lies in the Singular and/or
GINAC interface.
I'm not so sure about this. Let's pick on this particular leak:
{{{
==25238== 5,320 (1,680 direct, 3,640 indirect) bytes in 35 blocks are
definitely lost in loss record 17,325 of 18,340
==25238== at 0x4C22FEB: malloc (vg_replace_malloc.c:207)
==25238== by 0x13642E4C: __pyx_f_4sage_5rings_7integer_fast_tp_new
(integer.c:29882)
==25238== by 0x4EC2232: type_call (typeobject.c:731)
==25238== by 0x4E6CC77: PyObject_Call (abstract.c:2492)
==25238== by 0x218F6E2B:
__pyx_f_4sage_4libs_8singular_8singular_si2sa_ZZ(snumber*, sip_sring*)
(singular.cpp:3084)
==25238== by 0x21902F6D:
__pyx_f_4sage_4libs_8singular_8singular_si2sa(snumber*, sip_sring*,
_object*) (singular.cpp:5483)
==25238== by 0x2084D51E:
__pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular_coefficients(_object*,
_object*) (multi_polynomial_libsingular.cpp:27385)
==25238== by 0x4E6CC77: PyObject_Call (abstract.c:2492)
==25238== by 0x20858DB0:
__pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular_gcd(_object*,
_object*, _object*) (multi_polynomial_libsingular.cpp:24344)
==25238== by 0x4E6CC77: PyObject_Call (abstract.c:2492)
==25238== by 0x4F01D15: PyEval_CallObjectWithKeywords (ceval.c:3575)
==25238== by 0x4E87C25: methoddescr_call (descrobject.c:246)
==25238== by 0x4E6CC77: PyObject_Call (abstract.c:2492)
==25238== by 0x4F01D15: PyEval_CallObjectWithKeywords (ceval.c:3575)
==25238== by 0xF9E2BB9: __Pyx_PyEval_CallObjectWithKeywords
(element.c:26384)
==25238== by 0xF9D7B3C:
__pyx_pf_4sage_9structure_7element_16NamedBinopMethod___call__
(element.c:19673)
==25238== by 0x4E6CC77: PyObject_Call (abstract.c:2492)
==25238== by 0x15AF691C:
__pyx_f_4sage_5rings_22fraction_field_element_20FractionFieldElement__add_
(fraction_field_element.c:5090)
==25238== by 0xF9BE0A1:
__pyx_pf_4sage_9structure_7element_11RingElement___add__ (element.c:10804)
==25238== by 0x4E6CF6D: binary_op1 (abstract.c:917)
==25238== by 0x4E6D41F: PyNumber_Add (abstract.c:1157)
==25238== by 0x4F0611A: PyEval_EvalFrameEx (ceval.c:1189)
==25238== by 0x4F0A1C0: PyEval_EvalCodeEx (ceval.c:2968)
==25238== by 0x4F0A291: PyEval_EvalCode (ceval.c:522)
==25238== by 0x4F1E371: PyImport_ExecCodeModuleEx (import.c:675)
}}}
On line 3842 of `multi_polynomial_libsingular.pyx`, we have:
{{{
if _ring.ringtype != 0:
if _ring.ringtype == 4:
P = self._parent.change_ring(RationalField())
res = P(self).gcd(P(right))
coef = sage.rings.integer.GCD_list(self.coefficients() +
right.coefficients()) <--------------------
return self._parent(coef*res)
}}}
The calls to `.coefficients()` are creating the integers which are not
freed. Here is the definition of that function:
{{{
cdef poly *p
cdef ring *r
r = (<MPolynomialRing_libsingular>self._parent)._ring
if r!=currRing: rChangeCurrRing(r)
base = (<MPolynomialRing_libsingular>self._parent)._base
p = self._poly
coeffs = list()
while p:
coeffs.append(si2sa(p_GetCoeff(p, r), r, base))
p = pNext(p)
return coeffs
}}}
Looks innocent enough... `si2sa` ends up calling:
{{{
cdef Integer si2sa_ZZ(number *n, ring *_ring):
...
cdef Integer z
z = Integer()
z.set_from_mpz(<__mpz_struct*>n)
return z
}}}
I really don't see where any of this could be going wrong. I think it has
to do with the fast integer creation functions. Sage has a pool of
allocated Integer objects. The `integer_pool_count` seems to go up and
down randomly, staying in the low range. From one loop to the next, in the
original poster's first example, it goes 9, 8, 11, 10, ...
I think that the experts for this memory pool need to step up to the
plate...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9129#comment:10>
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.
