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

 Replying to [comment:31 SimonKing]:
 > Last idea, before I go to sleep:
 >
 > We could
 > - only have a ''weak'' reference to the values (here: a morphism, say,
 phi) of the `MonoDict` in `_convert_from_hash` (here:
 `CDF._convert_from_hash`),
 > - keep a strong reference from the morphism to the domain (here: from Q
 to phi)
 > - add a ''strong'' reference from the domain (Q) to the morphism (phi).
 >
 > Would this save us?
 >
 > We want that a strong reference [edit: I mean an external strong
 reference] to Q keeps phi alive. Well, it does, since we added a strong
 reference Q->phi.
 >
 > We want that phi can be collected, if no external strong reference to Q
 [edit: or to phi] exists. Well, there only are weak references from the
 `MonoDict` to phi and to Q. Hence, the only strong reference to phi comes
 from Q, and the only strong reference to Q comes from phi. This is a
 circle, that Python's cyclic garbage collector can deal with. Both Q and
 phi would be collected, and removed from the `MonoDict`.
 >
 > [edit:] And finally: An external strong reference to phi will keep Q
 alive, since we have a strong reference from phi to its domain Q.
 >
 That would suit as well I guess and sounds kind of like the coerce_to
 solution nils suggested.
 If we go this way, I guess we should do the same for actions.

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