#14711: Memleak when creating QuadraticField
-------------------------------------------------+-------------------------
Reporter: jpflori | Owner:
Type: defect | davidloeffler
Priority: critical | Status: new
Component: number fields | Milestone: sage-5.12
Keywords: memleak, number field, | Resolution:
QuadraticField | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: u/SimonKing/ticket/14711 | Commit:
Dependencies: | Stopgaps:
-------------------------------------------------+-------------------------
Comment (by SimonKing):
Replying to [comment:53 nbruin]:
> > Concerning compositions, I agree that the parent in the middle should
be kept alive by the composed map (even if this map is in the coercion
system, hence, domain and codomain are only weakly referenced): If the
composed map is kept in memory, then we need to be able to apply the
composition, and hence the "man in the middle" needs to be available.
>
> Yes, you are correct. You might want to check if compositions do tend to
occur in the coercion system.
They do frequently occur, because coercions are found by some kind of
backtracking algorithm. But, somehow surprisingly, I don't got the
impression that the crashes I am observing come from this.
Anyway, I agree that one should have a strong reference in the middle.
> The generic way of making a "weak" version of a map would still lead to
a map that (internally) keeps strong references to domain and codomain.
No. You would have weak reference to the domain and codomain, but a strong
reference to the middle. A `FormalCompositeMap`, by the way, stores two
maps `__first` and `__second`, and in my current experimental code I
simply make `__first.codomain` a constant function (if it isn't already).
It ''could'' in principle mean that the composite map gets deallocated,
while `__first` stays somewhere else in the coercion system, and now keeps
a parent (namely the middle one) alive that may be collectable. I'll worry
about it later...
> That makes me realize a further complication: the copying probably has
to happen both ways.
> Before you prepare a map to become part of the coercion system, you'd
have to make sure that the map you're holding is not referenced by anyone
outside. Thus, you'd have to make sure that either the origin of the map
is guaranteed (it's not a map that is referenced elsewhere--I think this
will be impossible to verify in practice, since users can register
arbitrary maps as coercions)
I think the (unwritten, I am afraid) contract is that
`register_coercion()` is only called in `__init__`. So, perhaps it should
rather be `_register_coercion()`, to remove it from the user interface.
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:54>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
