#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):
Hi Nils,
Replying to [comment:41 nbruin]:
> Replying to [comment:40 SimonKing]:
> > No idea what you are talking about here. "Protocol" in the sense of
"interface"?
>
> Protocol as in "how to use the interface properly". In this case the
protocol would include: keep strong references to domain and codomain for
as long as you're keeping a reference to the the map.
You mean: Of the homset. If you create a map, then it's fine.
Admittedly, I am not totally happy with letting Hom be with weak
references from the very beginning. What I could imagine, though: Let it
be strong in the beginning; but change `Homset.__call__` so that it first
replaces the strong by a weak reference ''in the homset''. Namely, maps
(i.e., the things returned by `__call__`!) will then have the burden to
carry strong references to domain and codomain.
> The problem is, homomorphisms constructed by the coercion framework
might leak into user space:
> {{{
> sage: QQ.coerce_map_from(ZZ)
> Natural morphism:
> From: Integer Ring
> To: Rational Field
> }}}
Correct.
What about renaming `coerce_map_from()` into `_cm_coerce_map_from()`? It
would not be part of the official interface (since it is an underscore
method) and hence is entitled to return something that only makes sense
when used within the coercion model. We could then define
{{{
#!python
def coerce_map_from(self, P):
phi = self._cm_coerce_map_from(P)
if phi is None:
return
phi._make_strong_references()
return phi
}}}
returning a map with strengthened references (note: I am not speaking
about a copy). So, this would be the "official" way to get a "safe" map
from an unsafe internally used coercion.
> No, I said "fully weak", i.e., also with weak values. You already have
one of those global associative caches in the `Homset` constructor.
I see. Hmmm. There is one important difference to Homsets: If you only
store weak references to the coerce maps, then what would prevent them
from being immediately garbage collected? In the case of Homsets, it is
the elements that prevents them from being garbage collected. Hence,
having a fully weak cache does make sense.
> Indeed, if you can make you idea work. But I think it needs some pretty
invasive changes in how one can extract and use maps found by the coercion
framework.
I don't think so, if one separates the internally used methods from the
interface.
> Your idea would mean we'd have multiple versions of maps around, some
with weak references (which shouldn't leave the coercion framework) and
some with strong references. Which should be equal? which should be
identical?
Again, I am not talking about "returning copies".
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:42>
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.
