I agree that this is a bug. I do not think it is the same issue as the leak you reported involving elliptic curves. The reason I don't think so is that it is possible to compute class numbers with no memory leak using the PARI getno function in either cypari or cypari 2. There are many things that can cause the PARI heap to grow (and it happens in cypari2 with just ordinary vectors and matrices as discussed in cypari2 issue #112). One major cause of PARI heap GENs not getting freed is that those GENs are managed by Python Gen objects which are not being deallocated due to references being held by other Python objects. When a Python Gen is dealloc'ed it should free the PARI GEN which is it managing if that GEN is on the PARI heap. That was not happening with the t_VEC GEN describiing an elliptic curve, even though the Gen object was calling the PARI gunclone function because the gunclone function was not freeing the "lazy" components of that vector. (That has been fixed in cypari.)
I think something else is causing Sage NumberField objects to leak memory (i.e. to not be deallocated) in your example. The fact that both issues involve growth of the PARI heap does not mean that both issues have the same cause. The statement that they "probably" have the same cause is not supported by any evidence and I do not believe that they do have the same cause. - Marc On Friday, September 6, 2024 at 3:26:55 AM UTC-6 Georgi Guninski wrote: > This is not complaint, it is an observation about bug of type memory leak. > To leak about one GB, run the testcase `leaknf5` from the top of the > thread with argument N=3*10^4: > > #3*10^4 leaks: 1084.55 MB in 1m35.208s > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/aeb951f9-ba91-4d91-bbb3-2b259a0ff701n%40googlegroups.com.
