#14711: Memleak when creating QuadraticField
-------------------------------------------------+-------------------------
Reporter: jpflori | Owner:
Type: defect | davidloeffler
Priority: critical | Status: new
Component: number fields | Milestone: sage-5.13
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 SimonKing):
Replying to [comment:69 nbruin]:
>
> Indeed, domain and codomain. So those callbacks are already taken care
of by `_coerce_from_hash` being a `MonoDict`. The codomain is actually not
relevant for this (and would be strongly referenced by the map anyway --
perhaps "weakened" maps should only have their domain reference weakened
and parent (reference to the homset) cleared? If we just always keep
codomain strongly referenced compositions would naturally keep things
alive guaranteed anyway. Virtually all maps have a strong ref to the
codomain (via generator images) internally anyway, so putting it
explicitly on the outside shouldn't hurt much.
This might actually be a good idea. Note that some wise person decided to
store coerce maps on the codomain. Hence, having a strong reference from
the map back to the codomain will not hurt at all, with the additional
advantage you just mentioned. It would also fix the problem with composed
maps ''and'' with `PrecomposedAction`!
> Do we really need `_coerce_from_list`? Have we identified what it does
that cannot be accomplished with the data stored in `_coerce_from_hash`?
I don't know why it had originally been introduced. But when I added the
weak versions of triple and mono dict, I actually thought of it as a way
to make some coercions (namely those explicitly registered) permanent.
> I doubt you could prove about such an incidental "bumping in" strategy
that the number of defunct maps is bounded linearly in the number of
active stuff (perhaps measured by active entries in `_coerce_from`?). That
means you wouldn't be able to prove that you don't have a memory leak, and
I suspect that with a little study, one could concoct an example that
exhibits the leak as well.
Sure. But the more you have to struggle to construct a leak, the more
happy I'll be... `:-P`
> Given how delicate this code is, please do put ample documentation about
assumptions and strategies in the code. Otherwise, the next person to work
on this code will likely screw things up. Hopefully it'll be cought by
doctests, but we've seen that this could easily not happen.
OK, I'll try to be explicit in either the comments in the code, or in the
docs.
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:71>
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.
