#14711: Memleak when creating QuadraticField
-------------------------------------+-------------------------------------
Reporter: jpflori | Owner: davidloeffler
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-5.13
Component: number fields | Resolution:
Keywords: memleak, number | Merged in:
field, QuadraticField | Reviewers:
Authors: Simon King | Work issues:
Report Upstream: N/A | Commit:
Branch: | 05fb569cb132a8c89713021f1f4b25cd2dd7cb1c
u/SimonKing/ticket/14711 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:100 SimonKing]:
Good, I think we at least are in sufficient agreement for the practical
implications of what we need.
> Let me try to summarise what is (or may be) left to do:
>
> - Add a section explaining the current weak coercion model, to
facilitate maintenance,
> - Add `_install_coerce_map_from()`.
To clarify this point (and it might be helpful to put something along
these lines in the documentation), it seems to me there would be 4 ways to
put coercions in place:
- A programmatic way, by supplying code in `_coerce_map_from_`. Since
it's programmatic, it seems it can be rediscovered easily when parents get
garbage collected and recreated, so it seems appropriate maps stemming
from here do not lead to lifetime implications.
- A way to put a coercion in that ensures that the codomain keeps the
domain alive (`.register_coercion`)
- A way to put a coercion in that ensures that the domain keeps the
codomain alive (`register_embedding` does that, but only can only
accommodate one per domain)
- A way to put a coercion in that does not imply any life support between
domain and codomain. Someone who starts out should probably not use this,
because garbage collection can lead to surprising results. It may be
required to avoid memory problems.
I think the fourth point is desirable because the alternative,
programmatic solutions via `_coerce_map_from_`, feel much more heavy-
weight (subclassing a whole parent just to extend `_coerce_map_from_` may
be appropriate for someone who is concerned with developing sage, but
seems inappropriate to me for someone who is thinking about using sage to
do a complicated computation.
> - Perhaps: Let the string representation of a weakened map consist of a
warning to not use this map outside of the coercion framework.
I think yes: Due to cyclic references, parents will usually survive until
the next GC, which may be quite a while after the last reference is lost.
So place where the map becomes liable to turn defunct may be quite distant
from the place where the map if found to be defunct. People deserve a
reminder about that.
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:103>
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.
