#13447: Make libsingular multivariate polynomial rings collectable
----------------------------------------------------------------+-----------
Reporter: nbruin |
Owner:
Type: defect |
Status: needs_review
Priority: major |
Milestone: sage-5.4
Component: memleak |
Resolution:
Keywords: | Work
issues:
Report Upstream: None of the above - read trac for reasoning. |
Reviewers: Simon King
Authors: Nils Bruin, Simon King | Merged
in:
Dependencies: #11521 |
Stopgaps:
----------------------------------------------------------------+-----------
Comment (by SimonKing):
Replying to [comment:64 nbruin]:
> Replying to [comment:57 SimonKing]:
> > Singular uses `r->ref` only in `rKill` - it makes me wonder why we use
`rDelete` and not `rKill`, by the way. In fact, `rKill` deletes local
data, but `rDelete` doesn't.
>
> If we do that, we should ensure that `rKill` has an accurate view of the
number of references. That means adjusting to Singular's conventions. If
we rKill with our current code, we'd leak because we'd call with a
positive refcount.
No, we don't. With the current patch, `rKill` is ''only'' called if
ref==0.
> > '''Conclusions'''
> > Since `r->ref` does not play a rôle in libsingular, we are free to use
`r->ref` to count the number of pointers to r (not "number of pointers
minus one"). However, when calling singular interpreter functions, we must
make sure that `r->ref>0`. With our patch, we already do so - hence,
that's fine.
>
> In principle yes, but not if we use rKill
I disagree, since we only call rKill with `r->ref==0`.
> and I think it's a bad idea in general because it might cause unforeseen
problems in the future. Better to stick with one interpretation of what
the `ref` field means.
In a way, we do. Namely, one could argue that a Sage polynomial ring
`MPolynomialRing_libsingular` is an interpreter variable (roughly, it is
an object that does not live in the Singular kernel but points to a ring
in the Singular kernel). Hence, when creating a polynomial ring, it agrees
with Singular's conventions to increase the refcount.
> As you indicate, currRingHdl can be NULLed again by rKill. We need to
correct that if we need currRingHdl later.
`currRingHdl` is only NULLed if `currRing` is deleted. So, that should be
fine.
> In any case, rKill just does a straight `currRingHdl=NULL` if
`(r==currRing)`, so `currRingHdl` is definitely gone.
You mean, it doesn't free it before assigning `NULL`? Yes, that would seem
to be a leak.
> Is it really necessary to use `rKill`? It seems it is more part of the
interpreter layer and that the libsingular interface itself is largely one
level lower.
I'll try `rKill` versus `rDelete` in `singular_ring_delete` and will try
to see if there is a leak when creating and deleting super commutative
rings (SCA).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13447#comment:65>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
