#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:40 SimonKing]:
> > The protocols required to correctly handle homsets and homomorphisms
without those strong references will be very painful.
>
> 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.
> If you have a homomorphism outside of the coercion framework, then the
domain and codomain will be kept alive, unless you call
`_make_weak_references()` on the map (which the user shouldn't do---it is
an underscore method after all).
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
}}}
Are you always going to return a copy of the morphism held in the coercion
framework with strong references to domain and codomain, and mandate that
the only supported interface is accessing the coercion maps via that
interface? You'd better check the current code base for compliance with
that specification. Especially: do all maps know how to create a copy of
themselves? Do map compositions know how to recurse into their components
for making copies and ensure that domain/codomain references are made
strong again?
> Problem: If this is a global object, then you will have a strong
reference to it, hence, you will have a strong reference to all the coerce
maps, and thus (at least when you have strong references to domain and
codomain) ''all'' parents that are ''ever'' involved in a coercion or
conversion ''either'' as domain or codomain will be immortal.
No, I said "fully weak", i.e., also with weak values. You already have one
of those global associative caches in the `Homset` constructor. (in fact,
that's the only use and the reason why `TripleDict` grew a
`weakvalues=true` parameter)
> By the way, in the branch that I am preparing there is still only
`_coerce_from`. As it has turned out, a `_coerce_to` is not needed.
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.
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?
Compare with now:
{{{
sage: a1=QQ.coerce_map_from(ZZ)
sage: a2=QQ.coerce_map_from(ZZ)
sage: b=sage.rings.rational.Z_to_Q()
sage: c=sage.rings.rational.Z_to_Q()
sage: [a1 is a2, a1 is b, b is c]
[True, False, False]
sage: [a1 == a2, a1 == b, b == c]
[True, False, False]
}}}
Your approach will have to break `a1 is a2`. How will you deal with
equality?
I think getting some of these references weak within the coercion
framework would be great. It should be a little more robust that a
`_coerce_to` and `_coerce_from` solution (except for maps that internally
end up keeping a strong reference to their domain; how do map compositions
fare in this respect?).
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:41>
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.
