My experiments with cypari so far indicate the opposite of what I
expected. (This is with one small but significant bug fix that I found
along the way.) The main observations are:
(1) Without the call to pari.ellrootno there is no memory leak. The
call to pari.getheap returns the same value
On Saturday, August 31, 2024 at 9:58:01 PM UTC+9 Michael Orlitzky wrote:
Why not do what everyone else does, and let developers merge PRs into
the "develop" branch when they're approved? Waiting only causes merge
conflicts.
As a middle gound, we may let the beta manager bot collect (merge
This is now fixed in cypari. The fix consisted of replacing gunclone by
gunclone_deep in the Gen.__dealloc__ method. The same change would
probably help in cypari2, although I would not expect it to fix the other
memory leaks reported in issue #112.
Here is the explanation. The Pari GEN retu
On Sun, Sep 1, 2024 at 7:38 AM Georgi Guninski wrote:
>
> >As well, with cypari, a call to pari.getheap() adds 1 object there, a
> bug, I guess.
> >(this does not happen with cypari2)
> >In [14]: pari.getheap()
> >Out[14]: [334, 163655741]
> >In [15]: pari.getheap()
> >Out[15]: [335, 16365
Unsurprisingly, changing gunclone to gunclone_deep in Gen.__dealloc__ is
not a full fix. It stops this leak but it also causes a crash when running
the doctests. On macOS the crash error is "freeing a pointer which was not
allocated". On linux the error is "corrupted size vs. prev_size in
fastbi
I would say that the getheap behavior is a symptom of the same memory
management bug(s). Also, it is not as simple as you suggest. It is not
always true that every call to getheap leaves something on the heap:
>>> from cypari import pari
>>> pari.getheap()
[4, 41]
>>> pari.getheap()
[5, 58]
>>
