memory leak when deleting polynomial rings involving libSingular

[85eec1a4-3d04-4b4d-b711-d4db03337c41]

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.

CC: @robertwb @malb @jpflori

Component: memleak

Issue created by migration from https://trac.sagemath.org/ticket/5949

[aghitza]

comment:1

See also the discussion thread at http://groups.google.com/group/sage-support/t/ef01dae47c835137 .

[williamstein]

comment:2

If we've released for 2 months without fixing this, it doesn't make sense to keep it as a blocker. Note that the lisp interface is in fact 100% completely broken right now.

[jdemeyer]

comment:3

Confirmed on sage-4.6.1.alpha1

[jpflori]

Description changed:

--- 
+++ 
@@ -1,28 +1,12 @@
-The following code consumes inordinate amounts of memory while Magma can do it with 14 MB :)
+Memory is leaked when polynomial rings involving libSingular are deleted:

-p=30 +while 1:

• p = random_prime(1<<50)

• R.<x,y> = PolynomialRing(GF(p))

• def FindGroupOrder(p,s):

• K = GF(p)

• v = K(4*s)

• u = K(s**2-5)

• x = u**3

• b = 4xv

• a = (v-u)*3(3*u+v)

• A = a/b-2

• x = x/v**3

• b = x*3 + Ax**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): +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
  @@ -52,9 +36,7 @@
  ==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 +This translates to rings/polynomial/multi_polynomial_libsingular.pyx +359, more specifically the rComplete() line in

       self._ring.order[nblcks] = ringorder_C
  @@ -72,7 +54,3 @@
  BOOLEAN rComplete(ring r, int force = 0); 

  Changing rComplete() to use 0 instead of 1 does not fix the problem.

• -Cheers,

• -Michael

[malb]

comment:6

Just to confirm it is not an upstream bug:

while (1) { def p = prime(random(2,2^30)); ring r = p,(x,y),dp; };

does not seem to leak memory as we do.

[jpflori]

comment:7

I guess one of the problems here is that polynomial rings are cached.

See #5970

There is however memleaks involved.