#5949: memory leak when deleting polynomial rings involving libSingular
------------------------+---------------------------------------------------
Reporter: mabshoff | Owner: mabshoff
Type: defect | Status: new
Priority: major | Milestone: sage-4.7.1
Component: memleak | Keywords:
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies:
------------------------+---------------------------------------------------
Description changed by jpflori:
Old description:
> The following code consumes inordinate amounts of memory while Magma can
> do it with 14 MB :)
> {{{
> p=30
>
> def FindGroupOrder(p,s):
> K = GF(p)
> v = K(4*s)
> u = K(s**2-5)
> x = u**3
> b = 4*x*v
> a = (v-u)**3*(3*u+v)
> A = a/b-2
> x = x/v**3
> b = x**3 + A*x**2 + x
> E = EllipticCurve(K,[0,b*A,0,b**2,0])
> return factor(E.cardinality())
>
> while p<134217689:
> p=next_prime(p)
> g=FindGroupOrder(p,11)
> print g
> }}}
>
> Valgrind pretty much points at libSingular (This was for running up to
> 2^12 or so):
> {{{
> ==26879== 2,109,920 bytes in 469 blocks are possibly lost in loss record
> 14,860 of 14,862
> ==26879== at 0x4C22FEB: malloc (vg_replace_malloc.c:207)
> ==26879== by 0x1F1D0B3F: omAllocFromSystem (omAllocSystem.c:186)
> ==26879== by 0x1F1D0CC1: omAllocLarge (omAllocSystem.c:41)
> ==26879== by 0x1F0A0C2A: npInitChar(int, sip_sring*) (omalloc.h:2354)
> ==26879== by 0x1F0B817A: nInitChar(sip_sring*) (numbers.cc:506)
> ==26879== by 0x1F0C7197: rComplete(sip_sring*, int) (ring.cc:2922)
> ==26879== by 0x1ECBD1C7:
> __pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_27MPolynomialRing_libsingular___init__(_object*,
> _object*, _object*) (multi_polynomial_libsingular.cpp:4995)
> ==26879== by 0x45C040: type_call (typeobject.c:436)
> ==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
> ==26879== by 0x485809: PyEval_EvalFrameEx (ceval.c:3784)
> ==26879== by 0x488296: PyEval_EvalFrameEx (ceval.c:3659)
> ==26879== by 0x489A95: PyEval_EvalCodeEx (ceval.c:2836)
> ==26879== by 0x487704: PyEval_EvalFrameEx (ceval.c:3669)
> ==26879== by 0x488296: PyEval_EvalFrameEx (ceval.c:3659)
> ==26879== by 0x489A95: PyEval_EvalCodeEx (ceval.c:2836)
> ==26879== by 0x4D40D7: function_call (funcobject.c:517)
> ==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
> ==26879== by 0x41E6CE: instancemethod_call (classobject.c:2519)
> ==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
> ==26879== by 0x485809: PyEval_EvalFrameEx (ceval.c:3784)
> ==26879== by 0x489A95: PyEval_EvalCodeEx (ceval.c:2836)
> ==26879== by 0x4D40D7: function_call (funcobject.c:517)
> ==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
> ==26879== by 0x41E6CE: instancemethod_call (classobject.c:2519)
> ==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
> }}}
> The above leak gets larger and larger depending on how I pick the upper
> bound.
>
> This translates to rings/polynomial/multi_polynomial_libsingular.pyx
> +359, more specifically the rComplete() line in
> {{{
> self._ring.order[nblcks] = ringorder_C
>
> rComplete(self._ring, 1)
> self._ring.ShortOut = 0
> }}}
> From src/kernel/ring.h:
> {{{
> // this needs to be called whenever a new ring is created: new fields
> // in ring are created (like VarOffset), unless they already exist
> // with force == 1, new fields are _always_ created (overwritten),
> // even if they exist
> BOOLEAN rComplete(ring r, int force = 0);
> }}}
> Changing rComplete() to use 0 instead of 1 does not fix the problem.
>
> Cheers,
>
> Michael
New description:
Memory is leaked when polynomial rings involving libSingular are deleted:
{{{
while 1:
p = random_prime(1<<50)
R.<x,y> = PolynomialRing(GF(p))
}}}
Valgrind pretty much points at libSingular:^^
{{{
==26879== 2,109,920 bytes in 469 blocks are possibly lost in loss record
14,860 of 14,862
==26879== at 0x4C22FEB: malloc (vg_replace_malloc.c:207)
==26879== by 0x1F1D0B3F: omAllocFromSystem (omAllocSystem.c:186)
==26879== by 0x1F1D0CC1: omAllocLarge (omAllocSystem.c:41)
==26879== by 0x1F0A0C2A: npInitChar(int, sip_sring*) (omalloc.h:2354)
==26879== by 0x1F0B817A: nInitChar(sip_sring*) (numbers.cc:506)
==26879== by 0x1F0C7197: rComplete(sip_sring*, int) (ring.cc:2922)
==26879== by 0x1ECBD1C7:
__pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_27MPolynomialRing_libsingular___init__(_object*,
_object*, _object*) (multi_polynomial_libsingular.cpp:4995)
==26879== by 0x45C040: type_call (typeobject.c:436)
==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
==26879== by 0x485809: PyEval_EvalFrameEx (ceval.c:3784)
==26879== by 0x488296: PyEval_EvalFrameEx (ceval.c:3659)
==26879== by 0x489A95: PyEval_EvalCodeEx (ceval.c:2836)
==26879== by 0x487704: PyEval_EvalFrameEx (ceval.c:3669)
==26879== by 0x488296: PyEval_EvalFrameEx (ceval.c:3659)
==26879== by 0x489A95: PyEval_EvalCodeEx (ceval.c:2836)
==26879== by 0x4D40D7: function_call (funcobject.c:517)
==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
==26879== by 0x41E6CE: instancemethod_call (classobject.c:2519)
==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
==26879== by 0x485809: PyEval_EvalFrameEx (ceval.c:3784)
==26879== by 0x489A95: PyEval_EvalCodeEx (ceval.c:2836)
==26879== by 0x4D40D7: function_call (funcobject.c:517)
==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
==26879== by 0x41E6CE: instancemethod_call (classobject.c:2519)
==26879== by 0x417E92: PyObject_Call (abstract.c:1861)
}}}
This translates to rings/polynomial/multi_polynomial_libsingular.pyx +359,
more specifically the rComplete() line in
{{{
self._ring.order[nblcks] = ringorder_C
rComplete(self._ring, 1)
self._ring.ShortOut = 0
}}}
From src/kernel/ring.h:
{{{
// this needs to be called whenever a new ring is created: new fields
// in ring are created (like VarOffset), unless they already exist
// with force == 1, new fields are _always_ created (overwritten),
// even if they exist
BOOLEAN rComplete(ring r, int force = 0);
}}}
Changing rComplete() to use 0 instead of 1 does not fix the problem.
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5949#comment:5>
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.
