#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):

 Yes, we have run into these things repeatedly. We're storing maps as
 `_coerce_from` and `_convert_from` on the codomain because for those maps,
 the codomain needs the domain to exist anyway (a polynomial ring will be
 holding a reference to its coefficient ring, a quotient ring needs the
 ring it was quotiented from).

 This goes very wrong when we have maps into LARGER rings that exist
 independently. Indeed, as soon as you're coercing/converting/embedding a
 number field into Qbar, into SR, or into CC, your ring has been damned
 with virtually eternal life (SR is one ring to forever in the darkness
 bind them...).

 A nasty solution is to ALSO have _coerce_to and _convert_to, store each
 map in only one, and in the discovery process look on both the domain and
 the codomain. One can then choose whether the map should be cached on the
 domain or the codomain (depending on which one is expected to have the
 longer natural line). We'd end up mostly using the `_*_from` variants as
 we have now, but for things like QQbar etc. we'd choose the other one.

 This might reduce the number of times where we'll get a leak this way, but
 I suspect that it'll be possible to get strong reference cycles via this
 process nonetheless.

--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:28>
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.

Reply via email to