#13447: Make libsingular multivariate polynomial rings collectable
----------------------------------------------------------------+-----------
Reporter: nbruin |
Owner:
Type: defect |
Status: needs_work
Priority: major |
Milestone: sage-5.4
Component: memleak |
Resolution:
Keywords: | Work
issues: Understand why sometimes `new_RingWrap` needs an incref and sometimes
not
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 nbruin):
> However, not all is good. Namely, we interrupt the computation above,
and continue as follows:
> {{{
> sage: from sage.libs.singular.function import singular_function
> sage: P.<x,y,z> = PolynomialRing(QQ)
> sage: ringlist = singular_function("ringlist")
> sage: l = ringlist(P)
> // ** redefining my_awesome_sage_ring **
> }}}
I think what your code does, is look up if there is a Singular variable
that points to `currRing`. If so, you use that one and you let the sage
variable `my_awesome_sage_ring` dangling in the system. If you don't find
a Singular variable pointing to `currRing` then you (re)create the
variable `my_awesome_ring` to refer to `currRing`. But it could be that
that variable is alive and well, happily pointing at some other ring (that
once was `currRing`). I think the system probably has good reason to
complain.
What you should probably do is create `my_awesome_sage_ring`, keep a
pointer to it, and refcount rings that you let it point to. Now you're
simply holding a singular variable reference to a ring. When you need
`currRingHdl` to point somewhere, you can do that via
`my_awesome_sage_ring`. If you need to NULL `currRingHdl`, you can do so
without consequence. You still keep your own pointer to
`my_awesome_sage_ring`.
It means that the ring pointed to by `my_awesome_sage_ring` is protected
against garbage collection, but that's correct: We're holding a reference
to it! Such rings will become eligible for deletion once
`my_awesome_sage_ring` is made to point elsewhere. If you don't like rings
that were `currRing` to survive until `currRingHdl` is actually needed to
point elsewhere, you could NULL the `data.uring` field of
`my_awesome_sage_ring` as soon as you get a chance, but I wouldn't bother.
I haven't traced through your precise usage, but grabbing and dropping
Singular variables without adapting reference counts sounds fishy to me
and liable to lead to segfault.
I'm pretty sure `currRingHdl` is just a Singular Interpreter level entry
to `currRing` and probably in the singular interpreter, the current ring
is always only a ring that actually has a name in the interpreter, so
`currRingHdl` is simply a borrowed reference to that variable. That's why
`currRingHdl` manipulations in singular do not involve refcounting (I
haven't checked, but it seems to me you claim they don't): The rings
themselves are refcounted, but that has already happened when the handle
struct that `currRingHdl` is pointing at was instantiated. That struct is
surving independent of `currRingHdl` because it represents a variable
binding in the singular interpreter and therefore is probably indexed in
some tree, linked list or hash table (i.e., the index that `rFindHdl` goes
digging in).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13447#comment:76>
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.
