#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:42 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.
No, also for the map, if I understand your proposal correctly. If I keep a
reference to just a map, I'd expect it to keep the domain and codomain
alive as well (i.e., the semantics of a map with
`_make_strong_references`; the only type of map that should be allowed to
escape into the wild).
> 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.
But that responsibility would fall back onto the homset once the last
reference to a map has been lost. You wouldn't know when that would
happen. Do the maps in the coercion framework really need a Homset?
Perhaps you can just leave that blank if you have `_use_weak_references`.
> 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.
That leaves you with a memory leak again: After asking for a `coerce_map`,
the map stored in the coercion framework now has strong references again,
even after I discard my requested `coerce_map`.
> > 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.
Yes, that's why one still needs the strong references in `_coerce_from` or
`_coerce_to`. It just unlinks the responsibility of keeping the map alive
from the ability to find it, given domain and codomain. If you can make
your idea work, you won't need it. But I'll keep my sceptical position for
now (either justified or for the sake of constructive argument, we'll
see).
> Again, I am not talking about "returning copies".
And that's where you'll get big trouble from. If you're going to return
strong versions of maps stored in the coercion system, you have to make
those copies. Otherwise, there's nothing that tracks the lifetimes
properly.
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:43>
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.
