#13447: Make libsingular multivariate polynomial rings collectable
----------------------------------------------------------------+-----------
Reporter: nbruin |
Owner:
Type: defect |
Status: needs_info
Priority: major |
Milestone: sage-5.4
Component: memleak |
Resolution:
Keywords: | Work
issues: Input from a libsingular expert
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):
Replying to [comment:53 SimonKing]:
> I am sure that it is not safe: One can't even call singular_ring_delete
on it. That's why I removed it, unless `currRing==NULL`.
I think that's because `singular_ring_delete` does a `changeCurrentRing`
on it. Calling `rDelete` seems to work just fine. I think that thanks to
the `init=1` the memory for the ring is allocated, but initialized to 0
thanks to the `omAlloc0`. My failure to locate a `ref = 1` anywhere in
Singular's code also makes me believe that they're happy giving back a
ring where `ref = 0`.
I'm not so sure the `rChangeCurrRing` dance is necessary in
`singular_ring_delete`. The code in `intrusive_ptr_release` doesn't need
it. I suspect Volker put it in as an extra precaution while he was trying
to debug other issues. A cursory reading of the code of `rDelete` doesn't
seem to indicate its operation is affected in any way by whether the
current ring is equal to the one being deleted.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13447#comment:55>
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.
