Opened 12 years ago

Last modified 7 years ago

#5949 new defect

memory leak when deleting polynomial rings involving libSingular

Reported by: mabshoff Owned by: mabshoff
Priority: major Milestone: sage-6.4
Component: memleak Keywords:
Cc: robertwb, malb, jpflori Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by jpflori)

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.

Change History (11)

comment:1 Changed 12 years ago by AlexGhitza

  • Summary changed from memory leak expose by elliptic curve code to memory leak exposed by elliptic curve code

comment:2 Changed 12 years ago by was

  • Priority changed from blocker to critical

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.

comment:3 Changed 10 years ago by jdemeyer

  • Priority changed from critical to major
  • Report Upstream set to N/A

Confirmed on sage-4.6.1.alpha1

comment:4 Changed 10 years ago by jpflori

  • Cc jpflori added

comment:5 Changed 10 years ago by jpflori

  • Description modified (diff)
  • Summary changed from memory leak exposed by elliptic curve code to memory leak when deleting polynomial rings involving libSingular

comment:6 Changed 10 years ago by malb

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.

comment:7 Changed 10 years ago by jpflori

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

See #5970

There is however memleaks involved.

comment:8 Changed 8 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:9 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:10 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:11 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4
Note: See TracTickets for help on using tickets.