#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 nbruin):
Replying to [comment:52 SimonKing]:
> In other words, you do think that we should distinguish between
underscore methods that are used internally in the coercion system and
just return the maps, and an "official" interface that returns strong
copies. Do I understand correctly?
Yes, with your approach the maps stored and used in the internals of the
coercion systems are not able to stay healthy on their own. They can only
survive within a controlled environment. So you cannot let those maps
escape into the wild (the royal society for prevention of cruelty to maps
would probably have you arrested). I don't see another solution than
making a version that is better prepared for the outside world.
> 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 would be quite painful to work with.
The natural way of constructing them would be to have a containing map
type with `_domain,_codomain,_parent` set appropriately, together with a
sequence of maps. Those maps would normally be normal, healthy maps with
their own strong references to their domains and codomains: a composition
would hence carry internally a strong reference to both its domain and
codomain (due to the first and last map in the sequence).
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.
You'd have to make a custom way of weakening this map. Would you weaken
the first and last map in the sequence? Then for a composition of two
maps, you'd have to separately keep a reference to the middle (co)domain.
Or would you have half-weakened maps as well, that only have a weaked
domain or codomain?
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) or you have to make a copy before weakening
it (if weakening is an in-place operation, as you proposed above), further
upping the cost of coercion discovery. Otherwise, registering a coercion
might have the side-effect of weakening a map that someone else is holding
already.
(these are the kind of snowballing complications I was afraid of by making
a separate type of map suitable for the coercion system)
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:53>
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.
