Memleak when deleting elliptic curve over finite field ?

12 views
Skip to first unread message

Jean-Pierre Flori

unread,
Jun 8, 2011, 5:19:46 AM6/8/11
to sage-support
Dear all,

Using the following piece of code makes the memory footprint of sage
grow indefinitely:

sage: K = GF(1<<50,'t')
sage: j = K.random_element()
sage: while 1:
....: E = EllipticCurve(j=j)
....: del E
....:

This seems to be less dramatic with finite fields of char != 2 and
inexistant for ZZ and QQ.

Am I missing something here to get my memory back ?

Cheers,

Simon King

unread,
Jun 8, 2011, 8:13:25 AM6/8/11
to sage-support
On 8 Jun., 11:19, Jean-Pierre Flori <jpfl...@gmail.com> wrote:
> Using the following piece of code makes the memory footprint of sage
> grow indefinitely:

I just noticed that elliptic curves are instances of
sage.structure.parent.Parent, but violate the unique parent
assumption:

sage: K = GF(1<<50,'t')
sage: j = K.random_element()
sage: from sage.structure.parent import Parent
sage: isinstance(EllipticCurve(j=j),Parent)
True
sage: EllipticCurve(j=j) is EllipticCurve(j=j)
False
sage: EllipticCurve(j=j) == EllipticCurve(j=j)
True

Should that be fixed as well (in addition to the memory leak)?

Cheers,
Simon

Jean-Pierre Flori

unread,
Jun 13, 2011, 12:45:46 PM6/13/11
to sage-support
I created a ticket concerning the memleak:
http://trac.sagemath.org/sage_trac/ticket/11468
I did not have the time to find the origin of the problem.

Simon, I guess you could open another ticket with what you spotted.

Simon King

unread,
Jun 13, 2011, 3:31:45 PM6/13/11
to sage-support
Hi Jean-Pierre,

On 13 Jun., 18:45, Jean-Pierre Flori <jpfl...@gmail.com> wrote:
> I created a ticket concerning the memleak:http://trac.sagemath.org/sage_trac/ticket/11468
> I did not have the time to find the origin of the problem.
>
> Simon, I guess you could open another ticket with what you spotted.

You mean the non-uniqueness of elliptic curves? I'll first ask on sage-
nt whether the people using elliptic curves agree that they *should*
be unique parents.

Cheers,
Simon

Simon King

unread,
Jun 14, 2011, 2:44:48 AM6/14/11
to sage-support
On 13 Jun., 21:31, Simon King <simon.k...@uni-jena.de> wrote:
> Hi Jean-Pierre,
>
> > Simon, I guess you could open another ticket with what you spotted.

Since sage-nt seems to agree that it is a bug, I opened trac ticket
#11474.

Cheers,
Simon

Jean-Pierre Flori

unread,
Jun 14, 2011, 4:58:03 PM6/14/11
to sage-support

On 14 juin, 08:44, Simon King <simon.k...@uni-jena.de> wrote:
> Since sage-nt seems to agree that it is a bug, I opened trac ticket
> #11474.
Good !

About the original memleak, I tried looking at how
EllipticCurves_finite_field (maybe not correct name) are created but
could not find anything fishy, only Python code which should not
produce any memleak.
I also tried running sage under valgrind (using the new spkg available
on trac) but that was not more helpful.
So any help or advice, even completely trivial, to investigate this
would be welcome.

Cheers,
JP

Alastair Irving

unread,
Jun 15, 2011, 8:26:24 AM6/15/11
to sage-s...@googlegroups.com
On 14/06/2011 21:58, Jean-Pierre Flori wrote:
>
> On 14 juin, 08:44, Simon King<simon.k...@uni-jena.de> wrote:
>> Since sage-nt seems to agree that it is a bug, I opened trac ticket
>> #11474.
> Good !
>
> About the original memleak, I tried looking at how
> EllipticCurves_finite_field (maybe not correct name) are created but
> could not find anything fishy, only Python code which should not
> produce any memleak.

Hi

I think this is a problem with multivariate polynomials over finite
fields and is not specific to elliptic curves. The following code
produces a leak:

K=GF(2^50,"t")
R.<x,y>=PolynomialRing(K)
a=K.random_element()
while(1):
f=a*x
del f

When constructing an elliptic curve its equation is constructed in the
3-variable polynomial ring over K, and thus we will get this leak.

Best wishes

Alastair

Jean-Pierre Flori

unread,
Jun 15, 2011, 8:29:33 AM6/15/11
to sage-support
Thanks a lot, I'll have a look at that.

On 15 juin, 14:26, Alastair Irving <alastair.irv...@sjc.ox.ac.uk>
wrote:

Jean-Pierre Flori

unread,
Jun 15, 2011, 3:50:00 PM6/15/11
to sage-support
S the memleak seems to be located within creation or rather coercing
to MPolynomial_libsingular.
Calling gc.collect() whithin the loop seem to fix or are least
attenuate the problem.
However, calling afterwards does not free memory back.

Jean-Pierre Flori

unread,
Jun 15, 2011, 6:09:06 PM6/15/11
to sage-support
I finally found the memleak in different si2sa_* functions in
sage.libs.singular.singular and provided a fix on Trac.

Jean-Pierre Flori

unread,
Jun 15, 2011, 6:48:57 PM6/15/11
to sage-support
But theres another memleak in the roots method of polynomial_zzpex...

Jean-Pierre Flori

unread,
Jun 15, 2011, 7:18:28 PM6/15/11
to sage-support
Which seems to come from list() method.

On 16 juin, 00:09, Jean-Pierre Flori <jpfl...@gmail.com> wrote:

Jean-Pierre Flori

unread,
Jun 15, 2011, 8:07:40 PM6/15/11
to sage-support
and from ZZ_pE_c_to_list function

Jean-Pierre Flori

unread,
Jun 15, 2011, 8:46:20 PM6/15/11
to sage-support
Ok so the memleak comes from ZZ_pE_to_ZZ_pX in
c_lib/src/ntl_wrap.cpp
It should have been fixed by trac #1092, but has been reverted by
commit 8503.
I'll reopen #1092.

Jean-Pierre Flori

unread,
Jun 15, 2011, 8:51:54 PM6/15/11
to sage-support
this is now 11495

Jean-Pierre Flori

unread,
Jun 16, 2011, 11:13:58 AM6/16/11
to sage-support
The following piece of code also seems to leak memory.
The problem seems to occur while resolving the action of ZZ on E.

sage: K = GF(1<<55,'t')
sage: a = K.random_element()
sage: while 1:
....: E = EllipticCurve(j=a); P = E.random_point(); 2*P;

Jean-Pierre Flori

unread,
Jun 18, 2011, 9:36:52 AM6/18/11
to sage-support
This is now #11521.
Reply all
Reply to author
Forward
0 new messages