#12173: Update FLINT to 2.3
-------------------------------+--------------------------------------------
Reporter: mhansen | Owner: tbd
Type: enhancement | Status: new
Priority: major | Milestone: sage-5.1
Component: packages | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: #12433 | Stopgaps:
-------------------------------+--------------------------------------------
Comment (by jpflori):
Replying to [comment:48 fredrik.johansson]:
> The first Invalid read of size 8 is likely not a bug. On various
platforms, mpn_copyi relies on page boundaries being aligned to a multiple
of 16 bytes so that it can safely read an extra 8 bytes, IIRC. (This pops
up all over the place when valgrinding flint unit tests, and it's
convenient to add it to the valgrind suppression file.)
Thanks, I wasn't aware of that.
>
> The second one has to be what it looks like: some polynomial lives until
after _fmpz_cleanup has been called.
>
> So the question is how we can guarantee that all Python objects
referencing flint objects get deallocated before _fmpz_cleanup is called.
I tried to modify the __dealloc__ methods of all classes involving flint
polynomials and in the different files directly using them by first
checking that the pointer is not 0 before calling the clear function, but
it did not solve the problem.
So either I forgot some of them or my test was stupid (I just copied the
idea from the PARI's GEN class, I didn't actually think).
>
> If this is impossible, I guess we could compile flint in reentrant mode
for Sage (but this would slow things down, unfortunately).
Slowing down the library would not be that great.
As i mentioned earlier, jsut moving the call to _flint_cleanup within
quit_sage solves the problem, even though this is surely not the "right"
solution.
I'm not convinced compiling flint in reentrant mode would be although I
have no real knowledge of reentrancy.
>
> One possibility is that we change _fmpz_cleanup to free all mpz limb
data but leave the mpz array. This might still be a bit fragile, but if it
works, it should solve the problem of polluting valgrind logs since there
will only be one large block of unfreed memory.
>
> We must also have this problem with flint_compute_primes.
>
> Does Sage free the MPFR caches on exit, and if so where?
Deallocation is done by quit_sage() defined in
$SAGE_ROOT/devel/sage/sage/all.py
Different libraries are concerned, e.g. PARI, but MPFR is not.
Potentially, and if this was possible, this was just forgotten.
>
> Perhaps this should be brought to sage-devel.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12173#comment:50>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
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-trac?hl=en.
