On Aug 28, 9:50 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 8/28/07, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote:
>
>
>
> > Dear William,
>
> > On Sun, 19 Aug 2007, William Stein wrote:
> > > On 8/19/07, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote:
> > > > > There was a huge bug-squashing day today with many people at over
> > > > > 30 SAGE bugs fixed. The most interesting one whose fix turns out
> > > > > to be pretty important was one you had reported:
> > > > > http://www.sagemath.org:9002/sage_trac/ticket/274
> > > > > So this will be fixed in sage-2.8.2.
>
> > > > That's great news. Now I can get back to some long runs of
> > > > SupersingularModule computation. Thanks!
>
> > > Unfortunately there might be other memory leaks or bugs. But if
> > > you find them, definitely report them, as they will get fixed soon.
>
> > The original code at
>
> >http://www.sagemath.org:9002/sage_trac/ticket/274
>
> > {{{
> > sage: get_memory_usage()
> > '276M'
> > sage: K = GF(10007^2, 'a')
> > sage: X = PolynomialRing(K, 'x').gen()
> > sage: for i in range(1000):
> > s = K.random_element(); t = K.random_element()
> > poly = s + t*X
> > ....:
> > sage: get_memory_usage()
> > '281M'
> > }}}
>
> > now only leaks about 0.1MB, but extending the for loop range from 10**3
> > to 10**5 leaks about 6.3MB!
>
> > Also the following code
>
> > {{{
> > def Supercomp():
> > p=ZZ(10**5).next_prime()
> > szfilename = "timings100k.txt"
> > mem_szfilename = "memory100k.txt"
> > while true:
> > t = cputime()
> > M = get_memory_usage()
> > X = SupersingularModule(p)
> > X.hecke_matrix(2)
> > f = open(szfilename, 'a')
> > f.write(str([p, cputime(t)]) + ", ")
> > f.close()
> > g = open(mem_szfilename, 'a')
> > g.write(str([p, get_memory_usage()-M]) + ", ")
> > g.close()
> > X.save('X' + str(p))
> > p = ZZ(p).next_prime()
>
> > Supercomp()
> > }}}
>
> > had consumed 20% of memory on sage.math after a day of computation and I
> > had to kill it.
>
> > ===
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 24320 burhanud 39 19 12.2g 11g 15m R 100 18.9 1453:36 sage-ipython
> > ===
>
> > I'll have to spend some time to pin down where the leaks are.
>
> Thanks, Ifti. I've made this trac #501:
>
> http://trac.sagemath.org/sage_trac/ticket/501
>
> > Regards,
> > Ifti
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://www.williamstein.org
Okay, while Sage 2.8.3alpha2 fixed ticket #505 (destroyAllCodes() not
being called on exit in the m4ri code), there is still a huge problem
in the ntl wrapper:
==22784== 791,674 bytes in 65,421 blocks are definitely lost in loss
record 2,472 of 2,481
==22784== at 0x4A05CB9: operator new[](unsigned long)
(vg_replace_malloc.c:199)
==22784== by 0x9280247: ZZ_pX_repr (in /tmp/Work2/sage-2.8.3.alpha2/
local/lib/libcsage.so.0.0.0)
==22784== by 0x176D6D57: __pyx_f_3ntl_9ntl_ZZ_pX___repr__ (ntl.c:
6216)
==22784== by 0x443C61: _PyObject_Str (object.c:406)
==22784== by 0x443D0A: PyObject_Str (object.c:426)
==22784== by 0x44EA8F: string_new (stringobject.c:3892)
==22784== by 0x45A272: type_call (typeobject.c:422)
==22784== by 0x4156A2: PyObject_Call (abstract.c:1860)
==22784== by 0x480783: PyEval_EvalFrameEx (ceval.c:3775)
==22784== by 0x485025: PyEval_EvalFrameEx (ceval.c:3650)
==22784== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831)
==22784== by 0x4CFF37: function_call (funcobject.c:517)
William did suggest a fix but he either didn't code it up and merge it
or it somehow got lost. We should open an individual ticket for that
one because it just bleeds RAM like a stuck pig.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
