Opened 7 years ago
Last modified 6 years ago
#17494 new defect
Memory leak for letterplace implementation of free algebras
Reported by: | SimonKing | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-6.5 |
Component: | memleak | Keywords: | |
Cc: | malb | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | Fixed upstream, in a later stable release. | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
At #17435, I noticed the following:
sage: L.<x,y,z> = FreeAlgebra(GF(25,'t'), implementation='letterplace') sage: p = x^4+x*y*x*z+2*z^2*x*y sage: for i in range(20): ....: m = get_memory_usage() ....: for j in range(300): ....: z = p^7 ....: print get_memory_usage()-m ....: 2.0 2.0 2.0 2.0 0.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 0.0 2.0 2.0
This leak even pertains when #16958 is applied.
Change History (4)
comment:1 Changed 7 years ago by
- Report Upstream changed from Not yet reported upstream; Will do shortly. to Reported upstream. Developers acknowledge bug.
comment:2 Changed 7 years ago by
- Report Upstream changed from Reported upstream. Developers acknowledge bug. to Fixed upstream, in a later stable release.
If I understand correctly, the leak is fixed in a later version of singular. Hope it will be in Sage soon...
comment:3 follow-up: ↓ 4 Changed 6 years ago by
comment:4 in reply to: ↑ 3 Changed 6 years ago by
Replying to rws:
Maybe related: http://ask.sagemath.org/question/29444/high-memory-usage-when-substituting-variables/
I think that points to a more basic and hence more severe memory leak.
import gc, collections gc.collect() old=set( id(a) for a in gc.get_objects()) R.<x,y,z>=ZZ[] f=12^2*(x^4+y^4)-15^2*(x^2+y^2)*z^2+350*x^2*y^2+9^2*z^4 pt=[1,2,3] m=get_memory_usage() for i in xrange(10^5): temp=f(x=x+pt[0]*z,y=y+pt[1]*z,z=pt[2]*z) #This also uses a lot of memory. if (i% 100) == 0: print get_memory_usage()-m gc.collect() new=collections.Counter( str(type(a)) for a in gc.get_objects() if id(a) not in old) new
This code clearly shows leaking and it shows the leak is not in python reference counted objects. I would find it hard to believe that such a basic leak in normal polynomial arithmetic would go unnoticed in Singular, so I would expect the error is somewhere in the sage/singular interface.
Here is the corresponding computation in Singular (as shipped with Sage):
So, the leak is in Singular, not in the wrapper.